DMVPN- Details Analysis

DMVPN - Phase1,2, and 3

• NBMA networks and all traffic broadcast and uni-cast must be sent across the network as uni-cast packets.
• This simply means multicast traffic destined for an IGP neighbor will always be encapsulated in a uni-cast packet for delivery
• Hub router always knows the identities of all the spokes for which it is the next-hop server (NHS)
• ip nhrp map multicast dynamic command on the hub is used to dynamically create mappings in the NHRP multicast table for each spoke that registers with it
• Spoke routers create a static multicast mapping for hub 
•  ip nhrp map multicast [ nbma address of hub] 
•  ip nhrp nhs [overlay address] [underlay address] multicast

PHASE I

• Only provides hub-spoke tunnel deployment. This means GRE tunnels are only build between the hub and spokes
• Traffic destined to networks behind spokes is forced to first traverse the hub.
• Restricts it form building dynamic spoke-to-spoke tunnels. Because all spoke-to-spoke traffic in DMVPN phase 1 always traverses the hub.
• Flood a default summary route to the spokes for all traffic. This is achieved in EIGRP using the ip summary-address eigrp [asn] 0.0.0.0 0.0.0.0 command under the tunnel interface

PHASE1- Configuration
Hub 
Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip summary-address eigrp 1 0.0.0.0 0.0.0.0
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

Spoke
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel destination 192.168.1.1

PHASE 2

• Traffic between the spokes would always hit the hub.
• The hub burdened with encapsulate/decapsulate overhead for the spoke-to-spoke traffic
• Phase 2 improved on phase 1 by allowing spokes to build a spoke-to-spoke tunnel on demand with these restrictions
• Spoke must use multipoint GRE tunnels
• The spokes must receive specific routes for all remote spoke subnets
• The next hop of the entry in the routing table must list the remote spoke as the next hop

CONFIGURATION

• Need to configure mGRE on the spokes allows multiple GRE tunnels to be formed using a single tunnel interface ( tunnel mode gre multipoint)

•     Spokes must receive specific routes for all remote spoke subnets. For EIGRP, this is accomplished by disabling split horizon on the tunnel interface

• The hub uses its tunnel 0 interface to reach the networks behind the spokes. Split horizon will prevent the hub from advertising those networks to remote spokes.
• no ip split-horizon eigrp command

• After the NHRP resolution is complete, traffic will not pass through Hub anymore.
• Because the next hop for each prefix must be preserved. In Phase 2, it is not possible to summarize from the hub to the spokes

PHASE2- Configuration
Hub 
Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # no ip next-hop-self eigrp 1
Router (config-if) # no ip split-horion eigrp 1
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

Spoke
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel mode gre multipoint

PHASE 3

• Spokes register their Tunnel/NBMA mappings with the hub (or hubs). This allows the hub to dynamically discover all spokes and establish routing adjacency and routing information exchanged.
• In fact, the hub is not required to preserve the reachability information and also summarize information to send to all spokes

• Use NHRP traffic indication messages from the hub to signal to the spokes that a better path exists to reach the target network
• " ip nhrp redirect" on the hub and " ip nhrp shortcut"
• This command provides the hub to the send the NHRP traffic indication message while the shortcut command tells the spokes to accept the redirect and install the shortcut route

PHASE 3 CONFIGURATION
HUB 

Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp redirect
Router (config-if) # ip summary-address eigrp 1 0.0.0.0 0.0.0.0
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

SPOKE
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp shortcut
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel mode gre multipoint
 
REFERENCE

1. INE_BLOG_DMVPN_EXPLAIN
2. INE_DMVPN_VIDEO
3. CISCO_DMVPN_CONFIGURATION_DOC

DMVPN Phases

DMPVN Phases

• DMVPN Phase 1
• mGRE on hub and p-pGRE on spokes
• NHRP still required for spoke registration to hub
• No spoke-to-spoke tunnels
• Routing
• summarization/default routing at hub is allowed
• Next-hop on spokes is always changed by the hub
• DMVPN Phase 2
•  mGRE on hub and spokes
• NHRP required for spoke registration to hub
• NHRP required for spoke-to-spoke resolution
• Spoke-to-spoke tunnel triggered by spoke
• Routing
• Summarization/default routing at hub is NOT allowed
• Next-hop on spokes is always preserved by the hub
• Multi-level hierarchy requires hub daisy-chaining
• DMVPN Phase 3
• mGRE on hub and spokes
• NHRP required for spoke registration to hub
• NHRP required for spoke-to-spoke resolution
• When a hub receives and forwards packet out of same interface
• Send NHRP redirect message back to packet source
• Forward origin packet down to spoke via RIB 
• Routing
• Summarization/default routing at hub is allowed
• Results in NHRP routes for spoke-to-spoke tunnel
• With no-summary, NHO is performed for spoke-to-spoke tunnel
• Next-hop is changed from hub IP to spoke IP
• Next-hop on spokes is always changed by the hub
• Because of this, NHRP resolution is triggered by hub
• Multi-level hierarchy works without daisy-chaining
 
Reference
DMVPN_CONFIGURATION_CISCO_DOC 
DMVPN_INE_DMVPN_REVIEW 
 
 
 
 

Dynamic Multipoint VPN

Dynamic Multipoint VPN

• Point to Multi-point Layer 3 overLay VPN
• Logical hub and spoke topology
• Direct spoke to spoke traffic is supported
• DMVPN uses a combination of 
• Multipoint GRE tunnels (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto Profiles

Why DMVPN?

• Independent of SP access method
• Only requirement is IP connectivity
• Routing policy is not dicitated by SP
• MPLS L3 VPN restrictions (E.g)
• Highly scalable
• If properly designed

DMVPN allows on-demand full mesh IPSec tunnels with minimal configuration such as

• mGRE(Multipoint GRE Tunnnels)
• Next Hop Resolution Protocol (NHRP)
• IPsec Crypto Profiles
• Routing

Creates on-demand tunnels between nodes

• initial tunnel-mesh is hub-and-spoke (always on)
• Traffic patterns trigger spoke to spoke tunnels
• Solves management scalability problem 

Maintain tunnels based on traffic patterns  

• Spoke-to spoke tunnel is on-demand
• Spoke-to spoke tunnel lifetime is based on traffic

Requires two IGPs: Underlying and Overlay

• IPv4/IPv6 supported for both passenger and transport

 How DMVPN Works ( Hub to Spoke)

• Two main components
• DMVPN Hub/NHRP Server (NHS)
• DMVPN Spokes /NHRP Clients (NHC)

Spokes/Clients register with Hub/Server

• Spokes manually specify Hub's address
• Sent via NHRP registeration request
• Hub dynamically learns Spokes' VPN address & NBMA address

Spokes establish tunnels to Hub

• Exchange IGP routing information over the tunnel

 Spoke to Spoke ( routes via IGP)

• Learns via tunnel to Hub
• Next-hop is spoke2's VPN IP for DMVPN phase 2
• Next-hop is Hub's VPN IP for DMVPN phase 3 

Spoke1 ask Spoke2's real address

• Maps next-hop (VPN) Ip to tunnel source (NBMA) IP
• Send via NHRP resolution request

Spoke to Spoke tunnel is formed

• Hub only used for control plane exchange
• Spoke-to-spoke data plane may flow through hub initially

NHRP Important Messages

• NHRP Registration Request
• Spoke register their NBMA and VPN IP to NHS
• Required to build the spoke to hub tunnels
• NHRP Resolution Request
• Spoke queries for the NBMA-to-VPN mappings of other spokes
• Required to build spoke-to-spoke tunnels
•  NHRP Redirect
• NHS answer to a spoke-to-spoke data-plane packet through it
• Similar to IP redirects, when packet in/out interface is the same
• Used only in DMVPN Phase 3 to build spoke-to-spoke tunnels

REFERENCE

1.  INE_DMVPN_Overview
2.  cisco_doc_dmvpn_configuration