# Cisco SD-WAN OMP Deep-Dive: — Routes, TLOCs, Service Routes & Path Selection Source: https://ai.techclick.in/blog_cisco_sdwan_omp Markdown: https://ai.techclick.in/blog_cisco_sdwan_omp.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN OMP explained for L1/L2 engineers + ENSDWI 300-415: the 3 OMP route types (OMP routes, TLOCs, service routes), redistribution, best-path order, timers, graceful restart, send-path-limit and show sdwan omp. Cisco SD-WAN OMP Deep-Dive: — Routes, TLOCs, Service Routes & Path Selection student learning map A visual study map for Cisco SD-WAN OMP Deep-Dive: — Routes, TLOCs, Service Routes & Path Selection showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN OMP Deep-Dive: — Routes, TLOCs, Service... Cisco SD-WAN · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① What OMP is — the overlay's own... 4. Practice ② The 3 OMP route types — prefix,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. 👉 So far: OMP = the overlay's routing protocol, edge↔vSmart only, BGP-style reflector model. Next we'll draw exactly who peers with whom. Figure 1 — OMP peers only with vSmart — never edge-to-edge Three WAN Edge routers each open one OMP peering session to the central vSmart controller over the DTLS control connection. There is no OMP session edge-to-edge. The vSmart learns every prefix and TLOC, runs best-path, and reflects the result back to all edges, so each edge gets a full map of the overlay without talking routing to its peers. OMP runs edge↔vSmart only — the controller is the overlay's map-maker vSmart Controller runs OMP best-path · reflects routes WAN Edge · Mumbai MPLS Internet WAN Edge · Delhi MPLS Internet WAN Edge · Pune MPLS Internet - OMP over DTLS no OMP edge-to-edge — IPsec data tunnels only (no routing here) one session per edge — like BGP to a route-reflector underlay / untrusted overlay / trusted control / policy key insight allowed / SLA-met Follow the amber dashed lines: every edge has ONE OMP session up to vSmart, none across the bottom. The data plane (IPsec) is edge-to-edge, but the routing brain is not. 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. 🧭 OMP = overlay routing tap to flip 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. 🪞 vSmart = route-reflector tap to flip 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. 🏷️ Three route types tap to flip 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. ⚖️ Best-path like BGP tap to flip OMP preference = local-pref, plus origin type/metric and TLOC checks. Equal paths → active/active. So: tuning OMP is tuning the overlay. Quick check · Q1 of 10 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? a) By design, edges run OMP only to vSmart; there is no edge-to-edge OMP session b) OMP is broken — edges must peer directly c) He needs to enable OMP — it's off by default d) Only vBond/Validator runs OMP Correct: a. OMP peers edge↔vSmart (and controller↔controller) only — like clients to a route-reflector — so an edge-to-edge OMP neighbour never exists and its absence is normal. OMP is on by default (not off), and vBond/Validator handles onboarding/authentication, not OMP route exchange. 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. Reveal answer Answer: Losing reachability to vSmart (all of them, or the controller itself going down). Because vSmart is the only OMP peer each edge has, if the controller is unreachable no new routes are learned or reflected. Existing routes survive for a while via graceful restart, but the overlay stops adapting — which is exactly why you deploy redundant vSmarts. ## ② 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. Figure 2 — Three OMP route types — three jobs A three-column comparison of the OMP route types. The OMP route carries the actual prefix with attributes origin, originator, preference, TLOC next-hop and VPN label. The TLOC route is the transport locator, a three-tuple of system-IP, color and encapsulation that says reach-me-here. The service route advertises a network service such as firewall or IPS for service insertion, keyed by a service ID. Each column lists what it carries and what breaks if it is missing. The 3 OMP route types — three jobs, one protocol OMP route (vRoute) "here is a PREFIX" 10.10.10.0/24, VPN 10 carries: origin, originator (sys-IP) preference, origin-metric TLOC next-hop, site-id VPN label, tag no TLOC resolved → prefix known but unusable TLOC route "reach ME at this transport" 10.255.255.1 · mpls · ipsec 3-tuple: system-IP + color + encap plus: public/private IP, weight preference, site-id TLOC down → every prefix via it goes too Service route "a SERVICE lives here" FW=1, IDS/IPS=2, IDP=3 carries: VPN-ID, service-id originator, TLOC custom netsvc1-4 = 4-7 used by service-chaining policy to steer via FW/IPS Mnemonic: OMP route = WHAT (prefix) · TLOC = WHERE (transport) · service route = via WHICH box (firewall/IPS) Read the three columns side by side: prefix vs transport-locator vs service. The red lines at the bottom of each column are the failure you'll actually troubleshoot. cEdge CLI — see all three route types 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 Expected output 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 Read the flags, not just the prefix 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. Quick check · Q2 of 10 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? a) The service route — a firewall is blocking it b) The TLOC route — the next-hop TLOC may not be resolved or its tunnel is down c) Nothing; "R" means installed d) The DNS record for the prefix Correct: b. An OMP route resolves into a next-hop TLOC; if that TLOC isn't reachable (no up IPsec tunnel) the prefix stays received-but-not-installed. So the next check is show sdwan omp tlocs for that next-hop. "R" means received, not installed; service routes are for service insertion, not basic reachability; DNS is unrelated to the OMP RIB. 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. Reveal answer Answer: Two TLOCs — the edge has two transports (e.g. MPLS and Internet), so the same prefix is advertised once per TLOC/next-hop. Same prefix, same metric, two locators. If they tie all the way through best-path, you get active/active ECMP across both transports — provided send-path-limit lets both through. ## ③ 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. cEdge CLI add-on — redistribute service-side routes into OMP (VPN 10) config-transaction sdwan omp address-family ipv4 vrf 10 advertise connected advertise static redistribute ospf redistribute bgp 65010 ! commit Expected output Branch-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 🖥️ This is the screen you'll read OMP on in the GUI — vManage → Monitor → Devices → (select WAN Edge) → Real Time , then pick the OMP table. (Recreated for clarity — your console matches this.) vmanage.lab.local · Monitor · Devices · Real Time 1 Device Branch-Delhi (cEdge) 2 Real Time table OMP Received Routes 3 VPN 10 Prefix 10.10.10.0/24 4 Status / Attr C,I,R · pref 0 · origin connected Next-hop TLOC 10.255.255.1 · mpls · ipsec Search Figure 4 — OMP cheat-sheet — best-path order, defaults & show commands A cheat-sheet card. Left column lists the OMP best-path tie-break order from active-over-stale down to lowest private TLOC IP. Middle lists key attributes and default values: OMP preference 0, admin distance 250 on vEdge and 251 on cEdge, send-path-limit 4, ecmp-limit 4, graceful-restart 43200 seconds, holdtime 60 seconds, advertisement-interval 1 second. Right column lists the three troubleshooting show commands for routes, tlocs and services. OMP cheat-sheet — keep this open in the lab and before the exam Best-path order (top wins) 1 · ACTIVE > STALE (graceful-restart) 2 · valid: next-hop TLOC reachable 3 · lower admin distance 4 · higher OMP preference 5 · higher TLOC preference 6 · lower origin type 7 · lower origin metric 8 · vEdge > vSmart sourced 9 · lower router-id / system-IP 10 · lower private TLOC IP ties through step 8 → ECMP (active/active) send-path-limit caps how many ties advertised ecmp-limit caps how many the edge installs Defaults to memorise OMP preference ...... 0 AD vEdge / cEdge ... 250 / 251 send-path-limit ... 4 (1-16) ecmp-limit ........ 4 graceful-restart .. 43200s holdtime .......... 60s advertise-interval 1s redistribution auto: connected, static explicit: BGP, OSPF, EIGRP service IDs: FW=1 IDS/IPS=2 IDP=3 · custom 4-7 show commands show sdwan omp peers show sdwan omp summary show sdwan omp routes → prefixes + attrs (C/I/R flags) show sdwan omp tlocs → is the transport locator UP? show sdwan omp services → FW/IPS service routes flags: C=chosen I=installed R=received Red=received but not best old vEdge: drop "sdwan" → show omp ... Read the overlay as a graph: routes = WHAT, TLOCs = WHERE, peers/summary = is the map even being shared. underlay / untrusted overlay / trusted control / policy key insight allowed / SLA-met Your one-card revision sheet. Keep it open in the lab and skim it the night before the ENSDWI exam — left = order, middle = defaults, right = the three show commands. Common mistake — "vSmart shows 2 paths, my branch only uses 1" 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. Common mistake — "the prefix is in OMP but traffic still fails" 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. Next: The Data Plane — TLOCs, Colors, IPsec & BFD Recap: WAN Edge Onboarding Prove you've got OMP cold 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. Quick check · Q4 of 10 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? a) send-path-limit b) Administrative distance c) Graceful restart (default 43,200 s window) d) Service routes Correct: c. Graceful restart lets an edge keep forwarding on last-known OMP routes (marked STALE) when its vSmart session drops, for up to the graceful-restart-timer (default 12 hours) — exactly the "traffic kept flowing during a controller reboot" behaviour. send-path-limit caps advertised paths, AD ranks sources on one edge, and service routes are for service insertion. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why doesn't OMP run edge-to-edge like BGP between routers? What's the real difference between an OMP route and a TLOC route? Which routes does OMP redistribute automatically and which do I have to configure? How do I make one transport preferred without breaking redundancy? Why are two equal paths a good thing, not a tie I must break? What show commands do I run first when OMP misbehaves? 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. Q5 · Remember In Cisco SD-WAN, which devices does a WAN Edge run OMP with? a) Every other WAN Edge, in a full mesh b) Only vBond / the Validator c) Only the vSmart controller (and controllers peer with each other) d) Only the LAN-side IGP Correct: c. OMP runs edge↔vSmart (and controller↔controller) only — like clients to a route-reflector. There is no edge-to-edge OMP. vBond/Validator handles onboarding/authentication, not OMP; the LAN IGP is service-side, separate from OMP. Q6 · Apply You need a branch's OSPF-learned LAN routes to reach every other site. Connected routes already appear fabric-wide but the OSPF ones don't. What do you do? a) Nothing — OMP redistributes OSPF automatically b) Add 'redistribute ospf' (or 'advertise ospf') under the OMP address-family for that VRF c) Lower the OMP administrative distance d) Set send-path-limit to 1 Correct: b. OMP auto-redistributes connected and static (hence those appear) but NOT OSPF/BGP/EIGRP/IS-IS — you must explicitly redistribute/advertise them per VRF. AD only matters on the same edge across protocols; send-path-limit 1 would break multipath, not fix redistribution. Q7 · Apply A critical prefix should prefer the MPLS transport but keep Internet as backup, without touching IGP metrics. Which OMP lever? a) Raise OMP preference (or TLOC preference) on the MPLS path b) Disable the Internet TLOC c) Increase the holdtime to 120 s d) Reduce ecmp-limit to 1 Correct: a. OMP preference (step 4, like local-pref) or TLOC preference (step 5) selects MPLS while leaving Internet installed as backup. Disabling the Internet TLOC removes redundancy; holdtime governs session liveness; ecmp-limit 1 just caps installed paths and doesn't express a preference. Q8 · Analyze A far site shows prefix 172.16.5.0/24 in OMP as STATUS 'R' but never 'C,I', and traffic to it drops. Control connections to vSmart are healthy. Most likely root cause? a) OMP is disabled on the source edge b) The prefix's next-hop TLOC isn't resolved / has no up tunnel — resolved but not installed c) The OMP licence expired d) send-path-limit is too high Correct: b. Received-but-not-installed (R, not C,I) with healthy control connections points at the next-hop TLOC: if it's unresolved or its IPsec tunnel is down, the prefix can't be installed. Check show sdwan omp tlocs / bfd sessions. OMP isn't off (you see the route), there's no per-prefix licence, and a high send-path-limit doesn't suppress install. Q9 · Analyze vSmart shows two equal-cost OMP routes for a prefix (MPLS and Internet), but each branch installs only one transport, so one link sits idle. What single setting most likely caused this? a) Graceful restart is enabled b) OMP preference is 0 on both c) The advertisement-interval is 1 s d) send-path-limit is set to 1, so vSmart reflects only one of the tied paths Correct: d. send-path-limit caps how many equal-cost paths vSmart advertises; at 1 it reflects only one of the tied routes, so edges install a single transport and you lose active/active. Graceful restart aids failover, equal preference (0) is fine for ECMP, and the 1 s advertisement-interval is just the default cadence. Q10 · Evaluate Two designs for a dual-transport branch: (A) hard-set send-path-limit 1 and pick MPLS, leaving Internet purely as a cold standby; (B) leave send-path-limit at its default and let equal paths run active/active, using OMP preference only when you truly need MPLS-first. Which is the better default and why? a) A — fewer paths is always simpler and safer b) B — default send-path-limit keeps both transports usable (active/active or fast failover), and preference still lets you bias MPLS per-prefix when needed c) A — Internet should never carry production traffic d) Identical — send-path-limit doesn't affect forwarding Correct: b. Design B uses both links (active/active when tied, instant failover otherwise) and still allows MPLS-first via OMP/TLOC preference where it matters — getting redundancy and value from the second circuit. Design A silently disables multipath and wastes a paid transport; send-path-limit absolutely affects which paths are advertised and therefore forwarded. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: Because an OMP route only carries the prefix plus a next-hop TLOC — until that TLOC resolves and an IPsec tunnel to it is actually up, the prefix is received but not installed ("resolved but not installed"), so there's no path to forward on even though the address is in the OMP table. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on OMP at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · The Data Plane: TLOCs, Colors, IPsec & BFD → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt