This post will describe some of the crypto design considerations for DMVPN.
DMVPN Overview and Crypto Overhead
First let’s have a quick recap of what Dynamic Multipoint VPN (DMVPN) is. DMVPN is an overlay technology where multi point GRE tunnels are used to form an overlay where a routing protocol will run across the overlay. DMVPN is a hub and spoke technology where the DMVPN hub acts as a centralized control plane. DMVPN uses Next Hop Resolution Protocol (NHRP) to register the IP addresses of the spokes with the hub. When a router looks in its routing table, the next-hop will be the IP address of the tunnel, not the real outside IP which must be used for the GRE encapsulation. To find the outside IP of the spoke, NHRP is used to resolve the next-hop to the real outside IP.
DMVPN runs over public transport. This means that it’s possible to snoop the traffic while in transit. To prevent this from happening, DMVPN is often combined with IPSec to encrypt the packets. IPSec can run in two modes, transport mode and tunnel mode. In transport mode, the original IP header is not encrypted and there is no additional IP header added. In tunnel mode, which is the default for tunnels, a new IP header is added and the original IP header is encrypted. Tunnel mode is a must for classic LAN to LAN setups because normally the inside subnets are private addresses and the tunnel is formed between publically routable IP addresses.
The difference between transport mode and tunnel mode is show in the picture below.
IPSec in transport mode adds around 36 bytes and in tunnel mode it adds around 52 bytes. The exact number depends on the encryption algorithm and padding of the packet. When using DMVPN with IPSec, it is unneccessary to use tunnel mode. Why? DMVPN uses GRE which means that a new IP header is already added by GRE. The GRE encapsulation happens on the tunnel interface before the encryption process takes place. The picture below shows a GRE encapsulated packet.
GRE has added an IP header for transport. The source IP is the outside IP of the spoke and the destination IP is the hub or spoke outside IP for the other end of the tunnel. When using DMVPN and IPSec together, IPSec transport mode should be used to save on the overhead. The default is to use tunnel mode, so transport mode needs to be configured under the transform set. This will then save at least 16 bytes of overhead. It is common though to set the MTU to 1400 on the tunnel interface and to adjust the MSS of the LAN to 1360 bytes.
DMVPN Dual Tier Design
In very large DMVPN topologies, the DMVPN hub may become a choke point. Remember that the DMVPN hub is essentially a centralized control plane for the DMVPN topology. This is especially true in phase 1 networks where all traffic must pass through the hub and where no spoke to spoke tunnels are available. When using DMVPN and IPSec together, the hub must both handle NHRP, routing protocols and the encryption of packets even if the packets are going between two spokes. When traffic passes between two spokes in phase 1, the encrypted traffic will travel from spoke x to the hub to perform decryption, only to hairpin the packet and send it back out the same interface after encrypting it towards spoke z. This can put a very high load on the hub router.
To lessen the load of the hub router, it is possible to split the NHRP and routing protocols to one router and the crypto process to another router. This is demonstrated in the picture below.
The encryption and decryption of packets is now handled by the crypto headend router. It will then forward the GRE packets to the DMVPN hub which will terminate NHRP and routing protocols. How does this impact our design?
The IPSec tunnel endpoint is now different from the GRE tunnel endpoint. This means that we can’t use IPSec transport mode since it reuses the IP header. We need to use IPSec tunnel mode which adds a new IP header. The destination IP of the IPSec packet will then be the crypto headend router. This will add more overhead to our packets. This also means that we can’t use an IPSec protection profile because the crypto endpoint is now different from the GRE tunnel endpoint. This means that we need to use a static crypto map on the spokes. The crypto headend will use a dynamic crypto map.
It also means that spoke to spoke tunnels are not supported since all IPSec tunnels are now terminating on the crypto headend instead of forming tunnels directly between the spokes. This means that this design is mostly valid if we already run a large hub and spoke network without spoke to spoke tunnels and we need to scale the hub.
In my previous post I made a case for using DMVPN and GET VPN together. GET VPN uses a group SA which means that we don’t establish tunnels. We can combine the two technologies here to have a DMPVN hub and then have crypto headends acting as GMs. This design let’s us split the DMVPN hub and crypto headend responsibilities while still allowing for spoke to spoke tunnels. This link to another blog demonstrates how the two can be combined.
Really nice description of the challenges!
In true CCDE style, what you need now is a “simple” comparison table of the requirements vs the technologies which meet them to aid selection … 🙂
In a branch location(500 users) if we have primary as mpls and backup as dmvpn connection.is this best option to choose? What is the user limit to go with dmvpn?
That’s one of the options you can use. It depends on the use case and your applications and so on. DMVPN can scale to at least a few thousand spokes depending on hardware and routing protocol in use so 500 should be fine.
Pingback:CCDE Success: References Used – localpref.net
Nice writeup…I am doing some testing with 2 spokes both using a LTE Sim and they get a common public IP. In transport mode, While trying to form DMVPN tunnel with a hub, only 1 CPE is up but not the other. But when changed to tunnel mode both the CPE’s are able to establish DMVPN tunnel with hub. Just trying to understand if tunnel mode is the best mode in this kind of scenario and any other aspects that we need to consider other than the MTU increase?