Cisco Catalyst SD-WAN Deep Dive Part 5: Topology Walkthroughs — Dual Transport, DIA, and TLOC Extension

6 July 2026 CiscoSDWAN

Parts 1 through 4 built the pieces — controllers, OMP, TLOC color and policy, BFD and forwarding — in isolation. This post puts them together into actual site designs, which means first introducing one concept that’s been quietly assumed throughout: how Catalyst SD-WAN segments traffic with VPNs.

VPN numbering: Cisco’s VRF, with reserved numbers that matter

Every interface on a WAN Edge belongs to a VPN, and VPN here means essentially what VRF means everywhere else in Cisco’s product line — a separate routing/forwarding context. Three VPN ranges carry fixed meaning:

  • VPN 0 — the transport VPN. Every WAN-facing interface — every TLOC — lives here. VPN 0 is where the underlay reachability described in Part 2 actually exists.
  • VPN 512 — the management VPN, reserved for out-of-band device management, deliberately kept separate so a management-plane connectivity problem can’t be caused by (or cause) a service-side outage.
  • VPN 1–511 and 513–65530 — service VPNs. This is where actual user/LAN traffic lives, where the prefixes carried in OMP routes (Part 2) and the service routes pointing at firewalls/IDS (Part 2, Part 3) are actually anchored. A site with separate corporate and guest networks is two service VPNs; a site with a single flat LAN is one.

With that in place, the rest of this post is just combinations of what Parts 1–4 already built, applied across VPN 0 and a service VPN at once.

Worked design: dual MPLS + Internet branch

A typical branch: one MPLS circuit, one business-Internet circuit, single LAN segment. In VPN 0 terms: two TLOCs, color mpls and color biz-internet. Following Part 3’s guidance, mpls is commonly set to restrict — this site’s committed-bandwidth circuit shouldn’t silently absorb tunnels it wasn’t sized for — while biz-internet stays no-restrict, free to pair with whatever it needs to on the other end. The LAN itself sits in a single service VPN (say, VPN 1), advertised as one OMP route with both TLOCs as viable next-hops, multipath-eligible per Part 2’s mechanics, with app-route policy (Part 4) steering voice/video toward whichever TLOC pair is currently meeting the tighter SLA class and bulk traffic riding wherever there’s headroom.

That’s the whole site, end to end, in the vocabulary this series has already built: two TLOC routes, one OMP route, BFD-fed SLA measurement deciding which transport carries what, moment to moment.

Direct Internet Access: breaking out locally instead of backhauling

The design above still assumes Internet-bound traffic (SaaS, general browsing) transits the overlay to a hub before egressing — fine for centralizing inspection, wasteful in latency and hub bandwidth if there’s no actual reason to backhaul it. Direct Internet Access (DIA) lets a branch break Internet-bound traffic out locally over its own biz-internet circuit instead, typically via a data policy match (destination doesn’t match any known corporate/OMP-learned prefix → NAT and route out VPN 0 locally) rather than tunneling it anywhere.

The design trade-off is the same one every vendor’s SD-WAN forces: DIA reduces hub load and improves SaaS latency, at the cost of losing centralized inspection on that traffic unless you also stand up local security (or steer it to a cloud-delivered service, which is exactly what Part 7’s SIG/Secure-Firewall discussion is for). This is conceptually the same decision the Fortinet local-breakout post walks through with SD-WAN zones, rules, and a multi-VRF guest-Wi-Fi segment — same business question (local breakout vs. hub backhaul), same per-segment granularity (a branch can DIA its guest VPN while still backhauling corporate VPN traffic for inspection), just expressed as a FortiGate SD-WAN rule rather than a Catalyst data policy match.

It’s also worth naming the design Catalyst SD-WAN deliberately moves away from with DIA available: the VeloCloud MPLS-only-site architecture covered earlier on this site describes sites with no Internet transport at all, where every byte — including Internet-bound traffic — has nowhere to go but the MPLS circuit toward a partner gateway. That’s not a worse design, it’s a different constraint (no local Internet circuit exists to break out over), and it’s a useful contrast for why DIA is a choice Catalyst SD-WAN branches get to make rather than a universal default — the choice only exists because the branch has a local Internet-capable TLOC in the first place.

TLOC extension: participating in the fabric without your own WAN circuit

Not every site has its own WAN transport. A small spoke co-located in the same building (or same equipment closet) as a better-connected site is the classic case, and the answer is TLOC extension: the small site’s WAN Edge connects to the larger site’s WAN Edge over a LAN-side hand-off, and the larger site’s transport interface is extended to appear as if it were local to the smaller site’s edge — that edge advertises a TLOC that’s physically someone else’s circuit. The smaller site still gets its own system-IP, its own site-ID, its own OMP routes for its own LAN — it’s a fully participating fabric member, just borrowing physical transport rather than owning it.

This is a narrow tool for a narrow problem (co-located sites, temporary builds, a spoke too small to justify its own circuit), but it’s worth knowing it exists precisely because the alternative — giving every small site its own redundant transport regardless of practical need — is usually the more expensive default people reach for without considering the extension option.

Next

Part 6 leaves on-prem topology behind and goes to the cloud side: Cloud OnRamp for SaaS and Cloud OnRamp for IaaS — how a Catalyst SD-WAN fabric measures and steers around SaaS application performance, and how it wires into a hyperscaler’s own transit infrastructure, directly mirrored against this site’s existing two-part Fortinet Cloud On-Ramp coverage of AWS Transit Gateway and Azure Virtual WAN.