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.
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.
![](/2010/10/s1600-EIGRP_DMVPN.png)
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. This behavior makes DMVPN way more scalable than VPLS.
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
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).
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)
And while we're nitpicking - the only authoritative structure is the CEF table, which is built from RIB and augmented by the NHRP cache.
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-)