In our last post, we established that external connectivity in SD-Access is just routing between VRFs — BGP out, VRF-lite handoff, fusion router in between. If you haven’t read it yet, start there. This post builds directly on top of it.
Today we’re going to tackle one of the most common points of confusion in SD-Access design: which border node role should I use, and why does it matter?
When you go to provision a border node in Cisco Catalyst Center, you’re asked to declare what type of external network that border connects to. The three options — known internally as Internal, External, and Internal + External (sometimes called “Anywhere”) — each tell the fabric something fundamentally different about how to forward traffic to the outside world.
Getting this wrong doesn’t break your fabric. But it can mean traffic takes an unnecessarily inefficient path, and troubleshooting becomes harder than it needs to be. So let’s get it right.
The Core Question: Does LISP Know About It?
Before we look at each border type, there’s one principle that underpins all three:
If LISP knows about a prefix, traffic goes directly to the border connected to that network. If it doesn’t, traffic falls back to the default route.
This is the key distinction. The border node type you choose essentially answers the question: should the LISP control plane learn routes from this border, or should it just be a default exit?
External Border: The Default Exit
The External Border is the simplest to understand. It connects to networks that are, in LISP’s view, unknown — the internet, a MAN, or a WAN circuit where you don’t know (or don’t care about) the specific prefixes on the other side.
Routes learned from the external domain are not registered with the fabric control plane node. Instead, this border node becomes the gateway of last resort — the LISP equivalent of a default route — for all virtual networks in the site.
When an edge node has traffic for a destination it can’t find in LISP, it sends that traffic to the external border node. From there, normal IP routing takes over.
When to use it: Most deployments should use External borders as their primary egress point. If you have a single pair of border nodes that handle internet, WAN, and data centre traffic alike, External is almost certainly the right choice. You don’t need to register anything — traffic hits the border and routes out normally.
One important note for LISP Pub/Sub deployments: External borders need a default route in their own RIB (usually learned from the upstream peer) so that LISP can use it as the fabric’s gateway of last resort. Without it, the control plane has nowhere to point the default.
Internal Border: The Shortcut to Known Networks
The Internal Border is used when your border connects to a network with known, specific prefixes — a data centre, shared services infrastructure, or a private WAN — and you want edge nodes to send traffic there directly rather than via the default path.
Here’s the problem it solves. Imagine you have two pairs of border nodes: one pair (External) connected to the internet and the campus distribution, and a separate pair (Internal) connected directly to your data centre. Without internal border registration, your edge nodes only know about the default route pointing to the External borders. Traffic destined for the data centre goes to the External border first, which then has to hairpin it across to the Internal border. Wasteful, and harder to troubleshoot.
When you configure a border as Internal, routes learned from the connected network are registered (imported) into the LISP control plane node, just like an edge node registers an endpoint. Now the fabric knows that 10.100.0.0/16 (your DC block) lives behind the Internal border nodes, and edge nodes can send traffic there directly. No hairpin. No unnecessary hops.
When to use it: Use Internal borders when you have a dedicated uplink to a known network — typically a data centre or shared services block — and you want optimal, direct forwarding from every edge node to that destination.
Internal + External (“Anywhere”): The Combined Role
The Internal + External border — referred to in the Catalyst Center UI as the “Anywhere” type — does both jobs simultaneously. It registers known routes into LISP and acts as a gateway of last resort for everything else.
This is commonly used when a single pair of border nodes serves as the common egress point for the whole site, but you also have specific prefixes you want to import into LISP for optimisation. A good example: your border nodes connect to both the internet and a data centre, but each border node has a direct link to a different data centre with unique prefixes. By using Internal + External and registering those DC prefixes, each edge node knows which border to use for which data centre — no guessing, no hairpin.
The Cisco design guide offers a useful rule of thumb here:
“If the same forwarding result is achieved whether or not you register the known external prefixes, most deployments should provision a border node using the external border node type.”
In other words: if all your border nodes are equivalent exit points and there’s no routing efficiency to be gained by registering specific prefixes, keep it simple and use External.
A Quick Decision Guide
| Situation | Border Type |
|---|---|
| Single egress point for everything (internet, WAN, DC) | External |
| Dedicated uplink to data centre or shared services | Internal |
| Common egress plus specific DC prefixes to optimise | Internal + External |
| Fabric in a Box or small site with one border pair | External |
Redundancy and Load Balancing
Regardless of which type you choose, border nodes should always be deployed in pairs. By default, the fabric load-balances traffic across both nodes within a fabric site. If you need to influence which border is preferred:
- Border Priority: A lower number means a more preferred border for egress traffic. This is configured in Catalyst Center.
- AS Path Prepending: Influences ingress traffic by making certain borders less preferred for routes advertised externally. This is disabled by default and should be used deliberately.
One important constraint to keep in mind: Catalyst Center supports a maximum of four External or Internal + External border nodes per fabric site. Internal borders don’t have this four-node cap, which gives you more flexibility when connecting to multiple known networks.
What About Layer 2 Borders?
We’ve focused entirely on Layer 3 handoff in this post. There’s also a Layer 2 border mode — where the border bridges fabric VNIs to traditional VLANs in an external switched domain. This is primarily useful for migration scenarios, where you need an SD-Access fabric and a legacy switching domain to share the same IP subnets during a phased cutover. That deserves its own post, so we’ll come back to it.
Coming Up Next…
Now that we understand how border nodes connect the fabric to the outside world, the next natural question is: what happens when you need to connect multiple fabric sites together?
In our next article, we’ll look at SD-Access transit networks — the SD-Access Transit and IP Transit options — and how the LISP Pub/Sub control plane has simplified multi-site connectivity compared to the older LISP/BGP model.
Until then, remember: the border type you choose is just telling LISP how much to trust the network on the other side.
BGP · Cisco · Routing · SDA · LISP