Hello,
The description you shared is not entirely correct. Let me try to describe all DMVPN phases and their differences - that will hopefully clarify the doubts.
DMVPN Phase 1 is the initial DMVPN version, and it allows spokes to dynamically register to hubs. The data flows, however, are always going through the hub. Phase 1 does not provide spoke-to-spoke tunnels. It was possible to run a routing protocol in Phase 1 between the hub and and the spokes; obviously, the only adjacencies that would come up would be between the hub and the spokes, never between spokes. It was quite enough if the dynamic routing protocol advertised only a default route from the hub to the spokes. Of course, the hub has to learn about all networks on all sites behind spokes, so in this direction, the routing protocol is very important.
DMVPN Phase 2 is the improved version where spokes dynamically register to hubs but are also capable of creating spoke-to-spoke tunnels. The dynamic routing is not only supported here but plays a very important role here. Similar to Phase 1, the routing protocol adjacencies in Phase 2 are built only between hub and spokes, not between spokes. However, every spoke must know about all networks behind all other spokes, whether it needs to send packets to those sites or not, and very importantly, the next hop IPs to the networks on others sites must be the spoke routers on those sites, not the hub. This required some tweaking of the dynamic routing protocol on the hub so that it kept the original next hop IP address intact. When a spoke needed to send a packet to a network behind another spoke, it would consult the local NHRP mapping table, and if the mapping wasn't there, it would ask the hub for the tunnel-to-underlay IP address translation. So in Phase 2, dynamic routing is extremely important; it needs to populate the spokes' routing tables with all networks from all sites, but keep the next hop addreses pointing to the remote spokes, not to the hub. Spokes would use NHRP to request the tunnel-to-underlay IP address mappings from the hub as needed.
DMVPN Phase 3 is further improved version where spokes dynamically register to hubs, they keep the spoke-to-spoke tunnel capability too, but the process of resolving the NHRP mapping for the remote spoke is different. Dynamic routing is used here, too, but resembles the approach in Phase 1. Instead of populating every spoke with the full list of the networks, it is enough for the hub to send only a default route to the spokes, and advertise itself (the hub) as the next hop for the default route. When a spoke needs to send a packet to a network behind another spoke, it simply follows its routing table, and at the beginning, sends the packet along the default route to the hub. The hub will route that packet according to its own routing table - and it will realize that the packet came through the Tunnel interface and needs to be send back through that Tunnel interface again (although to a different spoke). The hub will therefore forward the packet as needed, but it will also utilize an extension to the NHRP called NHRP Redirect, allowing the original spoke to learn the following information through NHRP:
- the network and netmask for the real destination network of the packet
- the remote spoke's tunnel IP as the next hop of that destination network
- the tunnel-to-underlay IP translation for that next hop
The original spoke will use this NHRP Redirect to populate both its own routing table with a route that describes the destination of the original packet and is more specific than the default route, and to populate its own NHRP mapping table for the remote spoke.
So, what's the improvement here? Greater scalability. Spokes no longer need to have a list of all networks on all sites. The routing protocol there should only advertise a default route or some general summary route from the hub to all spokes. When, and only when, a spoke needs to talk to a network behind another spoke, the extensions to NHRP will make sure that the spoke will learn the specific destination network and the remote spoke information over NHRP, not over a dynamic protocol, and this process will be triggered by initially sending the original packet to the hub.
In all three phases, a dynamic routing protocol is both supported and very useful. In all three phases, it allows the hub to learn about the networks behind every spoke. In Phase 1 and Phase 3, the hub should only advertise a default route or a similar summary to the spokes; Phase 1 does not support spoke-to-spoke communication while Phase 3 uses NHRP extensions to learn the networks behind remote spokes on as-needed basis. In Phase 2, the hub needs to advertise all networks to all spokes, and keep the spoke IPs as the next hop IPs, unchanged. And finally, no matter what the phase is, the routing protocol adjacencies are only built between the hub and the spokes.
Please feel welcome to ask further!
Best regards,
Peter
