Notice that Cisco ISE and NDP are two separate entities. These are actually separate software processes that are run on either dedicated hardware, or on virtual machines. In each case, each one serves a very specific purpose:
ISE is a security policy management platform that enables organizations to enforce security policies across their network infrastructure. This includes things like Network Access Control, Authentication and Authorization, Endpoint Compliance, Device Profiling, Security Intelligence Integration, and Policy Enforcement Across Wired, Wireless, and VPN. ISE can be used as a standalone solution, but or it can be integrated with DNA Center, where the policies defined in DNA can then be enforced by ISE. More about ISE can be found here.
Cisco Network Data Platform or NDP is a multipurpose real-time network data collection and analytics engine used to significantly increase the business potential of network data. It is essentially an analysis tool that âingestsâ a multitude of logging and monitoring info and does data correlation analysis, visualization, and action through a whole series of APIs connected to the DNA system.
Now the provision and assurance sections, as they are described, are actually parts of the DNA center dashboard. The provision section essentially lists the network devices that are âregisteredâ to the DNA center and are configured and prepared to receive commands and to be controlled by the DNA center. The assurance section essentially gives you an overview of the network where you can view various aspects and vitals. You donât control anything there, you only view. Does that make sense?
I believe that the only way to be able to further and more deeply understand the various concepts and their inner workings is to gain hands-on experience with these systems. You can do a bit more reading about each one, but nothing can replace the benefit of real hands-on experience.
I am very early onto SD-Access so I just need to know the basics.
These Fabric Edge Node switches have certain VLANs and subnets configured. We have a control plane node deployed somewhere in the network that is responsible for mapping to which edge node is which client connected to, correct?
Assume that we have 3 switches.
If the first switch has a client that wants to talk to someone, say to a host in the same VLAN connected to the second switch, it will reach out to the control plane node. The control plane node will check its mapping and tell SW1 that it needs to send the data to SW2 to reach it.
My question is, what if a host connected to SW1 wants to talk to someone who isnât in the same subnet? The VXLAN tunnels are there to maintain L2 connectivity, what if we really need L3 this time and actually route the traffic? What will the edge node do, still ask the control plane node for mapping information, or?
Let me indicate step by step the process of what happens when a host wants to talk to another host outside its subnet:
Host-A sends traffic to a different subnet. This is a classic case of inter-VLAN routing.
The default gateway of Host-A is the local Fabric Edge Node itself. In SD-Access, each Fabric Edge acts as the gateway, and this is typically done using Anycast Gateway MAC/IP.
The Edge Node performs local SVI-based routing. It checks its VRF table. Determines the destination subnet.
Now, the destination IP is not locally connected, so it queries the Control Plane Node asking: âDo you know where this destination IP lives?â
If the Control Plane Node replies with a location (e.g., itâs on SW2), then SW1 encapsulates the already routed packet in VXLAN and sends it to SW2. This is VXLAN routed traffic, not bridged traffic.
If the destination is outside the fabric entirely, then the Border Node is the exit point to external networks. SW1 will forward the packet to the appropriate Fabric Border Node based on the routing table.
Great, thank you! I have two more simple questions.
I understand that when deploying SD-Access, we have the option to fully automate the underlay which means that our Cisco DNA Controller will configure it by using the LAN Automation feature. From what I understand, this creates a L3 routed design with IS-IS deployed as the routing protocol.
Why exactly is IS-IS used with SD-Access? I see this protocol used very often with it.
Another thing that my book mentions is that Cisco Plug and Play is used to deploy and configure the devices. What exactly should I imagine under plug and play? That once devices are connected, they will go ahead and communicate with the controller and download their configuration without any user intervention?
Both OSPF and IS-IS are protocols that are often levereaged as underlay routing protocols for various technologies including MPLS, VXLAN, and yes, SD-Access. Both are suitable, but IS-IS tends to have the edge as far as preference goes. It is slightly more preferred, letâs say. There are several reasons for this:
It is scalable and simple. IS-IS is a lightweight, link-state protocol designed for large-scale networks. Unlike OSPF, it doesnât require hierarchical area configuration (though it supports levels), simplifying deployment in automated scenarios.
It directly maps to Layer 2 MAC addresses for adjacency formation, so it doesnât rely on the network layer (IPv4 or IPv6) for its messages between routers during initial setup. This also matches up well with SD-Accessâs goal of abstracting the underlay from overlay policies.
IS-IS is protocol agnostic. SD-Access uses an overlay (VXLAN) for policy enforcement, decoupling it from the underlying routing protocol. IS-IS ensures a stable, efficient underlay without adding complexity to the overlay.
Cisco recommends IS-IS for SD-Access because it supports efficient LAN Automation workflows. Features like multi-topology routing (MTR) allow parallel underlay/overlay operations, critical for SD-Access fabric roles (Border, Control Plane, Edge nodes).
The Cisco Network Plug and Play solution provides a simple, secure, unified, and integrated offering for enterprise network customers to ease new branch or campus device rollouts or for provisioning updates to an existing network. The solution provides a unified approach to provision enterprise networks comprised of Cisco routers, switches, and wireless devices with a near zero touch deployment experience.
It reduces the burden on enterprises by greatly simplifying the process of deploying new devices. An installer at the site can deploy a new device without any CLI knowledge, while a network administrator centrally manages device configuration.
So it is a mechanism that helps simplify the process of deploying new devices. You can take a look at the linked document which describes Ciscoâs PnP solution more fully.
