Showing results for 
Search instead for 
Did you mean: 

Upstream WAN/Carrier Requirements to support SDA IP Transit

Ideal Networks
Level 1
Level 1

Good morning, could anyone share with me the upstream carrier requirements in order to support SDA IP Transit between external border nodes? Ie: MTU Sizes, VRF Capabilities, Support for eBGP etc


I understand that different architectures are supported ie: MPLS/IPSEC/GRE but i cant nail down what is and isnt supported in order to enable necessary de-encapculation/encapsulation of control and data plane traffic and inline SGT tagging.


Any assistance would be greatly appreciated.








3 Replies 3

Hall of Fame
Hall of Fame

Look at some presentation to preserv the SGT :


***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Mind the terminology. External Border node  meant to be the ingress/egress of traffic from or to the fabric. It is  the gateway of last resort. When you say between external border nodes, I imagine you connecting fabrics through some external network. Well, External Border nodes, by cisco docs, is meant to talk with fabric and no-fabric devices which means there will be no SGT outside the External Border node.

 Also, considering you are connecting your fabric to the outside fabric world with External Border node, the limition you may have in terms of protocol, most probably, will reside on the external device not in the border node.In order to participate the fabric, the External Border node must be an uptodated device like a 9300 or 9500 Catalyst switch and those device will support almost all kind of protocol out there.  So, pay attention on where you are connecting your External border node.

 And as I said, mind the terminology to get accurated help.


Thank you Flavio, forgive my description, when i say "external" border node i am not refering to either the default border or handoff to a fusion router.


This would be the border or  border/control plane router connected to an upstream carrier network providing internal intersite connecivity for the company ie: MPLS/DMVPN etc.


Based on the CVD, there seems to be 3 options to achieve this, although only the last one seems valid in this scenario.


VRF Aware—A border node will be VRF-aware. All user-defined VNs in the fabric site are instantiated and provisioned as VRFs.

Site Prefixes in VRF—The EID-space prefixes associated with the fabric site will be in VRF routing tables on the border node.

Upstream Infrastructure—The border nodes will be connected to a next-hop device and further routing infrastructure (referenced simply as next-hop, for brevity). This upstream infrastructure, while a necessary part of the overall design, is not part of the fabric site and is therefore not automated though SD-Access workflows in Cisco DNA Center.


Non-VRF-Aware Peer

This deployment type begins with VRF-lite automated on the border node, and the peer manually configured, though not VRF-aware.  For each VN that is handed off on the border node, a corresponding interface is configured on the peer device in the global routing table.  This deployment option is commonly used when the fabric site hands off to a WAN circuit, ISP, an MPLS CE or PE device, other upstream routing infrastructure, or even a firewall which is special-case non-VRF peer discussed further in the Firewall section.

This deployment type is common in WAN infrastructure.  If this next-hop peer is an MPLS CE, routes are often merged into a single table to reduce the number of VRFs to be carried across the backbone, generally reducing overall operational costs.  If the next-hop peer is an MPLS PE or ISP equipment, it is outside of the administrative domain of the fabric network operator.  The result is that there is little flexibility in controlling the configuration on the upstream infrastructure.  Many times, ISPs have their own peering strategies and themselves are presenting a Layer 3 handoff to connected devices.


Non-VRF aware means that peer router is not performing VRF-lite.  It may have the functionality to support VRFs, but it is not configured with corresponding fabric VRFs the way a VRF-Aware peer would be.  The non-VRF aware peer is commonly used to advertise a default route to the endpoint-space in the fabric site.