DMVPN Phase 3 issue

[adamehill87]

Hello All,

I have a DMVPN phase 3 setup between a hub router and two spoke routers in a lab enviornment. below is my configration

HUB

SPOKE1

SPOKE 2

tunnels come up on the hub just fine via the above configs as seen below

at this point that's when things begin to get weird. First wierd thing i notice is whenever a spoke attempts to ping/traceroute its own local tunnel-ip, it behaves like the hub is the next hop to its own local IP. 

second wierd thing i noticed is that in the tunnel interface config, the command 'ip nhrp shortcut' dosent appear on the tunnel interface unless i remove the 'tunnel mode gre multipoint' syntax

then finally (and ultimately) when i attempt to do spoke to spoke communications .... redirect attempts get dropped as such

so my main point is i am able to get DMVPN up but im unable to get the hubs redirect feature or the spokes shortcut feature working in order to do phase 3 DMVPN. 

im currently using iosv verion 15.9(3)M6 .... but i even tried setting this up using a different image (cisco IOS Linux version 15.7(3)M2) and saw the same exact results. Is there something im missing or overlooking? 

@Harold Ritter 

[tvotna]

I believe #1 and #2 are expected. "ip nhrp shortcut" should be ON by default on mGRE interfaces in new versions, but you can double-check with "show run all | sec interface".

Behavior #3 might be expected too. The "show ip nhrp redirect" command is a Hub command. In this command the "Destination" is the destination IP address from the data packet which triggered NHRP redirect (typically LAN IP address behind Spoke2) and the "NBMA address" is the address where the Redirect message is sent to by the Hub (i.e. NBMA IP of Spoke1). So, you tried to ping 172.16.255.3 from 172.16.255.19 and didn't receive a reply back, right?

Did you complete your EIGRP setup? Can you try to ping LAN IP address behind Spoke 2 from a LAN IP address behind Spoke 1? Apart from LAN subnets, this should create NHRP entry with "nhop" flag on Spoke 1 for Spoke 2 tunnel interface IP address. After that Spoke 2 tunnel interface IP address should become pingable too.

You can also enable debug on all routers and trace what exactly happens, and enable "logging dmvpn" and look at syslog messages. Debugs:

debug nhrp detail
debug nhrp cache
debug nhrp packet
debug nhrp routing

[MHM Cisco World]

Points to check

1-% NHRP-WARNING: 'ip nhrp redirect' failed to initialise <<- when you add ip nhrp redirect did you get this message ?

2- if NO for point 1 then 

Remove

No Ip split horizon eigrp 1

And then 

Ip summary address eigrp 1 x.x.x.x 

Make hub inject summary fo any LAN behind both spokes 

This make spoke send to hub then hub send redirect.

MHM

[tvotna]

@MHM Cisco World, you're mixing up "no ip split-horizon" and "no ip next-hop-self". The "no ip next-hop-self" should not be used in DMVPN phase3, whilst "no ip split-horizon" is perfectly valid in DMVPN phase3 and must be configured on the hub if summarization is not used. Summarization has no impact on redirects whatsoever, provided that "no ip split-horizon" is configured.

[MHM Cisco World]

I already mention he need to use summary when he remove no ip split-horizon.

@adamehill87 share the show route in spoke before and after spoke-spoke connection did you see "%" in route ?

[tvotna]

@MHM Cisco World, What I mean is that in the context of this discussion your recommendation to remove "No Ip split horizon eigrp 1<- this use only for phaseII" is wrong.

[adamehill87]

thank you both for responding. When i get home later today i'll complete my EIGRP setup and see if its just expected behavior 

[liviu.gheorghe]

Hello @adamehill87 ,

First wierd thing i notice is whenever a spoke attempts to ping/traceroute its own local tunnel-ip, it behaves like the hub is the next hop to its own local IP.

This is expected behaviour - if you take a look at the output of show ip nhrp detail, that shows the local NHRP cache on your spoke router you will see that there is an entry for your hub router's protocol address 172.16.255.13 pointing to it's NBMA address 1.120.10.13 and also an entry for the spoke protocol address 172.16.255.19 pointing to the HUB NBMA address 1.120.10.13.

It's similar to the classic configuration of NBMA networks, Frame-relay or ATM, where you would map your WAN address to the DLCI pointing to your neighbour and on your neighbour map your WAN address to the DLCI pointing to your router. That was the way you could ping your own interface.

Hope this helps.

[adamehill87]

alright so heres my update

i completed my EIGRP config for both the hub and the two spokes. Here is the current config for each router

HUB

SPOKE 1

SPOKE 2

all routers are able to ping each others tunnel interfaces so we are good there. However what i am noticing now is the two spokes will form EIGRP adjacencies with the hub, but they will NOT form adjacencies with each other. 

SPOKE 1

SPOKE 2

the other thing i notice is that although the hub is learning both spoke1 and spoke2's routes via the tunnel interface, the hub is NOT advertising spoke1's routes to spoke2 and vice versa .... despite the fact that i turned off split horizon everywhere.

I was under the impression that when a network behind spoke1 wants to speak to a network behind spoke2 .... spoke1 would send its NHRP info to the hub then the hub would send a redirect message back to spoke1 saying 'send your traffic straight to spoke2' .... but that NHRP redirect process seems to not be happening with the hub, hence no '% routes' in any of the spokes routing table. when i debug nhrp at the hub it seem the hub continually tries to redirect the spoke traffic but never succeeds

and this is the point where im lost in my troubleshooting efforts, as i will admit i do not fully understand which behavior is considered 'expected behavior' vs which behavior is abnormal.

[MHM Cisco World]

I'm hub add

Ip nhrp map multicast dynamic 

MHM

[adamehill87]

sorry i forgot to mention i did attempt to add that command on the hub and it takes but it still dosent show up in the 'show run' output. when i do a 'show run all' though it'll show up. My issue unfortuantely still persists though  

[liviu.gheorghe]

Turning off split horizon on the Tunnel interface is for EIGRP to be able to announce routing updates received from spoke 172.16.255.19 to spoke 172.16.255.3. EIGRP adjacencies are formed using multicast packet sent to 224.0.0.10 IP address and those packet don't travel further than the next router. This is the reason that on the HUB you have only the spoke routers as EIGRP neighbors and on the spoke routers only the HUB router.

On the spoke routers, I see you are announcing a summary with a leak-map. Can you share the configuration for the leak-map?

[adamehill87]

ahh okay thank you for clearing that up for me.

as for my summary ... i am using that to advertise a default route to the other downstream routers. The leak map is basically allowing each link on the spokes to advertise all the other eigrp routes with the prefix list 0.0.0.0/0 le 32. 

[liviu.gheorghe]

Ok, so the EIGRP-LEAKMAP-DEFAULT leak-map permits any EIGRP routes to be announced to neighbors of the spoke routers, found on interface Gi0/0 and Gi0/1, in addition to the summary route 0.0.0.0/0.

This means that you should see EIGRP routes from subnets 10.0.13.0 and 10.0.23.0 on spoke 2 and subnet 10.15.19.0 on spoke 1. And all subnets from 10.15.19.0, 10.0.13.0 and 10.0.23.0 on the HUB.

[liviu.gheorghe]

---

@adamehill87 wrote:

I was under the impression that when a network behind spoke1 wants to speak to a network behind spoke2 .... spoke1 would send its NHRP info to the hub then the hub would send a redirect message back to spoke1 saying 'send your traffic straight to spoke2' .... but that NHRP redirect process seems to not be happening with the hub, hence no '% routes' in any of the spokes routing table. when i debug nhrp at the hub it seem the hub continually tries to redirect the spoke traffic but never succeeds

---

I can see the ip nhrp redirect on the HUB, but I'm not seeing the ip nhrp shortcut on the spoke routers. Without the shortcut command, you don't have DMVPN Phase 2 or 3 in which the spoke talks directly with another spoke, you only have Phase 1 in which the spoke talks only to the hub, so no '% routes'.