What is the main difference between DMVPN Phase 2 and Phase 3 ?

The difference between DMVPN Phase 2 and Phase 3  can be understood in terms of routing.

So for an example, let's take spoke 1's tunnel ip as 192.168.1.2/24 and spoke B tunnel ip address as 192.168.1.3/24 both of them registering to the same hub 192.168.1.1/24. Consider that we are using EIGRP as a routing protocol. Here's is how phase 2 and phase 3 would look like

Phase: 2

So the spokes essentially preserve their hop which means that according to the routing table on Spoke A any subnet on spoke B will be learned via Spoke B tunnel address which is 192.168.1.3. Since Spoke A knows tunnel ip address of the destination but is unaware of the NBMA address it triggers NHRP resolution request to the Hub. Hub see's that and thinks "Okay I have a resolution request for Spoke B, let me forward that to Spoke B". Resolution request reaches Spoke B , now Spoke B has all the necessary information to build a dynamic tunnel to Spoke A, it has its NBMA address and tunnel address ( as can be seen from NHRP resolution message), so it initiates a spoke to spoke tunnel between Spoke B and Spoke.

Notice that this packet flow is the control plane as long as there isn't any direct tunnel between the spokes the traffic continues to flow via the hub.

Phase 3:- 

Phase 2 has it's own limitations in terms of routing, which means while you scale the network to maybe 1000 Spokes the routing table on each spoke will have too many entries, which essentially isn't needed. Some of the spokes could just be a small scale routers (used in a small store for example) hence it becomes difficult for the routers to have such a huge routing table. Phase 3 fixes this problem in the most effective way. So this time EIGRP does not preserve the next hop rather than next hop self is configured on the HUB which means that all the spokes see all the network being learned from the Hub, that's easy, isn't it !!!! Further, you can summarize your network on the HUB

Now hub has NHRP redirect enabled and spoke have NHRP shortcut enabled ( i will come back to it shortly)

Coming back to our example now Spoke A with source as 192.168.1.2 wants to communicate to 192.1681.3, because of next hop self on the HUB Spoke A learns it via Hub and starts sending traffic towards HUB. Now HUB  thinks "HOLD ON !!! I got the traffic and I routed the traffic back the same interface towards Spoke B which means there is a better path than this" At this point HUB sends redirect back to the spoke A saying "Excuse me Mr.Spoke A I got a better path than this, can you please send me a resolution request so that I can help you in building a direct spoke to spoke tunnel ". Spoke A says "As you command my master " and sends a resolution request to HUB which is forwarded to Spoke 2 which in turn establishes a direct Spoke to Spoke tunnel between A and B. Spoke A, on the other hand, adds NHRP shortcut for the subnet on Spoke B.

DMVPN Phase 3 can be used for very large deployments and is lot more scalable than DMVPN Phase 2, which means you can have a better hierarchy in DMVPN Phase 3 than in DMVPN Phase. So far in terms of deployment I haven't found a flaw in DMVPN Phase 2 if you think that you should go for DMVPN Phase 2 there is  nothing stopping you, it works fine but like I said scaling with DMVPN Phase 3 is a lot more easier than DMVPN Phase 2.

Thanks

Shakti

Phase 2:

When SPOKE wants to communicate with another SPOKE, a dynamic SPOKE to SPOKE tunnel will get created!

CEF table for SPOKE2 from SPOKE1 route will be incomplete and will be in incomplete adjacancy

Therefore the SPOKE1 sends a NHRP request to the HUB and when HUB replies, the SPOKE2 route will become valid

During resolution request, CEF won't be used - Process Switching using Routing table will be used

Routing table will get updated in SPOKE1 and SPOKE2

Temporary/Dynamic Tunnel valid for 2 hours by default!

Phase 3:

Advantages: Summarization can be done in HUB, but in Phase 2 since we preserve the next hop, we cannot do summarization

Problems in Phase 1:

No dynamic SPOKE to SPOKE tunnel

CPU utilization high on HUB

Problems in Phase 2:

No Summarization possible

Until the resolution reply, process switching is used instead of CEF

Therefore in Phase 3, we combine summarization and exclude process switching and form Dynamic Spoke to Spoke Tunnels

CEF Table is valid before resolution and after resolution