TLOC Extension: Sharing Transports Between Edge Routers

A dual-router branch has an obvious problem: you have two WAN Edge routers for redundancy, but you may only have one MPLS circuit. It terminates on one router. If that router fails, the other router - the redundant one - has no way to reach the MPLS transport, and half your redundancy is fiction. TLOC extension solves exactly this: it lets one router use a transport that is physically connected to the other.

This article covers TLOC extension: the problem it solves, how it works, and how it fits a redundant branch design. It extends the complete SD-WAN guide. Command syntax is drawn from Cisco's current 20.x documentation, clearly labelled as a documented reference.

The problem, precisely

You build a dual-router branch for high availability. Router 1 and Router 2, both WAN Edges. But WAN circuits are expensive and often physically singular:

• The MPLS circuit is one handoff from the provider - it terminates on Router 1.
• The internet circuit is a different handoff - it terminates on Router 2.

Now each router has only one transport. Router 1 has MPLS but no internet. Router 2 has internet but no MPLS. If Router 1 dies, you lose all MPLS connectivity at the branch, because the only router connected to MPLS is gone - even though Router 2 is alive and well. Your "redundant" branch has a single point of failure per transport. That is not redundancy; it is two half-connected routers.

The solution: extend the TLOC

TLOC extension connects the two routers with a link and lets each router reach the other's transport across it. Router 1's MPLS transport becomes usable by Router 2, and Router 2's internet transport becomes usable by Router 1. Now each router has a TLOC on both transports - one local, one extended through its partner.

Recall from the OMP deep dive that a TLOC is a tunnel endpoint (system-ip + colour + encapsulation), and a router can have up to eight. TLOC extension gives a router an additional TLOC for a transport it is not physically connected to, reached via the partner router. Both routers now advertise MPLS and internet TLOCs, so the loss of either router still leaves the branch with both transports.

How it is configured

A physical link connects the two routers (the TLOC-extension interface). On Router 2, its interface toward Router 1 is configured to reach Router 1's MPLS transport:

! On Router 2 - reach MPLS via Router 1
interface GigabitEthernet3
 description TLOC-EXTENSION-TO-R1
 ip address 10.99.1.2 255.255.255.252
 tloc-extension GigabitEthernet1      ! R1's MPLS transport interface
!

The tloc-extension command binds Router 2's inter-router interface to Router 1's MPLS transport interface. Router 2 now builds its MPLS tunnels through Router 1's MPLS circuit, across the inter-router link. It has an MPLS TLOC without an MPLS circuit of its own. Router 1 is configured symmetrically to reach the internet transport via Router 2.

Verifying it (documented reference)

The proof is that each router now has TLOCs on both colours:

Router2# show sdwan omp tlocs | i mpls|biz-internet
ipv4     10.0.0.12   mpls          ipsec  ...   ! extended via R1
ipv4     10.0.0.12   biz-internet  ipsec  ...   ! local

Router2# show sdwan bfd sessions
SYSTEM IP   COLOR         STATE   ...
10.0.0.11   mpls          up            ! MPLS tunnel, built through R1
10.0.0.11   biz-internet  up            ! internet tunnel, local

Router 2 has a working MPLS BFD session despite having no MPLS circuit - the session runs through Router 1's MPLS transport via the extension link. That is the whole feature working: full dual-transport reachability on a router that is only physically connected to one transport.

Where TLOC extension fits

The economic driver is real: TLOC extension lets you build a properly redundant dual-router branch without paying for duplicate circuits of every transport at every branch. You buy one MPLS and one internet handoff, terminate them on different routers, and extend - and the branch survives the loss of either router with both transports intact.

Design considerations

1. The inter-router link is now critical. It carries the extended transport's traffic. If it fails, the extension breaks and each router falls back to only its local transport. Make it robust - a direct connection, ideally with its own redundancy if the branch is important enough.
2. Capacity. When Router 2 sends MPLS traffic through Router 1's circuit, that traffic crosses the inter-router link and shares Router 1's MPLS bandwidth. Size the inter-router link and account for the shared circuit capacity under a failure.
3. The extension carries the transport, not the service. TLOC extension is about the transport (VPN 0) side. The service-side (LAN) redundancy - HSRP/VRRP for the endpoints' gateway - is a separate design concern layered on top.
4. Failure behaviour. Trace what happens when each component fails: Router 1 down (Router 2 keeps internet locally, loses MPLS entirely), the extension link down (each router falls to its local transport), Router 1's MPLS circuit down (both routers lose MPLS, since Router 2's MPLS was via Router 1). Know these before you deploy.

Key takeaways

• TLOC extension lets one WAN Edge use a transport that is physically connected to its partner router, via a link between them.
• It solves the dual-router branch problem: two routers for HA, but each transport terminates on only one router, so losing a router loses a transport. Extension gives each router a TLOC on both transports.
• Configured with the tloc-extension command on the inter-router interface, binding it to the partner's transport interface. The router then builds that transport's tunnels through its partner.
• Verify with show sdwan omp tlocs and show sdwan bfd sessions - a working tunnel on a colour the router has no local circuit for is the proof.
• It delivers true dual-router, dual-transport redundancy without duplicating every circuit at every branch - the economic win.
• Design carefully: the inter-router link becomes critical and shares the extended circuit's bandwidth; trace every failure case before deploying.

That closes the advanced SD-WAN series, and with it the CCIE Software-Defined Infrastructure domain across both SD-Access and SD-WAN. The full cluster index lives on the SD-WAN pillar.