EIGRP Neighbors Won't Come Up on the DMVPN Overlay

The tunnel is up, one spoke can ping another, and EIGRP still shows no neighbor on the hub. That combination is normal rather than mysterious: a ping proves unicast reachability through NHRP, and EIGRP hellos are multicast. On a DMVPN overlay the routing protocol's delivery model is a second configuration surface, and it is the one people skip because the first surface already looks healthy. Each layer below is checked with its own command, so a failure at one does not send you back to the top of the list.

Write down the adjacencies you expect

Before any show command, make a short list: which spoke should peer with which hub, over which tunnel interface, in which EIGRP autonomous system. Multi-hub designs fail in the gaps between hubs, and a list turns "EIGRP is broken" into "spoke 3 is not registering to hub 2". Include the tunnel subnets you expect on each link, because an address mismatch between the two ends looks exactly like a protocol failure. Write the list on the ticket, so the next shift compares against the design instead of against the last screenshot.

Check NHRP, then check the multicast path

Start with registration state and the mappings the hub actually holds. A spoke with no dynamic entry on the hub has not registered, and no routing protocol will fix that. Then confirm that the spoke accepts multicast from the hub's NBMA address, which is a separate line from the NHS entry.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

The ip nhrp map multicast line is what lets the spoke send its hellos to the hub as replicated multicast over the overlay, and what lets the hub's multicast reach the spokes it has registered. Without it, unicast through NHRP works and multicast does not, which is precisely the split that makes a ping look like proof. The Cisco IOS XE DMVPN guide documents the hub and spoke multicast behaviour for each phase, so match your configuration to the phase you actually deployed rather than copying a fragment from another topology.

Check EIGRP's own interface policy

A tunnel that is not in the EIGRP process, or is passive, will never form an adjacency no matter how healthy the overlay is. Read the interface's participation and the neighbor table together, since the first explains the second.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Authentication and metric weights have to match on both ends. A key chain with the wrong mode, or a K-value mismatch, drops hellos without an obvious syslog line on the receiver. If the design uses explicitly configured unicast neighbors, follow that model completely instead of layering it on top of multicast settings until something comes up.

Keep GRE carriage and IPsec protection separate

DMVPN carries multicast inside GRE, and IPsec protects the GRE packets rather than the inner multicast directly. That is why the blanket claim that IPsec cannot carry multicast is wrong for this design and useless as a diagnosis. Check the IPsec profile on the tunnel, the security associations for each peer, and the tunnel interface state as three separate facts.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

An SA that is up with counters moving while EIGRP stays down moves your investigation back up the stack: the packets are being protected and delivered, so the problem is which packets the protocol is choosing to send.

Verify routes, not just neighbor counts

Once the adjacency forms, read what it advertises and installs. On a multipoint tunnel, split horizon and next-hop behaviour decide whether a spoke can reach another spoke through the hub, and summarization can hide a prefix even though the neighbor relationship is perfect.

Finish with a permitted application between two sites and confirm the path it takes. Direct spoke-to-spoke shortcuts are a forwarding requirement with their own NHRP and security state, and adding them to make a neighbor count look better usually creates a second problem.

Record the phased design, the multicast mapping and the EIGRP policy in one place. The next engineer will need the design, not the transcript.