This blog is part of a series covering various SD-Access topics.
Previous blogs in this series:
- What Is SD-Access and Why Do I Care?
- Navigating Around SD-Access
- Managing SD-Access Segmentation
- Securing SD-Access Traffic
- SD-Access Single-Site Design
- SD-Access Multi-Site Design
- SD-Access Multi-Site Lab
- SD-Access Multi-Site Lab Tasks
- SD-Access IP Pools
- SD-Access and e911 Services
- Migration to SD-Access
- SD-Access and Wireless
- SD-Access Study Resources
- SD-Access and Internet of Things
- SD-Access: SD-Access Flows: Registration and Same Fabric Forwarding
The previous blog covered multi-site flows where the sites are connected via IP Transit, either just using global routing or with ubiquitous VRFs throughout the transit core.
We now move on to the case where the core is based on the SD-Access Transit core. Recall that the SDA Transit approach is more elegant in that it uses tunnels across an IP core, which saves you from having to configure VRFs all over your core, assuming you wish to strongly preserve segmentation. The limitation is that Cisco does not recommend SD-Access Transit for WAN application. It is more for campus / small regional applications with high-speed fiber and suitable latency.
Context
The context for this blog is a multiple SD-Access fabric sites, using SD-Access Transit to connect them to each other.
Cross-Site Forwarding with SDA Transit
TL;DR: Cross-Site Forwarding is similar to IP Transit cross-site but uses LISP + VXLAN tunnels.
The first step is the same as for IP Transit: query goes to site CN.
The CN returns a negative reply, in effect saying, “send it to the BN; it’s not local.”
The EN then tunnels the traffic to the BN.
The next part is highly similar to what happens for tunneling within a site fabric, except that it is for tunneling between sites.
Specifically, the BN queries the Transit Control Node(s) (TCNs). They provide the VTEP to tunnel to across the core SDA Transit network.
All the sites are running LISP to the TCN, which tells it which IP prefixes are at which site, associated with which VTEP. You can think of it as similar to ordinary routing tracking the tunnel endpoint as next hop (for a tunnel).
Once the TCN tells the BN “where to go,” the BN tunnels the traffic to the other site.
That gets the packet(s) to the BN at the destination site.
There, it’s the story you should now be familiar with: check local VTEP cache for destination IP, tunnel traffic to the VTEP / EN switch. It de-encapsulates the packet, removing the VXLAN tunnel header, and forward the native packet out the correct port.
Conclusion
I hope this series of blogs on forwarding has been useful and informative for you. I may be writing of additions soon – several follow-on topics have occurred to me. For instance, having fusion firewalls at more than one site is “highly interesting”, as in “use caution, care needed”.
I have not covered: BUM (Broadcast, Unknown Unicast, Multicast) forwarding. I’ll refer you to the Cisco slides for that. See 2020 APJC BRKCRS-3493.
References
- Cisco SD-Access Technology Deep Dive – DGTL-BRKCRS-3810
- Cisco SD-Access for Distributed Campus – DGTL-BRKCRS-2815
- Cisco SD-Access – Connecting the Fabric to External Networks – BRKCRS-2811
- Real World Route/Switch to Cisco SD-Access Migration Tools and Strategies – BRKCRS-3493
