This topic is to discuss the following lesson:
what would be the reason for nbma 192.168.123.2 to inside ip 172.16.123.2 be showing twice under “show dmvpn” command? It has shown several times in your examples.
Take a look below:
Spoke2#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 # 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:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 2 192.168.123.2 172.16.123.2 UP 00:01:27 DT2 172.16.123.2 UP 00:01:27 DT2 1 192.168.123.1 172.16.123.1 UP 00:02:57 S
Above you can see two entries for the spoke1 router. When we add the detail parameter, you can see why there are two entries:
Spoke2#show dmvpn detail Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete N - NATed, L - Local, X - No Socket T1 - Route Installed, T2 - Nexthop-override C - CTS Capable # 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 is up/up, Addr. is 172.16.123.3, VRF "" Tunnel Src./Dest. addr: 192.168.123.3/MGRE, Tunnel VRF "" Protocol/Transport: "multi-GRE/IP", Protect "" Interface State Control: Disabled nhrp event-publisher : Disabled IPv4 NHS: 172.16.123.1 RE priority = 0 cluster = 0 Type:Spoke, Total NBMA Peers (v4/v6): 3 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network ----- --------------- --------------- ----- -------- ----- ----------------- 2 192.168.123.2 172.16.123.2 UP 00:01:52 DT2 18.104.22.168/32 192.168.123.2 172.16.123.2 UP 00:01:52 DT2 172.16.123.2/32 1 192.168.123.3 172.16.123.3 UP 00:01:52 DLX 22.214.171.124/32 1 192.168.123.1 172.16.123.1 UP 00:03:22 S 172.16.123.1/32
There’s an entry for 126.96.36.199/32 and 172.16.123.2/32 network.
Hope this helps.
Rene I set this up, Spoke still use Hub as next-hop, Spoke 2 is fine but Spoke 1 still shows 188.8.131.52 as next hop in cef
see output below
Spoke 2 Spoke2#traceroute 184.108.40.206 source loopback 0 Type escape sequence to abort. Tracing the route to 220.127.116.11 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.123.1 32 msec 28 msec 24 msec 2 172.16.123.2 76 msec 32 msec * Spoke2#show ip cef 18.104.22.168 22.214.171.124/32 nexthop 172.16.123.2 Tunnel0
Spoke 1 Spoke1#traceroute 126.96.36.199 source loopback 0 Type escape sequence to abort. Tracing the route to 188.8.131.52 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.123.1 28 msec 52 msec 28 msec 2 172.16.123.3 52 msec 44 msec * Spoke1#show ip cef 184.108.40.206 220.127.116.11/32 nexthop 172.16.123.1 Tunnel0
I checked all Tun0 configs, ip nhrp redirect, and ip nhrp shortcut are on the Tun0. All 3 routers are using same code 15.2(4)M6 Adv Enteprise.
Please advise. Thanks
How should the behavior when it is deployed with the ISIS? It would be nice to post a lesson of ISIS in phases 1, 2 and 3.
That is a short answer…you can’t IS-IS is not supported in DMVPN.
IS-IS doesn’t use IP for routing and NHRP only supports IP for address resolution.
Hey Rene, you DMVPN phase 3 with OSPF definitely made a difference in this whole nightmare. I spent several hours researching and trying to troubleshoot an OSPF point-to-multipoint issue. At this point I am still not sure what the problem is. I have a customer network that experience this same behavior where the spoke to spoke traffic does randomlt go direct via a new tunnel. Because this is a DMVPN backup network there’s no traffic all the time. I have waited enough time to allow for the first set of packets to traverse to the destination via the Hub but the next-hop override never get’s installed in some of the spokes. Trust I tried everything and nothing made a difference. I ensured that all configuration were in accordance to the latest Cisco’s best practices including the following:
- Static default route at each site pointing to the Internet. All DMVPN NBMA IP address were reachable via that path.
- Hub using “ip nhrp redirect”
- spoke using “ip nhrp shortcut”
- All OSPF network types “Point-to-Multopint” ***** THIS IS INTERESTING ONE
Pretty much at least three people have checked the config and none have been able to determine what the problem is. I then went through your article and you mentioned an interesting thing about the OSPF point-to-multipoint behavior in regards to the next-hop. This is exactly where I’m not a 100% sure on what’s causing the issue but if I change all the OSPF interface to “BroadCast” the thing works like a charm. I move them back to p-2-multipoint the spoke-to-spoke traffic keep not being stable in terms of it’s path. That inconsistency keeps causing routing changes in terms of OSPF cost and undesired behaviors.
If possible it would be awesome if you can throw some light on what you think of the following:
Is there a well known issue with DMVPN phase 3 when using OSPF point-to-multipoint in terms of how the CEF table get updated with the next-hop override information? Are there any issues on why the override is never seen on certain spokes regardless those have the exact config (Except IP addresses and mappings)?
Is there a specific reason why to use point-to-multipoint over than Broadcast other than having to manually set OSPF priorities to manually set the DR/BDR routers?
Thanks a lot,
The difference between OSPF P2MP and broadcast/non-broadcast is that with P2MP, the next hop will always be the hub and with broadcast/non-broadcast it will be the remote spoke. I have an example for this:
This is about frame-relay but it’s the exact same thing with DMVPN. If it’s working with broadcast (where the next hop is the remote spoke, not the hub) then it indeed sounds like an issue with the next hop override.
You could try to enable some NHRP and OSPF SPF debugs on your routers, see if anything happens. Is there a reason why you want to use OSPF? Since it’s a link-state routing protocol, it’s not the best option for DMVPN. All your routers are in the same area so any change triggers an SPF calculation.
If broadcast works then I don’t see a problem to use that instead of P2MP.
Do you think that is possible to set up a DMVPN Phase3 in a single Cloud environment with Dual Hub and Dual spokes (without using IOS XE and nhrp summarize features) ? What should I have to keep in mind regarding NHRP possible conflicts in LAN-to-LAN traffic between spokes?
Thank you very much for your time
This shouldn’t be a problem. Did you see this example?
If you do this, it’s best to use EIGRP or BGP.
What do you say that ospf cant be summarized on pahse 3, if the main purpose of phase 3 is to summarize the netowrks
Rene mentions in the conclusion that summarization cannot be applied. This is not a limitation of DMVPN Phase 3 but a limitation of OSPF. Summarization within the same area cannot be implemented. For this reason, all spoke routers will have to have specific routes to all other destinations, something that is not ideally efficient.
On a side note, the purpose of DMVPN Phase 3 is to allow spoke routers to directly communicate with each other rather than to communicate via the hub. This is done using NHRP redirect on the hub which will instruct the hub to inform spokes that they can communicate directly. Secondly, it is accomplished using the NHRP shortcut feature in the spoke routers which allows them to make changes to the CEF entry when they receive an NHRP redirect message from the hub. More on this can be found here:
I hope this has been helpful!