Running Routing Protocols over Tunnels

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 tunnel1 is to prevent the intermediate nodes from inspecting the traffic and performing their own forwarding decision2, 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”3 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 node4.

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 space5 using tunnels6 built over the provider address space. They must use routing protocols7 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.

  1. Or MPLS LSP, because I really don’t want to go into the “is MPLS tunneling” discussion. ↩︎

  2. Ignoring the “increasing my job security,” “just because I can,” and “I need to practice for the CCIE lab exam on my production network” aspects. ↩︎

  3. MPLS/TE tunnels are one-way tunnels, so building routing adjacencies over them would be a bit hard, but I’m digressing. I vaguely remember seeing a use case for IGP routing adjacency over MPLS/TE tunnels a long while ago, but I can’t remember what it was. Do leave a comment if you know more. ↩︎

  4. As one might expect, there are a half-dozen nerd knobs you can tweak to save your broken design or to make a CCIE lab more interesting. ↩︎

  5. IPv4, IPv6, or Ethernet traffic ↩︎

  6. MPLS LSPs, VXLAN tunnels, GRE tunnels… ↩︎

  7. Or static routes, SDN controllers, or a crystal ball. ↩︎

Recent posts in the same categories

2 comments:

  1. Anonymous 09 November 2024 10:24
    Not tested for this specific case but I know an implementation that allows to filter routes in OSPF: https://docs.fortinet.com/document/fortigate/7.6.0/cli-reference/103419153/config-router-ospf#:~:text=OSPF%20area%20filter-list
    Replies
    1. Tim Hendricks 12 November 2024 07:10

      IMHO VLAN interfaces should always be passive because they don't represent real physical paths and just clutter the routing tables. Am I wrong?

    2. Ivan Pepelnjak 13 November 2024 09:24

      That's a pretty good starting point. There might be exceptions (there always are), for example, when you're using the same device as a switch and an aggregation router.

  2. Dan Massameno 15 November 2024 03:54

    Great article.
    For Ivan's Type 3 VPN setup, I always use two different VRFs.

    Global VRF: This is the underlay with general Internet. Frequently I have one static route for 0.0.0.0/0.

    Internal VRF: This is the customer network, frequently OSPF.

    With VRFs I never have to dance around filtering routes into and out of the OSPF. In fact, nothing fancy needs to be done at all. Clean separation every time.

    I did my first infinite recursion when doing IP (with IPX/SPX) over GRE over IPSec. Never fun. Don't want to troubleshoot that ever again.

Add comment
Home
Sidebar