This is a post in a series of “stream-of-study” content where I post loosely-structured notes taken while labbing various scenarios and technologies.
!--------------------!
! Phase 2 DMVPN !
!--------------------!
! HUB !
!--------------------!
!once Phase 1 is completely up and running, implement the following
!change on the hub to allow spoke-to-spoke data plane forwarding
!
int tu1
no ip next-hop-self
!
!This configuration allows all spokes to see the actual tunnel next hops for all other spoke-advertised LAN segments, so spoke will perform a route table lookup followed by an NHRP resolution request for the NBMA lookup of the spoke against the NHS, the hub. Following this resolution, spokes will dynamically create NHRP mappings for other spokes and build tunnels to the remote spokes
!
!--------------------!
! Phase 3 DMVPN !
!--------------------!
! HUB !
!--------------------!
!
!While Phase 2 is functional, it is inefficient because every resolution requires two lookups, but moreso that it requires that every spoke router contains the full route table, since the spoke has to know the next hop of the other spoke specifically to resolve the NBMA address and build an NHRP mapping - because of this, you cannot do any route summarization in Phase2, since that would make the next hop be the hub and you would be back to hub-and-spoke from a data-plane forwarding perfpective since the next hop in a summarized route advertisement will always be the hub so there will be no spoke resolution possible
!
!phase 3 takes a better approach and uses NHRP redirect and shortcut commands to allow spoke routers to install NHRP routes (flagged by an "H") or next-hop-override routes (flagged by a "%") so they can still dynamically map spoke routes without needing to have the full routing table installed, so you get the best of both worlds. In reality, phase 1 or phase 3 are the only viable phases to be used in production, phase 2 doesn't scale well.
!
!to enable phase 3, ensure that next-hop-self is enabled on the hub, then enable nhrp redirects
!
int tu1
ip next-hop-self eigrp 100
ip nhrp redirect
!
!--------------------!
! Spokes !
!--------------------!
!
!to allow spokes to participate in Phase3 topology, enable NHRP shortcut on the tunnel interface
!
int tu1
ip nhrp shortcut
!
!this will allow the spoke to dynamically map and install override routes (% Flag) for the spokes as outlined above.
!
!To optimize the route table on the spokes, summary routes may be installed on the hub tunnel interface, which will allow spokes to install NHRP (H flag) routes in the route table
!--------------------!
! HUB !
!--------------------!
!summary route example
!
int tu1
ip summary-address eigrp 100 10.0.0.0/8
!
!this command sends an EIGRP route from the hub to all spokes for 10.0.0.0/8 and stops advertising any 10.x.x.x/8 specific spoke routes out, which minimizes the routing table for spoke prefixes within this supernet
CCIE #TBD 