SD-Access Flows: SDA Transit

Peter Welcher
Architect, Operations Technical Advisor

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

Previous blogs in this series:

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.


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.


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.



Disclosure Statement