DMVPN

Friday. June 19, 2020

In the last few months, I have been working with an overlay technology called DMVPN (Dynamic MultiPoint Virtual Private Network) which, today, with emerging technologies related to SD-WAN can be considered as legacy. I will use this and the following posts to explain some things related with DMVPN.

DMVPN is a dynamic way of virtual private network (VPN) that allows a mesh of VPNs without the need to pre-configure all tunnel on spokes. Tunnels on spokes establish on demand based on traffic patterns without repeated configuration on hubs or spokes. Depending on DMVPN design also called phases: 1, 2 or 3. VPN Phase selection affects routing protocol configuration and how it works over the logical topology.

DMVPN Components

This technology involves 4 components that are the following:

• mGRE: The encapsulation based on GRE but with a behavior like a LAN where is possible to have many neighbors reachable over the same interface. So, the “m” in mGRE stands for multipoint.
• NHRP (Next Hop Resolution Protocol): It is a protocol defined on the RFC 2332 that allows a router, wishing to communicate over a Non-Broadcast Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable “NBMA next hops” toward a destination. Creating an analogy with a LAN environment we know that Address Resolution Protocol (ARP) is used to determine MAC address of your neighbor. On mGRE environments ARP is not used but is replaced by NHRP, binding together the logical IP address on the tunnel with the physical IP address used on the outgoing link.
• IPsec Tunnel Protection: IPsec is triggered immediately for both point-to-point and multipoint GRE tunnels. Also, it is not necessary to configure any crypto ACLs, since these will be automatically derived from the GRE tunnel source and destination addresses. IPsec profiles are used to define the IPsec encryption parameters. There is no set peer … or match address … commands required because this information is derived directly from the associated GRE tunnel or NHRP mappings. IPsec is optional and used primarily over public networks.
• Dynamic Routing Protocols: Supports all routing protocols, except IS-IS that cannot be used since it doesn’t run over IP.

How it works?

• Spokes have a dynamic permanent GRE/IPsec tunnel to the hub, but not to other spokes; they register as clients of the NHRP server.
• When a spoke needs to send a packet to a destination (private) subnet behind another spoke, it queries the NHRP server for the real (outside) address of the destination spoke.
• Now the originating spoke can initiate a dynamic GRE/IPsec tunnel to the target spoke (because it knows the peer address).
• The spoke-to-spoke tunnel is built over the mGRE interface.
• When traffic ceases then the spoke-to-spoke tunnel is removed.

Design Models and their characteristics

Phase 1: Hub-and-Spoke

• P2P GRE on spokes and mGRE on hubs
• ISAKMP/IKEv2 Authentication + Certificate (PKI), (Pairwise/Wildcard) Pre-shared Key (PSK)
• NHRP Registration
• Spoke has static NHRP mapping for Hubs
• Hub dynamically learns Spoke’s NHRP mapping
• Handles dynamically addressed spokes (DHCP, NAT , …)
• Check source protocol address in NHRP registration message with source IP on GRE/IP header
• Can switch to IPsec tunnel mode, but then lose spoke-spoke tunnel capability
• No Multicast between Spoke and Spoke
• Route Summarization at Hub

Phase 2: Spoke-Spoke

• mGRE tunnel interface per DMVPN cloud on Hubs and Spokes
• Hubs must be inter-connected in a “Daisy chain” over same mGRE tunnel
• IKE authentication information (Certificates, Wildcard Pre-shared Keys)
• Spoke-spoke data traffic direct
• Reduced load on hub
• Reduced latency
• Single IPsec encrypt/decrypt
• Still hub-and-spoke
• Hub cannot summarize spoke routes
• Routes on spokes must have IP next-hop of remote spoke (preserve next-hop)

Phase 3: Spoke-Spoke

• Increase scale
• Hierarchical network Layout
• Increase total number of spokes; same spoke to hub ratio
• Distribution hubs off load central hub
• Manage local spoke-spoke tunnels
• IP multicast and routing protocol
• No hub daisy-chain
• NHS still interconnected; any pattern
• Use RIB to forward NHRP packets
• Spokes don’t need full routing tables
• Can summarize routes at the hub
• Reduces RIB space and RP load
• Reduce RP load on hub

__

References

1. RFC 2332