NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

Understand how OMP (Overlay Management Protocol) distributes routes, TLOCs, and policies across a Catalyst SD-WAN fabric. In this lesson you will configure the SD-WAN system identity (system IP and site ID), create a simple local prefix to be advertised, and verify how OMP advertises reachability and TLOC information to peers via the controllers. This matters in production because OMP is the mechanism that lets branch routers learn remote subnets and transport locators (TLOCs) without having full BGP/OSPF peering between every site — enabling scalable, policy-driven WAN fabrics used in real enterprises.

In a real-world scenario: a regional branch with a local LAN needs to advertise its subnets into the SD-WAN fabric so remote data centers and hubs can reach those subnets over the best transport (MPLS, Internet). OMP carries both reachability (routes) and data-plane locators (TLOCs) so the fabric can set up IPsec tunnels end-to-end or via hubs.

Quick Recap

Topology (from Lesson 1): two WAN Edge routers registered to the SD-WAN controllers. This lesson uses the same WAN edges and controller-plane concept. The only IPs referenced from the earlier material are the SD-WAN system IPs:

WAN Edge 1 System IP: 10.255.255.11 (Site ID 10)
WAN Edge 2 System IP: 10.255.255.21 (Site ID 20)

No new devices are added in this lesson.

ASCII Topology (minimal view showing relevant addresses)

[WAN Edge 1]----------------[Controller(s)]----------------[WAN Edge 2]
Loopback0:10.255.255.11                    (control-plane)   Loopback0:10.255.255.21
Site-ID:10                                               Site-ID:20

Key Concepts

Before touching the CLI, understand these essential OMP behaviors and why they matter:

OMP is the control-plane protocol for SD‑WAN. It runs inside authenticated TLS/DTLS sessions between WAN Edges and Controllers. Think of OMP as a special-purpose BGP-like protocol: it advertises routes, TLOCs (transport locators), encryption keys, and policy information across the fabric.
TLOC = System IP + Color + Encapsulation. A TLOC identifies a transport endpoint (for example, an MPLS or internet-facing interface). Controllers learn TLOCs from each WAN Edge and (by default) advertise them to other WAN Edges so that IPsec tunnels can be formed end-to-end. Analogy: TLOCs are like the public addresses of your colleagues — once you know someone's address you can send them a secure parcel.
OMP distributes reachability and policy separately from data-plane transport. OMP tells the fabric what prefixes a site can reach (connected, static, or routes learned from IGP/BGP), while the TLOCs tell where to send packets for that site. This separation allows controllers to influence forwarding (for example, prefer MPLS TLOCs for certain traffic) without changing the local routing table directly.
Controllers provide the glue: full-mesh by default. Controllers receive OMP information from WAN Edges and re-advertise TLOCs and OMP routes, building a fabric-wide view. By default, controllers advertise TLOCs to all WAN Edges resulting in a full-mesh of IPsec tunnels (unless control policies change this behavior).
When routes change, OMP updates are sent automatically. OMP propagates route advertisements (added/withdrawn) via the controller network. In production this enables automated failover — when a transport degrades, controllers can update which TLOCs are preferred for a prefix.

Tip: Remember OMP is not a forwarding protocol. It is a control protocol that tells the fabric what to do; actual data transfers occur over IPsec tunnels identified by TLOCs.

Step-by-step configuration

Each step below follows the exact pattern: what, why, commands, explanation, and verification.

Note: All configuration below uses the system IPs from the reference material: 10.255.255.11 (site 10) and 10.255.255.21 (site 20). Organization name used is NHPREP and passwords (where shown) use Lab@123 as required.

Step 1: Set system identity (system-ip, site-id, organization)

What we are doing: Assign the router its SD‑WAN identity. The system IP uniquely identifies the WAN Edge in the fabric and the site ID groups devices logically. This identity is embedded in OMP advertisements and forms the basis for TLOCs.

configure terminal
interface Loopback0
 ip address 10.255.255.11 255.255.255.255
 exit
sdwan
 system-ip 10.255.255.11
 site-id 10
 organization NHPREP
 exit
end

What just happened: Loopback0 holds the system IP (a stable identifier independent of physical interfaces). Under the sdwan stanza we set the system-ip, site-id, and organization; these values are used when the WAN Edge authenticates to Controllers and when it advertises TLOCs and OMP routes. The controller and other WAN Edges will see this router as 10.255.255.11 (site 10).

Real-world note: Using a loopback for the system IP ensures the identity stays stable even when transport interfaces flap or IP addresses change.

Verify:

show running-config interface Loopback0
!
interface Loopback0
 ip address 10.255.255.11 255.255.255.255
!

show sdwan system-status
System IP: 10.255.255.11
Site ID: 10
Organization: NHPREP
SD-WAN Control State: Not yet connected to controller (or Connected)

(Exact state will reflect whether the router has registered to controllers in your lab.)

Step 2: Create a local subnet to advertise (simulate a LAN)

What we are doing: Configure a local connected prefix on the router so OMP has at least one prefix to advertise to the fabric. This demonstrates how connected routes are advertised via OMP.

configure terminal
interface Loopback1
 ip address 192.168.100.1 255.255.255.0
 exit
end

What just happened: Loopback1 creates a locally connected subnet 192.168.100.0/24 on this WAN Edge. OMP will see this as a connected route eligible for advertisement to controllers (which then advertise to other WAN Edges), allowing remote sites to reach 192.168.100.0/24 via TLOCs.

Real-world note: In production, these would be real LAN subnets on branch devices. You may instead have IGP or BGP routes that are redistributed into OMP.

Verify:

show ip route 192.168.100.0
Routing entry for 192.168.100.0/24
  Known via "connected", distance 0, metric 0
  Tag 0, type connected
  Installed via interface Loopback1

show sdwan omp routes
Prefix                       Next Hop      Source    System-IP
192.168.100.0/24             Local         CONNECTED 10.255.255.11

The show sdwan omp routes output shows the local prefix is present in OMP's route table and is ready to be advertised.

Step 3: Confirm OMP registration and TLOC advertisement

What we are doing: Verify that the WAN Edge has registered with controllers, and verify the TLOCs learned/advertised by this router and the controller. This step proves that OMP control connections and TLOC advertisement are functioning.

show sdwan control connections

What just happened: This command lists control-plane (TLS/DTLS) connections to the controller(s), including the status of the connection and the system IP used for authentication. A successful connection is required for OMP updates to flow.

Verify (expected output):

show sdwan control connections
Controller-IP   Local-If     State       Protocol   System-IP
10.0.0.10       GigabitEthernet0/0  Connected   TLS      10.255.255.11

show sdwan tloc
System-IP       Site-ID  Color     Encapsulation  Private-IP      Public-IP
10.255.255.11   10       mpls      ipsec          192.0.2.11      203.0.113.11
10.255.255.21   20       biz-inet  ipsec          198.51.100.21   203.0.113.21

The show sdwan tloc output demonstrates this router's local TLOC (system-ip 10.255.255.11) and TLOCs learned from the controller for remote WAN Edges (10.255.255.21). TLOC fields include color and encapsulation which are used by controllers to influence routing/policy.

Real-world note: TLOC color labels (e.g., mpls, biz-inet) allow you to prefer certain transports for application classes — useful for optimizing SaaS or voice traffic.

Step 4: Observe OMP route propagation across the fabric

What we are doing: Verify that OMP has both learned and is advertising the connected prefix. On a remote WAN Edge (system IP 10.255.255.21), confirm the presence of the 192.168.100.0/24 route learned via OMP and the associated TLOC used for forwarding.

! On WAN Edge 2 (Site 20):
show sdwan omp routes

What just happened: The remote WAN Edge should show the 192.168.100.0/24 prefix as learned via OMP from 10.255.255.11. The route will include the TLOC (System IP) that indicates where traffic should be sent.

Verify (expected output on Site 20):

show sdwan omp routes
Prefix                       Next Hop      Source      System-IP
192.168.100.0/24             10.255.255.11 OMP         10.255.255.11

show sdwan tloc
System-IP       Site-ID  Color     Encapsulation  Private-IP      Public-IP
10.255.255.11   10       mpls      ipsec          192.0.2.11      203.0.113.11
10.255.255.21   20       biz-inet  ipsec          198.51.100.21   203.0.113.21

From these outputs: WAN Edge 2 sees the prefix and knows to forward to system IP 10.255.255.11 using the TLOC advertised via the controllers. The data plane will use IPsec tunnels identified by the selected TLOC.

Real-world note: If the controller advertises multiple TLOCs for a site, control policies can prefer one color (e.g., mpls) over another for certain application classes.

Verification Checklist

Check 1: System identity is set on each WAN Edge.
- How to verify: show sdwan system-status — verify System IP and Site ID match expected (10.255.255.11 / Site 10).
Check 2: Local connected prefix is present in the OMP route table on the originating WAN Edge.
- How to verify: show sdwan omp routes on originating site — verify 192.168.100.0/24 listed as CONNECTED.
Check 3: Remote WAN Edge has learned the connected prefix and has TLOC information.
- How to verify: show sdwan omp routes and show sdwan tloc on remote site — verify prefix present and TLOC entry for 10.255.255.11 exists.

Common Mistakes

Symptom	Cause	Fix
`show sdwan control connections` shows "Not Connected"	System IP/site-id mismatch or organization mismatch between router and controller	Verify `sdwan system-ip`, `site-id`, and `organization` are correct; fix the values and restart sdwan service if required
`show sdwan omp routes` missing expected local prefixes	Local prefix is not configured or not eligible for advertisement	Ensure the prefix is configured as a connected network (e.g., on Loopback) or redistributed from IGP/BGP; verify route exists with `show ip route`
TLOC for a remote site not visible	WAN Edge not registered to controller or controller not advertising TLOCs	Check controller connectivity (`show sdwan control connections`); confirm controllers have the TLOC by viewing `show sdwan tloc` on other nodes
Route present in OMP but traffic not forwarding	No valid TLOC/transport or IPsec tunnel down	Use `show sdwan tloc` to find available transports; troubleshoot IPsec tunnel connectivity or bring up alternate TLOCs

Key Takeaways

OMP is the control-plane protocol that advertises reachability (routes), TLOCs, and policies across the SD‑WAN fabric; it runs over secure TLS/DTLS channels to controllers.
A router's system IP and site ID (configured on Loopback0 in the lab) are essential identity elements used when advertising TLOCs and OMP routes.
TLOCs are the transport locators (system IP + color + encapsulation) that tell the fabric where to send data. Controllers advertise TLOCs to create a fabric-wide view, enabling full-mesh or policy-driven topologies.
Verification commands (show sdwan system-status, show sdwan control connections, show sdwan tloc, show sdwan omp routes) let you confirm both control-plane registration and that connected prefixes are being distributed by OMP — a critical troubleshooting sequence in production SD‑WAN deployments.

Final note: In production fabrics, controllers and control policies may alter default behavior (for example, restricting TLOC advertisements or preferring certain colors). Always confirm controller-side policy when expected OMP behavior differs from lab defaults.

OMP — Overlay Management Protocol