A regional planning commission needs township prefixes to converge over a single-hub DMVPN overlay after tunnels are up. Which approach fits ENARSI config/verify practice?
Select an answer to reveal the explanation.
Short Explanation
Tunnels are the roads; EIGRP or OSPF over those tunnel interfaces is how township maps get shared. NHRP finds peers—it doesn’t replace your routing protocol for LAN prefixes.
Full Explanation
After DMVPN tunnels are up for a regional planning commission, township prefixes converge over the overlay by running an IGP such as EIGRP or OSPF across the DMVPN tunnel interfaces so hub and spoke routers become overlay neighbors and exchange civic LAN routes. NHRP resolves NBMA endpoints for encapsulation; it does not replace a routing protocol for advertising remote township networks. Overlay IGP (or BGP on tunnels in some designs) is the ENARSI config/verify practice for prefix exchange once tunnels exist.
Running LDP between spokes across the Internet underlay instead of an overlay IGP is not the DMVPN LAN-prefix model and exposes label distribution on an inappropriate underlay. Advertising all township routes only in the global ISP BGP table without tunnel interfaces leaks civic routing into the underlay provider and bypasses the overlay design. Disabling routing protocols and relying solely on NHRP to install every remote LAN prefix confuses NBMA mapping with route advertisement—NHRP does not carry full township IGP topology.
Exam caveat: split-horizon and next-hop behavior on mGRE matter (EIGRP stub/NHRP shortcuts, OSPF network type); wrong interface network types can prevent spoke learning even when tunnels are up. Operational check: verify EIGRP/OSPF adjacencies on tunnel interfaces (show ip eigrp neighbors / show ip ospf neighbor), confirm remote township prefixes in the overlay RIB via tunnel next hops, and ensure underlay ISP routing is used only to reach NBMA endpoints—not as the primary civic LAN routing plane.