DMVPN — Spoke-to-Spoke Multicast (but why?!)

So now that I’ll off my on-call rotation, I’m getting back to studying. I needed something to fire me, so I started watching DMVPN videos from Cisco Live! 2014. One thing that really sparked my interest was spoke-to-spoke multicast communication. I’ll lead by saying this… not a production solution I’d recommend. However, for purposes of studying and better understanding DMVPN I think it’s very cool.

First up, how do we get it working? Well let’s take a look at some sample config from a Hub and two spoke routers before spoke-to-spoke multicast is running.

   Hub
   …
   interface tunnel 100
    ip address 172.10.100.1 255.255.255.0
    ip nhrp map multicast dynamic
    ip nhrp network-id 100
    tunnel source 10.10.1.1
    tunnel mode gre multipoint

  
   Spoke1
   interface tunnel 100
    ip address 172.10.100.2 255.255.255.0
    ip nhrp map multicast
    ip nhrp map 172.10.100.1 10.10.1.1
    ip nhrp nhs 172.10.100.1
    ip nhrp network-id 100
    tunnel source 10.10.1.2
    tunnel mode gre multipoint

  
   Spoke2
   interface tunnel 100
    ip address 172.10.100.3 255.255.255.0
    ip nhrp map multicast
    ip nhrp map 172.10.100.1 10.10.1.1
    ip nhrp nhs 172.10.100.1
    ip nhrp network-id 100
    tunnel source 10.10.1.3
    tunnel mode gre multipoint  

Alright so that’s nothing new, super basic  DMVPN. Now with OSPF, if we wanted or were required to use the broadcast network type we go ahead and treat this connection that same as though it were hub and spoke frame relay. The spokes would all have their interfaces set to ospf priority 0 making the hub router the DR with no BDR. So assuming we’ve done that let’s take a look at our OSPF neighbor table on the hub and spoke 1.

   Hub#show ip ospf neighbor

   Neighbor ID     Pri   State           Dead Time   Address         Interface
   172.16.2.2        0   FULL/DROTHER    00:00:39    172.16.10.2     Tunnel100
   172.16.3.3        0   FULL/DROTHER    00:00:37    172.16.10.3     Tunnel100

   
   SPOKE1#show ip ospf neighbor
 
   Neighbor ID     Pri   State           Dead Time   Address         Interface
   172.16.1.1        1   FULL/DR         00:00:37    172.16.10.1     Tunnel100

So this works just fine… but what happens if we make the following changes on spoke 1 and 2?

   
   SPOKE1#conf t
  
   SPOKE1(config)#int tun100
   SPOKE1(config-if)#ip nhrp map multicast 10.10.1.3
   SPOKE1(config-if)#end

  
   SPOKE2#conf t
  
   SPOKE2(config)#int tun100
   SPOKE2(config-if)#ip nhrp map multicast 10.10.1.2
   SPOKE2(config-if)#end

Something magical happens… our spokes (without any neighbor statements) become OSPF neighbors. This gives us some really interesting properties within our DMVPN cloud. For one, we have this strange static mapping, always on, of broadcast and multicast traffic between spokes… but unicast traffic is still dynamic. Again, this isn’t a best practice but rather an exercise attempting to better understand nhrp within dmvpn. Quick output of shows commands from spoke 1 (just trust me, they’re about the same on spoke 2), then some closing thoughts.

  
   SPOKE1#show ip ospf nei        
  
   Neighbor ID     Pri   State           Dead Time   Address         Interface
   172.16.1.1        1   FULL/DR         00:00:38    172.16.10.1     Tunnel100
   172.16.3.3        0   2WAY/DROTHER    00:00:38    172.16.10.3     Tunnel100
   SPOKE1#show ip nhrp brief      
      Target             Via            NBMA           Mode   Intfc   Claimed
         172.16.10.1/32 172.16.10.1     10.10.1.1       static   Tu100   <   >
         172.16.10.3/32 172.16.10.3     10.10.1.3       dynamic  Tu100   <   >
   SPOKE1#show 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: Tunnel100, IPv4 NHRP Details
   Type:Spoke, NHRP Peers:2,
  
    # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
    —– ————— ————— —– ——– —–
        1 10.10.1.1           172.16.10.1    UP 01:55:53     S
        1 10.10.1.3           172.16.10.3    UP 00:44:32     D
  
   SPOKE1#show ip nhrp multicast
     I/F     NBMA address 
   Tunnel100  10.10.1.3       Flags: static           (Enabled)
   Tunnel100  10.10.1.1       Flags: static           (Enabled)

The best way to think of NHRP (paraphrasing Mike Sullenberger) is a beefy ARP. If you think about the purpose and function of arp compared to nhrp they’re incredibly similar. Where arp attempts to map ip address to mac-address for forwarding on an ethernet network, nhrp attempts to map gre ip to non-broadcast ip. Of course that’s only it’s primary function, nhrp can also carry cool info like nhrp groups used to assign per-tunnel QoS.