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

TLOC Extension: Two Routers, Two Circuits, Four Paths

Software Defined Infrastructure ｜ Configuration ｜ Advanced ｜ 22 min read

A site with two routers and two transports has an obvious problem that is easy to miss on a diagram. If the first router owns the private circuit and the second owns the internet circuit, then each transport has exactly one router in front of it — and losing either router loses a transport entirely, even though the circuit itself is fine. The site still has connectivity, and it has lost half its path diversity to a failure that path diversity was supposed to cover.

The obvious fix is to give both circuits to both routers, which means four circuits and a bill nobody approves. TLOC extension is the other answer: a direct link between the two routers, over which each one reaches the other's transport. Two circuits, two routers, and every combination survives a single failure of either kind.

This article covers the problem precisely, how the extension is configured and what the static routing has to look like, what path the traffic actually takes and what that means for the link between the routers, how the arrangement interacts with path selection and failover, and the failures that are hard to spot because the site keeps working while quietly having lost the redundancy it was built for. 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 ClaimTLOC extension buys path diversity at the cost of a bandwidth dependency between two routers, and the link between them is a capacity decision that gets made by accident far more often than deliberately.
Without extension each transport depends on one router. A direct link between the routers lets each reach the other's circuit, so a single router failure costs no path diversity.

What Problem Does TLOC Extension Solve?

What is the gap?

A dual-router site with one transport each looks redundant and is only half redundant. The routers back each other up for the site's connectivity, and neither backs the other up for a transport. Losing a router loses whichever circuit it owned, so a site with a private circuit and an internet circuit degrades to one transport on any single router failure — precisely the situation two transports were bought to prevent.

A Deeper Dive into the Problem

Counting what actually survives

The useful exercise is to enumerate single failures and record what each one costs. Without extension, four single failures matter and two of them cost a transport. With extension, the same four failures cost nothing beyond capacity. That table is the whole justification, and it is more persuasive than any description because it names the specific outcome somebody is trying to avoid.

Single failure Without extension With extension
MPLS circuit down Internet only, via EDGE-2 Internet only, via either router
Internet circuit down MPLS only, via EDGE-1 MPLS only, via either router
EDGE-1 down MPLS lost entirely Both transports, via EDGE-2
EDGE-2 down Internet lost entirely Both transports, via EDGE-1
Extension link down N/A Back to the left-hand column

The alternatives and why they lose

Two other designs solve the same problem. Buying both circuits into both routers gives full diversity with no shared dependency and costs twice the circuits, which is the right answer when the circuits are cheap and the site is critical. Accepting the gap is the right answer when the site is small and a degraded transport for the duration of a router replacement is tolerable. Extension sits between them and is chosen most often because the economics usually favour it.

! What the site looks like before extension
EDGE-1# show sdwan omp tlocs | include 10.255.1.11
ipv4   10.255.1.11   mpls           ipsec   ...   C,I,R
! ^ one TLOC. This router knows one transport.
!
EDGE-2# show sdwan omp tlocs | include 10.255.1.12
ipv4   10.255.1.12   biz-internet   ipsec   ...   C,I,R
!
! A remote site therefore sees two TLOCs for this location,
! each with a single router behind it.

What the extension link is

An ordinary routed link between the two routers, carrying the extended transport's traffic. It is not a tunnel, not a special protocol, and not part of the LAN — it is a dedicated path whose only job is to let one router reach the other's transport network. Where both transports are extended in both directions, it commonly carries a sub-interface per extended transport so the two do not share a subnet.

Why this is not solved at the LAN side

A reasonable first instinct is that the site's LAN redundancy already covers this: if one router fails, hosts use the other, so what is lost. What is lost is on the WAN side rather than the LAN side. Hosts do reach the surviving router, and that router has one transport, so every conversation from the site now shares a single circuit — and remote sites have only one path in. The LAN redundancy worked exactly as designed and the transport diversity still halved.

The distinction is worth being explicit about because the two kinds of redundancy are frequently conflated in design reviews. Gateway redundancy at the site answers "can hosts still reach a router". Transport diversity answers "does the site still have two independent paths to the rest of the network". A dual-router site without extension has the first and only partially has the second, and only the second is what a second circuit was purchased for.

Where it does not apply

A single-router site has nothing to extend. A site where both routers already have both circuits gains nothing. And a site whose two routers are in different buildings needs a link between those buildings that is at least as reliable as the circuits it is protecting, or the extension introduces a dependency worse than the one it removes. That last case is the one worth checking, because the topology diagram rarely shows how the inter-router link is actually delivered.

Count endpoints, not circuits, when assessing a siteA site's real diversity is the number of tunnel endpoints remote locations can reach it on, which at a two-router two-transport site should be four. Circuit count and router count both look right in the failing cases described here; the endpoint count is the only figure that distinguishes a site with extension working from one where it lapsed.
Extension protects against router loss, not circuit lossBoth circuits failing is still both circuits failing. What the arrangement adds is that a router failure no longer takes a healthy circuit out of service with it. Being precise about that prevents it being sold internally as protection it does not provide.
Sub claimA dual-router site with one transport each is half redundant, because losing a router costs a circuit that is still working — which is the specific failure extension exists to remove.

How Is TLOC Extension Actually Configured?

What are the pieces?

Three, and all three are needed. A link between the two routers with addressing in the extended transport's subnet. A statement on the router that owns the circuit, naming which of its interfaces is being extended out of which interface. And a route on the borrowing router telling it to reach that transport's gateway across the link. Miss the third and the configuration looks complete and forms no tunnels.

A Deeper Dive into the Configuration

The router that owns the circuit

The owner declares that the interface facing its peer is an extension of its transport interface. That single statement is what permits the peer's traffic to use the circuit, and it is directional — extending the internet circuit towards the first router is one statement, and extending the private circuit the other way is a separate one on the other device.

! EDGE-2 owns the internet circuit and extends it to EDGE-1
interface GigabitEthernet0/0/0
 description Internet circuit
 ip address 203.0.113.42 255.255.255.248
!
interface GigabitEthernet0/0/2
 description TLOC extension link to EDGE-1
 ip address 203.0.113.45 255.255.255.248
 tloc-extension GigabitEthernet0/0/0
 ! ^ names the transport being extended out of this link
!
! Confirm it is in place
EDGE-2# show running-config interface GigabitEthernet0/0/2 | include tloc
EDGE-2# show sdwan control local-properties | include tloc-ext

The router that borrows it

The borrowing router treats the extension link as a transport interface. It gets an address in the same subnet as the circuit, builds a tunnel interface on it with the owner's colour, and needs a route to the circuit's gateway pointing across the link. That route is the piece most often missing, because everything else about the configuration reads as complete without it.

! EDGE-1 borrows EDGE-2's internet circuit
interface GigabitEthernet0/0/2
 description TLOC extension link to EDGE-2
 ip address 203.0.113.44 255.255.255.248
 ! ^ same subnet as EDGE-2's internet circuit
!
! The route that is always forgotten
ip route 0.0.0.0 0.0.0.0 203.0.113.41
! ^ the ISP gateway, reached across the extension link
!
sdwan
 interface GigabitEthernet0/0/2
  tunnel-interface
   encapsulation ipsec
   color biz-internet
   allow-service dns
   allow-service icmp
  exit
 exit
!
! EDGE-1 should now advertise TWO tlocs
EDGE-1# show sdwan omp tlocs | include 10.255.1.11

Doing it in both directions

Most designs extend both transports, so each router borrows from the other. That means two extension relationships over the same physical link, and keeping them in separate subnets is what stops them interfering. A sub-interface per extended transport is the usual arrangement and it makes the configuration read as two independent relationships, which is what they are.

! Both directions over one physical link, two sub-interfaces
! ===== EDGE-1, which owns MPLS =====
interface GigabitEthernet0/0/2.100
 encapsulation dot1Q 100
 ip address 10.1.12.1 255.255.255.252
 tloc-extension GigabitEthernet0/0/1
 ! ^ extends EDGE-1's MPLS circuit to EDGE-2
!
interface GigabitEthernet0/0/2.200
 encapsulation dot1Q 200
 ip address 203.0.113.44 255.255.255.248
 ! ^ EDGE-1 BORROWS the internet circuit here
!
! ===== EDGE-2, which owns the internet =====
interface GigabitEthernet0/0/2.100
 encapsulation dot1Q 100
 ip address 10.1.12.2 255.255.255.252
 ! ^ EDGE-2 borrows MPLS here
!
interface GigabitEthernet0/0/2.200
 encapsulation dot1Q 200
 ip address 203.0.113.45 255.255.255.248
 tloc-extension GigabitEthernet0/0/0

Addressing, which the provider decides

The borrowing router needs an address the provider will route, which means the circuit has to come with more than one usable address. A single-address handoff cannot be extended in this form, and that constraint is a procurement question rather than a configuration one. Discovering it during implementation is common and it is entirely avoidable by asking the provider for a small subnet at ordering time. A handful of usable addresses costs little and is impossible to add retrospectively without a change request and a wait.

Provider handoff Extension possible What is needed
A small routed subnet Yes One address per router from it
Single address, static Not in this form Request additional addresses
Single address by DHCP Not in this form Request a static subnet
Private circuit, your addressing Yes Nothing — you control it

Colours, and keeping them honest

The borrowed tunnel interface must carry the same colour as the circuit it is actually using, because the colour is what tells remote sites how to reach it and whether to expect a translated address. Giving the borrowed interface a different colour from the one the owner advertises produces two endpoints claiming different transports over one circuit, which confuses selection and defeats any policy written in terms of transport.

The related point is that the colour's public or private character has to match the circuit's reality on both routers. A private colour on the borrowing router for a circuit that crosses translation will behave exactly as a private colour does anywhere — advertising an address remote sites cannot reach. The colour follows the circuit, not the router, and both routers must agree about it.

Verifying it actually worked

! Each router should now hold two TLOCs of its own
EDGE-1# show sdwan omp tlocs | include 10.255.1.11
ipv4   10.255.1.11   mpls           ipsec   ...   C,I,R
ipv4   10.255.1.11   biz-internet   ipsec   ...   C,I,R
!
! And sessions on both colours from both routers
EDGE-1# show sdwan bfd sessions | include biz-internet
EDGE-1# show sdwan control connections
!
! From a REMOTE site, four TLOCs for this location
REMOTE# show sdwan omp tlocs | include 10.255.1.11|10.255.1.12
! ^ two per router. That is the goal, and it is the
!   single check that proves the design is working.
Pitfall: the extension configured without the static route Symptom: the borrowing router has an address in the transport subnet, a tunnel interface with the right colour, and forms no tunnels on that colour. Its own transport works normally. Every piece of the extension configuration appears to be present. Cause: the router has an address on the extension link but no route towards the circuit's gateway, so nothing it sends on that colour can leave the site. The extension statement on the peer permits the traffic; it does not tell this router where to send it. Confirm: show ip route has no path towards the transport gateway; a ping to the gateway from that router fails. Fix: add the route across the extension link, and check both routers — when both transports are extended, both need one.
Sub claimThe extension statement permits the traffic and the static route directs it, which is why a configuration containing only the first looks complete and builds no tunnels at all.

What Does the Traffic Path Actually Look Like?

Where does the traffic go?

Traffic that a router sends on a borrowed transport leaves that router, crosses the link to the owner, and exits the owner's circuit — without being decapsulated or inspected in between. The owning router is forwarding it as ordinary transit, not terminating it. That has two consequences worth understanding: the tunnel genuinely belongs to the borrowing router, and the link between them carries real user traffic rather than control traffic.

A Deeper Dive into the Path

Whose tunnel is it

The borrowing router's. Its system address appears in the endpoint identity, its encryption keys protect the traffic, and a remote site building a tunnel to that endpoint is building it to that router. The owning router is a hop in the middle that happens to be at the same site. This is why the arrangement delivers genuine diversity rather than a workaround: remote sites really do have two independent paths into the location.

! A remote site's view - two distinct endpoints per router
REMOTE# show sdwan bfd sessions | include 10.255.1.11
SYSTEM IP      SITE ID  STATE  SOURCE TLOC   REMOTE TLOC    ...
10.255.1.11    111      up     mpls          mpls
10.255.1.11    111      up     biz-internet  biz-internet
! ^ both to EDGE-1, one of them through EDGE-2's circuit
!
! The owning router does not terminate it
EDGE-2# show sdwan bfd sessions | include 10.255.1.11
! ^ empty: EDGE-2 has no session to EDGE-1's endpoint,
!   because it is transit rather than a tunnel peer

The bandwidth consequence

Everything the borrowing router sends on that transport crosses the link between the routers, so that link carries a share of the site's WAN traffic rather than nothing. Sizing it as an afterthought — a spare gigabit port because one was free — usually works and occasionally does not, and the failure mode is congestion that appears only on one transport and only for one of the two routers.

! Watch the extension link like a WAN link, not a patch cable
EDGE-1# show interfaces GigabitEthernet0/0/2 | include rate|drops
  30 second input rate 184000000 bits/sec
  30 second output rate 211000000 bits/sec
  Total output drops: 0
!
! Compare against the circuit it is feeding
EDGE-2# show interfaces GigabitEthernet0/0/0 | include rate
!
! If the extension link is smaller than the circuit, it
! becomes the limit for the borrowing router's share.

What happens when the extension link fails

The borrowed endpoint goes away and the site reverts to the arrangement it had before extension was configured — each router with its own transport. Nothing else breaks, no traffic is black-holed, and remote sites withdraw the affected endpoints normally. This is a benign failure mode and it is worth stating, because the instinct is to assume that a link carrying WAN traffic failing must be serious.

What the provider sees

Two routers now source traffic from one circuit, with two different addresses from the provider's subnet. For a private circuit that is unremarkable. For an internet circuit it occasionally matters, because some access products expect a single device and enforce that in ways ranging from a hardware address restriction to a session limit. Where such a restriction exists, it surfaces as the borrowing router's traffic being dropped while the owner's works perfectly.

That symptom is easy to misread as a configuration fault, because everything on both routers is correct and one of them simply does not pass traffic. Establishing early what the provider permits — how many addresses, whether hardware addresses are restricted — turns this into a procurement conversation before implementation rather than a diagnosis afterwards.

Quality of service on the extension link

Traffic crossing the extension link is already encapsulated, so the outer marking is what any policy on that link can act on. If the site applies shaping or prioritisation on its WAN circuits, the extension link needs equivalent treatment or it becomes the place where prioritisation quietly stops applying. This is a small configuration item that is easy to omit because the link does not look like a WAN link. 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 extension link carries encapsulated WAN traffic
! and deserves the same treatment as a WAN circuit
interface GigabitEthernet0/0/2
 service-policy output WAN-QOS
!
! Confirm the policy is acting on what you expect
EDGE-1# show policy-map interface GigabitEthernet0/0/2
EDGE-1# show interfaces GigabitEthernet0/0/2 | include drops|queue
The owning router is transit, not a peerIt forwards the borrowing router's encapsulated traffic without terminating it, which is why the owning router shows no tunnel session to its neighbour and why nothing about the arrangement appears in its own endpoint table. Looking for evidence of the extension on the owning router's tunnel state is looking in the wrong place.
Sub claimThe borrowed tunnel belongs to the borrowing router and merely transits its neighbour, which is what makes the diversity real and what puts genuine WAN traffic on a link that is usually sized as an afterthought.

How Does It Interact With Selection and Failover?

Does the overlay know the difference?

No, and that is the design's best property. A borrowed endpoint is an ordinary endpoint as far as selection is concerned — it has a colour, a preference, a weight, and it competes on exactly the same terms as a directly attached one. Nothing in policy needs to know that a particular path traverses a neighbour, which means no policy has to be written to accommodate the arrangement.

A Deeper Dive into Behaviour

Preference across four endpoints

A two-router site now presents four endpoints to the overlay, and the preference values decide which ones remote sites use. Leaving them all equal means traffic spreads across all four, which is usually right. Setting preference to prefer directly attached endpoints over borrowed ones is a reasonable refinement, because it keeps traffic off the extension link when it does not need to be there.

! Prefer the direct path, use the borrowed one as backup
! ===== EDGE-1 =====
sdwan
 interface GigabitEthernet0/0/1
  tunnel-interface
   color mpls
   preference 200          ! its own circuit
  exit
 exit
 interface GigabitEthernet0/0/2
  tunnel-interface
   color biz-internet
   preference 100          ! borrowed via EDGE-2
  exit
 exit
!
! The result: the extension link carries traffic only when
! the direct path is unavailable, which is usually what
! the capacity planning assumed anyway.

Detection, which is unchanged

Liveness is measured end to end between the two tunnel endpoints, so a failure anywhere along the borrowed path — the extension link, the neighbour, the circuit, or anything beyond it — is detected by the same mechanism at the same speed as a failure on a direct path. The arrangement adds hops and adds no detection delay, because nothing in the middle is being probed separately.

! Liveness is end to end, whatever is in between
EDGE-1# show sdwan bfd sessions
EDGE-1# show sdwan bfd history | include biz-internet
!
! A failure of ANY of these looks identical to the overlay:
!   the extension link
!   EDGE-2 itself
!   EDGE-2's circuit
!   anything upstream of it
! All are simply "that endpoint is unreachable".

What application-aware routing sees

Path quality on a borrowed path is measured over the whole path including the extension link, so a congested extension link shows up as loss or latency on that transport and traffic moves away from it automatically. That is correct behaviour and it is worth knowing during an investigation: a transport that has become unattractive at one router and not the other points at something between those two routers rather than at the circuit.

The comparison worth running

Observation Suggests Check
One colour degraded on both routers The circuit or its provider The circuit itself
One colour degraded on one router only The extension link Utilisation and drops on that link
Both colours degraded on one router That router or its LAN path The router itself
Both colours degraded everywhere Something site-wide Power, LAN, upstream

Capacity after a failure, which is the number to state

Path diversity and capacity are different promises, and extension delivers the first fully and the second partially. After the owning router fails, the site has both colours available and one router's worth of forwarding capacity behind them. Whether that is acceptable is a question about the site's actual traffic rather than about the design, and answering it in advance prevents an argument during the incident about whether the redundancy "worked".

The honest formulation is that extension guarantees the site keeps two transports through any single failure, and guarantees nothing about throughput. For most branches that is exactly the right trade, because the concern was losing a path rather than losing headroom. For a site where the two circuits are both near capacity in normal operation, the design needs a conversation about what degraded looks like.

Failover in practice

Losing the owning router removes the borrowed endpoint and the owner's own endpoint at the same moment, leaving the borrowing router's direct endpoint carrying everything. The site keeps both transports in the sense that remote traffic still has two colours available to it — one from each router — but at reduced total capacity. That is the outcome the design was bought for, and it is worth rehearsing once rather than discovering during an incident.

! Rehearse it: shut the owning router's transport and watch
EDGE-2(config)# interface GigabitEthernet0/0/0
EDGE-2(config-if)# shutdown
!
! On a remote site, two endpoints should disappear
REMOTE# show sdwan bfd sessions | include 10.255.1.11|10.255.1.12
REMOTE# show sdwan omp tlocs | count
!
! And traffic should still reach the site
REMOTE# ping vrf 10 <an address at the site>
!
EDGE-2(config-if)# no shutdown
Nothing in policy needs to know the extension existsTopology policy, application-aware routing and preference all operate on endpoints, and a borrowed endpoint is simply an endpoint. That is why the arrangement can be added to an existing site without touching any central policy — the site gains two endpoints and everything already written continues to apply to them unchanged.
Test by failing the owning router, not the circuitFailing a circuit tests something the site could already survive. Failing the router that owns a circuit is the specific scenario extension was configured for, and it is the test that proves the configuration works rather than merely that it is present.
Sub claimA borrowed endpoint competes in selection on identical terms to a direct one, which is why the arrangement needs no policy accommodation and why nothing in the overlay has to be told it exists.

Which TLOC Extension Failures Are Hard to Spot?

What are the failures worth memorising?

Four, and they share a property: the site keeps working. The missing static route, which produces a configuration that looks complete and forms no borrowed tunnels. An extension configured in one direction only. An extension link too small for what it carries. And the case where the arrangement was working and silently stopped, leaving a site that believes it is redundant and is not.

A Deeper Dive into the Failure Catalogue

Configured one way only

Pitfall: extension built in one direction and not the other Symptom: one router has two endpoints and the other has one. The site works, remote sites reach it on both transports, and nothing indicates a problem — until the router with two endpoints fails, at which point a transport is lost exactly as it would have been without any extension at all. Cause: the extension statement and the borrowing configuration were applied for one transport and never mirrored for the other, usually because the first one was verified, declared working, and the second forgotten. Confirm: count endpoints per router at the site — both should have the same number. Fix: mirror the configuration, and make the endpoint count per router a commissioning check rather than an assumption.

The redundancy that quietly lapsed

Pitfall: a borrowed endpoint down for weeks with no symptom Symptom: nothing at all, until a router failure produces a bigger outage than expected. Investigation afterwards finds the borrowed endpoint had been down since an unrelated change, possibly months earlier. Cause: a borrowed endpoint being down costs nothing while both routers are up — traffic simply uses the remaining three paths. There is no user-visible consequence and therefore no report, which is the defining characteristic of lapsed redundancy. Confirm: the endpoint count per router, compared against the designed number. Fix: monitor that count as a first-class metric; it is the only thing that detects this class, and the expected value is known and constant.

The undersized link

Pitfall: an extension link smaller than the circuit it feeds Symptom: one transport performs well from one router and poorly from the other, with both showing as healthy. Application-aware routing steers traffic away from the borrowed path, so the symptom is reduced capacity rather than failure. Cause: the borrowing router's share of that circuit is limited by the link between the routers, and a link chosen for convenience rather than capacity becomes the constraint. Confirm: utilisation and output drops on the extension link, compared against the circuit's capacity. Fix: size the link at least to the circuit's capacity, or set preference so the borrowed path is a backup rather than an active peer.

A commissioning checklist

! Prove it works, rather than that it is configured
!
! 1. Each router advertises the designed number of TLOCs
EDGE-1# show sdwan omp tlocs | include 10.255.1.11 | count
EDGE-2# show sdwan omp tlocs | include 10.255.1.12 | count
!
! 2. A remote site sees all of them
REMOTE# show sdwan omp tlocs | include 10.255.1.11|10.255.1.12
!
! 3. Sessions exist on the borrowed colour from both
EDGE-1# show sdwan bfd sessions | include biz-internet
EDGE-2# show sdwan bfd sessions | include mpls
!
! 4. The route across the extension link exists, both ways
EDGE-1# show ip route 0.0.0.0
EDGE-2# show ip route <mpls gateway>
!
! 5. Fail the OWNING router and confirm nothing is lost

Documenting it where it will be read

The arrangement is invisible from any single device's perspective: the owning router shows no tunnel to its neighbour, the borrowing router shows an ordinary transport interface, and neither configuration announces that the two are related. Somebody troubleshooting either router a year from now will not know the extension exists unless something tells them.

Interface descriptions are the place for that, because they are read by whoever is about to change the interface. A description naming the peer router and the transport being extended costs nothing and prevents the specific accident of someone reconfiguring what looks like a spare inter-router link. The same applies to the static route, which otherwise reads as an inexplicable default route on a router that already has one.

What to monitor

One number, and it is the one nothing else covers: endpoint count per router, compared against the designed value. It is constant in normal operation, it changes only when something in this article has gone wrong, and it has no false positives. Utilisation on the extension link is a useful second, and everything else is already covered by ordinary transport monitoring. Two checks, both trivial, covering a failure class that produces no other signal.

Templating it across an estate

Extension is a per-site arrangement whose configuration is highly repetitive, which makes it a good candidate for a template with the site-specific addresses as variables. The benefit is not typing but consistency: a template applied to every dual-router site cannot omit the static route at one of them, which is precisely the failure mode described earlier and precisely the kind of omission that happens when forty sites are built by hand over several months.

The values that vary per site are the transport subnets and the extension link addressing; everything else — the extension statements, the tunnel interfaces, the colours, the preferences — is identical. Separating those two categories explicitly when writing the template is what keeps it reusable, and it also documents which parts are decisions and which are per-site facts.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers SD-WAN within the software-defined infrastructure domain, and this topic tends to appear as a design question rather than a configuration one: given a site with two routers and two transports, how do you ensure a router failure does not cost a transport. Being able to name the mechanism, state the three configuration pieces, and identify the static route as the one usually missing covers what is asked.

Lapsed redundancy is invisible by definitionEvery failure in this section leaves the site fully operational, which means none of them generates a report and none of them is found by responding to incidents. They are found by comparing a count against a designed value, which is why that check is worth automating even though it looks trivial.
Sub claimEvery failure in this list leaves the site working, which means none will ever be reported and the endpoint count per router is the only check that finds them.

Conclusion

A dual-router site with one transport each is not as redundant as it appears: each circuit has a single router in front of it, so losing a router costs a circuit that is still perfectly healthy. TLOC extension removes that specific failure by giving each router a path to the other's transport, turning two circuits and two routers into four tunnel endpoints and full diversity for a fraction of the cost of duplicating the circuits.

The configuration is three pieces and the third is the one that gets missed. The link between the routers, the statement on the owner permitting its circuit to be used, and the route on the borrower telling it where to send traffic. Without that route the configuration reads as complete, the tunnel interface exists, and no tunnel ever forms — which is a frustrating amount of time to lose to a single line.

Everything else about the arrangement is deliberately unremarkable. The borrowed endpoint competes in selection like any other, liveness is measured end to end so detection is unchanged, and a failure anywhere along the borrowed path looks like any other endpoint failure. The two things that need attention are the capacity of the link between the routers, which now carries real WAN traffic, and the endpoint count per router — the only number that reveals when the redundancy has quietly lapsed. 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 TLOC extension as allowing a WAN Edge router to use a transport circuit attached to a second WAN Edge router at the same site.
  2. Cisco documentation describes the tloc-extension interface command, which names the local transport interface being made available over the link to the peer router.
  3. Cisco documentation notes that the router using the extended transport requires an IP address in that transport's subnet and a route towards the transport gateway.
  4. Cisco documentation defines a TLOC as the combination of system IP address, colour and encapsulation, so a router using an extended transport advertises an additional TLOC of its own.
  5. Cisco documentation describes TLOC preference, where the higher value is preferred, as the mechanism for favouring a directly attached transport over an extended one.
  6. RFC 5880 specifies BFD, which SD-WAN uses between tunnel endpoints to detect liveness independently of the number of intermediate hops.
  7. RFC 4301 defines the IPsec security architecture protecting the data plane tunnels, which remain associated with the router that originates them.
  8. RFC 6347 specifies DTLS, used for the control connections between WAN Edge routers and the controllers.
  9. Cisco design guidance describes dual WAN Edge site topologies in which each router terminates a different transport, and the redundancy implications of that arrangement.
  10. Cisco documentation describes application-aware routing measuring loss, latency and jitter over the full tunnel path, which for an extended transport includes the inter-router link.
  11. Cisco documentation describes sub-interface based TLOC extension, used when both transports at a site are extended over a single physical link between the routers.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include SD-WAN within the software-defined infrastructure domain.