Introduction to SD-Access

Lessons Discussion
21

Hello Juan

Let me try to elaborate on all of these. First, take a look at the diagram Rene shared in the lesson once again:

image
image895×518 44 KB

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 hope this has been helpful!

Laz

22

Yes, i need real experience on this.

i’ll explore developer.cisco.com for some DNA lab.

1 Like
23

Hello Laz,

Link does not work anymore.

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-2810.pdf

Best regards,
Michel

24

Hello Michel

Yes, unfortunately, some links do go out of date. I did a search for the PDF document and found this:

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKCRS-2810.pdf

Take a look at slide 41 and on to see how LISP plays a role in the control plane.

I hope this has been helpful!

Laz

25

Thank you Laz,

Best regards,
Michel

1 Like
26

Hi, everyone.

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?

Thank you.
David

27

Hello David

Let me indicate step by step the process of what happens when a host wants to talk to another host outside its subnet:

  1. Host-A sends traffic to a different subnet. This is a classic case of inter-VLAN routing.
  2. 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.
  3. The Edge Node performs local SVI-based routing. It checks its VRF table. Determines the destination subnet.
  4. Now, the destination IP is not locally connected, so it queries the Control Plane Node asking: “Do you know where this destination IP lives?”
  5. 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.
  6. 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.

I hope this has been helpful!

Laz

28

Hi Laz.

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?

Thank you.
David

29

Hello David

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).

According to this Cisco documentation:

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.

I hope this has been helpful!

Laz

30

Hello, everyone.

What exactly is a Fusion router? I understand that inside the SDA fabric, we could have many different kinds of VRFs.

Is the Fusion’s router job to (for example) connect somewhere where shared services reside (DHCP, DNS, SNMP and so on) which are either gonna be in their own VRF or in the global VRF and provide some form of… route leaking/communication between the shared services and the fabric?

Thank you.
David

31

Hello David

It seems that you’ve got the basic understanding of what a fusion router, or a fusion device in an SD-Access (SDA) topology, actually does.

Just to clarify, it is used to interconnect the SDA fabric with external networks or services outside of the fabric domain. It acts as a bridge between the SDA fabric’s overlay virtual network and traditional L3 networks. In that context, it does indeed enable inter-VRF communication, providing route leaking between internal and external VRFs. And it does allow for shared services to be used by multiple virtual networks in order to eliminate the inefficient duplication of such services.

Note that the fusion router is typically positioned at or just outside the fabric border. It may be the same physical device as an SDA border node or a separate dedicated router/switch, depending on design requirements.

More detailed info can be found here:

I hope this has been helpful!

Laz

32

Hello Laz,

I have several questions regarding on how traffic would flow within a SDA fabric.

  1. How does a fabric edge node switch forward unicast traffic between hosts on the same VLAN and edge node? Traditionally, the hosts would see that they are on the same subnet, and would just ARP for eachothers MAC addresses and start sending frames to eachother. The switch would just be using the MAC address table to forward these frames between the hosts on the same VLAN. In a SDA environment, is the MAC address table still involved at all in this scenario?

  2. Assume the same question as above, but instead of unicast traffic, lets consider multicast traffic. Would Layer 2 mechanisms such as IGMP snooping and a querier still be needed in order to prevent multicast traffic from being flooded within this specific VLAN? Would the mrouter port still play the same role in ensuring that the IGMP snooping mechanism works properly for a specific VLAN in preventing the flooding of multicast traffic?

Thank You Laz

33

Hello Paul

These are great questions, and they help in understanding how SD-Access works. Let me try to unpack how the SDA fabric behaves, with the key differences from a classic VLAN-based campus.

  1. For unicast between two hosts on the same VLAN and attached to the same Fabric Edge
  • Host discovery: The edge learns the host’s MAC on the access port like a normal switch and gleans the IP. It registers IP/MAC/VN to the control-plane.
  • ARP handling: The edge uses ARP suppression. It will answer ARP locally (it knows connected endpoints, and it can also query the control-plane for remote ones). Local-proxy-ARP is used so you don’t see broadcast ARP storms.
  • Forwarding: Because both hosts are on the same edge, the traffic stays on that edge. The packet is typically L3-switched at the Anycast SVI (ingress routing) rather than bridged across a campus VLAN. No VXLAN encapsulation is needed for local traffic.
  • Is the MAC table used? Yes. The MAC address table is still used by the switch’s ASIC to perform the final L2 forwarding lookup to determine the correct physical egress port for the frame. The difference is how the switch learned the information. Instead of learning via flooding, it learned via the LISP control plane interaction (for location) and local host communication (for port mapping).
  1. For multicast within that same VLAN on a single edge node (sender and receivers on the same VLAN and same edge)
  • IGMP snooping: Still used and still valuable. It constrains delivery to the interested access ports on that switch.
  • IGMP querier: You still need a querier so snooping entries don’t age out. In SDA L3 VNs, the edge’s Anycast SVI for that VLAN typically acts as the IGMP querier (DNA Center provisions this), so you don’t need an external mrouter to keep the snooping state.
  • mrouter port: Functionally, the SVI on that same edge is the multicast router interface for snooping purposes. You’re not relying on an uplink mrouter port to the core/aggregation.

So to summarize:

  • Yes, the MAC table is still used on fabric edges for local egress to hosts. What changes is that SDA avoids fabric-wide L2 flooding; ARPis suppressed and lookups are control-plane driven.
  • In the default SDA L3 VN, even “same subnet” traffic is routed at the Anycast gateway on the edge. If both endpoints are on the same edge, it stays local. If remote, it’s VXLAN tunneled, there’s no campus-wide L2.
  • IGMP snooping remains relevant per-edge to constrain multicast on access ports. A querier is still required. In L3 VNs the edge SVI fills that role.

I hope this has been helpful!

Laz

34

Thank You Laz!

Some follow up questions that I have, specifically related to how multicast traffic is handled on a SDA environment:

Consider the following two scenarios:

Scenario 1:

Within a single fabric edge node switch, assume we have a single VLAN with some multicast sources that are transmitting several multicast streams to other multicast receivers on this same VLAN and edge node. For this specific VLAN, IGMP snooping is enabled, as well as immediate leave. The IGMP snooping querier command is also applied globally on this edge node. For this VLAN SVI on the edge node, assume there’s a basic SDA config applied to it, for example, the SVI has a anycast Layer 3 gateway configured, the SVI is on some VRF/VN, the SVI has some IP address and subnet mask configured, etc. In this scenario, the SVI does not have any PIM configurations applied to it, so that the IGMP snooping querier global command enables the snooping querier for this VLAN on this edge node. Finally, lets take into account that this edge node has a layer 3 link to the intermediate border node that comprises the underlay.

Scenario 2:

Same exact configuration described in scenario 1, except this time we don’t run the IGMP snooping querier global command on this edge node. Instead, we configure PIM on the VLAN SVI, IP PIM Passive mode as an example. Also on the SVI, we configure IGMP version 2.

Taking the two scenarios into consideration, I have the following questions:

  1. When the multicast sources on the VLAN mentioned above begin to transmit multicast traffic, given the configurations mentioned, is there any fundamental difference on how the two scenarios would treat multicast traffic within this same VLAN and edge node? My understanding is that both configurations will ensure that multicast traffic from the sources is only forwarded out of switchports that received IGMP membership reports for the streams that the sources are transmitting. In both scenarios, snooping is enabled, and there is a querier enabled for this VLAN either through the snooping querier command, or by enabling multicast routing and letting the SVI generate the IGMP general queries for this VLAN. Also, as you mentioned on the previous response, the edge node itself would not have an mrouter port, since it is the snooping querier in scenario 1, or the multicast router in scenario 2. Therefore, this specific VLAN will not have an mrouter port, but given the configurations, our multicast traffic within this VLAN should not be flooded, and the IGMP snooping mechanism should function properly.

  2. Assume that the multicast sources and receivers are on the same VLAN/subnet, but on different edge node switches. Under this scenario, my understanding is that we would encapsulate the multicast frames from the source with a VxLAN header and tunnel those frames across the fabric to the other edge node. I also assume in this scenario the edge node with the multicast source has to consult the control plane node’s mapping system to find out which edge node it needs to send the traffic to. Does this involve some type of Layer 2 LISP function? Does the VLAN SVI on the edge node switches that have the sources and receivers need anything specific configured on them in order for this to work? My understanding is that for the SVIs for this specific VLAN across both edge nodes would be configured with the same anycast layer 3 gateway, IP address and subnet mask, VRF/VN.

Thank You Laz

35

Hello Paul

Your fundamental understanding here is correct in both scenarios you described. For multicast traffic where the source and receivers are on the same VLAN and connected to the same fabric edge node, both scenarios will result in the same functional outcome: IGMP snooping will work correctly, and multicast traffic will be pruned, not flooded.

The key is that IGMP snooping requires an IGMP Querier on the VLAN to solicit membership reports from hosts. Both of your scenarios accomplish this, but through different mechanisms. So, what’s a fundamental difference?

The difference is design intent and architectural alignment. In an SD-Access fabric, the SVI on the edge node is the default gateway and the Layer 3 boundary for the endpoints. Therefore, enabling multicast routing capabilities (PIM) on this SVI is the architecturally correct and standard method. This is how Cisco DNA Center automates the configuration. It aligns the edge node with its role in the larger fabric-wide multicast design. The igmp snooping querier command is a fallback feature used when no other solution is available. It is a legacy tool for L2-only domains and is not part of the standard SDA deployment model. More about it can be found in this lesson:

Keep in mind that the issue between the use of an mrouter port or an igmp querier is largerly independent from SDA. It is only involved with SDA as far as the automatic configuration of the multicast routing by Cisco DNA Center.

Now, concerning your second question, you are absolutely on the right track here as well. When sources and receivers are on different edge nodes, the SD-Access fabric must transport the traffic between them.

For encapsulation and transport, the data plane uses VXLAN. The source edge node receives the multicast frame, encapsulates it within a VXLAN header, and sends it across the underlay IP network to the destination edge node. The key, however, is that it’s typically not a native multicast flood in the underlay. Instead, the source edge node performs head-end replication. It creates a unicast VXLAN-encapsulated copy of the packet for each remote edge node that has an interested receiver.

The most critical part is the control plane’s mechanisms for finding the receivers. The source edge node must consult the control plane to learn which other edge nodes need the traffic. You mentioned a “Layer 2 LISP function.” In the original SD-Access architecture, the LISP control plane was extended to handle multicast group registration. Edge nodes with listeners would register their interest for a given multicast group with the control plane nodes (Map Server/Resolver). The source edge node would then query the control plane to get a list of all interested RLOCs (the loopback IPs of the egress edge nodes) and perform head-end replication to that list.

However, the modern and current standard for SDA uses BGP EVPN as the control plane for this function. It is more scalable and standards-based. For this inter-edge communication to work, a specific configuration is indeed required on the SVI, and it’s the piece that bridges local IGMP with the fabric’s BGP EVPN control plane.

In addition to the standard SDA Anycast Gateway configuration, Cisco DNA Center will automatically configure ip pim sparse-mode (or a similar PIM mode) on the SVI. This PIM configuration is the trigger that instructs the edge node to:

  • Listen for local IGMP reports.
  • Translate those reports into BGP EVPN routes and advertise them to the fabric.

Without PIM enabled on the SVI, the edge node would only handle multicast locally (as in your first question) and would have no mechanism to signal receiver interest to the rest of the fabric.

I hope that all makes sense! It’s really great to be able to look at the intricate details of operation of SDA and the related and underlying technologies.

I hope this has been helpful!

Laz