Cisco Catalyst SD-WAN Deep Dive Part 2: OMP, the Overlay Management Protocol

Part 1 left off at the moment a WAN Edge’s control connection to vSmart comes up and the two start exchanging OMP routes. This post is entirely about what’s actually inside that exchange — what OMP carries, how it decides a best path, and why the answer to “is this BGP?” is “no, but whoever wrote it had BGP open in the next tab.”

OMP is path-vector, not link-state, and that’s a deliberate choice

The Overlay Management Protocol is Viptela’s own creation, not a repurposed standard — there’s no RFC for it, no IANA port assignment outside Cisco’s own documentation. But the design lineage is unmistakable and Cisco doesn’t hide it: OMP is a path-vector protocol, structurally a close cousin of BGP, carrying attribute-tagged routes between peers that each independently run best-path selection. If you’ve spent any time with the BGP route-dampening series on this site, the vocabulary below — origin, preference, tag, originator — will read like a slightly-renamed BGP path attribute table, because that’s essentially what it is.

The reason this matters architecturally, not just trivia-wise: path-vector scales by attribute comparison rather than full-topology flooding, which is exactly the property that lets a single vSmart hold routing state for thousands of sites without doing anything resembling SPF. It also means OMP inherits BGP’s general convergence character — fast to propagate a withdrawal, but vulnerable to the same flapping pathologies if a site’s reachability is unstable, which is precisely the failure mode that BGP route dampening was invented to dampen. OMP itself doesn’t implement dampening; what it leans on instead is BFD-driven fast failure detection feeding fast OMP withdrawal, which we’ll cover properly when we get to the data plane in Part 4.

Three kinds of route, not one

This is the part that trips up engineers coming from a pure-BGP background, because OMP doesn’t advertise one flat thing called “a route.” It advertises three distinct route types over the same session, and a given prefix’s reachability is reconstructed by combining information across all three.

OMP routes (vRoutes)

This is the closest analogue to a BGP NLRI — a prefix, plus the attributes needed to reach it. Critically, the next-hop for an OMP route is not an IP address. It’s a TLOC (Transport Locator) — really a reference to one, identified by a (system-ip, color, encapsulation) triple. This is the single biggest structural departure from BGP: BGP’s next-hop is “go to this IP”; OMP’s next-hop is “go to this transport,” and resolving a transport to an actual reachable IP address is what the TLOC route (next section) is for. We’re deferring the deep mechanics of color and restrict/no-restrict to Part 3 — for now just hold onto the idea that an OMP route points at a TLOC, not at an interface.

Key attributes carried on an OMP route:

Attribute	Meaning
Originator	System IP of the edge that originated the prefix
Preference	Higher wins (set via policy; default equal)
Origin / Origin Protocol	How the prefix entered OMP — connected, static, OSPF, BGP, etc., plus a metric
Tag	Opaque value, usable for policy matching, like a BGP community in spirit
Site ID	Identifies the originating site — used heavily in centralized control policy to express “site A can/can’t reach site B”
TLOC	The next-hop TLOC(s) this prefix is reachable via

TLOC routes

A TLOC route describes a transport locator itself, not a destination prefix: which (system-ip, color, encapsulation) exists, what its private and public IP/port are, what carrier it’s tagged with, its NAT type (detected back in Part 1’s vBond handshake), and its own preference. Every WAN Edge advertises one TLOC route per active transport — a dual-MPLS-plus-Internet site advertises three. Other edges resolve the TLOC references inside OMP routes against this table to know the actual IP/port to build an IPsec tunnel toward. This is also where Part 1’s NAT-detection step pays off: the TLOC route carries both the private and the post-NAT public address/port, so a remote edge behind its own NAT can still figure out where to send packets.

Service routes

The third type advertises that a service — not a destination network — is reachable at a given site: a firewall, an IDS/IPS, a load balancer, Cisco’s own application-aware routing services. Other sites can be steered through that service via centralized policy without needing to know anything about the service device’s actual IP addressing — they just match on the advertised service type and let policy do the redirection. This is the OMP-level hook that later makes hub-anchored security inspection possible, conceptually parallel to what the Fortinet hub-placement series describes for centralizing inspection at a DC hub, just expressed as a first-class route type instead of a policy convention layered on top of plain reachability.

Best-path selection: familiar shape, shorter list

vSmart and every WAN Edge independently run OMP best-path selection over the OMP routes they’ve learned, and the comparison order will feel immediately recognizable if you know BGP’s: prefer higher preference, then prefer the route whose origin type ranks higher (a fixed protocol-preference order, roughly: connected/static beats OSPF beats BGP, mirroring administrative distance logic more than BGP’s own origin-code comparison), then prefer lower origin metric, then a handful of tie-breakers ending in lowest originator system-IP as the deterministic last resort. It’s a shorter list than BGP’s full attribute cascade because OMP doesn’t need AS-path, doesn’t need MED-vs-local-pref scoping rules, and doesn’t need to worry about eBGP-vs-iBGP distance — there’s no AS concept in the overlay at all.

Multipath: where OMP actually diverges from a route reflector

Here’s the structural point worth sitting with, because it’s the thing that makes the vSmart-as-route-reflector analogy from Part 1 imperfect rather than exact. A classic BGP route reflector reflects exactly one best path per prefix to its clients by default — multipath in iBGP is a separate, often-fiddly feature you have to explicitly enable and tune. vSmart, by contrast, is designed from the ground up to hand back multiple best paths per OMP route to a requesting edge, controlled by how many paths policy allows (commonly referred to as the ECMP/multipath limit). The edge then programs all of those into its forwarding table as genuine equal-or-weighted-cost paths across different TLOCs — which is exactly the SD-WAN value proposition: a site with MPLS and two Internet circuits doesn’t pick one “best” transport and fail over, it can active-actively load-share a flow’s packets (or, more commonly, load-share flows) across all three simultaneously, all driven by what vSmart handed down over OMP.

This is worth contrasting directly with Arista’s approach to the same problem: Arista’s overlay leans on actual BGP peering between Edge Connect devices and Gateways for underlay-facing reachability, then layers DMPO path selection on top for the overlay forwarding decision — two separate mechanisms doing two separate jobs. Cisco collapses both into OMP: one protocol carries the reachability and expresses the multipath forwarding intent, because TLOC-aware multipath was a day-one design requirement rather than a feature bolted onto a borrowed protocol.

Overlay and underlay are different address families, on purpose

It’s worth being explicit about a distinction that’s implicit in everything above: the underlay is whatever IP transport actually exists between sites — an MPLS VPN, a residential or business Internet circuit, an LTE/5G link — and all the underlay ever needs to know is how to get a packet from one TLOC’s public/private IP to another’s. It does not need to know anything about the actual LAN subnets sitting behind each WAN Edge. The overlay is the OMP-distributed set of site prefixes — the actual /24s, /23s, whatever a branch’s LAN looks like — riding inside IPsec tunnels built between TLOCs.

This separation is precisely why a Catalyst SD-WAN fabric can run happily across an Internet transport with heavy NAT in the middle, an MPLS transport with full any-to-any underlay reachability, and an LTE failover link with carrier-grade NAT, all at once, without the overlay routing table caring even slightly about which underlay topology it’s riding on. The underlay’s job is “get this TLOC’s traffic to that TLOC.” The overlay’s job is “this site’s /24 is reachable, and here are the TLOCs to use to get there.” Conflating the two — trying to reason about branch LAN reachability in underlay terms — is the single most common source of confusion when engineers new to this architecture start troubleshooting, and it’s worth internalizing now because the entire rest of this series builds on keeping them separate in your head.

What it looks like on the box

A (simplified, redacted) show omp routes on a WAN Edge with three transports:

VPN PREFIX FROM PEER PATH-ID PREF METRIC STATUS
1 10.20.30.0/24 10.1.0.2 0 100 0 C,Red
1 10.20.30.0/24 10.1.0.2 1 100 0 C,Red
1 10.20.30.0/24 10.1.0.2 2 100 0 C,Red

Three path-IDs for the same prefix means three valid TLOC paths are installed — this site is reachable over all three transports simultaneously, with C flagging each as a chosen/installed path. A corresponding show omp tlocs would show the three (system-ip, color, encap) tuples those path-IDs resolve to — exactly the TLOC routes described above. We’ll dig into what color (here standing in for Red) actually constrains in Part 3, including the restrict/no-restrict behavior that decides whether an edge is even allowed to consider a given color as a candidate path in the first place.

Next

Part 3 picks up the TLOC thread properly: what color means as a first-class attribute (not just a label), how restrict/no-restrict changes which TLOCs can pair with which, what a service route looks like wired into centralized policy end-to-end, and how localized policy differs from the centralized policy vSmart enforces.