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.

CCIEv5's DMVPN

First off, fear not. I've already recorded videos from DMVPN part 2, I didn't give up lol. I just need to get some time to toss everything into text format. I just thought I'd do a really short post about DMVPN on the new blueprint. I haven't tested yet, however from Cisco 360 workbooks, I'm starting to get a good idea of what kind of curve balls to expect on the lab. It's gets me SUPER excited to see how deep just the workbooks have been getting on the subject matter, Cisco is treating it as a frame-relay replacement more than just a subtle new topic.

So far I seen scenarios where you can't allow broadcast/multicast in the DMVPN cloud, so OSPF behavior is similar to FR networks without broadcast. I've also seen some per-tunnel QoS, where you have to leverage NHRP to apply policy-maps per-dynamic tunnel via NHRP groups (IOS help nhrp, you'll be fine. Not "ip nhrp", just nhrp ?). Cisco also loves to trip you up with phrasing like "Map broadcast traffic between spoke routers R1 and R2", but they'll make no mention of the hub. This sounds like you're digging into additional nhrp maps, but that's not the case. Since so long as you're mapping multicast to the hub, nhrp will dynamically map broadcast/multicast traffic between spokes, just as it does with unicast traffic.

So I know I'm just rambling in this post, but this new content should get you excited, not scared. Honestly, one of the best study sessions I've had on the subject matter was sitting down with a follow CCIEer, building a DMVPN network... and looking for ways to break it. Then doubling back and seeing how manipulate behavior, and of course lots of DOC CD and IOS help along the way.


Study hard! I'll have my next DMVPN post out soon.