DMVPN and NHRP Overview¶
DMVPN is a dynamic tunneling form of a VPN, that enables to create a dynamic-mesh VPN network without having to statically pre-configure all possible tunnel endpoint peers.
The DMVPN solution enables to dynamically build an NBMA network that interconnects scattered sites via GRE tunnels.
Static or dynamic GRE tunnels are used to interconnect the sites, the NHRP protocol is used to determine a route with the fewest hops from a sender to a receiver.
The DMVPN solution relies on a hub and spoke model, but supports optimizing routes, so that spokes can directly communicate together via dynamic GRE tunnels.
Finally, DMVPN supports an automatic IPsec protection with limited configuration.
DMVPN and NHRP terminology¶
- Hub and Spoke model
A computer network topology in which a series of spokes connect to a central hub. Communication between spokes transits via the hub. The hub dispatches traffic or information among the spokes.
- NBMA, Non-Broadcast Multiple-Access network
A computer network to which multiple hosts are attached, but data is transmitted only directly from one computer to another single host, typically over a virtual circuit. In the DMVPN case, the virtual circuits are GRE tunnels.
- NHRP, Next Hop Resolution Protocol
A client-server protocol used to determine a route with the fewest hops from a sender to a receiver in an NBMA network.
- NHC, NHRP client
A client of the NHRP protocol, that runs on a spoke.
- NHS, NHRP server
The server of the NHRP protocol, that runs on the hub.
- DMVPN, Dynamic Multipoint Virtual Private Network
A dynamic tunneling form of a VPN, that enables to create a dynamic-mesh VPN network without having to statically pre-configure all possible tunnel endpoint peers.
DMVPN and NHRP operation¶
Hub and spoke topology¶
A DMVPN network is an NBMA network composed of spokes (NHC devices) connected to a central hub (NHS device) via GRE tunnels.
Each device has an internal IP address, named the protocol address, typically configured on its GRE interface, and an outer IP address, named the NBMA address, which is the source address of the GRE packets.
The hub and all spokes are considered IP neighbors in the NBMA network, whose IP addresses are their protocol address.
All members of the DMVPN network register their protocol address and NBMA address to the NHS via the NHRP protocol.
The NHRP protocol enables to resolve the next-hop to reach the protocol address of a neighbor in the NBMA network, i.e. the destination IP address of GRE packets in which the packets should be encapsulated.
Depending on the situation, the next hop may be the NBMA address of the NHS (the traffic will transit via the hub) or the NBMA address of the destination spoke (if a shortcut optimization is established).
NHRP use case example¶
The diagram above illustrates the use case that will be used across all the phases proposed. It is a NBMA network with 4 devices. One of those devices acts as the hub, while the others stand for the spokes. Here are some details:
NBMA network spans over Internet and the nodes use public IPv4 addresses.
each device has a GRE interface with an IP address on GRE interface named
protocol address. That IP address will need to be a 32 bit mask or 128 bit mask, whether it is an IPv4 or an IPv6 address. Configuring an other bitmask will lead to a misconfiguration problem. Once done, NHRP will use that IP address to associate with its NBMA address. NHRP is able to mount dynamically or statically routes to a remote NBMA address.each device is attached to its own private network 192.168.y.z/24. More than one private network can be used behind GRE interface.
a gre tunnel is established. This tunnel relies on NBMA source ip address of the device.
Optionally, all traffic going through the gre interface is encrypted.
NHRP can help in establishing traffic between two devices, either between spoke and hub, or between two spokes. In the former case, it is possible to avoid configuring multipoint GRE interfaces, as traffic is redirected to hub.
Note
DMVPN is partially supported on cross-vrf GRE interfaces, i.e. GRE
interfaces with a link-vrf different from their vrf: their cross-vrf
must be vrf main.
The first two paragraphs describe how to use GRE interfaces and NHRP to establish connections between the spokes via the hub, either statically or dynamically.
The last paragraph introduces the redirect feature that enables dynamic tunnel
establishment between spokes.
Traffic flowing between spoke and hub¶
Once the GRE interface is set up on the spokes, it is possible to use NHRP to mount routes to reach remote networks from hub.
It is possible to configure NHRP static entries on both hub and spoke sides, so that NHRP routes will be automatically added in the system. Note that this mechanism does not involve any communication between both sides, from NHRP protocol point of view.
The other solution involves a transaction between the spokes and the hub. A spoke configures the NHRP service, and declares a NHS. Actually NHS stands for the hub device. Once done, a spoke begins the transaction by sending a NHRP registration request. This request contains the NBMA IP address associated to the protocol IP address of the GRE interface. For the hub, the reception of incoming requests will lead to a registration reply indicating the success (or the failure) of the operation, along with its NBMA and protocol IP address.
Traffic flowing between spokes¶
It is possible to send the traffic directly between spokes, by relying on point to multipoint GRE interfaces on the spokes side too.
Tunnels are dynamically established, based on a nhrp redirect feature located on the hub
side. NHRP helps on the hub side by identifying traffic that is flowing in and out
through the same GRE interface. The hub takes a snapshot and sends some NHRP redirect
information to the relevant spokes. At the end, the negotiation finalises between the spokes.
RFC¶
See also