A transit authority designs DMVPN so bus-yard routers keep public Internet reachability separate from tunnel overlay addressing. What separation must operators maintain?
Select an answer to reveal the explanation.
Short Explanation
Think of the underlay as your outer coat: it gets you across the Internet, while the overlay carries the civic network inside the tunnels. Keep those addressing planes separate so the tunnel endpoints can reach each other and civic routes can travel through the tunnels.
Full Explanation
A transit authority must keep bus-yard underlay and overlay addressing planes separate. Underlay addresses on public or provider-reachable interfaces provide outer IP reachability so hubs and spokes can exchange GRE/NHRP/IPsec across the Internet. Overlay tunnel addresses form the logical civic routing domain, where IGP or BGP advertise yard and headquarters prefixes inside the tunnels. Using identical IP addresses for both planes so NHRP can collapse them destroys the outer/inner separation DMVPN assumes and invites routing recursion. Putting the civic routing domain on public underlay addresses while reserving provider-reachable overlay addresses for tunnel endpoints reverses the intended roles: provider reachability belongs to the underlay, and civic routes belong in the overlay. Requiring underlay routes to be learned only through the DMVPN tunnel before any outer IP can be assigned also reverses the bootstrap order; underlay reachability must exist first so tunnels can form. Exam caveat: questions often test whether you know NHS/NBMA reachability uses the underlay while tunnel IPs and site prefixes belong to the overlay. Practical check: document public/provider underlay IPs separately from the tunnel subnet and site prefixes, verify the hub NHS is reachable over the underlay before overlay adjacency forms, and ensure routing does not prefer tunnel paths for the underlay next hop, avoiding recursive tunnel-for-tunnel routing.