FEATUREDApplication Development & Modernization
PETER WELCHER | Solutions Architect
This blog is part of a series covering various SD-Access topics.
Previous blogs in this series include:
This blog and the following two SDA blogs are about SD-Access (“SDA”) traffic and control flows.
This blog discusses this topic in 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.
You should definitely check out the referenced Cisco Live presentations if you wish to supplement the details 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 or even troubleshoot it to some degree.
For example, for routing you are using 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 by using CCC, misconfiguration is very unlikely to be the problem (unless you deleted or added something manually).
Solution: don’t manually mess with the SDA LISP and BGP configuration, CCC 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 in order to deliver traffic 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 try various 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 (EN’s), aka Fabric Edges (FE’s), interact with the Border Nodes (BN’s), Control Nodes (CN’s), and Transit Control Nodes (TCN’s).
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 revolves around a single SD-Access fabric site. Subsequent blogs will deal with multi-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). This 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, A’s EN 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 CCC-deployed SD-Access, VLANs are typically associated with a whole VN and not just an SG.
So, if A and B are in different VN’s, the above diagram does not apply.
VN’s are based on routing VRF’s. Traffic between VN’s 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 VN’s (VRF’s).
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 discussing the coverage of the flows for SD-Access Transit will suggest how it all works for SD-Access Transit.
Exercise for the reader: diagram this!
References
