Thank you. That is exactly what I was looking for. One question, the document say:Tom
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.
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 is the most common topology which GETVPN is used with.
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.
Both of them can run over private WAN network such as MPLS Layer 2 or MPLS Layer 3 VPNs. DMVPN is setup over . 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.
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 runover 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.
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:
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.
If 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 email@example.com
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 cisco getvpn over internet DMVPN tunnels.
GET is a new technology - to be honest I would wait a while until all the bugs have been fixed.JMPTW.
Tom,PS. If you found my posts helpful, please rate them.