One can accomplish similar goals with FlexVPN using designs that include IKEv2 and other things like Flex server/client and flex mesh, but that is not what we are doing here. But, doesn’t that make it FlexVPN? Not really. For this blog, we will be implementing the IPsec piece using IKEv2 as the key management protocol. While this is fine, IKEv2 is the up and coming thing, and offers some pretty cool new features.

Traditionally, most of us are probably used to dealing with IKEv1 and IPsec in conjunction with DMVPN. We will do an implementation using EIGRP to start, and then show an implementation using OSPF. R1 will have a single mGRE tunnel interface that allows it to connect to both spokes. In our DMVPN phase I design here, we will have a P2P GRE tunnel interface on both spokes R2 and R3 that terminate on the hub, R1. The overlay DMVPN network we are building through the physical infrastructure is the 192.168.123.0/24 neetwork For simplicity, the “public” GigabitEthernet1 interfaces of all the routers are on the same VLAN and subnet, 100.100.100.0/24. The topology diagram depicts the logical DMVPN overlay network we are trying to build here. R1 will act as our hub, while R2 and R3 will be spokes. This is the preferred method in a deployment requiring direct spoke to spoke tunnelsĪs you can see below, our lab topology is pretty straight forward. Allows for summarization at the hub, and for direct spoke-to-spoke tunnels even between spokes in different regions in a hierarchical design.

Phase III – Allows for direct spoke-to-spoke tunnels in a more scalable manner than phase II.

There are technical limitations and scalability challenges with phase 2, as it does not allow for route summarization at the hub, and in a hierarchical type design, inter-region spoke traffic must always transit the regional hubs

Phase II – Legacy design that allows for direct spoke-to-spoke tunnels.

This is less efficient for spoke to spoke communication, but forces all traffic through the hub, which may be what you want from a security perspective. All inter-spoke traffic must transit through the hub. Spokes have P2P GRE tunnels to the hub with statically defined tunnel destinations.

Phase I – Strictly a hub and spoke topology.It is assumed the reader is fairly familiar with these things already. This blog will not be an exhaustive technical overview of GRE, NHRP, IPsec, IGP routing, etc.

High availability designs that include multiple hubs are also possible and supported through a couple different well known designs. These tunnels can and usually are secured with IPsec. Depending on the implementation details, these tunnels can be between a remote spoke site and a main hub site, or actually between spokes themselves. It’s primary purpose is very generally speaking, to dynamically nail up overlay VPN tunnels across a (usually) public network infrastructure (like the internet). Dynamic multipoint VPN, or DMVPN as it is more affectionately known, is a matured, very densely deployed technology at this point. In this blog, we will take a look at DMVPN phase I, exploring what exactly it is, how it works, and configuring it in a lab environment.

Dmvpn lab ccnp