cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
855
Views
0
Helpful
7
Replies

DMVPN Spokes cant communicate

MapleMagician
Level 1
Level 1

I am studying for my ENARSI exam. I set up a DMVPN network in my lab and I cannot get the spokes to communicate over the tunnel. However, each spoke can communicate with the hub over the tunnel. My underlay network has complete connectivity. If I run a traceroute between spokes however, i see that traffic is not using the tunnel. My underlay consists of BGP, OSPF and EIGRP. My hub is in OSPF area 1, and i also have spokes in area 2 and 3, and spokes in the BGP network and EIGRP network. Note, I have not yet implemented IPSEC, I am trying to get the tunnels working first.

Some things I have already tried. I am well aware that when using eigrp for the overlay you need to disable split horizon. One hypothesis was that because I was using named mode I had to disable split horizon under af-interface. I did try this and it had no effect. I tried getting rid of named mode all together and configuring classic mode. That also did not work.

Here is some relevant config.

Note, for the hub...the command

ip nhrp multicast dynamic

has been implemented, but for some reason it doesn't show up in the config. This has not been an issue in prior DMVPN implementations

HUB: 

interface Tunnel0
ip address 13.0.0.1 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 13
no ip split-horizon eigrp 13
ip nhrp authentication DMVPN
ip nhrp network-id 6783
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint

router eigrp DMVPN
!
address-family ipv4 unicast autonomous-system 13
!
topology base
exit-af-topology
network 10.1.5.0 0.0.0.255
network 13.0.0.0 0.0.0.255
exit-address-family

SPOKE

interface Tunnel0
ip address 13.0.0.5 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication DMVPN
ip nhrp network-id 6783
ip nhrp nhs 13.0.0.1 nbma 10.1.35.5 multicast
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint

router eigrp DMVPN
!
address-family ipv4 unicast autonomous-system 13
!
topology base
exit-af-topology
network 10.200.0.0 0.0.0.255
network 13.0.0.0 0.0.0.255
exit-address-family

Hub:

R5#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:4,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.51.50.51 13.0.0.2 UP 01:50:54 D
1 10.2.46.6 13.0.0.3 UP 01:52:08 D
1 10.200.2.2 13.0.0.5 UP 01:51:32 D
1 10.3.67.7 13.0.0.6 UP 01:15:59 D


Spokes:

E2#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.1.35.5 13.0.0.1 UP 02:39:47 S


 

1 Accepted Solution

Accepted Solutions

Torbjørn
Spotlight
Spotlight

What does your route table look like?

Your NHRP config looks like it should work fine for phase 2 DMVPN. The

ip nhrp redirects

command is not necessary for phase 2, and if you want phase 3 you would want to add ip nhrp shortcut to your spokes.

I believe the error here is that the superior route for the spoke networks are through the underlay, not through the tunnel. Typically you would have a less specific route for the underlay than the overlay network(default route towards internet, routing-protocol learned prefixes through the tunnels) that would cause traffic to be forwarded through the tunnels. In this case I am guessing that your spokes have learned the other spoke prefixes with the same prefix length through eBGP.

Happy to help! Please mark as helpful/solution if applicable.
Get in touch: https://torbjorn.dev

View solution in original post

7 Replies 7

Torbjørn
Spotlight
Spotlight

What does your route table look like?

Your NHRP config looks like it should work fine for phase 2 DMVPN. The

ip nhrp redirects

command is not necessary for phase 2, and if you want phase 3 you would want to add ip nhrp shortcut to your spokes.

I believe the error here is that the superior route for the spoke networks are through the underlay, not through the tunnel. Typically you would have a less specific route for the underlay than the overlay network(default route towards internet, routing-protocol learned prefixes through the tunnels) that would cause traffic to be forwarded through the tunnels. In this case I am guessing that your spokes have learned the other spoke prefixes with the same prefix length through eBGP.

Happy to help! Please mark as helpful/solution if applicable.
Get in touch: https://torbjorn.dev

Here is the route table from one of the spokes.

The other spokes that I am trying to communicate with are at 10.51.50.51, 10.2.46.6, 10.3.67.7

ryanbeaudry_0-1699819078039.png

Hub route table

ryanbeaudry_1-1699819338877.png

I have also attached the topology, The B routers are BGP, E is EIGRP, and R is OSPF.

 

 

Ip nhrp map multicast dynamic 

Add this to hub tunnel

Thanks A Lot
MHM

Torbjørn
Spotlight
Spotlight

Your hub routers best routes for the prefixes specified are learned through OSPF, it will hence not advertise the routes to the spokes through EIGRP(Distance vector protocols require that the routes are installed in the RIB to advertise the routes). This can be resolved by filtering the OSPF routes inbound on your hub router. It seems that the OSPF routes are being redistributed into EIGRP somewhere between your hub and your spoke, such that your spoke routers best route for the prefixes is external EIGRP with an AD of 170. By getting the hub to advertise the routes to your spokes with EIGRP(AD 90) your spokes will use the tunnel to reach the specified networks. Keep in mind that this might have other unintended consequences for routing and your issue might be best solved by making changes to your routing design.

The configuration for this would look something like this:

ip prefix-list filter-spokes deny 10.51.50.0/24
ip prefix-list filter-spokes deny 10.2.46.0/24
ip prefix-list filter-spokes deny 10.3.67.0/24
ip prefix-list filter-spokes permit 0.0.0.0/0 le 32

router ospf 1
distribute-list prefix filter-spokes in
Happy to help! Please mark as helpful/solution if applicable.
Get in touch: https://torbjorn.dev

So I ended up resolving this based on what you said in your original post. I removed the routing protocols from the DMVPN routers and configured a default route. Though admittedly I'm still struggling to understand why this worked.

Regardless, thank you for all your help!

you remove the IGP and use static route !!!
that not solution 
can you share the last config of both Hub and Spoke ?

waiting you 

Review Cisco Networking for a $25 gift card