Cisco Catalyst SD-WAN separates route distribution from transport health. Overlay Management Protocol, or OMP, distributes reachability and policy information. Transport Locations, or TLOCs, identify the WAN-side attachment points that can carry traffic. BFD continuously tests the overlay tunnels and measures whether those TLOCs are actually usable.
The three mechanisms therefore answer different questions:
- OMP: What destinations exist, and which transport locations can reach them?
- TLOC: Which specific WAN attachment can act as the next hop?
- BFD: Is the tunnel to that transport location alive, and what is its current quality?
The current 300-415 ENSDWI v1.2 blueprint includes OMP, TLOCs, vRoutes, and BFD in the core Catalyst SD-WAN architecture.
OMP is the overlay routing protocol
OMP is the control-plane protocol used between Cisco Catalyst SD-WAN Controllers and edge devices.
It carries more than simple IP prefixes. Cisco documents OMP as distributing routing, policy, and service information across the overlay.
An edge device can learn local routes from connected networks, static configuration, OSPF, BGP, EIGRP, or other supported protocols and advertise relevant reachability into OMP.
The controller learns those routes and can advertise them to other sites according to topology and policy.
That centralized model is one of the defining differences between Cisco SD-WAN architecture and a traditional WAN where every router independently exchanges all routing information with its direct WAN neighbors.
OMP is carried over the secure control connections between edge devices and Cisco SD-WAN Controllers, but it represents the service-side and transport information needed by the overlay. Current Cisco documentation describes several OMP route types, including prefix routes learned from the service side, TLOC routes that describe transport locations and their properties, and service routes used to advertise network services.
That separation prevents a common mental shortcut: an OMP prefix is not the same thing as a tunnel. The prefix says what is reachable; the TLOC identifies a transport attachment that can reach it; BFD state determines whether the corresponding data-plane tunnel is operational enough to use.
OMP vRoutes point to TLOCs
Cisco describes an OMP route, or vRoute, as a prefix associated with a TLOC.
The TLOC acts much like a next hop in the overlay.
A TLOC is built primarily from:
- the edge device’s system IP
- a transport color
- the encapsulation type
The transport color identifies the logical WAN transport, such as public internet or MPLS-style connectivity. The encapsulation identifies how the overlay tunnel is built.
The underlay still needs to route to the transport endpoint. OMP does not make an unreachable WAN address reachable by itself.
That is why SD-WAN versus MPLS should not be framed as “routing versus no routing.” SD-WAN can use multiple transport types, but those transports still have to provide IP reachability between tunnel endpoints.
The system IP is a stable logical identifier for the edge device, while the color expresses transport intent and the encapsulation describes the tunnel type. Two physical WAN interfaces on one edge can therefore produce distinct TLOCs even though they belong to the same router.
TLOC extension designs add another nuance: the transport attachment may be physically connected to one edge and made available to another edge through an inter-device link. The overlay still reasons in terms of TLOC identity and reachability, so troubleshooting should follow the advertised TLOC rather than assuming the cable must terminate on the router currently forwarding the service route.
One prefix can have multiple TLOC paths
A branch may have several WAN transports.
The same service-side route can therefore be advertised with more than one TLOC.
That gives the overlay multiple candidate paths to the same destination.
OMP attributes and policy influence which paths are preferred or advertised. Cisco documents attributes such as preference, origin, site ID, tag, and TLOC characteristics as part of OMP route selection.
The important operational point is that a prefix alone is not enough to understand forwarding. You need to know which TLOCs are associated with the route and whether those TLOCs are active.
When multiple paths exist, OMP selection can consider route attributes such as preference, origin, site information, and TLOC characteristics. Policy can modify or filter those attributes before routes are advertised to other sites.
This is why checking only the service prefix can hide the reason for a path choice. Two OMP entries for the same prefix can point to different TLOCs and carry different preference or policy outcomes. The forwarding table reflects the paths that survive both control-plane selection and data-plane viability checks.
BFD decides whether an overlay tunnel is alive
Cisco Catalyst SD-WAN automatically runs overlay BFD sessions across the tunnels between edge devices.
These sessions detect tunnel failure quickly.
Cisco also uses BFD to measure path statistics such as:
- latency
- loss
- jitter
That gives BFD two roles.
First, it is a reachability mechanism. If a TLOC’s BFD session is down, that transport path is not healthy enough to forward overlay traffic.
Second, it is a measurement source for application-aware routing.
Cisco BFD provides the underlying failure-detection model; in Catalyst SD-WAN, BFD also continuously measures overlay tunnel performance.
Overlay BFD runs between edge-device tunnel endpoints and is independent of the IGP or BGP that may be carrying the underlay. A transport can have enough IP reachability to build a tunnel while still experiencing loss or delay that makes application performance unacceptable.
Conversely, BFD cannot rescue a tunnel whose transport endpoint is unreachable. If the underlay loses the route to the remote TLOC address, the overlay session will fail because the outer packets can no longer cross the transport. This is the same layered principle seen elsewhere in SD-WAN: the overlay adds control and policy, but it still depends on ordinary IP reachability below it.
OMP can know a route while the forwarding path is unusable
This is one of the most useful troubleshooting distinctions.
An edge device can have an OMP route for a destination and still be unable to forward through a particular TLOC if the associated BFD session is inactive.
Cisco’s routing documentation explicitly states that an OMP path is installed in the forwarding table only when the TLOC it points to is active.
That creates a clean troubleshooting sequence:
- Does OMP know the destination?
- Which TLOC or TLOCs are associated with it?
- Is the chosen TLOC active?
- Does BFD show the corresponding tunnel up?
- If it is up, are loss, latency, or jitter affecting policy decisions?
This is much more precise than saying “SD-WAN routing is broken.”
A useful distinction is present in OMP versus installed for forwarding. The controller can continue to know a prefix and its candidate TLOCs even when a specific BFD path is down. The edge should not use a next hop whose transport location is inactive, so the forwarding entry can differ from the raw control-plane view.
When there are several TLOCs, a failure may remove only one path rather than the destination itself. That is the resilience benefit of the overlay, but it can also make an outage partial: one application or transport preference changes while general reachability remains.
Control connections and BFD sessions are different
The secure control connections between edge devices and the centralized control components are not the same as the data-plane BFD sessions between edge routers.
A branch can have healthy controller connectivity while a data-plane tunnel to another branch is down.
Likewise, temporary control-plane disruption does not necessarily mean every existing data-plane tunnel disappears immediately.
Keeping those planes conceptually separate is essential when troubleshooting Catalyst SD-WAN.
The broad architecture article on SD-WAN components is useful background, but OMP/TLOC/BFD troubleshooting needs this more precise control-versus-data-plane model.
Control connections are edge-to-controller relationships used for orchestration and control-plane exchange. Data-plane BFD sessions are edge-to-edge relationships over the overlay tunnels. They answer different health questions and can fail independently.
That distinction suggests a diagnostic order. If all controller sessions are down, investigate identity, certificates, reachability, or control-plane transport. If controller sessions are healthy but one remote site has no data-plane tunnel, focus on the TLOC pair, transport reachability, NAT behavior where relevant, and BFD state instead of assuming the centralized components are unavailable.
BFD quality metrics feed application-aware routing
A tunnel can be up and still be unsuitable for a particular application.
For example, a voice application may be sensitive to loss and jitter even when the tunnel remains reachable.
Catalyst SD-WAN can use BFD measurements with SLA classes and application-aware routing policy. That means a path can stay operational for general traffic while no longer meeting the threshold for a latency-sensitive application.
This distinction is important:
BFD up/down answers whether the path exists.
BFD performance metrics help answer whether the path is good enough for a policy-defined application requirement.
The performance side of BFD feeds application-aware routing. Cisco SD-WAN collects loss, latency, and jitter over the tunnels and evaluates those measurements against configured SLA classes. A BFD session can remain up while one application is steered away because the tunnel falls outside its SLA.
That creates three useful levels of state: route existence, tunnel liveness, and application fitness. A route can exist in OMP; a TLOC can be active with BFD up; and the same tunnel can still be out of SLA for voice. Keeping those levels separate makes policy behavior much easier to explain.
A practical OMP/TLOC/BFD troubleshooting workflow
When a branch cannot reach a remote prefix:
- Verify the edge device still has control connectivity to the SD-WAN controllers.
- Inspect the OMP route for the destination.
- Identify the associated TLOCs.
- Verify the expected TLOC is installed and active.
- Check BFD sessions to the remote transport location.
- Confirm the underlay route can reach the transport endpoint.
- Review OMP preference and policy if multiple candidate paths exist.
- Check BFD loss, latency, and jitter if application-aware policy is involved.
The core skill is separating information from viability.
OMP tells the overlay what paths are possible. TLOCs identify the transport attachments behind those paths. BFD tells the edge which tunnels are currently usable and how well they are performing.
OMP, TLOCs, and BFD become much easier to troubleshoot when they are treated as three linked databases rather than one feature. OMP describes destinations and candidate transport locations. TLOC identity tells the edge which WAN attachment represents each candidate. BFD proves whether the edge-to-edge tunnel is alive and supplies the quality measurements that higher-level policy can use. Follow those layers in that order and an “SD-WAN routing problem” usually becomes a specific route, transport, or tunnel-state problem.