Orhan Ergun 3 Comments

DMVPN vs. GETVPN – In this post I am going to cover the similarities and the differences between GETVPN and the DMVPN.

For the DMVPN basics, please read this post.

Both technologies provide overlay virtual private network in general and I will use the below comparison table and the design attributes listed in it. For the more technology comparison tables please click here.




I will compare them from the Scalability aspects first and then will continue with the other design consideration listed in the table.

DMVPN vs. GETVPN Scalability : DMVPN is scalable Layer 3 overlay technology which has to run on top of any routing protocol. Any routing protocol can be an underlay. Routing protocols also need to run over the DMVPN tunnels for the private addresses reachability.

So two routing protocols are needed, one for DMVPN to work, another for the reachability of the private addresses.

When EIGRP and BGP runs over DMVPN tunnel, better scalability can be achieved compare to the other routing protocols. Of course the best routing protocol for the DMVPN scalability is BGP. But BGP requires BGP Route Reflector which adds more network complexity to the overall design.

On the other side GETVPN uses underlay routing protocol only. Its known as tunnelless VPN since between the end points tunnel is not needed. There is no routing protocol which run over the GETVPN. GETVPN provides only encryption between the endpoints. Since it doesn’t use overlay routing protocols for end point reachability but relies only on the underlay routing protocol for encryption as well as end point reachability, it is much more scalable compare to DMVPN.


DMVPN vs. GETVPN on Full Mesh and Hub and Spoke Topologies :

DMVPN spokes create a permanent spoke to hub tunnels. If the spoke to spoke communication is required then DMVPN Phase 2 and DMVPN Phase 3 provide this functionality. Spoke to spoke tunnels are on demand and when they are not used , they are teared down. For DMVPN to run on full-mesh topologies, most of the overlay routing protocols which run over DMVPN tunnels need to be tuned properly. This brings operational complexity. Also for the encryption point to point SA has to be created between each end nodes.

On the other side GETVPN doesn’t use point to point SA. Instead GETVPN uses Group Encryption method which provides excellent scalability for the encryption even on the full mesh topologies.

Both work well on Hub and Spoke topology but when encryption is needed on DMVPN, number of required IPSEC sessions on the Hub needs to be accounted very carefully.


DMVPN vs. GETVPN over Private WAN : Both of them can run over private WAN network such as MPLS Layer 2 or MPLS Layer 3 VPNs. DMVPN is setup over MPLS Layer 3 VPN. If the requirement is to run tens of VRFs over DMVPN tunnels, in order to scale the network, MPLS VPN over DMVPN should be configured. This architecture is known as 2547overDMVPN.


DMVPN vs. GETVPN over the Public Internet : DMVPN can be built over the Public Internet. DMVPN  Hub needs static IP address but DMVPN spokes don’t need static IP address. Dynamic Public IP address is enough for the spokes to create permanent spoke to Hub tunnels. Private end point addresses are advertised through the overlay routing protocols which run over the DMVPN tunnels.

On the other side, GETVPN cannot run over the Public Internet because of IP Header Preservation. GETVPN uses IPSEC transport mode tunnels and any NAT device on the path breaks the NAT. So GETVPN is limited to the private networks only and MPLS VPN is the most common topology which GETVPN is used with.


DMVPN vs. GETVPN Tunnel Requirement : DMVPN HUB always uses mGRE (Multipoint GRE) tunnels, spokes in DMVPN Phase 1 use regular point to point GRE tunnels. Spokes in DMVPN Phase 2 and DMVPN Phase 3 use also mGRE tunnels.

GET VPN doesn’t use any tunnels. It only requires end node reachability for example when GETVPN runs between two routers. only those two routers need to reach each other This is provided by the underlay routing protocols.


DMVPN vs. GETVPN Standardization : Both technologies are Cisco proprietary but GETVPN’s Group Encryption, so Multi point to Multipoint Security Association idea is supported by the other vendors as well. For example Juniper calls its technology as ‘ Group VPN ‘.


DMVPN vs. GETVPN Overlay Routing Protocol Support :  GETVPN doesn’t require overlay routing protocol as its said many times so far. On the other hand, DMVPN supports all the routing protocols as an overlay except IS-IS. IS-IS doesn’t run on top of Layer 3  and DMVPM only provides Layer 3 connectivity.


DMVPN vs. GETVPN QoS Support : DMVPN without per spoke tunnel QoS doesn’t provide good QoS. Because DMVPN Hub can send more traffic than DMVPN spokes can handle. That’s why QoS template is enabled per site and spokes link capacity is not overloaded by the DMVPN Hub. GETVPN uses underlay network infrastructure QoS setting. IP TOS byte is copied to the IPSEC Header. This is known as IP TOS Byte preservation.


DMVPN vs. GETVPN Security : Both technologies provide IPSEC encryption but DMVPN is not scalable as DMVPN since for the DMVPN, between each pair of nodes separate IPSEC SA is created. GETVPN uses Key Servers to push the encryption keys and the group polices to the Group Member which are just the routers and all the group members use same IPSEC SA. It provides much better security scalability.


DMVPN vs. GETVPN Multicast Support : Last but definitely not least, When it comes to Multicast support, GETVPN always win. When 50Mb Multicast traffic need to be sent to the spokes, it needs to be replicated by the DMVPN Hub to all the interested DMVPN spokes.

This is not efficient way of doing Multicast for sure. You will put more pressure to the DMVPN HUB which is already doing many tasks such as NHRP Operations, QoS Handling , IPSEC Operations and so on.

Also ‘ ip pim nbma-mode ‘ should be enabled at the DMVPN HUB otherwise when the PIM prune comes from any spoke sites, all multicast traffic is stopped for the particular Multicast Group since DMVPN Hub doesn’t track the IP Addresses of the interested first hop routers before this comment.

On the other side, GETVPN uses underlay infrastructure for the Multicast Operation. If ASM is used, Randevous Point is configured for the infrastructure and GETVPN also uses it. If SSM is used as a Multicast routing architecture, then GETVPN gets benefit of source based, shortest path tree.

If Multicast is heavy and you have MPLS network, and the encryption is pushed by management or maybe regulatory requirements don’t even bother with DMVPN, start looking GETVPN design documents and when you stuck contact me from orhan@orhanergun.net

0.00 avg. rating (0% score) - 0 votes
  • Jaffer Razvi

    Couple of items to mention. You can run GETVPN over public infrastructure if you run it over LISP overlay (See lisp.cisco.com), works relatively well. When you use LISP overlay with GETVPN, you can also create a key VRF overlay then source client registration against it . . . ultimately build a multi-tenant VPN environment using the same or different key server. So technically, you do not need to run two different technologies DMVPN/FlexVPN on the public and GETVPN on the inside (MPLS/Private). There is a GETVPN interoperability feature, the documentation looks like you can mix it with Juniper devices, see the following link:


    You can also use GDOI based DMVPN, its fairly well documented:


    Newer versions of code also support GETVPN with IKEv2.

    Best regards,

    • Thanks Jaffer for the comment, there is no need to LISP for that reason, you can run it over many overlays, but not directly over Internet as I stated in the article. LISP instance ID would give the similar capabilities like MPLS labels so you could carry many VRF so it could be scalable as well but since it is not standard, not supported by even many equipments of Cisco or require special hardware. I like LISP for host mobility use case, maybe even for Internet multihoming, but for scalable overlay alternative, No no.. Even when I tried it for one customer year back, there was many hardware requirement, it was not stable etc. Nothing like as on the paper..

      • Jaffer Razvi

        You are probably referring to newer modules required on the Nexus/Catalyst 6500, I haven’t used it for mobility because there is not a strong use case even though we do use OTV (Maybe add it later), this all from the enterprise perspective not SP. It is also fairly new on the 6500s too, I cannot comment on these platforms however on the IOS XE platform on the ASR1000/ISR4400, its fairly robust for us, DDT is a possibility in the long run.