What Is a TLOC in a Cisco SD-WAN Deployment?

In a traditional wide-area network (WAN), routing decisions are bound directly to physical interfaces and static IP addresses. Transport circuits like MPLS, broadband internet, and LTE operate as isolated communication silos, requiring complex policy-based routing and manual tunneling configurations to steer traffic effectively.

Cisco SD-WAN (formerly Viptela) removes this rigid coupling by abstracting the underlying physical infrastructure into a software-defined fabric. At the core of this architecture is the Transport Locator (TLOC). A TLOC serves as the foundational attachment point that connects a Cisco WAN Edge router to the transport underlay, enabling the automated assembly and scaling of dynamic data-plane tunnels.

Understanding how TLOCs function, how they differ from other network identifiers, and how to configure, extend, and troubleshoot them is essential for designing and maintaining a resilient Cisco SD-WAN deployment.

What Is a TLOC? Understanding the 3-Tuple and OMP Operation

A TLOC represents the physical or logical interface where an edge router connects to a WAN transport provider. In data-plane terms, it acts as the next-hop address for overlay traffic traversing across the SD-WAN fabric. Rather than identifying a tunnel endpoint by a single interface IP, Cisco SD-WAN defines every TLOC by a specific 3-tuple value:

TLOC = { System IP, Color, Encapsulation }

The TLOC 3-Tuple Components

1. System IP Address
   The System IP is a persistent, globally unique 32-bit IPv4 address assigned to a WAN Edge device. It functions identically to a router ID in OSPF or BGP. It does not need to be routable in the underlay transport network; instead, it provides a stable device identifier that remains unchanged regardless of interface state changes.
2. Color
   The color attribute is an abstraction that specifies the transport circuit type associated with the interface (for example, mpls, biz-internet, public-internet, lte, or metro-ethernet). Colors tell the SD-WAN fabric whether a link is private or public:
3. Private Colors: (e.g., mpls, private1) By default, routers attempt to connect to other private color endpoints using their private, natively assigned IP addresses without NAT traversal.
4. Public Colors: (e.g., biz-internet, public-internet, lte) The router uses Session Traversal Utilities for NAT (STUN) to discover post-NAT public IP addresses and ports to establish tunnels across public backbones.
5. Encapsulation
   This defines the data-plane transport protocol applied across the underlay. Cisco SD-WAN supports IPsec (the enterprise standard for encrypted payload transmission) and GRE (used in specific high-throughput, unencrypted transit designs).

How OMP Builds Data Paths Using TLOC Routes

Cisco SD-WAN automates full-mesh or hub-and-spoke connectivity using the Overlay Management Protocol (OMP). When an edge router boots up and attaches to a transport:

1. TLOC Route Generation: The edge router creates a TLOC route containing its 3-tuple, along with metadata: private IP/port, public IP/port (resolved via STUN), Site ID, preference, weight, and encryption keys.
2. Control-Plane Advertisement: The router advertises this TLOC route to the centralized vSmart controller over secure DTLS or TLS control connections inside transport VPN 0.
3. Policy Reflection: The vSmart controller filters and distributes these TLOC routes to remote peer routers according to centralized control policies.
4. Data-Plane Formation: Once peer edge routers receive each other’s TLOC attributes, they initiate direct, peer-to-peer IPsec tunnels.
5. Liveness Monitoring via BFD: The routers immediately launch Bidirectional Forwarding Detection (BFD) over the newly formed tunnels to measure latency, jitter, loss, and reachability.

Key Takeaway: A TLOC is a composite 3-tuple {System IP, Color, Encapsulation} distributed by OMP that allows edge devices to advertise transport endpoints and dynamically build secure data tunnels without manual tunnel provisioning.

TLOC vs. System IP vs. Site ID: Key Architectural Differences

Because Cisco SD-WAN introduces multiple identification layers across control and data planes, network engineers often conflate TLOCs with System IPs and Site IDs. While all three are assigned during edge provisioning, they serve distinct functions within the overlay hierarchy.

Structural Interdependence

These three identifiers work together in a hierarchical model:
* The Site ID dictates where the traffic originates or terminates.
* The System IP defines which device is processing the traffic.
* The TLOC defines which physical path or circuit carries the data across the network.

When two routers share the same Site ID, OMP recognizes them as co-located branch routers. By default, Cisco SD-WAN suppresses data tunnel formation between identical Site IDs, assuming local LAN or Direct Connect paths handle intra-site traffic.

Key Takeaway: System IP identifies the router, Site ID identifies the location, and TLOC defines the specific underlay circuit used to send data across the overlay.

How to Configure a TLOC: Step-by-Step CLI and vManage Workflow

TLOCs are exclusively provisioned within VPN 0 (the Transport/Underlay VPN). To transform a standard interface into a functional TLOC, you must assign an IP address, declare it as a tunnel interface, set a transport color, and select the encapsulation.

CLI Configuration Workflow

Follow these sequential steps when configuring an edge router through the command line (cisco-native or SD-WAN CLI):

Step 1: Navigate to VPN 0 and Configure the Physical/Sub-Interface

Define the physical underlay interface connecting to the Internet or MPLS service provider.

sdwan
 config
  vpn 0
   interface GigabitEthernet0/0/0
    description WAN-Underlay-Biz-Internet
    ip address 198.51.100.2 255.255.255.0
    no shutdown

Step 2: Enable the Tunnel Interface and Assign Encapsulation

Designate the interface as a fabric tunnel endpoint and specify the encapsulation type (ipsec is typical).

    tunnel-interface
     encapsulation ipsec

Step 3: Assign Transport Color and Peering Parameters

Assign the circuit color. If the circuit should only form tunnels with matching transport colors on remote branches, append the restrict keyword.

     color biz-internet restrict

Step 4: Configure Allowed Inbound Services

By default, the tunnel interface blocks inbound infrastructure traffic. Permit the essential protocols required for control-plane and management stability:

     allow-service bfd
     allow-service omp
     allow-service stun
     allow-service https
     allow-service ssh
    exit
   exit
  commit

Cisco Catalyst SD-WAN Manager (vManage) Workflow

To deploy TLOC configurations at scale across template-driven devices:

1. Access Feature Templates: Navigate to Configuration > Templates > Feature Templates.
2. Configure the System Template: Ensure the System IP and Site ID are populated using global or device-specific variables.
3. Edit the VPN 0 Interface Template: Open the Cisco VPN Interface Ethernet template assigned to VPN 0.
4. Enable Tunnel Interface: Under the Tunnel Interface drop-down menu, toggle the value to On.
5. Define Color and Restrict: Set the transport color (e.g., biz-internet). Set Color Restrict to On if traffic must not cross-connect to unlike transports (e.g., keeping MPLS traffic off broadband internet).
6. Apply Tunnel Encapsulation: Select IPsec under the Encapsulation section.
7. Attach to Device Template: Attach the interface template to the device’s master Cisco VPN 0 Template, update device values, and deploy the template to the target hardware.

Key Takeaway: A TLOC is instantiated whenever an interface within VPN 0 has tunnel-interface enabled, a designated color, and an active encapsulation protocol.

Designing High Availability with TLOC Extensions

In a redundant branch deployment, enterprises often place two WAN Edge routers on-site for high availability. In many cases, each router terminates only one WAN connection—for example, Router A terminates the private MPLS circuit, while Router B terminates the broadband Internet circuit.

       [ MPLS Underlay ]         [ Internet Underlay ]
               |                           |
        +--------------+           +--------------+
        | WAN Edge 1   |           | WAN Edge 2   |
        | (Color: MPLS)|           | (Color: INET)|
        +--------------+           +--------------+
               |                           |
               +=== [ TLOC Extension Link ]+

Without an extension mechanism, Router A cannot send traffic over the Internet if its MPLS link fails, cutting the branch’s WAN bandwidth and redundancy in half. TLOC Extension solves this problem by allowing adjacent edge routers to share their local WAN connections across a dedicated Layer 2 or Layer 3 interconnect.

TLOC Extension Design and Implementation

Through TLOC extension, Router A can establish an “extended” TLOC using Router B’s Internet connection, and Router B can establish an extended TLOC using Router A’s MPLS connection. Both routers then maintain active data tunnels over both circuits simultaneously.

Step 1: Establish the Dedicated Interconnect

Connect an interface between Router A and Router B (e.g., GigabitEthernet0/0/2). This link must reside in VPN 0 and act as an unencapsulated point-to-point link.

Step 2: Configure the Local Extended Interface (Router A)

On Router A, configure the point-to-point link facing Router B, and define it as an extension to its local MPLS interface.

sdwan
 config
  vpn 0
   interface GigabitEthernet0/0/2
    description TLOC-Extension-Link-to-Edge2
    ip address 192.168.10.1 255.255.255.252
    tloc-extension GigabitEthernet0/0/0
    no shutdown
   commit

Step 3: Configure the Receiving Interface (Router B)

On Router B, configure its side of the interconnect. Router B marks this interface as a tunnel-interface with the color mpls, using Router A’s IP address on the interconnect as its next hop.

sdwan
 config
  vpn 0
   interface GigabitEthernet0/0/2
    description TLOC-Extension-From-Edge1
    ip address 192.168.10.2 255.255.255.252
    tunnel-interface
     encapsulation ipsec
     color mpls
    exit
    no shutdown
   commit

Design Considerations and Constraints

• Bandwidth Bottlenecks: The interconnect must match or exceed the WAN circuit bandwidth to prevent internal packet drops during high-utilization periods.
• MTU Adjustments: TLOC extension introduces an extra internal hop before encapsulation. Keep your MTU set to at least 1500 bytes (or higher if using 802.1Q sub-interfaces) to avoid packet fragmentation.
• Platform Limitations: Native TLOC extensions generally cannot cross cellular/LTE interfaces directly. Cellular connections require dedicated cellular gateway designs or bridging to be shared.

Key Takeaway: TLOC extension enables dual-router sites to cross-share WAN circuits over an internal VPN 0 link, ensuring every router at the site can reach all available WAN transports.

Troubleshooting TLOC Down States and BFD Session Failures

When a TLOC fails, goes down, or remains in an invalid state, the WAN Edge router cannot form data-plane tunnels. This breaks overlay reachability for client devices in service VPNs.

Use this step-by-step diagnostic workflow to isolate and resolve TLOC failures.

Step 1: Verify OMP TLOC Registration and Validity

Verify whether the router has successfully generated and installed its local TLOC into OMP, and check the status of remote TLOCs received from the vSmart controller:

WAN-Edge# show omp tlocs

Look at the Status column for each entry:
* C, I, R flags indicate that the TLOC route is Chosen, Installed, and Resolved.
* Issue: If a local TLOC is missing, verify that the interface in VPN 0 has tunnel-interface enabled and is in an up/up state.
* Issue: If the TLOC displays Inv (Invalid), the next-hop underlay route inside VPN 0 is typically missing or unresolvable.

Step 2: Check VPN 0 Underlay Routing and Control Connections

A TLOC cannot establish data tunnels if it cannot reach its underlay gateway or if its control connections to the SD-WAN controllers are down:

WAN-Edge# show ip route vpn 0
WAN-Edge# show control connections

• Confirm that VPN 0 contains an active default gateway (0.0.0.0/0) pointing out the physical WAN provider interface.
• Check that control connections to the vSmart controllers are in the up state across this TLOC. If control connections fail, verify whether intermediate firewalls are blocking UDP port 12346 (or base ports 12446, 12546 depending on core offsets) and DTLS/TLS ports.

Step 3: Inspect BFD Session States

Data tunnels form directly between TLOCs and are tracked via BFD. Check for active or failed BFD sessions:

WAN-Edge# show bfd sessions

• State = Up: The data tunnel is established, encrypted, and carrying traffic.
• State = Down / Admin Down: The underlying physical connectivity is failing, or UDP traffic is dropping along the path.
• Identify the destination TLOC {System IP, Color, Encapsulation} in the command output to determine which remote transport is failing.

Step 4: Check for NAT Traversal and Port Blocking

If BFD sessions drop or fail to transition from Init to Up, the problem is frequently tied to intermediate NAT devices or upstream firewalls:

WAN-Edge# show bfd summary
WAN-Edge# show control local-properties

• Review the Public IP and Public Port values under show control local-properties. If a public color is configured and the public IP/port is identical to the private values despite residing behind a NAT device, STUN negotiation has failed.
• Ensure upstream firewalls permit bidirectional UDP port 4500 (IPsec NAT-Traversal) and UDP ports 12346 through 13146.

Step 5: Check Color Compatibility and Restrict Attributes

If remote TLOCs appear in show omp tlocs but no BFD sessions appear in show bfd sessions:

• Check whether the local or remote TLOC uses the restrict keyword. If Router A sets its color to biz-internet restrict, it will only establish tunnels to remote TLOCs that also use the biz-internet color.
• Check whether public and private colors are misconfigured. Private colors assume direct, non-NAT reachability. If you assign a private color (mpls, private1) to an interface running behind a NAT device, tunnels to remote sites will fail because the endpoints cannot route to the private, RFC 1918 addresses directly.

Key Takeaway: Resolving TLOC failures requires checking three distinct layers: validating the underlay default gateway in VPN 0, confirming that OMP installs the TLOC route, and ensuring UDP/IPsec ports are open so BFD sessions can reach an Up state.

Official Technical Reference: Transport Locators and OMP

Cisco provides authoritative architectural specifications and design standards for TLOC management within the Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide and the Cisco Catalyst SD-WAN Routing Configuration Guide.

Core Protocol Standards and Specifications

• Overlay Management Protocol (OMP): Operates as a centralized control protocol running over secure DTLS/TLS sessions between WAN Edge devices and vSmart controllers. OMP distributes three classes of updates:
• OMP Routes: User prefix and subnet routes learned from service-side VPNs.
• TLOC Routes: Transport locator parameters, next-hop addresses, and cryptographic keys.
• Service Routes: Network services (e.g., firewalls, IPS) available inside the overlay fabric.
• Path Health Monitoring: Standardized using BFD (RFC 5880) encapsulated in SD-WAN IPsec packets (RFC 4303), running at aggressive hello intervals (default: 1000ms, with a 7x multiplier) to guarantee sub-second brownout and blackout failover.

CLI Reference: Primary Verification Commands

# View all learned and advertised transport locators
show omp tlocs

# View detailed operational attributes of local TLOCs (including public/private ports)
show control local-properties

# Inspect real-time data-plane BFD tunnel health between TLOC endpoints
show bfd sessions

# Review IPsec Security Parameter Indexes (SPI) negotiated across active TLOCs
show ipsec inbound-connections
show ipsec outbound-connections

Cisco Best Practice Design Rules

• Consistent Transport Color Naming: Use standardized color names network-wide (e.g., assign all enterprise Internet circuits to biz-internet rather than mixing public-internet and biz-internet). Inconsistent color names lead to unnecessary tunnel meshing and high control-plane overhead.
• Carrier Restriction Rules: Apply the restrict keyword exclusively to isolated, non-routable private networks (like air-gapped MPLS links) to prevent WAN Edge routers from attempting to form tunnels across incompatible underlay transports.
• MTU Planning: Account for the ~72 bytes of IPsec and BFD encapsulation overhead. When underlay transport circuits enforce standard 1500-byte MTUs, configure transport interfaces to avoid inner payload fragmentation, or leverage Cisco SD-WAN’s automated path MTU discovery (PMTUD) mechanisms.

Key Takeaway: Aligning your design with Cisco’s validated standards—including consistent color naming, proper MTU planning, and correct carrier restrictions—ensures scalable, stable, and deterministic transport locator performance across the fabric.

Conclusion

The Transport Locator (TLOC) is the critical link between physical network connectivity and Cisco SD-WAN’s dynamic overlay fabric. By packaging routing identity into a {System IP, Color, Encapsulation} 3-tuple, TLOCs give edge devices an automated, policy-driven way to discover paths and spin up IPsec tunnels across disparate WAN providers.

Whether provisioning single-router branches, engineering resilient dual-homed designs with TLOC extensions, or troubleshooting dropped BFD sessions, managing TLOCs properly ensures your software-defined WAN stays secure, adaptable, and highly available.

Please follow and like us: