NHRP in DMVPN Phase 1

[sarahr202]

Hi everybody

I hope you all are doing fine; please consider the following example:

R2 is hub and R3 is spoke, we are using DMVPN phase 1, I am trying to undestand the impact of ip nhrp map multicast 199.199.199.2
ip nhrp map 192.192.192.2 199.199.199.10 on NHRP and multicast traffic.

R2 (199.199.199.2)--INTERNET--200.200.200.3 -f0/1---R3 ( Spoke)

Focusing only on NHRP here.

R2#show running-config interface tunnel 0

interface Tunnel0
ip address 192.192.192.2 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/0
tunnel mode gre multipoint

R3#show running-config interface tunnel 0
interface Tunnel0
ip address 192.192.192.3 255.255.255.0
ip nhrp map multicast 199.199.199.2
ip nhrp map 192.192.192.2 199.199.199.10
ip nhrp network-id 1
ip nhrp nhs 192.192.192.2
tunnel source FastEthernet0/1
tunnel destination 199.199.199.2

Next, i removed the highlighted commands from R3:

R3(config-if)#no ip nhrp map multicast 199.199.199.2
R3(config-if)#no ip nhrp map 192.192.192.2 199.199.199.10

Next I shut and no shut f0/1 on R3 to force R3 to register with Hub R2, even though I have removed the commands above, I still see R3 has no issue with registering with R2( hub):

As far as NHRP registration is concerned , these commands do not have any impact, then how do these command impact NHRP in general? What aspect of NHRP will be effected if these commands are not configured?

I also see multicast traffic can still be passed over the tunnel even if we do not have these commands:

I enable ospf on tunnel 0 on both R2( hub) and R3( spoke), 

R2#show running-config | section ospf
router ospf 1
network 192.192.192.0 0.0.0.255 area 0

R2#show running-config interface tunnel 0

interface Tunnel0
ip address 192.192.192.2 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/0
tunnel mode gre multipoint

##R3#show running-config | section ospf
router ospf 1
network 192.192.192.0 0.0.0.255 area 0

R3#show running-config interface tunnel 0

interface Tunnel0
ip address 192.192.192.3 255.255.255.0
ip nhrp network-id 1
ip nhrp nhs 192.192.192.2
tunnel source FastEthernet0/1
tunnel destination 199.199.199.2

Note we are not using :  ip nhrp map multicast 199.199.199.2  ,  ip nhrp map 192.192.192.2 199.199.199.10 , below we can see ospf neighbor relationship forms:

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 FULL/ - 00:00:33 192.192.192.3 Tunnel0
R2#

I see these commands do not effect multicast traffic either, question is:  what purpose  do these commands serve?

Thanks and have a great weekend!!

[Mark Malone · Accepted solution]

Hi

just from the doc you are correct they are optional but for gre multipoint which I see you use it states its required , out of interest if you remove the multicast dynamic will it still work as without this ospf may not work as it needs this for its multicast packets in the tunnel , you have enabled a dynamic mapping but not a static one by not using the other 2 commands

Configuring a Static IP-to-NBMA Address Mapping on a Station

To participate in NHRP, a station connected to an NBMA network must be configured with the IP and NBMA addresses of its NHSs. The format of the NBMA address depends on the medium you are using. For example, GRE uses a network service access point (NSAP) address, Ethernet uses a MAC address, and SMDS uses an E.164 address.

These NHSs may also be the default or peer routers of the station, so their addresses can be obtained from the network layer forwarding table of the station.

If the station is attached to several link layer networks (including logical NBMA networks), the station should also be configured to receive routing information from its NHSs and peer routers so that it can determine which IP networks are reachable through which link layer networks.

Perform this task to configure static IP-to-NBMA address mapping on a station (host or router). To enable IP multicast and broadcast packets to be sent to the statically configured station, use the ip nhrp map multicast nbma-address command. This step is required on multipoint GRE tunnels and not required on point-point RE tunnels.

---

Note The IGP routing protocol uses IP multicast or broadcast, so this step, though optional, is often required.

[sarahr202]

Hi Mark,

Thanks for your response.

just from the doc you are correct they are optional but for gre multipoint which I see you use it states its required , out of interest if you remove the multicast dynamic will it still work as without this ospf may not work as it needs this for its multicast packets in the tunnel , you have enabled a dynamic mapping but not a static one by not using the other 2 commands

I removed the dynamic mapping from tunnel 0 on hub (R2), still ospf neighbor relationship forms:

R2(config)#interface tunnel 0
R2(config-if)#no ip nhrp map multicast dynamic

R2#clear ip ospf 1 process
Reset OSPF process? [no]: y
R2#
*Mar 1 03:24:15.987: %OSPF-5-ADJCHG: Process 1, Nbr 30.30.30.30 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 03:24:16.087: %OSPF-5-ADJCHG: Process 1, Nbr 30.30.30.30 on Tunnel0 from LOADING to FULL, Loading Done

Perform this task to configure static IP-to-NBMA address mapping on a station (host or router). To enable IP multicast and broadcast packets to be sent to the statically configured station, use the ip nhrp map multicast nbma-address command. This step is required on multipoint GRE tunnels and not required on point-point RE tunnels

We see in my example it is not true, we see ospf neighbor relationship forms even if we do not use ip nhrp map on hub or spoke or both.

Appreciate your response and have a nice weekend:)

[Mark Malone]

That's pretty interesting I have only deployed dmvpn using the best practices and have always used those commands  to form the connection , even the extract states you at least need that dynamic command , if I get a chance over weekend ill lab it up see If I come across something relevant

Usage Guidelines

Use this command when spoke routers need to initiate multipoint generic routing encapsulation (GRE) and IPSecurity (IPSec) tunnels and register their unicast NHRP mappings. This command is needed to enable dynamic routing protocols to work over the Multipoint GRE and IPSec tunnels because IGP routing protocols use multicast packets. This command prevents the Hub router from needing a separate configuration line for a multicast mapping for each spoke router.

[Peter Paluch · Accepted solution]

Sarah, Mark,

Please allow me to join in.

Sarah, when you removed the ip nhrp map multicast dynamic on the hub, did you also clear the NHRP mappings? The ip nhrp map multicast dynamic tells the hub to add a "multicast" flag to every dynamic NHRP mapping it creates, but once these mappings have been created, the removal of this command is not going to impact the existing mappings, only the new ones that get created afterwards.

I suggest you try performing the experiment again, but this time, make sure to clear the NHRP mappings after removing the mapping command (use the clear ip nhrp to remove the mappings).

Best regards,
Peter

[sarahr202]

Hi Peter,

Thanks as usual for awesome thought provoking answers.

1) When I removed ip nhrp map multicast dynamic and did clear ip nhrp, ospf drops:

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 FULL/ - 00:00:34 192.192.192.3 Tunnel0

R2(config)#interface tunnel 0
R2(config-if)#no ip nhrp map multicast dynamic

R2# clear ip nhrp

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 INIT/ - 00:00:34 192.192.192.3 Tunnel0

*Mar 1 00:43:34.395: %OSPF-5-ADJCHG: Process 1, Nbr 30.30.30.30 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached

####################################

This is what I also observed:

However, re-applying  ip nhrp map multicast dynamic under tunnel 0, will not bring OSPF up :

R2(config)#interface tunnel 0
R2(config-if)#ip nhrp map multicast dynamic

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 INIT/ - 00:00:34 192.192.192.3 Tunnel0

This is what I understand based on the behavior observed:

1)Every time NHC  ( R3 here) registers with NHS ( R2 here), NHS creates an entry which maps private ip to public ip in NHRP mapping table. NHS does not actively track if NHC is up .

it is responsibility of NHC to resend registration request  to NHS  every 1/3 of NHRP hold time which is the default, to keep the mapping between private ip-->public ip valid.

2) once I applied clear ip nhrp on R1, it removes all mapping between private ip--publicIP.

Now even if we apply the ip nhrp map multicast dynamic on R1, it will not bring ospf up, because there is no mapping in NHRP table so the command has no affect, it was only when I force R3 to send register request by bouncing tunnel0 on R3, does R2 create private ip-public ip mapping and the command ip nhrp map multicast dynamic takes effect and OSPF comes up:

R2(config)#interface tunnel 0
R2(config-if)#ip nhrp map multicast dynamic

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 INIT/ - 00:00:32 192.192.192.3 Tunnel0

R2#show ip nhrp

no mapping !!

Forcing R3 to register with R2:

R3(config)#interface tunnel 0
R3(config-if)#shut
R3(config-if)#no shut

R2#show ip nhrp
192.192.192.3/32 via 192.192.192.3, Tunnel0 created 00:00:43, expire 01:59:16
Type: dynamic, Flags: authoritative unique registered
NBMA address: 200.200.200.3

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
30.30.30.30 0 FULL/ - 00:00:37 192.192.192.3 Tunnel0

so we should not ever do clear ip nhrp on hub otherwise we might end up with outage until spoke registers itself again with hub.

I appreciate your and Mark's help, have a nice weekend:)

[Peter Paluch]

Hi Sarah,

Glad to have helped! :)

so we should not ever do clear ip nhrp on hub otherwise we might end up with outage until spoke registers itself again with hub.

Words of wisdom!

Best regards,
Peter