Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

OMP and TLOC Selection: The Route Is Chosen and Still Not Installed

Software Defined Infrastructure ｜ Concept ｜ Advanced ｜ 21 min read

OMP looks like BGP and is frequently explained by that comparison, which gets you about half way. Both distribute reachability from many speakers through a reflector, both carry attributes, both run a deterministic selection algorithm. The difference that matters is that OMP does not advertise a prefix with a next hop — it advertises a prefix with a tunnel endpoint identity, and that identity has to be independently reachable before the prefix is usable at all.

That indirection is the source of most confusion. A prefix can be present, valid and correctly chosen, and still not be installed, because the tunnel endpoint it points at cannot be reached. The route table and the tunnel table are two separate things that have to agree, and reading one without the other produces a confident and wrong conclusion. Anyone who has stared at a route that is clearly there while traffic clearly does not flow has met this.

This article covers what OMP actually advertises — three distinct kinds of thing, not one — what a tunnel endpoint identity is made of and why it is the unit of path selection, the selection algorithm in order, how centralised policy changes what an edge receives, and the failures that read as routing problems and are resolution problems. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

Blog ClaimAn OMP route is not usable until the tunnel endpoint it names is separately reachable, which is why the most common SD-WAN routing symptom is a prefix that is present, chosen, and not installed — and why reading the route table alone can never explain it.

OMP advertises prefixes, tunnel endpoints and services as three separate things. A prefix points at a tunnel endpoint rather than a next hop, and that endpoint must be independently reachable.

What Does OMP Actually Advertise?

What are the three kinds?

Prefixes from the service side, each pointing at a tunnel endpoint rather than at a next hop. Tunnel endpoint identities themselves, which is what those prefixes point at. And service advertisements, saying that a particular kind of appliance is available at a site, which is what service chaining consumes. They are separate advertisement types with separate tables, and a problem in one does not necessarily show in the others.

A Deeper Dive into the Advertisements

What gets advertised, and what does not

An edge advertises what it has been told to advertise, per protocol and per service context. This is not automatic: routes learned from a branch's routing protocol do not enter the overlay unless the configuration says to include that protocol. A branch whose prefixes are missing from everyone else's tables, with a healthy control connection, is nearly always missing one line of this.

! Nothing enters the overlay unless it is advertised
sdwan
 omp
  no shutdown
  graceful-restart
  advertise connected
  advertise static
  advertise ospf external
  address-family ipv4
   advertise bgp
  exit
 exit
!
! Confirm what this edge is putting into the overlay
Edge# show sdwan omp routes advertised
Edge# show sdwan omp summary | include advertised|received

Reading the route table properly

The output carries a status field, and it is the field that answers most questions. Chosen means selection picked it. Installed means it reached the forwarding table. Resolved means the tunnel endpoint it names was found. A route that is chosen and not installed has failed at resolution, and that single distinction separates a policy question from a tunnel question.

! The status letters are the whole diagnosis
Edge# show sdwan omp routes vpn 10
                                       PATH   ATTRIBUTE
VPN  PREFIX          FROM PEER    ID   LABEL  STATUS     TLOC IP        COLOR
--------------------------------------------------------------------------------
10   10.10.20.0/24   10.255.0.2   12   1002   C,I,R      10.255.1.12    mpls
10   10.10.20.0/24   10.255.0.2   13   1002   R          10.255.1.12    biz-internet
10   10.10.30.0/24   10.255.0.2   14   1003   C,R        10.255.1.13    mpls
!                                              ^ chosen and resolved,
!                                                but NOT installed
!
! Full detail for one prefix, including every attribute
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 detail

The tunnel endpoint table

Separate from the routes, and the place to look the moment a route is chosen and not installed. It lists every endpoint the edge knows about, with its addresses, its preference and weight, and — critically — whether it is up. An endpoint present but not up means the control plane knows about a site the data plane cannot currently reach.

! Every tunnel endpoint this edge has learned
Edge# show sdwan omp tlocs
ADDRESS                                          PUBLIC       PUBLIC
FAMILY   TLOC IP        COLOR         ENCAP  IP           PORT    STATUS
-----------------------------------------------------------------------
ipv4     10.255.1.12    mpls          ipsec  10.1.12.1    12386   C,I,R
ipv4     10.255.1.12    biz-internet  ipsec  203.0.113.42 12386   C,I,R
ipv4     10.255.1.13    mpls          ipsec  10.1.13.1    12386   C,R
!
! And whether a live tunnel exists to it
Edge# show sdwan bfd sessions
! ^ A TLOC without a BFD session is why a route stays
!   chosen and uninstalled.

Labels and how a prefix reaches the right context

Each service-side routing context is identified by a label carried with the advertisement, which is what allows one pair of tunnels between two sites to carry traffic for many isolated contexts without them mixing. The tunnel is shared; the label keeps the contexts apart. This is the same idea as a label-switched VPN and it has the same consequence: two sites need one tunnel pair regardless of how many isolated networks they exchange.

Practically, this matters when a prefix arrives in the wrong context or not at all. The context identifier has to match at both ends for traffic to land where it should, and a mismatch produces a prefix that is present in the overlay and absent from the context somebody is looking in. Checking which context a route was received into is a distinct step from checking whether it was received.

Service advertisements

A site can announce that it hosts a firewall or another inspection service, and central policy can then direct traffic through it. The advertisement is what makes the service addressable by policy rather than by address, which is what allows a policy to say "send this through the firewall" without naming where the firewall is. It is a separate table again, and an empty one on a site that should be offering a service is the first thing to check when a service chain does not engage.

! Advertising a service from the site that hosts it
vrf definition 10
!
sdwan
 service FW address 10.10.10.250
!
! What services the overlay knows about
Edge# show sdwan omp services
ADDRESS                                     PATH
FAMILY   VPN  SERVICE  ORIGINATOR    FROM PEER   ID    LABEL  STATUS
---------------------------------------------------------------------
ipv4     10   FW       10.255.1.11   10.255.0.2  22    1005   C,I,R

The three tables side by side

Table Holds Command Empty means
OMP routes Prefixes and the endpoint each points at show sdwan omp routes Nothing advertised, or policy filtered it
TLOCs Tunnel endpoint identities show sdwan omp tlocs No transports learned — check the control plane
Services Services offered per site show sdwan omp services No site advertised one
BFD sessions Which tunnels are actually alive show sdwan bfd sessions No data plane, whatever the routes say
Count the tables before reading themRoute count, endpoint count and tunnel session count on a healthy site are three numbers worth writing down once. Every subsequent investigation starts by collecting the same three and comparing, which locates the affected layer in seconds and needs no interpretation of the detailed output at all.
Advertisement is not the same as reachabilityThe control plane will happily carry a prefix from a site whose tunnels are all down, because withdrawing it is a separate event driven by session loss. A route in the table is a statement that somebody advertised it, not a statement that it can be reached — which is exactly the distinction the status letters exist to express.
Sub claimOMP carries three separate advertisement types into three separate tables, so "the route is there" and "the path is usable" are answered by different commands and are routinely confused.

What Is a TLOC and Why Is It the Unit of Path Selection?

What is it made of?

Three values: the router's system address, a colour naming the transport, and the encapsulation. Change any one of them and it is a different endpoint. A router with two circuits therefore advertises two endpoints that share a system address and differ in colour, and a policy that prefers one circuit over another is selecting between those two — not between routers, and not between prefixes.

A Deeper Dive into TLOCs

Why selection happens at the endpoint rather than the prefix

Every prefix from a site points at that site's endpoints, so preferring a transport is a statement about the endpoint and applies automatically to every prefix behind it. That is a considerable simplification: expressing "prefer the private circuit to this branch" is one value on one endpoint, not a policy applied to each of the branch's prefixes. It also explains why a transport failure withdraws everything behind it at once rather than prefix by prefix.

! Preference on the endpoint, not on the prefixes
sdwan
 interface GigabitEthernet2
  tunnel-interface
   color mpls
   preference 200
   ! ^ higher wins; every prefix behind this site
   !   now prefers the private circuit
  exit
 exit
 interface GigabitEthernet1
  tunnel-interface
   color biz-internet
   preference 100
  exit
 exit
!
Edge# show sdwan omp tlocs | include preference

Weight, which is a different mechanism from preference

Preference selects: the higher value wins and the other endpoint is not used while it is up. Weight distributes: among endpoints that survived selection, traffic is shared in proportion to the weight. A site with two equal circuits that should both carry traffic wants equal preference and weights reflecting their capacity, and a site with a primary and a standby wants different preferences. Using preference where weight was meant produces an idle circuit somebody is paying for.

! Same preference, unequal weights = both used, 2:1
sdwan
 interface GigabitEthernet1
  tunnel-interface
   color biz-internet
   preference 100
   weight 2
  exit
 exit
 interface GigabitEthernet3
  tunnel-interface
   color public-internet
   preference 100
   weight 1
  exit
 exit
!
! Confirm both are chosen, not just one
Edge# show sdwan omp tlocs | include biz-internet|public-internet
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include tloc|weight|status

Why an endpoint identity has to include the colour

If an endpoint were just the router, a site with two circuits would have one identity and there would be no way to express a preference between its circuits — the whole point of having two would be lost to the control plane. Including the colour makes each circuit separately addressable by policy, separately preferable, and separately withdrawable when it fails. That last property matters most: a circuit failing withdraws one endpoint and leaves the other advertising normally.

Including the encapsulation serves the same purpose one level down. Two endpoints that differ only in encapsulation are genuinely different tunnels with different properties, and treating them as one would make it impossible to prefer between them. The three-part identity is the minimum that lets policy address what operators actually want to address.

Colour restriction

By default an endpoint will attempt a tunnel to endpoints of any colour, which is what allows a branch on broadband to reach a hub on a private circuit through whatever path exists. Marking a colour as restricted limits it to endpoints of the same colour, which is how a private circuit is prevented from attempting tunnels across the internet. It is a small keyword with a large effect on the resulting tunnel count.

! Restrict: only build tunnels to the same colour
sdwan
 interface GigabitEthernet2
  tunnel-interface
   color mpls restrict
  exit
 exit
!
! Without restrict, this endpoint would also try to reach
! biz-internet endpoints at other sites - usually pointless
! on a private circuit and a source of failed tunnel attempts.
!
Edge# show sdwan bfd sessions | include mpls
Edge# show sdwan control local-properties | include restrict

Preference and weight compared

Attribute Effect Higher value Use for
TLOC preference Selects — the loser is unused Wins Primary and standby circuits
TLOC weight Distributes among survivors Gets proportionally more Two active circuits of unequal size
OMP route preference Selects, and is compared first Wins Preferring a whole site or prefix set
restrict Limits which colours may pair — Keeping a private circuit private
Pitfall: preference used where weight was intended Symptom: a site with two working circuits sends everything down one of them, and the second carries only its own control traffic. Both are healthy, both appear in every table, and the billing for the idle one continues. Cause: different preference values were set on the two endpoints, and preference is a selection mechanism — the lower one is simply not used while the higher is up. Weight is the attribute that shares traffic between them. Confirm: show sdwan omp tlocs shows different preference values; show sdwan bfd sessions shows both up. Fix: set equal preference and use weight to express the intended ratio.
Sub claimPreference selects and weight distributes, which is why a site paying for two circuits and using one is usually a design that reached for the wrong one of the two attributes.

How Does OMP Choose Between Paths?

What is the order?

Validity first — a path whose endpoint cannot be resolved is not a candidate. Then route preference, then endpoint preference, then origin type with the most direct sources winning, then the metric carried from the original protocol, and finally an identity-based tie-break. The first three are the ones anybody configures; the rest exist so that the outcome is deterministic rather than because they are usually the deciding factor.

A Deeper Dive into Selection

Validity, which eliminates most confusion

Before any attribute is compared, the path has to resolve to a usable endpoint. This is why the algorithm appears to be ignored in the cases people actually bring to it: the preferred path was eliminated at step one for a reason that has nothing to do with preference, and the comparison everybody is arguing about never happened. Checking resolution before reasoning about attributes saves the argument.

! Step one, before any attribute matters
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include status|tloc
   tloc         10.255.1.12, mpls, ipsec
   status       C,I,R
   tloc         10.255.1.12, biz-internet, ipsec
   status       Inv,U
!               ^ invalid, TLOC unresolved. Never a candidate,
!                 whatever its preference says.
!
Edge# show sdwan omp tlocs | include 10.255.1.12
Edge# show sdwan bfd sessions | include 10.255.1.12

Origin type, which decides more than people expect

When preference is left at its default everywhere — which is common — origin type becomes the deciding comparison, and it prefers the most directly connected source. A prefix that is connected at one site and redistributed from an interior protocol at another will always prefer the connected one, regardless of which is topologically better. That is usually right and it is worth knowing, because it explains outcomes that look arbitrary when only preference is being considered.

! Origin order, most preferred first:
!   connected
!   static
!   eBGP
!   OSPF intra-area
!   OSPF inter-area
!   OSPF external
!   iBGP
!   unknown
!
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include origin
   origin-proto  connected
   origin-metric 0

How many paths are reflected

vSmart does not necessarily pass on every path it knows for a prefix — there is a limit, and it is low by default. A site with four transports advertising to a controller that reflects fewer than four paths means some edges never learn about some of those transports and cannot use them. Raising the limit is a controller-side change and it is one of the few tuning knobs that genuinely changes what the data plane can do.

! On vSmart - how many paths per prefix are reflected
omp
 send-path-limit 8
!
! And on the edge, how many it will accept and install
sdwan
 omp
  ecmp-limit 8
 exit
!
! Verify the edge is really seeing all the transports
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 | count
Edge# show sdwan omp summary | include received|installed

Equal paths and what happens to them

When several paths survive the whole comparison unbroken, they are all installed and traffic is shared across them. That is usually the desired outcome for a site with two equivalent circuits, and it is worth confirming rather than assuming, because two limits govern it: how many paths the controller was willing to send and how many the edge is willing to install. Either being lower than the number of transports silently reduces the result.

The related subtlety is that equal-cost sharing here operates per flow rather than per packet, so a single large transfer does not spread across both circuits. A site reporting that one transfer only ever achieves the speed of one circuit is observing correct behaviour, and the fix if more is needed is application-level parallelism rather than anything in the overlay. Explaining that distinction early tends to prevent a capacity conversation that was never about capacity.

Graceful restart, which is why an outage is survivable

An edge that loses its controller sessions holds the routes it already learned rather than discarding them, for a period governed by a timer that is long by default. That is the mechanism behind the architecture's tolerance of a control-plane outage, and the timer value is the answer to "how long can we run without controllers". It is worth knowing the configured value rather than assuming, because it defines the window in which a controller failure is not yet a traffic problem. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

! The timer that decides how long an outage stays harmless
sdwan
 omp
  graceful-restart
  timers
   graceful-restart-timer 43200
   holdtime 60
   advertisement-interval 1
  exit
 exit
!
Edge# show sdwan omp summary | include graceful|hold|timer
The algorithm is deterministic, which is the point of its later stepsOrigin type, metric and the identity tie-break rarely reflect anybody's intent and exist so that every edge independently reaches the same answer from the same inputs. That property is what makes the overlay predictable, and it is why those steps should be understood rather than configured around.
Check validity before arguing about preferenceMost "the algorithm did not do what I configured" cases are a path that was eliminated at step one and never entered the comparison. One look at the status letters answers it, and it is faster than re-reading the policy.
Sub claimValidity is compared before every configurable attribute, so a path eliminated at that step makes the entire rest of the algorithm irrelevant — which is why selection so often appears not to follow the configuration.

How Does Policy Change What an Edge Learns?

Where is policy applied?

In the middle of the reflection, on the controller, before the edge ever sees the advertisement. That is the important structural fact: an edge does not receive everything and then filter it — it receives an already-filtered view. Comparing what one edge holds against what another holds is therefore comparing two different policy outcomes, and comparing either against the controller's own table shows what policy removed.

A Deeper Dive into Policy

Topology policy, which is really tunnel-count control

A full mesh is the default because every endpoint learns every other endpoint. Restricting that — hub and spoke, or regional meshes — is done by filtering which endpoints are reflected to whom, which reduces the tunnel count on every edge. This is the main lever for scale, and its effect is visible as endpoints simply not appearing in a branch's table.

! On vSmart - what a branch is allowed to learn
policy
 control-policy BRANCH-TO-HUB
  sequence 10
   match tloc
    site-list HUBS
   action accept
  !
  sequence 20
   match route
    site-list HUBS
   action accept
  !
  default-action reject
 !
 lists
  site-list BRANCHES
   site-id 100-999
  site-list HUBS
   site-id 1-10
 !
!
apply-policy
 site-list BRANCHES
  control-policy BRANCH-TO-HUB out
 !
!
! ^ 'out' = applied as vSmart advertises TO those sites

Seeing what policy removed

The edge can show what it received after policy, and the controller can show what it holds before applying it. The difference between those two is exactly what the policy did, which turns "the policy is not working" into a concrete comparison rather than a reading of intent. This is the single most useful technique for control policy and it takes two commands on two devices.

! What the edge received, post-policy
Edge# show sdwan policy from-vsmart
Edge# show sdwan omp routes vpn 10 | count
Edge# show sdwan omp tlocs | count
!
! What vSmart holds, pre-policy, for the same thing
vSmart# show omp routes vpn 10 | count
vSmart# show omp tlocs | count
!
! And which policy is attached to this site
vSmart# show running-config apply-policy

Why central policy beats per-edge configuration

Everything a control policy does could in principle be achieved by configuring each edge, and the reason not to is consistency rather than effort. A policy expressed once cannot disagree with itself between sites; the same intent expressed on two hundred devices can and eventually will. When a branch behaves differently from its peers, the first question in a per-edge design is what is different about that branch, and in a central design that question does not arise.

The trade is that the policy becomes a single object whose blast radius is the whole estate, so a mistake in it affects everything at once. That argues for the same discipline any central control deserves: review before activation, a known previous version, and a verification step that checks what a representative edge actually received rather than what the policy was meant to do.

Direction, which is easy to get backwards

A control policy applied outbound governs what the controller advertises to those sites; applied inbound it governs what the controller accepts from them. Both are useful and they solve different problems — outbound shapes what a branch can see, inbound shapes what a branch is allowed to inject. Applying the wrong direction produces a policy that appears to do nothing, because it is filtering a flow that was never the one in question.

Direction Governs Use to Symptom if reversed
out What the controller sends to those sites Limit what a branch learns Branch still learns everything
in What the controller accepts from those sites Limit what a branch can inject Bad prefixes still propagate

Changing attributes rather than filtering

Policy can also rewrite the attributes the algorithm compares, which is how a central decision about path preference is expressed without touching any edge. Setting preference in policy is generally preferable to setting it per tunnel interface, for the same reason central policy exists at all: it is one place to read and one place to change.

! Prefer the private transport for one VPN, centrally
policy
 control-policy PREFER-MPLS
  sequence 10
   match route
    vpn 10
    site-list BRANCHES
   action accept
    set
     preference 200
     tloc-list MPLS-TLOCS
    !
   !
  !
  default-action accept
 !
!
! Confirm the edge received the modified attribute
Edge# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include preference
An edge cannot tell you what policy removedIt only knows what arrived, and an advertisement filtered on the controller is indistinguishable from one that was never sent. That is why control policy is always diagnosed by comparing the two ends rather than by inspecting either alone.
Sub claimPolicy is applied during reflection rather than at the edge, so an edge receives an already-filtered view and the only way to see what was filtered is to compare it against the controller's own table.

Which OMP Failures Look Like Routing Problems?

What are the failures worth memorising?

Four. The prefix that is chosen and not installed because its endpoint is unresolved. The prefix that was never advertised because the source protocol was not included. The path that is missing because the controller's reflection limit is lower than the number of transports. And the policy applied in the wrong direction, which filters a flow nobody was asking about.

A Deeper Dive into the Failure Catalogue

Chosen but not installed

Pitfall: a route whose tunnel endpoint cannot be resolved Symptom: the prefix is present in the overlay route table, marked as chosen, and traffic to it fails. Every control-plane check passes and the route looks entirely correct. Cause: the route names a tunnel endpoint, and that endpoint has no live tunnel — a transport failure at the far site, a colour pairing that cannot form, or a firewall blocking the data plane ports. Selection succeeded; resolution did not. Confirm: the status field shows chosen without installed; show sdwan bfd sessions has no session to that endpoint. Fix: resolve the tunnel, not the route — the route was never the problem and no amount of policy will change the outcome.

Never advertised in the first place

Pitfall: a protocol not included in the advertisement configuration Symptom: one site's prefixes are absent from every other site, while that site learns everyone else's normally. Its control connections and tunnels are all healthy. Cause: routes do not enter the overlay automatically; each source protocol must be listed. A branch running a routing protocol on its service side whose configuration omits that protocol advertises nothing from it, and the asymmetry — learning fine, advertising nothing — is the signature. Confirm: show sdwan omp routes advertised on that edge is empty or missing the expected prefixes. Fix: add the protocol to the advertisement configuration, and check the whole estate rather than the one site, because a template omission affects every site built from it.

Paths lost to the reflection limit

Pitfall: more transports than the controller will reflect Symptom: a site has four working transports, and remote sites only ever use two of them. The unused ones are healthy, advertised, and simply absent from remote tables. Cause: the controller reflects a limited number of paths per prefix, and the default is lower than four. Paths beyond the limit are never sent, so remote edges cannot use transports they do not know exist. Confirm: count the paths for one prefix on the advertising edge and on a remote edge — the remote count is capped. Fix: raise the reflection limit on the controllers and the acceptance limit on the edges; both have to allow it.

A diagnostic order that works

! Advertised, reflected, received, resolved, installed
!
! 1. Is the source site advertising it?
EdgeA# show sdwan omp routes advertised | include 10.10.20.0
!
! 2. Does the controller hold it?
vSmart# show omp routes vpn 10 10.10.20.0/24
!
! 3. Did the destination site receive it?
EdgeB# show sdwan omp routes vpn 10 10.10.20.0/24
!
! 4. Did it resolve to a usable endpoint?
EdgeB# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include status|tloc
EdgeB# show sdwan omp tlocs | include 10.255.1.12
!
! 5. Is there a live tunnel to that endpoint?
EdgeB# show sdwan bfd sessions | include 10.255.1.12
!
! 6. And finally, the forwarding table
EdgeB# show ip route vrf 10 10.10.20.0

The policy applied in the wrong direction

Pitfall: a control policy attached inbound when outbound was meant Symptom: a policy intended to stop branches learning each other's prefixes has no effect — every branch still holds a full table. The policy is present, activated, and attached to the right site list. Cause: the direction decides which flow is filtered. Inbound governs what the controller accepts from those sites; outbound governs what it sends to them. A policy meant to limit what branches learn must be outbound, and attaching it inbound filters advertisements nobody was concerned about. Confirm: compare the route count on a branch against the controller's own table — if they match, nothing was filtered on the way out. Fix: change the direction, and verify by re-reading what a representative branch received rather than by re-reading the policy.

What to monitor

Three numbers per edge. The count of routes received, which falling is a policy or advertisement change rather than a link event. The count of tunnel sessions up against the expected peer count. And the count of routes chosen but not installed, which should normally be zero and is the direct measure of the resolution failures described above. That third one is not a standard metric anywhere and it is the most informative of the three.

Comparing two sites as a technique

Most questions of the form "why does this site behave differently" are answered fastest by diffing it against a site that behaves correctly. Route count, endpoint count, tunnel session count and the received policy are four numbers that should be comparable between two branches built from the same template, and the one that differs points directly at the cause.

It works because the architecture makes sites genuinely uniform: two branches built from one template and covered by one policy should hold near-identical state, differing only in their own prefixes and addresses. Anything else that differs is either a policy exception somebody added or a fault, and both are worth knowing about. This is a considerably faster route to the answer than reasoning forward from the configuration.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers SD-WAN control plane operation within the software-defined infrastructure domain. The questions concentrate on the model: what OMP advertises, what a tunnel endpoint identity is composed of, the order of the selection algorithm, and where policy is applied. Being able to state the three advertisement types and the first three selection steps covers most of it.

Read the status letters before anything elseChosen, installed and resolved are three different states, and the combination present in the output identifies which stage failed without any further investigation. It is the fastest single piece of information in SD-WAN routing and it sits in a column people skip past.
Sub claimThe count of routes that are chosen and not installed is the direct measure of resolution failure, and it is the one number that distinguishes a control-plane problem from a data-plane one without any further investigation.

Conclusion

OMP resembles BGP closely enough that the comparison is useful and differs in one structural way that matters more than all the similarities. A prefix does not carry a next hop; it carries the identity of a tunnel endpoint, and that endpoint has to be independently reachable before the prefix is usable. Everything confusing about SD-WAN routing traces back to that indirection, and the status letters in the route table exist precisely to expose it.

Selection happens at the endpoint rather than at the prefix, which is why preferring a circuit is one attribute on one endpoint and applies to everything behind it. Preference selects and weight distributes — two mechanisms that sound similar and produce opposite outcomes, and choosing the wrong one is how a site ends up paying for a circuit it never uses. Validity is compared before either of them, which is why the algorithm so often appears to ignore the configuration.

Policy is applied on the controller during reflection, so an edge receives a view that has already been shaped and cannot report what was removed from it. Diagnosing control policy therefore always means comparing two ends: what the controller holds and what the edge received. That comparison, and the chosen-but-not-installed count, are the two techniques that resolve the large majority of what gets reported as an SD-WAN routing problem. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

Reference Notes

  1. Cisco SD-WAN documentation describes OMP as advertising three types of information: OMP routes, TLOC routes and service routes.
  2. Cisco documentation defines a TLOC as the combination of system IP address, colour and encapsulation, and states that OMP routes reference a TLOC rather than a conventional next hop.
  3. Cisco documentation describes the OMP best-path selection order, beginning with the validity of the route and the resolution of its TLOC.
  4. Cisco documentation lists OMP route preference and TLOC preference as the first two configurable comparisons, with the higher value preferred in both cases.
  5. Cisco documentation gives the origin type preference order as connected, static, eBGP, OSPF intra-area, OSPF inter-area, OSPF external, iBGP, then unknown.
  6. Cisco documentation describes TLOC weight as distributing traffic among selected TLOCs in proportion to the configured value, distinct from preference which selects between them.
  7. Cisco documentation describes the restrict keyword on a colour, which limits tunnel establishment to TLOCs of the same colour.
  8. Cisco documentation describes the send-path-limit setting on vSmart, which bounds how many paths per prefix are advertised to OMP peers.
  9. Cisco documentation describes OMP graceful restart, which allows a WAN Edge to continue using previously learned routes while its control connections are down.
  10. Cisco documentation describes centralised control policy applied on vSmart in the inbound or outbound direction relative to a site list, filtering or modifying advertisements during reflection.
  11. RFC 4456 defines BGP route reflection, the model vSmart follows in reflecting OMP advertisements between WAN Edge devices that do not peer directly.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include SD-WAN control plane operation within the software-defined infrastructure domain.