EIGRP Neighbor or DMVPN Transit? Check the Role First

The adjacency is missing, and the router in the middle looks like the obvious suspect. It may be innocent. Forwarding the outer tunnel packets and participating in the overlay routing protocol are two different jobs, and a device can do the first without doing the second. Work the five checks below in order and stop at the first one that fails.

Step 1: draw the two roles

Draw the intended EIGRP adjacency as a logical connection between two routers, then draw the underlay routers that carry its tunnel packets. The same device does not have to appear in both lists, and confusing the lists is the most common reason a healthy transit router gets accused of breaking the adjacency.

A transit router forwards the outer packets using its ordinary IP routing and policy. It does not need to run the protocol carried inside the protected tunnel, and it does not need an EIGRP process to pass those packets along.

Step 2: check what the middle device terminates

If the middle router terminates the tunnel and is meant to form EIGRP adjacencies with spokes, the answer changes completely. That device needs the supported overlay routing behavior, and calling it transit does not make the neighbor requirement disappear. Read the tunnel configuration before the routing configuration. That answer decides every check that follows.

So the first real question is not which protocol to tune. It is whether the box is a hub, a spoke, a pure underlay hop or a Layer 2 service that carries frames between endpoints.

Step 3: verify the neighbor control plane

On each device that should be a neighbor, confirm four things: the EIGRP instance and autonomous system number, the authentication parameters, the interface participating in the process, and the network statement that covers that interface. A mismatch in any one of them keeps the adjacency down while the interface stays up and the ping keeps working.

RFC 7868 describes EIGRP as an IP protocol with a multicast control exchange, which is why a neighbor relationship is not something an intermediate router can proxy by routing packets toward a destination. Either the control exchange reaches the peer or the adjacency does not form.

Step 4: verify the transport delivers the control exchange

Next, check that the overlay actually carries the control traffic between the intended endpoints. Inspect the NHRP mapping for the peer and the outer route that reaches it, then confirm the tunnel interface is up and passing traffic. A successful underlay ping proves the outer path exists; it does not prove the overlay control exchange was delivered.

A transparent Layer 2 service, a point-to-point tunnel and a multipoint DMVPN cloud deliver multicast differently. Follow the supported interface, NHRP and multicast model for the one actually deployed instead of assuming all three behave alike.

Step 5: redesign the boundary if it cannot participate

If a required overlay device cannot run the protocol, change the design explicitly. Use a supported protocol or exchange model at that boundary, or arrange a suitable end-to-end tunnel so the neighbors are the endpoints that actually speak to each other. Do not assume a static route turns a nonparticipant into a relay for every control packet.

Record the role of each device in the diagram and keep it with the configuration. The RFC 7868 definition of the protocol exchange is the reference for why the neighbor relationship cannot be simulated by transit forwarding.

When the adjacency still fails after all five checks, the remaining suspects are platform features such as multicast handling on the tunnel interface and policy that filters protocol 88. Those are specific, testable causes, and they are worth more than another round of blaming the router in the middle.