Created by - Orhan Ergun
DMVPN - Dynamic Multipoint VPN and MPLS VPN are two of the most popular VPN mechanisms. In this post, we will look at DMVPN vs MPLS VPN comparison, from many different aspects. At the end of this post, you will be more comfortable positioning these private VPN mechanisms. DMVPN vs MPLS VPN When we compare the two protocols, we look at many different aspects. For this comparison, I think very first we should say that DMVPN is a Cisco preparatory tunnel-based VPN mechanism but MPLS VPN is standard-based, RFC 2547, non-tunnel based VPN mechanism. Although, whether MPLS LSP is a tunnel or not is an open discussion in the networking community, we won't start that discussion here again. DMVPN and MPLS VPN over the Internet Another important consideration for MPLS VPN vs DMVPN is, that DMVPN can be set up over the Internet but MPLS VPN works over private networks, Layer 2 or Layer 3 based private networks. DMVPN tunnels can come up over the Internet and inside the tunnels routing protocols can run to advertise the Local Area Networks subnets. But MPLS requires Private network underlay. Figure - DMVPN Networks can run over Internet or Private Networks DMVPN vs MPLS VPN Security Both VPN mechanisms don't come with encryption by default. Many people wrongly know that DMVPN comes with the IPSEC. In fact, it is wrong. There is only two standard-based technology for DMVPN, they are mandatory for DMVPN. These are; MGRE - Multipoint GRE and NHRP - Next Hop resolution protocol. IPSEC is optional for the DMVPN. Same for the MPLS VPN. IPSEC or GETVPN can run over MPLS VPN but they don't come together with the MPLS VPN, which means that MPLS VPN doesn't require IPSEC or GETVPN for its operation This is true for the DMVPN as well. It doesn't require either of them. Last but not least for the security of the MPLS vs DMVPN, GETVPN can provide the most scalable encryption method for both MPLS VPN as well as DMVPN. MPLS over DMVPN MPLS can run over DMVPN. The reason for it is to create even more scalable VPNs over DMVPN. Without MPLS, if there are many different business units that need to communicate river DMVPN, to segment those business units' network traffic, many different tunnels would be required. With MPLS VPN over DMVPN, which is commonly known as 2547 over DMVPN method, we don't need to create multiple DMVPN tunnels, but with just 1 single DMVPN tunnel, we can carry many different business units by segmenting their traffic in a scalable manner. DMVPN over MPLS VPN DMVPN can run over MPLS VPN as well. So, DMVPN doesn't only run over the Internet but the underlay network for DMVPN can be an MPLS network. In this case, DMVPN tunnel endpoint reachability is provided by the underlay MPLS VPN network. Underlay MPLS network can be MPLS Layer 2 VPN or MPLS Layer 3 VPN. In both cases, MPLS VPNs can provide reachability between the DMVPN Hub and Spokes. So far all this information about MPLS VPN vs DMVPN is applicable for every DMVPN Phase, DMVPN Phase 1, DMVPN Phase 2, and DMVPN Phase 3.
Published - Mon, 18 Apr 2022
Created by - Orhan Ergun
DMVPN Basics- In this article you will learn about the DMVPN design along with various IGP protocols such as EIGRP,OSPF and BGP. I am explaining this topic in deep detail in my Instructor Led CCDE and Self Paced CCDE course. DMVPN uses two major technologies for its operation : NHRP Next Hop Resolution Protocol mGRE Multipoint GRE In this post I will explain all the basics of Cisco DMVPN. Detailed routing protocol design over DMVPN will be covered in a different post which will be published in a few days. Let’s use the topology below to understand the specific pieces of DMVPN. The picture below has been received from cisco.com. Figure-1 Cisco DMVPN ArchitectureThree different address types are used in DMVPN. 1. Public – NBMA – Underlay address : All these terms can be used interchangeably and refers to a static known address on the hub and a dynamic or static address on the spokes. This address is used to bring up the tunnels. The underlay addresses of HUB and spoke must be reachable. If a spoke to spoke tunnel is created, spoke to spoke underlay (BGP between Service Providers) addresses must be reachable as well. If you are using DMVPN over Internet, the remote location reaches to its local service provider and service providers use BGP for public-NMBA-underlay DMVPN address reachability. Dynamic NAT (Network Address Translation) is allowed on the spokes. 2. Private – Tunnel – Overlay address : You may see one of these addresses in different resources, but all refer to the same thing. They are used interchangeably. In a single DMVPN cloud, one big tunnel subnet is used. Spokes register their private to public address mapping to Hub which is the Next Hop Server with the NHRP register message. For those who are familiar with LISP (Locator and Identity Separation Protocol), this operation is very similar to a Mapping database. LISP is out of the scope of this post. All the routing protocols ( RIP, EIGRP, OSPF, PIM, BGP) can be used over the overlay tunnels, except for IS-IS ! IS-IS doesn’t run over IP but uses layer2 (IS-IS has an ether type), so IS-IS can not be used over DMVPN. 3. Remote or Local address : This address is used in the local area and advertised through the routing protocol over the overlay DMVPN tunnel. In the topology above, spokes or remote sites register to the hub via NHRP protocol. The NHRP register message is used for spokes to register their underlay to overlay address mapping. DMVPN hub knows all the public IP to tunnel IP mapping before the routing protocol starts to advertise local addresses. DMVPN supports IPv4 and IPv6 unicast and multicast transport through the overlay tunnels. DMVPN also supports IPv4 and IPv6 transport through the underlay, which might be Internet or MPLS VPN. DMVPN can be used without IPsec encryption. IPsec is not mandatory for the DMVPN operation,but most if not all of the networks use IPsec with DMVPN. For large-scale DMVPN deployments, GETVPN can be used to encrypt the tunnels. Since HUB would create crypto key for each spoke separately,with IPSEC, with its group key capabilities, GET VPN provides excellent scaling if the encryption is the needed. DMVPN has three Phases. Phases 1, 2 and 3. Phasse 1 and 2 are made obsolete, by Phase 3, but I will explain how DMVPN works in Phase 1 and 2 as well. DMVPN Phase 1 : Spokes use Point to Point GRE but Hub uses a multipoint GRE tunnel. A mGRE tunnel simplifies configuration greatly on the Hub. Spokes have to specify the tunnel destination as Hub since they run P2P GRE tunnel not mGRE in DMVPN Phase 1. Summarization is allowed from the Hub down to spokes. The Hub can only send default route as well ,since the remote spokes next hop is not preserved by the Hub. Hub changes the IGP next hop to itself hence spoke to spoke traffic passes through the Hub. Spoke to spoke tunnel cannot be created in DMVPN Phase 1. In the topology above, for the 192.168.2.0/24 network behind Spoke 2, next hop is the tunnel IP of the HUB in the routing table of Spoke 1, not the tunnel IP of the Spoke 2. Thus, the data plane traffic always passes through Spoke 1 – Hub – Spoke 2 with this topology in DMVPN Phase 1. Why would you want to design DMVPN with Phase 1? You may want to bring all the traffic to your centralised place where all your security devices are located. You can filter unwanted traffic between the spokes first. Imagine you are using DMVPN over the Internet. After you create a DMVPN network, spoke to spoke communication, or a centralised shared services devices will be reachable through the Hub and traffic can be filtered before reaching the destinations. Spokes can use their local router for Internet traffic. Internet traffic doesn’t have to go the HUB. Although Phase 1 is obsolete and, as we will see, Phase 3 gives better scalability and feature sets, it still might be used. It provides excellent scalability for the routing compared to Phase 2. If you are using DMVPN over IPSEC, since the HUB router needs to encrypt and decrypt packets twice, Phase 1 with IPSEC reduces the overall scalability. DMVPN operation is very similar to the Ethernet ARP process. The difference is Ethernet is Broadcast Multiaccess, DMVPN is a Non Broadcast Multiaccess (NBMA). DMVPN Phase 2:Spoke to spoke dynamic on demand tunnels are first introduced in Phase 2. In contrast to Phase 1, mGRE (Multipoint GRE, not Multicast) is used in Phase 2. Thus, spokes don’t require tunnel destination configuration under the tunnel interface and tunnel mode is configured as ” Multipoint Gre”. Spoke to spoke traffic doesn’t have to go through the HUB. Spokes can trigger on demand tunnel between them. The biggest disadvantage of Phase 2 is, each spoke has to have all the Remote – LAN subnets of each other since the Hub, preserves the next hop of spokes. In the topology above, for the 192.168.2.0/24 network behind the Spoke 2, Spoke 1 has the tunnel interface (Private-Overlay) address of Spoke 2 as a next hop. In Phase 1, hub is the next hop. Thus, spokes have to have a reachability to the tunnel addresses of each other. This disallows the summarization or default routing from Hub down to the spokes. This is a serious design limitation for the large scale DMVPN networks. For the distance vector protocols, Split horizon needs to be disabled and “no next-hop self” should be enabled on the HUB. These are serious design limitations for the link state protocols that I will explain later in this post. DMVPN Phase 3: Spoke to spoke dynamic tunnels are allowed. Spokes don’t have to have the next hop of each other’s private address for the local subnets. 192.168.2.0/24 network behind the Spoke 2, has a next hop as HUB in the routing table of Spoke1. An NHRP redirect message is sent to the spokes to trigger spoke to spoke tunnels. Hub tells, Spoke 2 that Spoke 1 wants to communicate, and provides the Public-Underlay-NBMA address of Spoke 1 in the above topology. Spokes have an NHRP Shortcut. Which means, even in the routing table of Spoke 1, the tunnel IP address of HUB is the next hop for the 192.168.2.0/24 behind the Spoke 2, and the FIB table of Spoke1 has the private-tunnel address of Spoke 2 as a next hop. Since the next hop in the routing table of the spokes is HUB’s tunnel address, spokes don’t have to have the specific next hop information of each other. This allows summarization and default routing in Phase 3. Hub can send a summary or just a default route down to the spokes. Hence, Phase 3 can scale extremely.
Published - Tue, 05 Apr 2022