DMVPN Topic Notes

• Dynamic Multipoint VPN
• Provides a traditional Hub-and-Spoke designs with much better scalability
  • Reduces configuration needed
  • Can use templated configuration for spoke deployment
  • Reduces the need for n*(n-1)/2 static tunnel configuration
• Only requires IP underlay connectivity
• • IPv4 and IPv6 supported
• Tunnels created on-demand between spokes
• Encryption is optional

• Initial tunnel-mesh is hub-and-spoke (always-on)

DMVPN Components

1. Multipoint GRE tunnels (mGRE)
2. Next-Hop Resolution Protocol (NHRP)
3. Dynamic Routing
4. IPsec Crypto Profiles

• DMVPN Hub
  • Acts as the NHRP Server
    • NHS – Next Hop Server
• DMVPN Spoke(s)
  • Acts as the NHRP Client
    • NHC – Next Hop Client
  • Spokes register with Hub via NHRP Registration Request
    • Spokes manually connect to Hub’s NBMA (public) address

NHRP Messages

• NHRP is the protocol used to connect Hub(s) to Spoke(s)
  • Resolve VPN tunnel addresses to NBMA addressing

NHRP Message: Registration Request

• Used in Phase 1, 2 and 3
• Spokes register their NBMA and VPN (GRE Tunnel) IP address to NHS
• Required to build the spoke-to-hub tunnels
• Sent by spokes every 1/3 of hold time

NHRP Message: Resolution Request

• Used in Phase 2 and 3
• Spoke queries for the NBMA-to-VPN mappings of other spokes
• Required to build spoke-to-spoke tunnels

NHRP Message: NHRP Redirect

• Used only in DMVPN Phase 3 to build spoke-to-spoke tunnels
• NHS answer to a spoke-to-spoke data-plane packet through it
• Sent by NHS to spoke when packet in and out interface is the same
  • Similar to IP redirects
• Creates NHO (Next Hop Override) routing table entries

Routing over DMVPN

• Not recommended to run OSPF due to hierarchical system
• ODR (On-Demand Routing) can be used to route over DMVPN
• Recommended to run EIGRP, RIPv2 or BGP as routing protocol
  •  If using a Distance Vector protocol over DMVPN, split horizon will come in to effect on the Hub
  • Need to disable on tunnel interface

• OSPF
  • Set the OSPF network type to BROADCAST or NON-BROADCAST
    • Command:
      • (config-if)#ip ospf network broadcast
      • (config-if)#ip ospf network nonbroadcast
  • Make sure the MTU matches on all nodes
    • Command:
      • (config-if)#ip mtu <mtu>
  • Set the OSPF priority to 0 to make sure the Spokes can't be the DR
    • Command:
      • (config-if)#ip ospf priority 0
• EIGRP
  • Can use summarization on the Hub to advertise default route with EIGRP
    • Command:
      • (config-if)#ip summary-address eigrp <AS #> 0.0.0.0 0.0.0.0
  • Can make sure next-hop isn't updated by the hub for Spoke-to-Spoke communication for Phase 2
    • `Command:
      • (config-if)#no ip next-hop-self eigrp <AS>
• BGP
  • Can use BGP dynamic neighbors to establish adjacencies, along with peer groups for automatic configuration
    • Command:
      • (config-router)#bgp listen range <network range to listen on> [peer-group <group-name>]
  • Use BGP listen to limit the number of  BGP dynamic neighbors
    • Command:
      • (config-router)#bgp listen limit <# of neighbors>

[_/su_spoiler]

Spoke-to-Spoke Routing

• Phase 1 doesn't support Spoke-to-Spoke direct routing
  • All traffic has to go via the hub first
• Phase 2 and 3 support Spoke-to-Spoke direct routing
  • Phase 2 through a CEF 'trick'

• The Hub uses pseudo-broadcast for broadcast traffic and psuedo-multicast for multicast traffic
  • Traffic inside the tunnel (VPN) is broadcast / multicast
  • Traffic outside the tunnel (NBMA network) is unicast and copied multiple times to each spoke

[_/su_spoiler]

Multicast Routing

• Multicast spoke-to-spoke is not supported in any phase
  • Traffic is always multicast to hub only

• Hub configuration
  • Using NHRP the Hub matches multicast to the dynamically learned spokes
  • Uses a pseudo-multicast method where all multicast packets are replicated and sent unicast down to each registered spoke
  • Command:
    • (config-if)#ip nhrp map multicast dynamic

• Spoke configuration
  • Using NHRP the spoke maps multicast to the static NBMA address of the Hub
  • Command:
    • (config-if)#ip nhrp map multicast [Hub NBMA address]

[_/su_spoiler]

Phase 1

Phase 1 Overview

• Legacy configuration
• Multipoint GRE on hub
• Point-to-Point GRE on spokes
• Spoke-to-Spoke tunnels are not supported

• Spoke dynamically registers to hub
  • Only sends NHRP Registration Requests
  • Does not send NHRP Resolution Requests as no spoke-to-spoke tunnels

• Summarization and default routing on hub is allowed
  • i.e. inject default route and send to spoke pointing towards hub

[_/su_spoiler]

Phase 1 Configuration

[_/su_spoiler]

Phase 2

Phase 2 Overview

• Legacy configuration
• GRE Multipoint on Hub and Spokes
• Spoke-to-Spoke tunnels are supported

• NHRP required for Spoke registration to Hub
  • Sends NHRP Registration Requests  to register with hub
  • Sends Resolution Requests to NHS for resolution of other spokes next-hop addresses, not the spokes networks

• Spoke-to-Spoke tunnel triggered by CEF requesting resolution of next-hop (as detailed in route)
  • This is why its important to preserve the next-hop field in route as the originating spoke
  • First packet process switched via hub
  • Subsequent packets CEF switched to destination spoke

• Summarization and default routing at hub is not allowed
  • Requires all spokes to have full routing information
  • Limits scalability
• Next-hop on prefixes needs to be preserved by the hub
  • Next hop remains as other spoke endpoint in routing updates
• Hub only used for control plane exchange

[_/su_spoiler]

Phase 2: Spoke-to-Spoke Dynamic Tunnel Formation

1. Spoke 1 receives Spoke 2's network range of 192.168.255.0/24 from the hub with a next-hop of 10.0.0.3 - even though the route is learned from the hub (or 10.0.0.1)
   • NHRP already has static entry for Hub Tunnel to NBMA mapping
2. CEF installs the route in Spoke 1 as 192.168.255.0/24 with next hop of 10.0.0.3
3. CEF marks the next-hop adjacency (10.0.0.3) as 'glean' or 'incomplete' , meaning it requires a L3 to L2 lookup to be performed
   • confirm with command: #show ip cef  192.168.255.0 internal
4. This lookup is performed by NHRP to the NHS when initial packet is sent to 192.168.255.0/24
   • Initial packet is process-switched across the hub and sent on to Spoke 2
5. NHS NHRP process responds with Spoke 2's Tunnel to NBMA mapping and CEF adjacency now complete
6. Spoke-to-Spoke connection is formed under NHRP for a default of 2 hours

[_/su_spoiler]

Phase 2 Configuration

[_/su_spoiler]

Phase 3

Phase 3 Overview

• Multipoint GRE on Hub and Spokes
• NHRP required for Spoke registration to Hub
  • Sends NHRP Registration Requests  to register with hub
• NHRP required for spoke-to-spoke resolution
• The hub (NHS) is not the only source of NHRP information

• Summarization and default routing at the Hub is allowed
  • Hub isn't required to preserve reachability information
  • Possible to just send a default route to the spokes
• No more invalid or glean adjacencies in the CEF table
  • All spoke routes point to the Hub router and are CEF switched across the Hub initially
  • Invalid CEF entries no longer used to trigger the NHRP Resolution Request process for Spoke-to-Spoke tunnel

• Uses NHRP Redirect messages to tell source its using sub-optimal path
  • NHRP resolution is triggered by hub when a packet is switched out same interface it was received on
• Uses NHRP Shortcut to install or update CEF table with NHRP mappings of spokes
  • NHO (Next Hop Override) is performed for spoke-to-spoke by NHRP process
  • RIB and FIB don't match.
    • RIB points to Hub
    • FIB (CEF) points to spoke fed from NHRP process
• Tries to resolve final destination rather than next-hop address
• Only learns the routes you're trying to forward to through NHRP process

• OSPF can run point-to-multipoint (optional)
  • Command:
    • (config-if)#ip ospf network point-to-multipoint

[_/su_spoiler]

Phase 3: Spoke-to-Spoke Dynamic Tunnel Formation

1. Spoke 1 receives Spoke 2's network range of 192.168.255.0/24 from the hub with a next-hop of 10.0.0.1 (hub's Tunnel address)
   • NHRP already has static entry for Hub Tunnel to NBMA mapping
2. CEF installs the route in Spoke 1 as 192.168.255.0/24 with next hop of 10.0.0.1
   • CEF adjacency complete due to static NHRP mapping between hub and spoke
3. If a packet is switched out the same mGRE interface on which it was received, it sends back to the source a NHRP Redirect message
   • Tells the source its using sub-optimal path to route packets and should use NHRP Resolution to find a better one
   • First packet is still routed using the routing table
   • Initially all spoke-to-spoke packets are CEF switched across the hub
4. Originating router receives NHRP Redirect message
   • Packet contains destination IP address of original packet and its payload
5. Originating router sends NHRP Resolution Request for the redirected destination IP, targeted at the original destination IP
   • Target is not the NHS, even though NHS or hub is traversed along the path
   • Target is originating router of destination prefix
     • Hub learned this route from Spoke 2, therefore Spoke 2 is the destination target
6. Spoke 2 responds to the NHRP Resolution Request directly to Spoke 1 (not via hub)
   • Reply contains entire prefix found in RIB, not just requested IP
7. Spoke 1 receives NHRP Resolution Request reply of the NBMA address of the prefix it needed and re-writes the CEF table, or creates a new CEF entry if needed
   • CEF rewrite procedure is called NHRP shortcut
   • CEF table still displays the original entry from the routing table

[_/su_spoiler]

Phase 3 Configuration

[_/su_spoiler]

DMVPN Phase Comparison 

Troubleshooting commands

#show ip nhrp – displays installed nhrp routes

#show dmvpn – displays tunnels, tunnel mappings and state of tunnels

#clear dmvpn session – clears all the DMVPN connections

#debug dmvpn all all – enables all debugging of DMVPN connections

#debug nhrp – enables debugging for the NHRP protocol

debug nhrp packet – enables debugging for the NHRP activity