Welcome to the first instalment of our series on Cisco SD-Access design. If you’ve been diving into fabric technology, it’s easy to get lost in the alphabet soup of LISP, VXLAN, and SGTs. But when it comes to the critical task of getting traffic in and out of your fabric, there is a refreshing truth: at the border, it is just traditional routing between VRFs that needs to work.
In this post, we’ll strip away the complexity and look at how the Fabric Border node acts as the bridge between your automated overlay and the rest of your world.
The Border Node: Your Gateway to the World
In an SD-Access environment, the Border Node is the designated exit and entry point. Its job is to take traffic from inside the fabric, where it is encapsulated in VXLAN, and hand it off to external networks like the Data Center, the Internet, or your existing WAN.
While internal fabric communication relies on LISP to find where endpoints are, the Border Node uses Border Gateway Protocol (BGP) to talk to the outside world. It advertises the internal fabric prefixes (the EID space) so that external routers know exactly how to send traffic back into the fabric.
The “Secret” Reality: It’s All Just VRFs
The most important concept to grasp for external connectivity is that every Virtual Network (VN) you create in Cisco Catalyst Center is simply a VRF instance on your network devices.
When traffic reaches the border node from a specific VN, it resides in a dedicated VRF routing table. To get that traffic to a shared service (like DNS or DHCP) or to the Internet, you are essentially performing VRF-lite handoff.
Cisco Catalyst Center automates this by provisioning:
- VRF-lite: Mapping each fabric VN to a unique subinterface or SVI.
- BGP Peering: Establishing a routing relationship between the Border and its “upstream” peer.
The Role of the Peer: Fusing the Tables
The device your Border Node connects to is often called a VRF-aware peer (or sometimes a “fusion” router). This peer’s only real responsibility is to provide reachability between the fabric VRFs and external resources.
This is accomplished through standard routing techniques:
- Route Leaking: If your services (like DHCP) are in the global routing table, the peer “leaks” those routes into the specific fabric VRFs.
- VRF Leaking: If services are in their own dedicated VRF, the peer uses BGP route targets to “fuse” the fabric VRFs and the service VRF together.
- Table Merging (Non-VRF-Aware Peers): In some designs, you don’t need to perform route or VRF leaking at all. Instead, you can connect your border node to a non-VRF-aware peer – such as a traditional router or a firewall – and map the interfaces for each fabric VN directly into that peer’s global routing table. This effectively “merges” the traffic from different fabric virtual networks into a single table on the peer device. This is a common strategy when using a firewall as a policy-enforcement point, allowing it to handle inter-VN communication and external access through standard security zones and inspection rather than complex leaking configurations.
Why This Matters
By treating external connectivity as a standard routing problem between VRFs, you gain two major benefits:
- Granular Isolation: Because each VN is its own VRF, you maintain total macro-segmentation; a user in the “Guest” VN cannot reach the “Finance” VN unless you explicitly allow it at the peer/firewall.
- Operational Familiarity: You don’t need to be a “Fabric Expert” to troubleshoot external routing. If BGP is up and the routes are in the VRF table, the traffic will flow.
Coming Up Next…
In our next article, we will go deeper into the different Border Roles—Internal, External, and “Anywhere” borders—and help you decide which one fits your site design.
Until then, remember: Inside the fabric, it’s an automated overlay. At the border, it’s the routing you’ve known for years.