Cisco SD-WAN Data Plane: — TLOCs, Colors, IPsec Tunnels & BFD

① TLOC anatomy — the address a remote edge dials

Every overlay tunnel in Cisco SD-WAN has to start somewhere, and that somewhere is a TLOC (Transport Locator). Think of it as the data-plane phone number of a transport on a WAN Edge router. A site with two transports — MPLS and Internet — has two TLOCs, one per transport, and a remote edge dials one of them to bring up a tunnel.

A TLOC is a 3-tuple, and all three parts matter: the system-IP (which edge), the colour (which transport), and the encapsulation (ipsec or gre). Change any one and it's a different TLOC. The system-IP is just an identity, like a BGP router-ID — it does not have to be reachable or routable anywhere.

TLOCs travel over OMP. Each edge advertises its TLOC up to the SD-WAN Controller (vSmart) over the encrypted control connection, and the controller reflects it to every other edge. The advertisement carries far more than an IP: the colour, the encapsulation, the private and public IP/port, and the IPsec keys. The TLOC is the OMP next-hop for an overlay route — the SD-WAN answer to BGP's NEXT_HOP attribute.

The dabbawala analogy from Mumbai fits perfectly. A dabbawala doesn't memorise every flat in the city; each tiffin carries a coded tag — area, building, floor. The system-IP is the building, the colour is which route the runner takes (local train vs cycle), and the encap is the box it's wrapped in. The central sorting desk (the controller) hands every runner the same tag-list, but the runner then walks the last leg himself — exactly how a WAN Edge learns TLOCs from the controller but builds the tunnel directly to the peer.

Branch-Mumbai# show sdwan omp tlocs | tab

ADDRESS                                              PUBLIC          PRIVATE
FAMILY  TLOC IP        COLOR         ENCAP  FROM PEER    IP / PORT       IP / PORT       STATUS
-----------------------------------------------------------------------------------------------
ipv4    10.0.0.11      mpls          ipsec  10.0.0.99    192.168.10.2    192.168.10.2    C,I,R
ipv4    10.0.0.11      biz-internet  ipsec  10.0.0.99    203.0.113.11    172.16.10.2     C,I,R
ipv4    10.0.0.99      biz-internet  ipsec  10.0.0.99    203.0.113.99    172.16.99.2     C,I,R

The four words you'll say every day

Tap each card — these are the anchors for the whole lesson.

② Colours — who is allowed to call whom

Colour is the single most misunderstood word in SD-WAN. It looks like a label you can name anything, and you can — but the colour you pick decides whether a tunnel is even allowed to form, and which IP address the edge uses to reach the peer. There are two families: public colours and private colours.

A public colour — biz-internet, public-internet, lte, default, the metallic set (gold, silver, bronze) and custom1-3 — uses the post-NAT public IP that STUN via the Validator (vBond) discovered, and it can build a tunnel to any colour. A private colour — mpls, metro-ethernet, private1…private6 — uses the pre-NAT private IP and only builds a tunnel to the same private colour. The logic: public colours expect a NAT in the path; private colours assume a clean transport (an MPLS core) with no NAT between sites.

There's a second lever beyond the colour family: the restrict keyword and the carrier attribute. Add restrict to a tunnel and that TLOC will only form tunnels to remote TLOCs with the same colour — even a normally-promiscuous public colour gets locked down. Engineers use restrict on biz-internet to stop the broadband transport from wastefully meshing with an MPLS-coloured TLOC, keeping like-with-like.

Branch-Pune# show sdwan control local-properties | i color|tloc
Branch-Pune# show sdwan bfd sessions | tab

tloc-color                       biz-internet
...
SOURCE   DST PUBLIC
SYSTEM IP  SITE  STATE  COLOR         COLOR         IP              ENCAP  UPTIME
10.0.0.99   100  up     biz-internet  biz-internet  203.0.113.99    ipsec  0:02:14:51
10.0.0.50   200  up     biz-internet  biz-internet  203.0.113.50    ipsec  0:02:14:48

③ IPsec without IKE — OMP hands out the keys

Here's the part that surprises everyone coming from DMVPN or classic site-to-site VPN: SD-WAN builds IPsec with no IKE. There is no phase-1, no phase-2, no DH negotiation between the two routers. Instead each WAN Edge generates its own inbound IPsec key, advertises it to the controller over the trusted OMP/DTLS control connection, and the controller re-advertises that key to every other edge. The peers never negotiate directly — a controller you already trust replaces a handshake you'd otherwise have to secure.

By default the overlay forms a full mesh — every TLOC builds an IPsec (or GRE) tunnel to every compatible remote TLOC — though a control policy or a hub-and-spoke topology can prune that. Keys aren't forever: they rekey on a timer, default 86400 seconds (24 hours), configurable from 10 seconds up to 1209600 seconds (14 days). One subtle rule the exam loves: the IPsec rekey timer must be at least 2× the OMP graceful-restart timer, because the controller distributes the keys — if a controller blip happens to land inside a rekey, traffic drops.

Aadhaar OTP onboarding is the everyday analogy. You don't swap a secret face-to-face with the bank clerk; a trusted central authority (UIDAI) issues a one-time code over a channel you both already trust, and you present it. SD-WAN does the same — the trusted controller distributes the per-edge keys over the already-encrypted OMP path, so two edges that have never spoken can bring up an encrypted tunnel instantly. The key even expires and is reissued, exactly like an OTP rotating.

When two routers sit at the same site and only one of them owns a given transport, TLOC-extension lets the second router borrow the first's transport over a dedicated link — so both get a TLOC on that colour for redundancy. A related knob, the tunnel group, overrides colour entirely: give two TLOCs the same group-ID and they'll tunnel to each other regardless of colour. These are the transport-sharing tools the 300-415 blueprint expects you to recognise.

④ BFD — the sensor inside every tunnel

Once a tunnel is up, BFD runs inside it automatically — you don't enable it per neighbour the way you would for OSPF/BGP. BFD has two jobs. First, liveness: it sends a hello every 1000 ms by default, and if 7 in a row go missing (the default multiplier) it declares the tunnel down — roughly a 7-second blackout detection. Second, and this is the one people forget, it measures the path quality: loss, latency and jitter on every probe.

That measurement is what feeds App-Aware Routing (AAR). The edge accumulates BFD's loss/latency/jitter over a poll-interval (default 10 minutes), and AAR reviews 6 of those windows (the default multiplier) — a 1-hour rolling SLA view — to decide whether a tunnel still meets the policy for voice, video or business apps. This is why BFD is a data-plane topic that quietly drives routing decisions.

DC-Edge# show sdwan bfd sessions

                              SOURCE        REMOTE                        DST PUBLIC   DETECT  TX
SYSTEM IP   SITE  STATE  COLOR         COLOR         SOURCE IP     IP           MULT    INT  UPTIME
10.0.0.11   100   up     mpls          mpls          192.168.10.2  192.168.99.2  7      1000  0:11:03:18
10.0.0.11   100   up     biz-internet  biz-internet  172.16.10.2   203.0.113.11  7      1000  0:11:03:13
10.0.0.50   200   up     biz-internet  biz-internet  172.16.50.2   203.0.113.50  7      1000  0:09:41:02

Now the scenario the whole lesson builds to — the brownout. A link doesn't always fail cleanly. An MPLS circuit can stay line-protocol UP while quietly dropping 4% of packets — a ping looks fine, the interface counter barely moves, but a voice call turns robotic. The interface can't see it; BFD can, because it's measuring loss and jitter on the live path. When BFD's numbers breach the voice SLA, AAR hops the call onto the healthy Internet tunnel and the user never notices — then returns it automatically when MPLS recovers.