Question about Dmvpn ip nhrp map multicast ip

[Liqu]

Hi everyone, 

Trying to understand a part of using the nbma address for dmvpn. 

Any direction would be appreciated, thanks. 

Do we have to use the nbma or can we use the VPN tunnel address instead?

I wasn't sure if this was okay since there are mappings already for tunnel with nbma address used for nhs server.

[jalejand · Accepted solution]

Hi Liqu

The ip nhrp map multicast is used to determine to which NBMA address this device is going to send out the multicast packets, for example.

When using MGRE tunnels, a destination is not statically determined (like using a fixed destination with the tunneld destination command), from the Spoke side, multicast packets require an NBMA address, usually, the IP address of the underlay network that usually points to the hub.

R1 Tunnel 192.168.1.100 --------------GRE------------ Tunnel 192.168.1.1 RxHub
R1 Underlay 1.1.1.1 ------------Underlay Network ------- Underlay 2.2.2.2 RxHub

By using the "ip nhrp map multicast 2.2.2.2" command under the tunnel interface at the spoke side, you are telling this router to send all the multicast traffic towards the DMVPN hub

[Liqu]

Thank you Jalejand, 

So it's not possible to use the overlay ip for it?

I was caught up in thinking if the mapping was already there for example

IP nhrp map <overlay address> <nbma address>

Under tunnel config, it would be okay to use the overlay address already referring the nbma

1. IP nhrp map multicast <overlay address>

[jalejand]

Multicast packets by nature are not permitted on NBMA networks, so each mutlticast packet like IGP hellos (OSPF/EIGRP) will be forwarded on a unicast fashion with GRE encapsulation, a final EIGRP hello packet for example should looke like this:

By using the same example:
R1 Tunnel 192.168.1.100 --------------GRE------------ Tunnel 192.168.1.1 RxHub
R1 Underlay 1.1.1.1 ------------Underlay Network ------- Underlay 2.2.2.2 RxHub

Hello from Tunnel 192.168.1.100 to EIGRP multicast 224.0.0.10
Outer IP packet, used for routing on the overlay:
From 1.1.1.1 to 2.2.2.2 - Unicast
Inner IP packet after GRE, processed by receiver by de-encapsulating the packet.
Ha! It was from 192.168.1.100 to 224.0.0.10 all along.

The ip nhrp map multicast 2.2.2.2 command will determine the following destination address:
From 1.1.1.1 to 2.2.2.2 <<<< Send it here, change the Outer IP destination to 2.2.2.2
If we force the router to send it to 192.168.1.2 directly, the Outer IP packet would be like this:
From 1.1.1.1 to 192.168.1.2 <<< Send the packet to a tunnel destination.

This can cause two behaviors:
1. The router might simply not forward the packet as 192.168.1.2 is not considered an NBMA address on its own NHRP table.
2. The router will send the packet out towards the tunnel interface, causing double GRE encapsulation, the receiver router will de-encapsulate this packet to only see another GRE encapsulation that it won't de-encapsulate, the EIGRP hello will never be discovered by the router as it was 1 encapsulation away, dropping the packet.

Even if you already have a static NHRP entry by using the "ip nhrp nhs" command, that creates a NHRP entry, it will still have one NBMA entry that is in this case 2.2.2.2, 192.168.1.2 is never considered an NBMA address.

[Liqu]

Thanks Jalejand,

After reading the causes I'm understanding it a lot more, thanks again.