Fabric Borders Internal External Transit

Introduction

In an SD-Access fabric, endpoints live inside overlay Virtual Networks (VRFs), but they still need to reach resources that sit outside the fabric -- services like DHCP, DNS, Active Directory, and the Internet. The fabric border node is the device that bridges the gap between the internal fabric world and the external routing domain.

Understanding the different border types, how they register (or do not register) prefixes with the Control Plane Node, and how external connectivity is handed off is essential for anyone designing or operating an SD-Access network. Getting this wrong means endpoints either cannot reach shared services or, worse, internal host routes leak into external routing tables where they do not belong.

By the end of this lesson you will be able to:

Distinguish between Internal and External border node roles and how they interact with the Control Plane Node.
Explain how IP Transit connects the fabric to outside domains using eBGP and VRF-lite.
Configure VRF route leaking on a peer device so fabric endpoints can reach shared services in the Global Routing Table.
Describe how LISP Extranet policies replace manual route leaking with a scalable, policy-driven approach managed through Cisco Catalyst Center.

Key Concepts

Border Node Types

The fabric border node is the exit point for traffic leaving the SD-Access fabric site. It performs an IP handoff -- either a trunk or a regular routed interface -- and advertises fabric EID prefixes into an external routing protocol such as eBGP. Crucially, the advertisement is summarized so that individual /32 host routes are never exposed to the external domain. This process is repeated for every IP subnet and VRF that exists inside the fabric.

There are two primary border roles:

Attribute	Internal Border	External Border
Registers external prefixes with Control Plane Node	Yes	No
Acts as Fabric Gateway of Last Resort	Yes	Yes
Typical use case	Shared services, data center connectivity	Internet edge, WAN uplinks

Internal Border -- Registers external prefixes with the Control Plane Node. When the border learns a route from outside the fabric (for example, a shared-services subnet), it publishes that prefix into LISP so that edge nodes know where to send traffic destined for those resources. It also serves as a gateway of last resort for fabric endpoints.
External Border -- Does not register prefixes with the Control Plane Node. It simply acts as a gateway of last resort. Traffic that has no specific match in the fabric's LISP mapping is forwarded to the external border, which then routes it out toward the Internet or another external domain.

A border node can also operate in a combined Internal + External mode, fulfilling both roles simultaneously. This is common in smaller deployments where a single pair of border nodes handles all external connectivity.

IP Transit

IP Transit is the mechanism used to connect the SD-Access fabric border to devices outside the fabric. The border node uses eBGP with per-VRF SVIs (sub-interfaces or VLAN interfaces) to peer with an external device such as an SD-WAN cEdge router. Each VRF inside the fabric gets its own SVI and its own BGP session, ensuring that routing isolation is maintained end to end.

Shared Services Challenge

Endpoints inside an SD-Access fabric site live in overlay Virtual Networks -- each one a separate VRF routing table. Yet those endpoints need to reach critical shared services such as DHCP, DNS, and Active Directory servers that typically reside outside the fabric, often in a data center. These shared services usually sit in the Global Routing Table (GRT) or occasionally in a dedicated Shared Services VRF.

Because the endpoints and the shared services are in different VRFs, some form of VRF route leaking is required to allow communication between them.

How It Works

Border-to-External-Domain Connectivity

When an SD-Access border node connects to an external routing domain that uses the Global Routing Table, the recommended design places a peer device (sometimes called a fusion router) between the border and the external network. This peer device runs MP-BGP and uses VRF import/export route targets to leak routes between the fabric VRFs and the GRT.

The traffic flow works as follows:

The border node hands off each fabric VRF to the peer device over a VRF-lite trunk or routed sub-interfaces.
On the peer device, each fabric VRF is configured with route targets that import from the GRT and export back into it.
The GRT on the peer device is configured to export its routes into each fabric VRF, enabling bidirectional reachability.
Shared-services routes from the GRT are now visible inside each fabric VRF, and fabric subnet summaries are visible in the GRT.

SGT Propagation Across SD-WAN

When the fabric border connects to an SD-WAN cEdge router, Scalable Group Tag (SGT) propagation must be explicitly enabled so that micro-segmentation policies survive the transit. This involves two steps:

Enable SGT propagation on the interface facing the SDA border -- This is done on the cEdge's service-side interface (VPN X) by enabling CTS (Cisco TrustSec) propagation.
Enable CTS SGT propagation into the SD-WAN overlay -- On the cEdge's tunnel transport interface (VPN 0), CTS SGT propagation is turned on so that tags are carried across the SD-WAN fabric.

Once SGTs are flowing into the SD-WAN overlay, ISE integrates with vSmart and SD-WAN Manager. The cEdges learn SGT assignments, and Zone-Based Firewall (ZBFW) policies on the cEdges can reference SGTs directly -- allowing policy enforcement without traditional IP-based ACLs.

LISP Extranet -- Replacing Manual Route Leaking

Manually configuring VRF route leaking on an external peer device works, but it does not scale well when there are many fabric sites and many VRFs. LISP Extranet provides a flexible, scalable, policy-based method for giving fabric endpoints access to shared services and the Internet without requiring manual route leaking outside the fabric.

LISP Extranet handles the route leaking natively within LISP on the Control Plane Node. It uses two roles:

Provider Virtual Network -- The VN that contains shared-services resources (DHCP, DNS, AD). This is the VN whose prefixes subscribers need to reach. It can be a dedicated VN or the INFRA_VN.
Subscriber Virtual Network -- The VN that contains endpoints, hosts, and users who need access to the provider's resources.

An Extranet Policy defines the relationship: one Provider VN and one or more Subscriber VNs. The communication matrix enforced by this policy is strict:

Direction	Provider VN	Subscriber VN
Provider VN to ...	N/A	Allowed
Subscriber VN to ...	Allowed	Denied

Subscriber-to-subscriber communication is explicitly denied. If two groups of endpoints need to talk to each other, they should be placed in the same Virtual Network rather than relying on Extranet.

Extranet Shared-Services Flow

Here is how LISP Extranet enables shared-services access step by step:

All Virtual Networks within the fabric need connectivity to shared services. These services connect to the fabric border through a Provider VRF (for example, "Shared Services"). The border performs a VRF-lite handoff for the Provider VN only. Shared-services routes are imported into the Provider VRF in LISP.
The administrator creates an SD-Access Extranet policy in Cisco Catalyst Center. The policy is pushed to the Control Plane Node. For example: Provider VN = "Shared Services," Subscriber VN = "Employee," Subscriber VN = "Contractor." Only one Provider VRF is allowed per Extranet policy instance, but multiple subscribers are permitted.
At this stage, the Control Plane Node knows about host entries in each subscriber VN and their locations (edge nodes). It also knows about shared-services prefixes learned via the border.
When a host in the Employee VN on an edge node wants to reach a server in Shared Services, the edge node queries the Control Plane. Because the Extranet policy links the Employee VN (subscriber) to the Shared Services VN (provider), the Control Plane returns the mapping, and the edge node can VXLAN-encapsulate the traffic toward the border, which forwards it to the shared-services server.

Configuration Example

VRF Route Leaking on a Peer Device

When using a peer device (fusion router) for manual route leaking between fabric VRFs and the Global Routing Table, the configuration uses MP-BGP route-target import and export statements:

ip vrf USERS
 rd 1:4099
 route-target export 1:4099
 route-target import 1:4099
 route-target import 1:4097
!
ip vrf DEFAULT_VN
 rd 1:4098
 route-target export 1:4098
 route-target import 1:4098
 route-target import 1:4097
!
ip vrf GLOBAL
 rd 1:4097
 route-target export 1:4097
 route-target import 1:4097
 route-target export 1:4099
 route-target export 1:4098

Explanation of each VRF block:

USERS VRF (RD 1:4099) -- Exports its own routes with route-target 1:4099 and imports routes tagged 1:4099 (its own) plus 1:4097 (the GLOBAL/GRT routes). This allows USERS endpoints to see shared-services routes from the GRT.
DEFAULT_VN VRF (RD 1:4098) -- Same pattern: exports 1:4098, imports its own plus the GLOBAL route-target 1:4097.
GLOBAL VRF (RD 1:4097) -- Represents the Global Routing Table side. It imports its own routes and exports into both 1:4099 and 1:4098, making GRT routes available to both the USERS and DEFAULT_VN VRFs.

Important: This configuration is done manually on the peer device outside of the fabric. Cisco Catalyst Center does not automate this portion of the deployment. The peer device sits between the border node and the external routing domain.

Real-World Application

Common Deployment Scenarios

Shared Services Access -- The most common use case for border nodes and Extranet policies. Every fabric site needs DHCP, DNS, and Active Directory. Rather than placing these servers inside every fabric site, they remain centralized in a data center and are reached through the border node's Provider VN handoff.
Internet Access -- An external border provides a default route as the gateway of last resort. Fabric endpoints that need Internet access forward unmatched traffic to this border, which routes it to a firewall or Internet edge router.
SD-WAN Integration -- When the external domain is an SD-WAN overlay, the border hands off VRFs via eBGP to cEdge routers. SGT propagation is enabled so that group-based policies survive the transit between SDA and SD-WAN domains.

Design Considerations and Best Practices

Best Practice: Use LISP Extranet for shared-services connectivity whenever possible. It eliminates the need for manual VRF route leaking on external peer devices, reducing operational complexity and configuration drift.

LISP Extranet is supported from Cisco IOS-XE 17.9 and Cisco Catalyst Center 2.3.4.x onward. Ensure your software versions meet these minimums before designing around Extranet.
Extranet policies require LISP Pub/Sub fabric mode.
A Provider VN in one Extranet policy cannot be a Subscriber VN in another policy, and vice versa.
A Virtual Network can be a Provider in only one policy but can be a Subscriber in multiple policies.
INFRA_VN can serve as a Provider VN but cannot be a Subscriber VN.
Multicast traffic does not work across Extranet boundaries. If multicast is required, the RP, source, and receivers must all reside within the same Virtual Network.
Extranet is not intended for leaking routes between two fabric VRFs. If two endpoint groups need full bidirectional communication, place them in the same VN.
Provider-to-provider communication is not supported.

Summary

Internal borders register external prefixes with the Control Plane Node, while external borders do not -- they serve only as a gateway of last resort.
The border node performs an IP handoff using eBGP and VRF-lite, advertising summarized EID prefixes so that /32 host routes never leak to external domains.
Manual VRF route leaking on a peer device (fusion router) uses MP-BGP route-target import/export to bridge fabric VRFs and the Global Routing Table for shared-services access.
LISP Extranet is the scalable, policy-driven replacement for manual route leaking -- managed entirely through Cisco Catalyst Center with Provider and Subscriber VN roles.
When integrating with SD-WAN, SGT propagation must be enabled on both the service-side interface and the tunnel transport interface of the cEdge to maintain micro-segmentation across domains.

Next up: In the next lesson, we dive deeper into SD-Access transit architectures -- comparing IP Transit and SD-Access Transit for multi-site fabric connectivity.