"ip nhrp map multicast dynamic" not working

Unanswered Question

Equipment: 871 router

IOS version: 12.4(22)T

Given the following mGRE VTI configuration:

interface Tunnel1

bandwidth 1544

ip address 192.168.99.1 255.255.255.0

no ip redirects

ip nhrp map 192.168.99.2 169.254.0.2

ip nhrp map multicast 169.254.0.2

ip nhrp map multicast dynamic

ip nhrp nhs 192.168.99.2

ip nhrp network-id 1

delay 4000

tunnel source FastEthernet4

tunnel mode gre multipoint

tunnel key 1234567890

tunnel checksum

The "ip nhrp map multicast dynamic" does not seem to perform as documented.

While additional dynamic unicast mappings are provided by the next-hop server, as is shown here:

SiteA#show ip nhrp brief

Target Via NBMA Mode Intfc Claimed

192.168.99.2/32 192.168.99.2 169.254.0.2 static Tu1 < >

192.168.99.3/32 192.168.99.3 169.254.0.26 dynamic Tu1 < >

192.168.99.4/32 192.168.99.4 169.254.0.34 dynamic Tu1 < >

...the expected corresponding dynamic multicast mappings are not created, as is shown here:

SiteA#show ip nhrp multicast

I/F NBMA address

Tunnel1 169.254.0.2 Flags: static

Consequently, multicast traffic, such as EIGRP cannot be passed to 192.168.99.3 or 192.168.99.4.

Any thoughts?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Fri, 02/13/2009 - 09:56

Hello Ben,

this C871 is likely to be a spoke router.

the right command for a spoke is:

ip nhrp map multicast 169.254.0.2

while ip nhrp map multicast dynamic is needed only on the hub side so I would suggest to remove it from the C871 and to try again.

For sure only one of the commands have to be used.

Hope to help

Giuseppe

I am experimenting with a variety of possible configurations, and I do, in fact, need to be able to send multicast traffic directly to 169.254.0.26 and 169.254.0.34.

I know precisely what my goal is and would like to be able to handle this in a scalable manner, avoiding the use of potentially dozens of individual "ip nhrp map multicast" statements in the future.

The point is that the statement does not seem to function as specified.

Giuseppe Larosa Fri, 02/13/2009 - 11:32

Hello Ben,

It is also possible that the platform and IOS combination doesn't support the command well.

see the following reference design guide for DMVPN

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPDG.html

If your objective is to send multicast traffic see the section IP multicast in the above document.

It provides a link to IPmc and sample configuration.

Hope to help

Giuseppe

That document actually gives the following example on page 2-30:

•Spoke router:

!

interface Tunnel0

description dmvpn tunnel

ip address 10.173.20.10 255.255.255.0

no ip redirects

ip mtu 1400

ip pim sparse-mode

ip nhrp authentication secret

ip nhrp map multicast dynamic

ip nhrp map 10.173.20.1 192.168.201.1

ip nhrp map multicast 192.168.201.1

ip nhrp network-id 10203

ip nhrp nhs 10.173.20.1

load-interval 30

tunnel source GigabitEthernet0/0.201

tunnel mode gre multipoint

tunnel key 123

tunnel protection ipsec profile dmvpn

...which, apart from the use of ipsec, is quite similar to my configuration. It does, in fact, include the "ip nhrp map multicast dynamic" statement.

Giuseppe Larosa Fri, 02/13/2009 - 12:12

Hello Ben,

yes I do agree.

This says that the two commands for ip nhrp map multicast can be used together.

so the only option left is that is not working well on your router.

Best Regards

Giuseppe

Correct.

I also tried it on a 2621 with IOS 12.3(26) and got the same results. (Although the "show ip nhrp multicast" command is not available under this IOS version I can clearly tell that multicast is not working unless I use individual static multicast mappings.)

So when does this command work, I wonder. Has anybody actually verified that it ever works?

Gregory Camp Sun, 02/15/2009 - 13:15

Ben,

I have never seen "ip nhrp map multicast dynamic" used in a spoke configuration before. It definitely works on the hub, because that is how the hub knows where to send EIGRP and OSPF multicast hellos too. I assume in this scenario you are trying to build a fully meshed DMVPN? Where every spoke is a neighbor to every other spoke?

Yes, but upon further examination, it appears that this command does not do what the documentation claims, or at least implies.

Given that the use of a next-hop server introduces a weakness to a fullly-meshed network which otherwise wouldn't exist (vulnerability to failure of all specified next-hop servers), unless all spokes are specified as nhs's, I might just wind up biting the bullet and specifying mappings for each node on every other node. A bit unmanagable, but more robust.

Actions

This Discussion