Most engineers think…
Most engineers think OMP is "just BGP with a new name" — every edge peers with every other edge, swaps full routing tables, and you read it like a normal IGP. So they go hunting for an OMP neighbour between two branches.
Wrong — and you'll waste an hour looking for a peering that never exists. OMP runs only between each WAN Edge and vSmart (and between controllers), exactly like every router peering with a single route-reflector. An edge never runs OMP to another edge. And OMP carries three different things at once — prefixes (OMP routes), transport locators (TLOCs) and service locations (service routes) — so a prefix can be "known" yet unusable until its TLOC resolves. Read OMP as a control plane that hands you a map, not as an IGP full mesh.
① What OMP is — the overlay's own routing protocol
Once your WAN Edges are onboarded and the control connections are up (lesson 1), they need to learn each other's networks. They don't run OSPF or BGP across the WAN to do that — they run OMP (Overlay Management Protocol). OMP is the fabric's own routing protocol. It is enabled by default the moment a device joins the overlay during zero-touch onboarding — you don't switch it on, you tune it.
The one sentence that saves you an hour of confusion: OMP runs only between each WAN Edge and the vSmart controller (and between controllers themselves). Two branches never run OMP to each other. Each edge opens exactly one OMP peering session to vSmart — over the secure DTLS control connection — even though it may have several physical transports. vSmart learns everything, runs best-path, and reflects the winners back down.
If that pattern feels familiar, it should: OMP is the BGP of the overlay. vSmart is the route-reflector; the WAN Edges are the clients. The attributes even rhyme with BGP — OMP preference behaves like BGP local-preference (higher wins), there's an origin type and an origin metric, and vSmart reflects routes without being in the data path. The analogy is so close that the ENSDWI 300-415 blueprint expects you to configure and verify OMP under the Router Deployment domain.
Why centralise the brain? Because it scales and it lets policy live in one place. In a full mesh of n sites you'd need roughly n² routing adjacencies; with OMP you need n sessions to vSmart. And because every route passes through vSmart, a single control policy on the controller can reshape what each branch sees, without touching a single edge. The trade-off: if an edge can't reach vSmart, it stops learning new routes (it keeps the last known set via graceful restart — more on that in section 4).
Four anchors before we go deeper
Tap each card — these four ideas carry the whole lesson.
The fabric's own routing protocol, on by default. Carries prefixes, locators and services between edges and vSmart. So: no OSPF/BGP across the WAN core.
Each edge peers ONLY with vSmart over DTLS. vSmart runs best-path and reflects winners. So: never hunt for an edge-to-edge OMP neighbour.
OMP routes (the prefix), TLOC routes (where to reach it), service routes (firewall/IPS). One protocol, three jobs. So: a prefix needs its TLOC to be usable.
OMP preference = local-pref, plus origin type/metric and TLOC checks. Equal paths → active/active. So: tuning OMP is tuning the overlay.
Rahul at Infosys greps every WAN Edge for an OMP neighbour pointing at the branch next door and finds none. He opens a ticket saying "OMP is broken between sites." What's actually true?
Pause & Predict
Predict: if EVERY WAN Edge peers only with vSmart and never with each other, what single failure would stop all of them from learning any NEW routes at once? Type your guess.
② The 3 OMP route types — prefix, locator, service
OMP is one protocol carrying three kinds of advertisement, and mixing them up is the single most common OMP confusion. The three are OMP routes (the actual prefixes), TLOC routes (the transport locators), and service routes (firewall/IPS and friends). Think of a courier: the OMP route is the delivery address, the TLOC is which gate of the building to use, and the service route is which security desk to pass through on the way.
OMP routes (vRoutes) — the prefixes
An OMP route is the prefix itself — say 10.10.10.0/24 in VPN 10 — bundled with its attributes: the origin (was it connected, static, BGP, OSPF?), the originator (the advertising edge's system-IP), an OMP preference, an origin-metric, the site-id, a tag, a VPN/service label for segmentation, and — crucially — a next-hop TLOC. That next-hop TLOC is the link to the second route type. An OMP route with no resolvable TLOC is a known address with no way to get there.
TLOC routes — the transport locators
A TLOC answers "reach me here." It's a 3-tuple: the system-IP of the edge, a colour (mpls, biz-internet, public-internet, lte…), and an encapsulation (ipsec or gre). One edge with two transports advertises two TLOCs. Along with the tuple, a TLOC route carries its public/private IP, a weight (for unequal load-sharing), a preference, the site-id and tags. The OMP route's next-hop points at a TLOC; the TLOC is what the IPsec data tunnel is actually built to. If a TLOC goes down, every prefix that resolved through it goes with it — which is why TLOCs get their own colours and the next lesson.
Service routes — firewall, IPS and service insertion
A service route advertises that a network service lives behind a given edge, so a centralised policy can steer traffic through it — that's service insertion. Each carries a VPN-ID, an originator and a TLOC, keyed by a well-known service-id: FW = 1, IDS/IPS = 2, IDP = 3, and custom netsvc1–4 = 4–7. You'll see these with show sdwan omp services. No service route, no service chaining — the policy has nothing to point at.
Branch-Delhi# show sdwan omp routes 10.10.10.0/24 | tab Branch-Delhi# show sdwan omp tlocs | tab Branch-Delhi# show sdwan omp services | tab
PATH ATTRIBUTE TENANT VPN PREFIX FROM PEER ID STATUS TYPE TLOC IP COLOR ENCAP PREF ---------------------------------------------------------------------------------------- 0 10 10.10.10.0/24 10.255.255.3 66 C,I,R installed 10.255.255.1 mpls ipsec 0 0 10 10.10.10.0/24 10.255.255.3 67 R installed 10.255.255.1 biz-int ipsec 0 ADDRESS COLOR ENCAP STATUS PREF WEIGHT (omp tlocs) 10.255.255.1 mpls ipsec C,I,R 0 1 VPN SERVICE ORIGINATOR TLOC IP COLOR STATUS (omp services) 10 FW 10.255.255.5 10.255.255.5 mpls C,I,R
In show sdwan omp routes the STATUS letters are your fastest diagnosis: C = chosen (won best-path), I = installed (in the RIB/forwarding), R = received from vSmart. A route that's R but not C,I was received but lost best-path or its TLOC didn't resolve. "C but not I" means chosen but the tunnel to its TLOC isn't up. You learn to read these three letters before you read anything else.
Priya at ICICI sees prefix 172.16.5.0/24 in the OMP table as STATUS "R" but it never becomes "C,I" and traffic fails. Which route type should she check next?
Pause & Predict
Predict: a branch advertises ONE LAN prefix but the OMP table at vSmart shows it twice with the same metric. What real-world thing produces two OMP routes for one prefix? Type your guess.
③ Redistribution & best-path — in and out of OMP
OMP only carries the overlay. Your branch LAN routes live in the service-side VRF, learned by an IGP, BGP, or as connected/static. To make them reachable across the fabric you redistribute them into OMP on the advertising edge; to hand the overlay's routes back to the LAN you redistribute OMP into the IGP/BGP. Get the direction wrong and you either black-hole the branch or create a loop.
The defaults matter and are exam-favourite trivia: OMP automatically redistributes connected and static routes from the service VPNs once it sees them. BGP, OSPF, EIGRP and IS-IS are NOT automatic — you must explicitly redistribute them into OMP, or use advertise. The reason is safety: auto-pulling a full BGP table into the overlay would be reckless, so Cisco makes you ask.
config-transaction
sdwan
omp
address-family ipv4 vrf 10
advertise connected
advertise static
redistribute ospf
redistribute bgp 65010
!
commitBranch-Mumbai# show sdwan omp routes vpn 10 | i 10.10. 0 10 10.10.10.0/24 - C,Red,R installed connected 0 10 10.20.0.0/16 - C,Red,R installed ospf-external % routes now advertised to vSmart and reflected to all sites
Now best-path. When vSmart (or the receiving edge) has more than one OMP route for the same prefix, it walks an ordered list of tie-breaks — and like BGP, the first difference wins. Memorise the order; the exam loves it and so do real outages:
1. ACTIVE beats STALE (a stale route comes from a peer in graceful-restart). 2. Route must be valid — its next-hop TLOC has to be known and reachable. 3. Lower administrative distance (OMP's AD is 250 on vEdge, 251 on cEdge — only compared when one edge learns the same prefix from several protocols). 4. Higher OMP preference (default 0, works like BGP local-pref). 5. Higher TLOC preference. 6. Lower origin type (connected < static < eBGP < OSPF-intra < … < iBGP < unknown). 7. Lower origin-metric. 8. vEdge-sourced beats vSmart-sourced. 9. Lower router-id / system-IP. 10. Lower private TLOC IP.
Here's the payoff that confuses people: two equal paths give you active/active. If two OMP routes for a prefix tie all the way through the order (two transports, same metrics), they don't fight — both get installed and traffic is load-shared ECMP across both TLOCs. That's the default behaviour, and it's why an SD-WAN branch with MPLS + Internet uses both links at once instead of leaving one idle.
▶ Follow one prefix through OMP best-path
Watch 10.10.10.0/24 get advertised, picked, reflected, and resolved into a usable route. Press Play for the healthy path, then Break it to see the failure.
Aditya at Flipkart faces this
Aditya, an L2 engineer, redistributes the branch BGP routes into OMP. Within minutes a few prefixes start flapping and a routing loop alarm fires between BGP and OMP at a dual-router site.
At a site with two WAN Edges, a prefix learned from the LAN via BGP gets into OMP, comes back to the second edge via OMP, is redistributed back into BGP, and re-enters OMP — a classic BGP↔OMP feedback loop because there's no site-origin tag to say "this came from my own site."
He checks origin and notices the same prefix oscillating between bgp and omp origin types on the two co-located edges — the loop signature.
vManage → Monitor → Devices → (edge) → Real Time → OMP Received Routes / BGP Routes; compare origin typeTag routes with Site-of-Origin (SoO) so an edge won't re-advertise into BGP a prefix that originated at its own site, breaking the OMP↔BGP loop. (Match SoO on the BGP side and set it consistently across both edges.)
After applying SoO, the prefix shows a single stable origin, the flap counter stops, and show sdwan omp routes shows steady C,I,R with no oscillation.
Karthik at TCS wants the MPLS path preferred over Internet for a critical prefix, cleanly, without touching IGP metrics. Which OMP lever is the intended one?
Pause & Predict
Predict: you redistribute OSPF into OMP on a branch but the routes never reach other sites — yet connected routes from the same VRF DO show up. What did you forget? Type your guess.
④ Timers, graceful restart & reading the overlay
OMP has a small set of timers, and two of them show up in interviews. Graceful restart is the safety net — if an edge loses its vSmart session, it keeps forwarding on the last-known routes (now marked STALE) instead of black-holing. The default window is a generous 43,200 seconds (12 hours), tunable from 1 second up to 7 days. That's why "vSmart rebooted but traffic kept flowing" is normal, not luck.
The other defaults to keep in your head: OMP holdtime 60 s (miss the keepalives within it and the session drops), advertisement-interval 1 s, OMP preference 0, send-path-limit 4 (range 1–16), and ecmp-limit 4 on the install side. send-path-limit caps how many tied paths vSmart will advertise; ecmp-limit caps how many the edge will install. Set send-path-limit to 1 and you've quietly killed active/active — a real, easy-to-miss outage.
vSmart(config)# omp vSmart(config-omp)# send-path-limit 6 vSmart(config-omp)# graceful-restart vSmart(config-omp)# timers holdtime 60 advertisement-interval 1 vSmart(config-omp)# commit Branch# show sdwan omp summary | i path-limit|graceful|holdtime
graceful-restart : enabled graceful-restart-timer : 43200 holdtime : 60 advertisement-interval : 1 send-path-limit : 6 routes-received : 184 routes-installed : 176
Reading the overlay is reading a graph: routes = WHAT, TLOCs = WHERE, peers/summary = is the map even being shared. Your three workhorse commands are show sdwan omp routes (prefixes + attributes + C/I/R flags), show sdwan omp tlocs (is the locator up?), and show sdwan omp services (firewall/IPS service routes). Start with show sdwan omp peers/summary — if the OMP session to vSmart is down, nothing else matters. On legacy vEdge the syntax drops the keyword: show omp routes.
Symptom: an edge installs a single transport for a prefix even though MPLS and Internet are both up and tied. Cause: send-path-limit on vSmart is 1 (or lower than the number of tied paths), so only one path is ever reflected. Fix: set omp send-path-limit 4 (or higher, up to 16) on vSmart, and make sure the edge's ecmp-limit is ≥ the number of paths. Then both TLOCs install and you get active/active.
Symptom: show sdwan omp routes lists the prefix as received (R) but never C,I, and pings drop. Cause: the next-hop TLOC isn't resolved or there's no up IPsec tunnel to it — "resolved but not installed." Fix: check show sdwan omp tlocs and show sdwan bfd sessions for that TLOC; bring the transport/tunnel up and the route installs. No reachable TLOC = no usable prefix, every time.
Take any ask — "make this branch prefer MPLS but keep Internet as backup, and tell me why a far site can't reach it." Name the protocol (OMP, edge↔vSmart only), the lever (raise OMP/TLOC preference on MPLS), the three route types you'd check (OMP route → its TLOC → service route if chaining), the best-path step that decided it (preference, step 4), and the command to prove it (show sdwan omp routes with C,I,R). If you can do that cold, you're ready for the SOC floor and the 300-415.
Meera at Airtel reboots a vSmart for maintenance. For the next few minutes branch traffic keeps flowing on routes marked STALE, then recovers. Which OMP feature made the data plane survive?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: In one line, why can an OMP route be "known" at a branch yet still be unusable? Then compare to the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- OMP (Overlay Management Protocol)
- Cisco SD-WAN's own routing protocol; TCP-based, on by default, runs inside the DTLS control connection between edges and vSmart.
- OMP route (vRoute)
- An advertised IP prefix in a VPN plus attributes (origin, originator, preference, next-hop TLOC, label); the 'what' of reachability.
- TLOC (Transport Locator)
- Where to reach an edge: a 3-tuple of system-IP + colour + encapsulation (e.g. 10.255.255.1 · mpls · ipsec); the data tunnel is built to it.
- Service route
- OMP advertisement that a service (FW=1, IDS/IPS=2, IDP=3, custom 4–7) lives behind an edge, so policy can steer traffic through it.
- vSmart (Catalyst SD-WAN Controller)
- The OMP route-reflector and best-path engine; not in the data path, but every route passes through it.
- OMP preference
- Per-route attribute, default 0, higher wins — behaves like BGP local-pref; step 4 of best-path and the usual path-preference lever.
- Administrative distance (OMP)
- Trust ranking of OMP, default 250 on vEdge / 251 on cEdge; compared only when one edge learns a prefix from multiple protocols.
- Best-path order
- OMP's 10 ordered tie-breaks: active>stale, valid TLOC, lower AD, higher pref, higher TLOC pref, lower origin type, lower metric, vEdge>vSmart, lower system-IP, lower private TLOC IP.
- send-path-limit
- Max equal-cost OMP routes a vSmart/edge advertises per prefix; default 4, range 1–16; set to 1 and active/active silently breaks.
- ecmp-limit
- Max equal-cost paths an edge installs into its forwarding table; default 4; the install-side cap that pairs with send-path-limit.
- Graceful restart
- Lets an edge keep forwarding on last-known (STALE) OMP routes if its vSmart session drops; default window 43,200 s (12 h), up to 7 days.
- Service insertion
- Forcing selected traffic through a firewall/IPS via OMP service routes and centralised policy — also called service chaining.
📚 Sources
- Cisco — Routing Configuration Guide, Cisco IOS XE Catalyst SD-WAN Release 17.x — 'Overlay Management Protocol': OMP overview, route advertisements, redistribution, configure OMP (graceful-restart, timers, send-path-limit). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/
- Cisco — IOS XE Catalyst SD-WAN Qualified Command Reference, 'OMP Commands' (advertise, redistribute, distance, send-path-limit default 4 range 1–16, graceful-restart-timer default 43200, timers holdtime 60 / advertisement-interval 1). cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-omp-commands.html
- Cisco Support TechNote 217479 — 'Troubleshoot OMP Best-path Selection Peculiarities and Typical Confusions' (full ordered best-path algorithm, AD 250/251, active vs stale). cisco.com/c/en/us/support/docs/routers/sd-wan/217479-omp-best-path-selection-peculiarities-an.html
- Cisco Support TechNote 218089 — 'Troubleshoot OMP Route Instability in Failover Scenario' (graceful restart, stale routes, send-path-limit behaviour in failover). cisco.com/c/en/us/support/docs/routers/sd-wan/218089-troubleshoot-omp-route-instability-in-fa.html
- Cisco Support TechNote 215992 — 'Resolve BGP-OMP Routing Loop when BGP Routing and SoO Are Used' (the dual-edge BGP↔OMP loop and the Site-of-Origin fix). cisco.com/c/en/us/support/docs/routers/sd-wan/215992-how-to-avoid-bgp-omp-routing-loop-in-sd.html
- Cisco Community — 'SD-WAN Controller - OMP best path selection' and 'OMP route Resolved but not Installed' (real practitioner confusion on best-path and resolved-but-not-installed TLOC state). community.cisco.com/t5/sd-wan-and-cloud-networking/
- NetworkAcademy.IO — CCIE Enterprise SD-WAN: 'OMP Overview', 'OMP Best-Path Selection', 'OMP Send Path Limit' (ordered algorithm, ECMP/active-active, send-path-limit default 4). networkacademy.io/ccie-enterprise/sdwan/omp-overview
- Cisco Learning Network — 'Implementing Cisco SD-WAN Solutions (ENSDWI 300-415) v1.2' exam topics — Router Deployment: Configure OMP; Architecture: control plane (vSmart, OMP). learningnetwork.cisco.com/s/ensdwi-exam-topics
What's next?
You can now read the overlay's routing brain. Next we drop to the data plane: how a TLOC's colour, encapsulation and BFD actually build and watch the IPsec tunnels your OMP routes ride on.