James got confused by a statement made by Hannes Gredler in his IS-IS book:

Things behave really badly if the total IGP cost over the tunnel undermines the total topologies’ cost. What happens next is that the tunnel “wraps” around itself, ultimately causing a meltdown of the entire network.

Let’s unpack that, starting with “Why would you need a tunnel?”

The only reason to transport traffic across a tunnel¹ is to prevent the intermediate nodes from inspecting the traffic and performing their own forwarding decision², typically due to one of the following scenarios:

1. We don’t like the forwarding decision taken by the intermediate node (traffic engineering)
2. We have to encrypt the traffic.
3. The intermediate node knows nothing about the address space of the transported traffic (VPN)

In the first two scenarios, tunnel termination- and intermediate nodes use the same address space. Running a routing protocol over a tunnel could easily result in the tunnel itself being the best path for the remote tunnel endpoint, resulting in the (infinite) encapsulation recursion vividly described by Hannes (see also: running OSPF over VXLAN).

MPLS/TE disables routing adjacencies over MPLS/TE “tunnels”³ to avoid tunnel recursive routing. MPLS/TE tunnel is solely a data-plane construct; when a link-state routing protocol installs its routes into the RIB/FIB, it changes the outgoing interface in the FIB to a tunnel interface if the best path in the link-state shortest-path tree traverses the tunnel tail-end node⁴.

You have to be extra careful with IPsec tunnel interfaces. You should announce the edge subnets over the tunnel (or the traffic wouldn’t be pulled into the IPsec tunnel and encrypted) but not the tunnel endpoints (to avoid recursive routing). When you figure out an easy way to do that with a single OSPF or IS-IS instance, please let me know.

VPNs are a different beast. The VPN edge nodes (PE devices in MPLS/VPN or EVPN lingo) transport traffic from customer address space⁵ using tunnels⁶ built over the provider address space. They must use routing protocols⁷ to exchange customer prefixes and transport prefixes. Traditional MPLS/VPN and EVPN achieve a clear separation between the two using BGP for customer prefixes and an IGP for transport prefixes. The GIFEE crowd wants to use EBGP everywhere, but even they usually use separate address families for the customer (L3VPN/EVPN) and transport (IPv4/IPv6) prefixes.

So far, so good. But what if you believe BGP is too complex to be used? If you’re willing to be persuaded otherwise, I have a few free labs to get you started. Nope? That’s too bad :( but it was worth a try.

However, you can use one more trick if you insist on running an IGP over a tunnel established between endpoints advertised with the same IGP: split the customer- and transport address spaces into two VRFs (one of them could be the global routing table). That will create two independent IGP instances, and as the tunnel endpoints are not in the customer VRF, you’ll never get recursive routing over a tunnel.