SD-Access Flows: Registration and Same Fabric Forwarding

This blog is part of a series covering various SD-Access topics.

Previous blogs in this series:

This blog and the next two are about SD-Access (“SDA”) traffic and control flows.

My target in these is a moderate depth, i.e., a level of detail you might remember when you need to, or that you might revisit quickly. These blogs will be mostly diagrams with accompanying text. From a blogging point of view, that’s recovering some time since diagrams are a lot more work than words.

Definitely, you should check out the referenced CiscoLive presentations if you wish to supplement the amount of detail below.

Why?

SD-Access uses a lot of sophisticated technology, including but not limited to BGP, LISP, IP multicast, and VXLAN tunnels.

The good news for SD-Access is that you don’t necessarily need to understand all the details to make it work and even troubleshoot it to some degree.

As an example, for routing your IS-IS or OSPF and BGP, you need to be able to diagnose when and where the routing is not working via show ip <protocol> neighbor or show ip <protocol> interface. Ditto BFD and PIM.

Plus, the usual show interface and CDP/LLCP commands for checking links are working.

Just these basics solve a lot of problems. Note that misconfiguration is very unlikely to be the problem unless you deleted or added something manually. Solution: don’t mess with SDA LISP and BGP configuration, DNAC will get upset with you!

For LISP, you need to understand that LISP tracks which IP addresses are where (like other routing protocols) and caches what address to tunnel to get to a given IP. Yes, it could be useful or desirable to know more, but the basics will get you a long way. If you know that, you can look up LISP show commands and start making sense of them.

For SD-Access, it is fairly useful to have a high-level understanding of how the Edge Nodes (ENs), aka Fabric Edges (FEs), interact with the Border Nodes (BNs), Control Nodes (CNs), and Transit Control Nodes (TCNs).

Knowing the service that each of these is responsible for can be helpful in troubleshooting! For instance, which device’s routing or LISP to check. You do want to know who (what) to blame, don’t you?

Context

The context for this blog is a single SD-Access fabric site.

Topics:

What flows enable L2 and L3 forwarding within a site?
How does forwarding across the fabric work?

Fabric Registration

Suppose a wired host is powered up and connects to the fabric.

A routed Ethernet network needs to learn what MAC address is on each L2 switch port and which L3 IP address is associated with that MAC address.

What happens with SD-Access?

The following diagram shows the initial wired registration sequence for SD-Access. This is the process by which SDA tracks what is where. The necessary addition to IP, MAC, VLAN is the SG security group and the VTEP information. VTEP = VXLAN Tunnel Endpoint = what switch to tunnel traffic to, for delivery to that IP / MAC (computer).

The following diagram provides an overview of the flows involved for a wired host.

Wireless is a little more complicated because the wireless controller (WLC) handles the AP at Layer 2 (SGT and VLAN, in particular). That means that in SD-Access, the WLC is responsible for informing the Control Node (CN) about the new client. The CN then updates the EN. It does DHCP snooping to learn MAC and IP and registers them with the CN.

The following diagram shows these steps (flows).

Same Fabric Flows

Now suppose we have two devices or hosts, say Host A and Host B, connected to two of the EN edge node switches. Suppose they are in the same VLAN.

Suppose A needs to ping or otherwise send traffic to B. What happens?

The following diagram shows what happens “under the hood.”

The short version is that A’s EN has to find out what EN switch host B is connected to (its “VTEP,” VXLAN Tunnel Endpoint). Once it knows that, it VXLAN tunnels the traffic to B’s VTEP.

Not shown: before step 7, the reply, host B’s EN switch might have to contact the CN if it does not have cached VTEP information for host A.

Let’s look at something a bit more challenging: when A and B are in different VLANs (within the same VRF or VN), the process is similar but a little different. The following diagram summarizes that.

Caution: This is not a usual case. With DNAC-deployed SD-Access, VLANs are typically associated with a whole VN and not just an SG.

So if A and B are in different VNs, the above diagram does not apply.

VNs are based on routing VRFs. Traffic between VNs typically has to go via a fusion router or fusion firewall.

For IP Transit, the traffic would have to be routed out to a fusion router, then back in the other VRF. That assumes routing eventually gets you to a router or firewall that forwards between the source and target VNs (VRFs).

In such a case, tunneling from EN to BN and BN to EN within the source and destination site(s) in question would also be involved.

My later blog with coverage of the flows for SD-Access Transit will suggest how it all works for SD-Access Transit.

Exercise for the reader: diagram this!