"ip nhrp map multicast dynamic" not working

[benstrauss]

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?

[Giuseppe Larosa]

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

[benstrauss]

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]

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

[benstrauss]

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]

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

[benstrauss]

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]

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?

[benstrauss]

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.

[smaxeh]

I was having a similar problem with the "ip nhrp map multicast dynamic" statement not working correctly on the hub.  I had to remove the tunnel and re-add it for it to work correctly.  Wireshark was showing the packets egressing the hub as having a destination address of 224.0.0.5 for both the "black" (post-GRE) and "red" (pre-GRE) side of the packets.   All the spokes had the "correct" destination (tunnel destination NBMA) set with the multicast address on the "red" side (pre-GRE).

[MHM Cisco World]

make new post and I will try help you in this issue.