DMVPN Phase II flow via HUB

[Evgeniy Ivanov]

Hi!
I have a questions about DMVPN phase II.
- why first packets between spokes will flow through hub? How can i influence on quantity of this packets, or on time of this kind of flow direction?
- Is it mandatory to use no eigrp next-hop self and no ip split horizon on hub only, or on spokes also?

Thank you!

[ghostinthenet]

With DMVPN phase 2, initial packets flow through the hub until NHRP resolution occurs. This happens after the first few packets, so the amount of traffic flowing through the hub is minimal. If you want to avoid this, consider moving to a phase 3 structure with NHRP redirects and shortcut switching.

On DMVPN phase 2, EIGRP next hop self and split horizon only needs to be done on the hub. Because all spokes are advertising via the hub, it is important that the hub preserve the original next hop in order to enable spoke-to-spoke traffic. Without this, everything would route through the hub and you would essentially have a phase 1 DMVPN. Disabling split horizon is necessary on the hub because EIGRP normally doesn't advertise received routes out of the same interface. With a single multipoint GRE tunnel, split horizon needs to be disabled for router to propagate out to the other spokes.

[Evgeniy Ivanov]

Thank you for reply. But i am still confused :).
After some research, i found that traffic will flow through hub only for 3 minutes, and this behavior was introduced in v15 IOS.
Also, i found that when spoke wants to establish spoke-to-spoke tunnel, it will send NHRP request to HUB, but HUB will not reply from cache, instead ot this, hub will forward this request to spoke.
- What is the purpose and benefits of sending traffic through hub for 3 minutes?
- Why hub is not processing NRHP request from cache, and forward it to spoke?

Thank you!

[ghostinthenet · Accepted solution]

It isn't a hard three minutes but up to three minutes if no IPSec spoke-to-spoke tunnel can be established. Once NHRP resolution completes, which is usually after only a few packets, traffic is routed normally and not through the hub. If the tunnel can't be established for whatever reason, everything continues to go through the hub. All of this is done to ensure that there is no loss of connectivity in the initial setup or due to spoke access problems.

As for the cache not being used at the hub, my guess would be that this is done to ensure that connectivity still exists to the spoke before providing authoritative information to the other network nodes, but this is speculation.

[Evgeniy Ivanov]

Sorry for late reply.

Thank you for help!