Routing and WAN Connectivity

Routing Protocols

The Catalyst 8000 organizes everything around VPNs, the SD-WAN term for separate routing instances. There are three roles: VPN 0 is the transport underlay, VPN 512 is management, and VPN 1 through 511 (and beyond) are service VPNs where customer traffic lives. The critical rule is that BGP, OSPF, and EIGRP are configured inside service VPNs, not in the global table. Each protocol process is scoped to a VPN/VRF and uses that VRF's routing table.

Throughout this section we use one worked scenario: a branch WAN Edge where service VPN 10 is the user LAN VRF. Interface GigabitEthernet0/0/1 lives in VPN 10 and faces a LAN switch running OSPF area 0, and the same VPN runs BGP toward an MPLS PE or data-center router (local AS 65010, neighbor 192.0.2.2 in AS 65000).

BGP on the edge

BGP (Border Gateway Protocol) is the path-vector protocol that exchanges routing information between autonomous systems. On a Catalyst 8000, BGP is most commonly used in a service VPN to peer with an MPLS provider edge (PE) router or a data-center core, while OMP carries routes between SD-WAN sites. BGP is configured per VPN (vpn 10) so it draws from that VRF's table. Inside the IPv4 address family you must explicitly activate the neighbor and configure redistribution if you want LAN prefixes advertised — without redistribute connected or redistribute ospf, the session can be established yet carry no prefixes.

That last point is the single most common BGP gotcha on these platforms. A show bgp vpn 10 summary reporting Estab looks healthy, but show bgp vpn 10 ipv4 unicast may show an empty table. Usual causes: missing redistribution, the neighbor not activated under the IPv4 AF, or an outbound route-policy filtering everything. An "up" BGP session is necessary but not sufficient.

BGP can also run on the transport side in VPN 0, peering with an ISP or MPLS provider to bring up the underlay. When it does, it uses far more restrictive advertisement, because you do not want raw transport routes leaking into the overlay.

OSPF and EIGRP service-side

OSPF (Open Shortest Path First) is a link-state IGP commonly run on the service side toward the branch LAN. The OSPF process is scoped to the service VPN. Two SD-WAN-specific habits: interfaces are attached to an area directly (the area 0 / interface block) rather than with the classic network statement, and because templates often default LAN interfaces to passive, you must explicitly passive-interface disable on any interface where you expect an adjacency.

EIGRP (Enhanced Interior Gateway Routing Protocol) is Cisco's advanced distance-vector IGP. Like OSPF and BGP, on a Catalyst 8000 in SD-WAN mode it is configured within a service VPN/VRF and reaches other sites only via OMP redistribution. The takeaway is structural: any service-side IGP lives inside its service VPN and reaches other sites only through OMP, exactly as OSPF does.

Route redistribution with OMP

OMP (Overlay Management Protocol) runs between WAN Edges and the vSmart controller — the "universal airport language." OMP advertises connected, static, OSPF, BGP (and EIGRP) routes from service VPNs into the overlay, but only for the route types you explicitly enable. If a LAN subnet is OSPF-learned but only advertise connected is enabled, OMP never pushes that prefix into the overlay, and remote sites will not see the branch LAN — even though it appears in show ip route vpn 10. The fix is to enable advertise ospf specifically.

The mirror-image problem is getting overlay routes back into the LAN. OMP routes are not automatically redistributed into local OSPF/BGP — you must explicitly configure redistribute omp per VPN. Here is where the translator must be disciplined: do not blindly redistribute OMP into both OSPF and BGP at the same site without route tags and filters. Doing so can re-inject an overlay route back into the overlay through the other protocol, creating a routing loop. The recommended discipline is to pick a single "direction of trust" per site and tag redistributed routes so they cannot loop back in. A common, low-risk pattern is to redistribute OMP into only one protocol toward the LAN (often OSPF) and keep BGP restricted to the PE/DC side.

In production you generally build vManage feature templates — a VPN template, interface template, OSPF template, BGP template, and OMP template — and attach them to a device template. The OSPF and BGP templates expose the same redistribution choices (including "Redistribute OMP" with metric/metric-type), and the OMP template exposes the per-VPN advertise checkboxes. The behavior is identical to the CLI; it is simply stored centrally and pushed consistently.

Figure 6.1: Route redistribution between service-side protocols and OMP

Figure 6.2: Redistribution loop hazard versus a single direction of trust

Key Takeaway: BGP, OSPF, and EIGRP all run inside service VPNs, never the global table. OMP carries routes between sites, but only the route types you explicitly advertise, and OMP routes reach the LAN only when you explicitly redistribute omp. Redistributing OMP into two protocols at one site invites loops — pick one direction of trust and use route tags.

Transport Options

Routing protocols decide what to advertise; transports decide how the bits physically move. The Catalyst 8000 separates two routing problems beginners often conflate. Transport-side routing lives in VPN 0 and answers: "How does this WAN Edge reach the internet/MPLS and the controllers so tunnels can form?" Service-side routing lives in the service VPNs and answers: "Once tunnels exist, how do user VPNs at different sites reach each other?"

This maps onto two more terms. The underlay is the physical IP network carrying the SD-WAN tunnels — internet, MPLS, LTE. It uses ordinary IP routing and has no awareness of SD-WAN VPNs or OMP; it sees only encrypted IP packets between transport addresses. The overlay is the logical fabric on top, carrying OMP control traffic and segmented user data. In short: underlay ≈ transport-side (VPN 0); overlay ≈ service-side plus OMP control.

Figure 6.3: Underlay (transport-side, VPN 0) versus overlay (service-side plus OMP)

A common branch pattern places each WAN circuit in VPN 0: Gig0/0/0 to the internet (color public-internet, often DHCP + ISP default route), and Gig0/0/1 to the MPLS PE (color mpls, often running BGP with the provider). The router installs the internet default and BGP-learned MPLS prefixes in VPN 0 only. With that reachability it reaches the controllers (vBond, vSmart, vManage), brings up DTLS/TLS control connections, and builds IPsec/GRE data tunnels. If VPN 0 routing is wrong, the tunnels and controllers never come up, and the service VPNs see no OMP routes even though the LAN looks fine.

The classic transport-side mistakes all stem from putting things in the wrong VPN: the ISP default route in a service VPN instead of VPN 0, forgetting NAT on an internet-facing VPN 0 interface, or using one physical interface in both VPN 0 and a service VPN. Each can break the control and data tunnels while LAN routing appears healthy — which is exactly why the underlay/overlay split is such a powerful troubleshooting lens.

Cellular and 5G connectivity

The underlay does not have to be wired. WAN transport options include MPLS, public internet, and cellular/LTE/5G, each surfaced into the overlay as a TLOC with its own color. A cellular interface in VPN 0 behaves like any other underlay link: it obtains IP connectivity from the carrier and is assigned a color such as lte, so the overlay can build tunnels across it and prefer or avoid it via policy. This makes cellular/5G attractive both as a primary transport where wired circuits are impractical and as a resilient backup. From the overlay's perspective the cellular path is just another TLOC color competing for traffic.

Loopback TLOCs and TLOC extension

A TLOC (Transport Location) is the unique identity of a WAN attachment point: the tuple of system-IP, color, and encapsulation (ipsec or gre). Every WAN-facing VPN 0 interface participating in SD-WAN becomes a TLOC, and only the TLOCs — not the raw VPN 0 routes — are advertised into the overlay. OMP's overlay routes (vRoutes) point at TLOCs as next-hops rather than at raw IP next-hops. Other airports learn the gates (TLOCs) you can be reached through, not your internal taxiway map (the underlay routes).

In dual-router or dual-transport designs, TLOC extension lets one router "borrow" another router's transport circuits over an intra-site link. The canonical scenario: Router A owns two underlay circuits (MPLS and Internet); Router B has only a LAN link to Router A. TLOC extension lets Router B's overlay traffic exit through Router A's TLOCs, so both routers share the transports without each needing its own physical circuit.

The non-negotiable rule: the TLOC extension link must live in VPN 0 (the same VRF as the original TLOC) and must not carry service VPN user traffic. Placing a TLOC-extension interface into a user service VRF mixes transport and user data and creates hard-to-debug routing overlaps. Keep these links on dedicated VPN 0 subinterfaces or VLANs.

Figure 6.4: TLOC extension sharing transport circuits between two routers

This split gives a sharp troubleshooting heuristic: if you see TLOC loss alarms, suspect a transport-side issue in VPN 0 (underlay reachability, or a color/tunnel misconfiguration). If TLOCs are up but applications are unreachable, the problem is on the service side — OMP, VPN IDs, or LAN routing.

Key Takeaway: Transport-side routing (VPN 0, the underlay) brings up tunnels to controllers and remote TLOCs; service-side routing (service VPNs, the overlay) connects users across sites. Only TLOCs — system-IP + color + encapsulation — are advertised into the overlay; the underlay sees only encrypted packets. MPLS, internet, and cellular/5G are each just a TLOC color, and TLOC extension shares circuits but must stay strictly inside VPN 0.

VRFs and Segmentation

The final piece is keeping different kinds of traffic separated end to end. On IOS-XE SD-WAN, including the Catalyst 8000 and virtual C8000V, each service VPN is literally implemented as a separate VRF in the data plane. vManage shows you "VPN 10," but the device enforces it as a VRF (e.g., vrf definition SDWAN-10 with an interface bound via vrf forwarding SDWAN-10).

So the practical equation is VPN = VRF. Each VRF has its own RIB and FIB; an interface belongs to exactly one VRF; and packets are switched only within the same VRF unless you explicitly configure inter-VRF routing. The VRF name is an IOS-XE artifact, but the VPN ID is what OMP and vSmart use to enforce segmentation across the fabric. A pleasant consequence: because the VRFs are genuinely separate tables, you can reuse overlapping IP ranges in different VPNs, since OMP tags every route with its VPN ID.

Global VRF and transport VPN

Segmentation is enforced at two levels simultaneously. On each device, the VRF level isolates the data plane: separate RIB/FIB per VRF, no switching between VRFs without explicit configuration. Across the fabric, the VPN level enforces it through OMP: OMP advertises vRoutes tagged with a VPN ID, vSmart maintains a separate topology per VPN, and a route in VPN 10 never automatically appears in VPN 20 anywhere in the fabric.

VPN 512 is reserved by default as the management VPN for out-of-band management — SSH, NETCONF, SNMP, vManage CLI — and is segmented like any other VRF. The discipline that keeps designs sane is keeping roles clean by VPN ID: VPN 0 carries transport only (no user LAN interfaces), VPN 512 carries management only (ideally truly out-of-band), and service VPNs carry user and tenant traffic. Critically, segmentation exists only in the overlay — the underlay sees encrypted traffic with no segmentation context.

Inter-VRF routing

Because the default is total isolation, any communication between segments must be deliberately enabled through route leaking. A worked example anchors the choice: VPN 10 (corporate users), VPN 20 (voice or OT/IoT), and VPN 30 (shared services such as DNS and Active Directory). By default, users in VPN 10 reach only other VPN 10 routes, voice reaches only VPN 20, and nobody reaches the DC services in VPN 30. To let users and voice reach shared services, you leak selected prefixes from VPN 30 into VPNs 10 and 20.

Figure 6.5: VRF segmentation with selective route leaking to shared services

1. Centralized route leaking via vSmart policy (recommended for fabric-wide consistency). You define source and destination VPNs, match routes from the source, and have vSmart clone those vRoutes into the destination VPN(s) by changing the VPN ID before advertising. A host in VPN 10 then sees the DC services as routes in its own VRF, while the DC stays in VPN 30. Use this when the inter-segment relationship must be consistent across many sites.
2. Route leaking between the global/transport VRF and service VPNs. Cisco documents controlled leaking between the global/VPN 0 context and service VPNs — useful when a service VPN needs reachability to something in the global/transport VRF, such as a shared NAT device or OOB management.
3. Local VRF Route Sharing on the Catalyst 8000 (device-local). The C8000V and Catalyst 8000 support sharing routes between VRFs through local import/export — for instance between a "User" VRF and a local "Firewall" VRF for service chaining. This is device-local; it does not alter how vSmart/OMP sees the VPNs. Use it for site-local relationships.

The guiding rule: for any segmentation that must hold across many sites, prefer vSmart route-leaking policies; reserve local VRF Route Sharing for relationships local to a single site. In all cases be conservative — use prefix lists and tags so you never accidentally leak a default route or an overly broad network between segments.

Key Takeaway: Every service VPN on a Catalyst 8000 is a real IOS-XE VRF (VPN = VRF), giving each segment its own table, allowing overlapping IP ranges, and keeping VPN 10 routes out of VPN 20 by default. Inter-segment traffic requires deliberate route leaking — centralized vSmart policy for fabric-wide consistency, or local VRF Route Sharing for site-local service chaining — always scoped tightly with prefix lists and tags.