DMVPN - Phase 2 vs. 3
Hate to bring up old topics, but they are so cluttered. . .
Could someone verify this for me? I've labbed up both Phases, read most of the posts on this, and here's my summary:
Phase 1: Allows dynamic spoke-to-Hub VPN.
Phase 2: Allows dynamic spoke-to-Hub VPN + spoke-to-spoke VPN via [Spoke-triggered] NHRP Requests.
Phase 3: Enhances Phase 2 by A) Stopping process-switching on the 1st packet and Scaling the RIB with summary/default routes on Spokes.
To elaborate on Phase 3:
A) In Phase 2, the first packet is always process-switched to the HUB, even though the next-hop is the 2nd Spoke in the RIB. The CEF entry is [invalid] to Spoke-2. In Phase 3, the CEF entry is always valid because it points to the hub, thus elminating process-switching.
Since all routes point to the HUB now, it is the HUB that triggers NHRP-Redirects, then Spoke-1 doing NHRP-Request by order of the Hub. This means that you can effectively just send a default route to spokes, and still have spoke-to-spoke connectivity via NHRP redirect. Great for scalability.
However, OSPF can only take advantage of enhancement *A above. This is due to single-area OSPF on an interface. I suppose you might get around it by filtering Type-1 Router LSA's on the spokes, except for the HUB's Type-1 LSA, then doing [no-summary] on the Hub. But we all know filtering LSA's out of the LSDB doesn't end well for anyone
Which leaves EIGRP the only IGP that can take advantage of BOTH enhancements.
----- Now, with that said. . . . . ---------
Phase 3 OSPF . . . should the network type be [broadcast] or [point-to-multipoint]?
Short Answer: [point-to-multipoint]
Debatable 2nd Answer: both
So let's just forget about enhancement *B for OSPF (RIB entry conservation). Not gonna happen in OSPF.
However, ehancement *A (getting rid of proc-switching) can still be accomplished if the Spokes receive full RIBs (or rather, full-visibility about other spokes' routes). The [point-to-multipoint] network type will cause the CEF entries to be 100% valid, at the very least -- so OSPF is still "okay" to use for this reason.
Using [broadcast] in Phase 3 simply doesn't make sense.
It WILL STILL WORK, but it's really no different from Phase 2. Using [broadcast] network type, you effectively LOSE BOTH ENHANCEMENTS that Phase 3 provides! The only thing that changes (by using redirect/shortcut cmds) is how NHRP works. However, CEF is in no way enhanced, as it's still process switching due to "invalid" spoke adjacencies (due to the Type-2 LSA with spoke neighbors directly connected), and as mentioned - no summarization of spokes' routes is possible.
If this is all correct, then I can't help but wonder. . .
In the CCIE Lab Exam, if you are asked to configure a Phase 3 DMVPN using OSPF [broadcast] network type. . .what do you do? I couldn't imagine them asking something like that. I supposed I would configure [ip nhrp redirect] on the Hub and [ip nhrp shortcut] on the Spokes, effectively changing NHRP behavior. But, since CEF behavior remains the same as Phase 2, I don't see the point.