Solution: EIGRP summarization breaks Phase 2 DMVPN

Last week I posted an interesting challenge: what happens if you configure route summarization in a Phase 2 DMVPN network? The only response came from an anonymous contributor strongly suspected to be a routing/DMVPN expert working for a CCIE-related training company. Everyone else obviously found the question too trivial ... or too obscure, in which case it could be a good idea to join us at the next DMVPN: From Basics to Scalable Networks webinar.

The anonymous responder was somewhat cryptic, so let’s do a step-by-step explanation. We’ll use a simple 3-router network; C1 is hub, R2 and R3 are spokes.

Routing updates in DMVPN networks (usually) flow only between the hub and the spokes as dictated by static and dynamic NHRP multicast maps. In our scenario, C1 and R2 (as well as C1 and R3) are EIGRP neighbors, but R2 and R3 cannot exchange routing updates. As explained in the Choose the Optimal VPN Service webinar (register here) this behavior makes DMVPN way more scalable than VPLS (I know, another shameless plug).

Without any special configuration on C1, R2 and R3 would never see each other’s routes. EIGRP uses split horizon filters; updates received from R2 are thus never sent to R3, which receives only EIGRP routes originated by C1 (and any other routes behind C1). R2 and R3 cannot communicate at all.

R3#show ip route eigrp | begin 10.0
      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D        10.0.1.1/32 [90/27008000] via 192.168.0.1, 00:01:27, Tunnel0
D        10.0.10.0/24 [90/26882560] via 192.168.0.1, 00:01:27, Tunnel0

When we disable EIGRP split horizon on the DMVPN tunnel interface of the hub router with no ip split-horizon eigrp 1 command, the spokes start receiving routes from other spokes, but the next-hop address is still the hub router. All traffic still flows through the hub (as dictated by the IP routing table).

R3#show ip route eigrp | begin 10.0
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.0.1.1/32 [90/27008000] via 192.168.0.1, 00:03:32, Tunnel0
D        10.0.1.5/32 [90/28288000] via 192.168.0.1, 00:00:07, Tunnel0
D        10.0.10.0/24 [90/26882560] via 192.168.0.1, 00:03:32, Tunnel0
D        10.0.15.0/24 [90/28162560] via 192.168.0.1, 00:00:07, Tunnel0

We have to disable EIGRP next-hop processing on the hub router to enable spoke-to-spoke traffic flow (no ip next-hop-self eigrp 1 command entered on the DMVPN tunnel interface). IP next hops for the spoke routes are now the other spoke routers.

R3#show ip route eigrp | begin 10.0
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.0.1.1/32 [90/27008000] via 192.168.0.1, 00:01:29, Tunnel0
D        10.0.1.5/32 [90/28288000] via 192.168.0.5, 00:01:24, Tunnel0
D        10.0.10.0/24 [90/26882560] via 192.168.0.1, 00:01:29, Tunnel0
D        10.0.15.0/24 [90/28162560] via 192.168.0.5, 00:01:24, Tunnel0

If we configure summarization on the hub router with the ip summary-address eigrp 1 10.0.0.0 255.0.0.0 command, the individual routes are suppressed (the spokes no longer receive /32s and /24s) and the summary prefix is advertised with the hub router as the next hop. Traffic between spokes yet again flows through the hub router – we’ve managed to destroy the most important property of Phase 2 DMVPN.

R3#show ip route eigrp | begin 10.0
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
D        10.0.0.0/8 [90/26882560] via 192.168.0.1, 00:00:02, Tunnel0

Update 2011-02-11: As bmigette pointed out in the comments, summarizing spoke routes on the tunnel interface of the spoke router is OK as is summarizing any non-spoke routes on the hub router. You break spoke-to-spoke traffic flow only if the hub router summarizes routes from multiple spoke sites into a single IP prefix.

Lesson learned

Careless route summarization at the hub router stops spoke-to-spoke traffic flow in Phase 2 DMVPN networks using EIGRP.

If you have to reduce the amount of routing information sent to the spoke routers (which only makes sense if DMVPN is a small part of your network), use static route-generated summaries and route filters (distribute lists).

9 comments:

  1. Sorry about that :) Apparently I got too used to my ID being cached in the browser to re-enter my credentials!

    ReplyDelete
  2. Oh, it was fun 8-) I knew immediately who it was, but couldn't resist writing the "mistery contributor" lead-in.

    ReplyDelete
  3. "All traffic still flows through the hub (as dictated by the IP routing table)."

    I guess this could be considered accurate in a sense but the way it's worded would lead to wrong assumptions. i.e. That the RIB is authoritative in DMVPN networks. It's not. NHRP is.

    In a DMVPN phase 3 network the routing table on the spoke still always shows the hub as the next hop but traffic actually flows via the spoke to spoke tunnel becuase NHRP will affect a change in CEF once the prefix is resolved via NHRP. If you were to compare the routing table in your "hub only" summarized scenario to the routing table in a phase 3 DMVPN network they would be the same but the traffic flow would not.

    The key to phase 3 is the NHRP redirect where the hub will tell the spoke to resolve(send NHRP resolution request) for some prefix X because the hub noticed that the first packet came and left the hub on an mGRE tunnel with the same NHRP network ID(likely the same tunnel interface unless it's a multi-tier DMVPN network)

    ReplyDelete
  4. While everything your write is absolutely correct, my blog post discusses the Phase 2 DMVPN (as indicated in the headline and a few times throughout the text), so my statement is still perfectly accurate.

    And while we're nitpicking - the only authoritative structure is the CEF table, which is built from RIB and augmented by the NHRP cache.

    ReplyDelete
  5. haha, fair enough. I was trying to stick to the control plane only so didn't bring up CEF. Never been here before so I did not notice you were the owner of the blog and likely already knew.

    ReplyDelete
  6. Hi all,
    I was skeptical about the route summarization thing. If you make a summary from the hub that summarize the routes from the spokes or same summary from the spoke that will be sent to hub, that's logical that it will became the next hop of the spoke since it's the way it work, and only the hub is reponsible for advertisement of routes in the DMVPN.
    Now, if you make a summary that concerns only the spoke network it work:
    I made a small test, 1 hub, 2 spoke. 10.[X].0.0 for each as private subnet. look at the spoke conf that advertise the summary:
    interface Loopback0
    ip address 10.2.0.1 255.255.255.0
    !
    interface Loopback1
    ip address 10.2.1.1 255.255.255.0
    !
    int tun0
    ip add 1.1.1.2 255.255.255.0
    !
    router eigrp 65000
    network 1.1.1.0 0.0.0.255
    network 10.2.0.0 0.0.0.255
    network 10.2.1.0 0.0.0.255
    no auto-summary
    !

    The summary:
    int tun0 ! the dmvpn tunnel int
    ip summary-address eigrp 65000 10.2.0.0 255.255.0.0 5

    Now, let's check what happens on the other spoke (same happen on the hub).

    R3#clear ip nhr ! clearing the nhrp cache
    R3#sh ip cef 10.2.1.0
    10.2.0.0/16, version 29, epoch 0 !see, the summary is installed, and point to my spoke tun as next hop
    0 packets, 0 bytes
    via 1.1.1.2, Tunnel0, 0 dependencies
    next hop 1.1.1.2, Tunnel0
    invalid adjacency ! invalid since next hop cef is glean (normal)
    R3#sh ip cef 1.1.1.2
    1.1.1.0/24, version 19, epoch 0, attached, connected
    0 packets, 0 bytes
    via Tunnel0, 0 dependencies
    valid glean adjacency (glean, as expected)

    now, let's check the ping, you'll see it work:
    R3#ping 10.2.1.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/44 ms
    R3#sh ip cef 10.2.1.0
    10.2.0.0/16, version 29, epoch 0
    0 packets, 0 bytes
    via 1.1.1.2, Tunnel0, 0 dependencies
    next hop 1.1.1.2, Tunnel0
    valid adjacency
    R3#sh ip cef 1.1.1.2
    1.1.1.2/32, version 31, epoch 0, connected
    0 packets, 0 bytes
    via 1.1.1.2, Tunnel0, 0 dependencies
    next hop 1.1.1.2, Tunnel0
    valid adjacency



    8-)

    ReplyDelete
  7. To summarize: you can always summarize spoke (or per-site) routes advertised into DMVPN. Absolutely true.

    ReplyDelete
  8. I was digging a bit in this DMVPN stuff, and I saw that on the DMVPN Phase 3, one of the improvements is allowing route summarization, so if I'm correct, the thing is that even with a 0.0.0.0/0 summary learnt through the router, the spoke will get a NHRP redirect from the HUB for the destination it tried to reach, and after that NHRP shortcut process is taking precedence over the FIB of the router, right ?

    ReplyDelete
  9. I was digging a bit in this DMVPN stuff, and I saw that on the DMVPN Phase 3, one of the improvements is allowing route summarization, so if I'm correct, the thing is that even with a 0.0.0.0/0 summary learnt through the HUB, the spoke will get a NHRP redirect from the HUB for the destination it tried to reach, and after that NHRP shortcut process is taking precedence over the FIB of the router, right ?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.