Showing results for 
Search instead for 
Did you mean: 

EIGRP neighbours not forming over DMVPN tunnel

A few weeks ago I managed to get the DMVPN tunnel to work with dialer interfaces over an ISND 30 link. But after messing around with an EIGRP distribution list and the router config I can't get the routers to form an EIGRP relationship over the tunnel interface and I have no idea why. 


When I take the passive interface off the dialer interfaces the two routers can form a relationship via the dialer interface, but when I make both dialer interfaces passive on both routers the EIGRP connection drops and doesn't form over the tunnel. I need the EIGRP to go over the tunnel so data will be encrypted with the encryption profile. 


I ran the debug EIGRP packets command on the spoke to see what happening and it keeps giving the same messages, I've attached the log. These debug messages are the same on the hub side except there is no (NULL) text in the line. 


Any help will be greatly appreciated as I have no idea what to do. 



Rob Ingram
VIP Mentor

Is the DMVPN tunnel even up? Provide the output of "show dmvpn" and "show crypto ipsec sa"

Why is the tunnel source as on the hub and not dialer7?


Also don't advertise the underlayer network in eigrp

I will perform the show commands when I'm back in the office tomorrow.

The tunnel source is the loopback address as the hub router as multiple dialer interfaces so I thought I could use a loopback address so every spoke router could connect to the DMVPN hub router.

Why shouldn't I advertise the network?

Because the network is your dialer interface network and if you redistribute that via EIGRP to the other router it will attempt to route to that network via the tunnel interface when it needs to be routed via the dialer interface.

You could only use a loopback if the peer routers can route to that loopback interface ip address outside of the tunnel, if you can fine.

Don't I want to the spoke router to route all data (even the address) via the tunnel so all data is encrypted?

With the loopback, I currently have a static route on the spoke that points to the hub's loopback address via the tunnel, could I enable EIGRP on the loopback so the spoke routers will learn it dynamically and can still route to it via the tunnel interface.

Is this just lab network or are you simulating a design for production environment?

No you wouldn't advertise the network, that's the transit network, over which the tunnel is established. Any communication between those networks (i.e. the VPN tunnel) is encrypted. You would just advertise the data/LAN networks. If you advertise the over the tunnel you'll get issues.

Ah okay I understand what you mean about advertising the address.

This is currently on a lab/test setup.

Hi Rob,


I've managed to get the DMVPN to work, I don't really know how but I just wiped the config from the spoke router and applied it again. The spoke router is learning all its routes via the tunnel now. I've attached both configs. 


The hub router still has the network command and will have to since this DMVPN config will need to be put onto another router that will have spoke routers not using DMVPN and requires the network command so it can send EIGRP messages out of the dialer interfaces. Will this cause any trouble for the DMVPN routers ? I've included the spoke's routing table in the text file and that shows there's no recursive routing error since its not learning about any of the addresses via the tunnel. 


Another question I have is about the encryption and authentication methods, currently it has 3DES and MD5 hash and from my understanding these are very weak. Would upgrading to AES 256 and SHA 256 be sufficient enough? 

In your lab topology the network is directly connected to the hub and spoke router right? So therefore the eigrp route for that network is irrelevant. In a real life topology you wouldn't advertise this network, you rely on the default route or a static route to communicate with the hub and spoke router's external/outside interface in order to establish the VPN tunnel.


Yes, 3DES/MD5 is weak. AES256/SHA256 is acceptable, however if you require the latest Next Gen algorithms you would need to use IKEv2.



I will look into the next gen algorithms, thanks.

The is directly attached to both the hub and spoke network yes, but this hub router will have other routers connected to it that won't be using DMVPN or any sort of tunnelling, this means EIGRP will need to be enabled for the network so the hub can form EIGRP neighbours with the none DMVPN routers. If I'm correct with this, this should not cause any problems with the DMVPN routers since the distribution list on the spoke router will block the advertisements from the hub router?
Recognize Your Peers
Content for Community-Ad