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.

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).

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.

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.

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

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).

"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)

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.

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 tun0ip 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!

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 ?

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 ?

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net, has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.