This topic is to discuss the following lesson:
Rene,
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.
Thanks.
Hi Harvinder,
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 2.2.2.2/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 3.3.3.3/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 2.2.2.2/32 and 172.16.123.2/32 network.
Hope this helps.
Rene
Rene I set this up, Spoke still use Hub as next-hop, Spoke 2 is fine but Spoke 1 still shows 172.6.132.1 as next hop in cef
see output below
Spoke 2
Spoke2#traceroute 2.2.2.2 source loopback 0
Type escape sequence to abort.
Tracing the route to 2.2.2.2
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 2.2.2.2
2.2.2.2/32
nexthop 172.16.123.2 Tunnel0
-
Spoke 1
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
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 3.3.3.3
3.3.3.3/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.
Hi @stlourenco,
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.
Hello there,
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,
Ricardo
Hi Ricardo,
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.
Rene
Hello Rene,
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 
Hello Hugo,
This shouldn’t be a problem. Did you see this example?
If you do this, it’s best to use EIGRP or BGP.
Rene
Hi Rene,
What do you say that ospf cant be summarized on pahse 3, if the main purpose of phase 3 is to summarize the netowrks
Hello Rafael
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!
Laz
1 Like
You say at the end of the lesson that you cannot Summarize in Phase 3, but in the OSPF routing table output for OSPF Network Type “Broadcast” it shows that there is an Inter-Area route. Does this not suggest that Summarization has occured then?
Hello Joseph
Rene’s statement was not to say that you cannot summarize in phase 3, but that OSPF itself cannot summarize routes within the same area (regardless of phase, topology, or underlying technology). The result is that for any particular area (area 1 in the case of this topology) OSPF spoke routers will always have specific entries for networks behind other spoke routers. You are correct that the network behind the hub router does appear as an IA network, and summarization can occur between areas, but all the spokes are in the same area, so inter-spoke communication cannot benefit from summarization.
Take a look at the following post that further clarifies this.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Actually did not get the concept of %( Over written) , if it is over written in CEF then it must be direct communication , not getting actual point like u c/an say when it is over written or post following path though hub is it over written and how?
Hello Pradyumna
The routing table is the result of multiple processes that take place to find the best route to a particular destination. When using DMVPN Phase 3, NHRP plays a role in the process to create the routing table we see when we issue the show IP route command.
Remember that in Phase 3 you don’t need a specific route to the destination specifically because NHRP takes care of these things. So initially, OSPF has a next-hop IP of the HUB for all routes. Once the first packet is sent, the HUB, using NHRP will send a redirect to both sender and receiver spoke, allowing them to have all subsequent communication directly. What actually allows them to do this is the fact that NHRP has gone in and overwritten the previous entry that OSPF had determined, with the next-hop IP of the spoke.
I hope this has been helpful!
Laz
1 Like
Hello,
I configured DMVPN with OSPF network types Broadcast and P2MP. My observation with my lab is that with Broadcast network type both Spokes are able to directly communicate whereas in case of P2MP they cannot.
In P2MP, the next hop is the Hub which is expected, however the traffic between Spokes is supposed to go directly which does not seem to be happening in my lab. CEF still shows next hop as Hub for networks behind Spokes.
I have also noticed that when I run show dmvpn command I do not see attributes T1 and T2 listed. Could this be the issue.
I also had done the EIGRP Phase 2 DMVPN Lab and there the traffic went directly between Spokes and I think that is because next hop does not change like in OSPF broadcast Network Type.
It seems to me that NHRP is not kicking in to over-ride the next hop in case of P2MP. Please clarify or is there something wrong with my config?
I am using (C7200-ADVENTERPRISEK9-M), Version 15.2(4)M7 IOS in GNS3 running in dynamips mode.
Below is my config
Hub:
Hub#sh run int tun0
Building configuration...
Current configuration : 281 bytes
!
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp redirect
ip ospf network point-to-multipoint
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
Hub#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/1001] via 172.16.123.2, 00:02:31, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/1001] via 172.16.123.3, 00:01:57, Tunnel0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O 172.16.123.2/32 [110/1000] via 172.16.123.2, 00:02:31, Tunnel0
O 172.16.123.3/32 [110/1000] via 172.16.123.3, 00:01:57, Tunnel0
Hub#
Spoke 1:
Spoke1#sh run interface tunnel 0
Building configuration...
Current configuration : 353 bytes
!
interface Tunnel0
ip address 172.16.123.2 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
ip nhrp shortcut
ip ospf network point-to-multipoint
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
Spoke1#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/1001] via 172.16.123.1, 00:02:52, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2001] via 172.16.123.1, 00:02:10, Tunnel0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O 172.16.123.1/32 [110/1000] via 172.16.123.1, 00:02:52, Tunnel0
O 172.16.123.3/32 [110/2000] via 172.16.123.1, 00:02:10, Tunnel0
Spoke1#
Spoke1#sh ip cef 3.3.3.3
3.3.3.3/32
nexthop 172.16.123.1 Tunnel0
Spoke1#
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.123.1 64 msec 64 msec 24 msec
2 172.16.123.3 48 msec 44 msec 76 msec
Spoke1#
Spoke1#sh ip cef 3.3.3.3
3.3.3.3/32
nexthop 172.16.123.1 Tunnel0
Spoke1#
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.123.1 24 msec 32 msec 28 msec
2 172.16.123.3 28 msec 60 msec 92 msec
Spoke1#sh ip cef 3.3.3.3
3.3.3.3/32
nexthop 172.16.123.1 Tunnel0
Spoke1#
Spoke1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# 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
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 01:20:09 S
1 192.168.123.3 172.16.123.3 UP 01:03:00 D
Spoke1#
Thanks for your help.
Hello Rahul
Thanks for your detailed explanation. At first glance your configs look correct. From the routing table we can see that the behaviour on your lab is different due to the fact that the “%” symbol doesn’t appear in the routing table of the spoke for the following entry:
O 172.16.123.3/32 [110/2000] via 172.16.123.1, 00:02:10, Tunnel0
From the very first implementation of the ip ospf network point-to-multipoint command, this symbol should appear in this entry but it does not, so indeed NHRP is not kicking in as you say.
The only thing that I can think of at this point is that maybe you forgot to remove the static OSPF neighbor configuration from the hub? I don’t see your OSPF config for the hub, so maybe this was missed? Take a look and let us know…
I hope this has been helpful!
Laz
Hello Laz,
Thanks for your help!
No, there are no static neighbors defined on the Hub. Below is my ospf config for all 3 Routers:
Hub#sh run | section ospf
ip ospf network point-to-multipoint
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 172.16.123.0 0.0.0.255 area 1
Hub#
Spoke1#sh run | s ospf
ip ospf network point-to-multipoint
router ospf 1
network 2.2.2.2 0.0.0.0 area 1
network 172.16.123.0 0.0.0.255 area 1
Spoke1#
Spoke2#sh run | s ospf
ip ospf network point-to-multipoint
router ospf 1
network 3.3.3.3 0.0.0.0 area 1
network 172.16.123.0 0.0.0.255 area 1
Spoke2#
Hello Rahul
From the configs you shared, I don’t see any reason for your topology not to function correctly. Sometimes these situations occur due to some glitch in GNS3. It can be frustrating sometimes, but if you’re in a position to identify the problem, and discuss it on the forum in such detail, it means that you have a firm understanding of the concepts involved, and that’s the ultimate goal.
If you’re determined to get this working, see if you can try it out on either another emulator (EVE-NG or VIRL/CML) or on real devices if you have access to them. This will confirm if the issue is indeed GNS3 or some configuration detail that we’re just not seeing…
I hope this has been helpful!
Laz
1 Like