What DMVPN Is and Why We Should Care

According to Cisco marketing, Dynamic Multipoint VPN (DMVPN) “will lower capital and operation expenses, simplifies branch communications, reduces deployment complexity, and improves business resiliency.” Okay. But what is it, really, and why should we care?

What is DMVPN?

DMVPN is a combination of features that help reduce some of the complexities of communications between a central location and multiple branch locations. It uses multipoint GRE (mGRE) and Next-Hop Resolution Protocol (NHRP) to help create a hub and spoke. Security may or may not be involved.

mGRE
Normally a GRE tunnel is a point-to-point interface with a defined source and destination. In a hub and spoke network, there would have to be n number of tunnel interfaces on the hub router for each of the spoke locations. With an mGRE tunnel, the hub router only needs to have a single tunnel interface, with n number of destinations. The issue is defining the destination or next hop of the tunnel; in walks NHRP.

NHRP
NHRP is defined in RFC 2332, which was defined to create a distributed mapping database of all spoke tunnels to a real address for NBMA networks. The hub router will act as a server of the registration of the spoke routers acting as clients. The configuration of the hub router is minimal, because the spokes are initiating the connections. Mapping must be configured from spoke to hub, but not the other way around. The hub will dynamically build the relationship based on the spoke’s initial requests. There has to be an underlying transport that will allow communication between the spokes and the hub.

Putting it together
Spokes have a dynamic permanent GRE tunnel to the hub, but not to other spokes. They register as clients of the NHRP server. When a spoke needs to send a packet to a destination (private) subnet behind another spoke, it queries the NHRP server for the real (outside) address of the destination spoke. Then the originating spoke can initiate a dynamic GRE tunnel to the target spoke (because it knows the peer address). The spoke-to-spoke tunnel is built over the mGRE interface.

What about security?
IPSec is not required for DMVPN, but it can be implemented over the mGRE tunnel. This would add the option of authenticating the source and encryption if so desired.

Why Should We Care?

There are a couple of compelling reasons to care about DMVPN.

First, in the real world, it will save on the configuration and overhead of the routers (and those of us who have to manage these devices).

For example, let’s say you have 250 different branch locations that would want to connect to a hub location. Without DMVPN, that would be 250 tunnel interfaces on the hub router, with each interface requiring something like seven lines of configuration code, which works out to be 1,750 lines of code on the hub router, plus configuring each spoke. Each spoke would have to be in a different subnet or use IP unnumbered. Every time you’d like to add another spoke, the hub router would need a new interface, and addressing would have to be set aside for the connection.

With DMVPN, the hub router has one tunnel interface with about 15 lines of code. The spoke would be in the same subnet, saving on address space. Adding additional spokes does not require any change to the hub router. That seems like a pretty reasonable rationale for using DMVPN.

Second, are single points of failure a concern? Then double all this with a second hub. With the traditional point-to-point type tunnel, the work just doubled. With DMVPN, it has doubled, but the overall impact is far less than the traditional method.

Finally, we should care about DMVPN because of CCIE Routing & Switching version 5.0. If you’re looking to achieve the latest version of the CCIE R&, you’ll notice on the version 5.0 blueprint that our traditional hub and spoke technology (Frame Relay) has been removed and DMVPN has been added. The hub and spoke topologies have always been interesting in the CCIE world, and using DMVPN enables us to continue with some of those interesting issues that arise with the routing protocols.

DMVPN Configuration

Let’s look at a single hub configuration. I am assuming an underlying network that allows the hub and spokes to be able to reach each other’s loopback interfaces.

R1: ! ! Hub router ! router ospf 123 router-id 10.0.0.1 network 10.0.0.0 0.255.255.255 area 0 ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Loopback 1 ip address 10.0.1.1 255.255.255.0 ! ! interface Tunnel0 ip address 10.0.0.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp network-id 124 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint
R2: ! ! Spoke Router ! router ospf 123 network 10.0.0.0 0.255.255.255 area 0 router-id 10.0.0.2 ! interface Loopback0 ip address 192.168.2.2 255.255.255.0 ! interface Loopback 1 ip address 10.0.2.2 255.255.255.0 ! interface Tunnel0 ip address 10.0.0.2 255.255.255.0 ip nhrp map 10.0.0.1 192.168.1.1 ip nhrp map multicast 192.168.1.1 ip nhrp network-id 123 ip nhrp nhs 10.0.0.1 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint ! ip route 0.0.0.0 0.0.0.0 Tunnel0
R3: ! ! Spoke Router ! router ospf 123 network 10.0.0.0 0.255.255.255 area 0 router-id 10.0.0.3 ! interface Loopback0 ip address 192.168.3.3 255.255.255.0 ! interface Loopback 1 ip address 10.0.3.3 255.255.255.0 ! interface Tunnel0 ip address 10.0.0.3 255.255.255.0 ip nhrp map 10.0.0.1 192.168.1.1 ip nhrp map multicast 192.168.1.1 ip nhrp network-id 123 ip nhrp nhs 10.0.0.1 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint ! ip route 0.0.0.0 0.0.0.0 Tunnel0

Note that the OSPF configuration is for traffic and routes through the tunnel. The tunnel interfaces will default to point-to-point for OSPF, so the network type will need to change to something that can support a hub and spoke configuration.

If you would like to support IPv6 across the DMVPN, the configuration doesn’t have to change too much other than adding the IPv6 pieces.

R1: ! ! Hub router ! router ospf 123 router-id 10.0.0.1 network 10.0.0.0 0.255.255.255 area 0 ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Loopback 1 ip address 10.0.1.1 255.255.255.0 ! ! interface Tunnel0 ip address 10.0.0.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp network-id 124 ipv6 address 2005:DEAD:BEEF:123::1/80 ipv6 nhrp map multicast dynamic ipv6 nhrp network-id 1 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint
R2: ! ! Spoke Router ! router ospf 123 network 10.0.0.0 0.255.255.255 area 0 router-id 10.0.0.2 ! interface Loopback0 ip address 192.168.2.2 255.255.255.0 ! interface Loopback 1 ip address 10.0.2.2 255.255.255.0 ! interface Tunnel0 ip address 10.0.0.2 255.255.255.0 ip nhrp map 10.0.0.1 192.168.1.1 ip nhrp map multicast 192.168.1.1 ip nhrp network-id 123 ip nhrp nhs 10.0.0.1 ipv6 address 2005:DEAD:BEEF:123::2/80 ipv6 nhrp map multicast dynamic ipv6 nhrp map multicast 192.168.1.1 ipv6 nhrp map 2005:DEAD:BEEF:123::1/80 192.168.1.1 ipv6 nhrp network-id 1 ipv6 nhrp nhs 2005:DEAD:BEEF:123::1 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint ! ip route 0.0.0.0 0.0.0.0 Tunnel0
R3: ! ! Spoke Router ! router ospf 123 network 10.0.0.0 0.255.255.255 area 0 router-id 10.0.0.3 ! interface Loopback0 ip address 192.168.3.3 255.255.255.0 ! interface Loopback 1 ip address 10.0.3.3 255.255.255.0 ! interface Tunnel0 ip address 10.0.0.3 255.255.255.0 ip nhrp map 10.0.0.1 192.168.1.1 ip nhrp map multicast 192.168.1.1 ip nhrp network-id 123 ip nhrp nhs 10.0.0.1 ipv6 address 2005:DEAD:BEEF:123::3/80 ipv6 nhrp map multicast dynamic ipv6 nhrp map multicast 192.168.1.1 ipv6 nhrp map 2005:DEAD:BEEF:123::1/80 192.168.1.1 ipv6 nhrp network-id 1 ipv6 nhrp nhs 2005:DEAD:BEEF:123::1 tunnel source Loopback0 tunnel mode gre multipoint tunnel key 123 ip ospf network point-to-multipoint ! ip route 0.0.0.0 0.0.0.0 Tunnel0
To add security to this configuration, you’ll need to configure at least one transform set, apply it to an IPSec security profile, and then apply the profile to the tunnel interfaces using the tunnel protection ipsec profile command.

Like any other technology, if you haven’t used it before, there can be some mystery or fear involved. But, as you can see, DMVPN isn’t all that bad. If you break it into its parts, it becomes very manageable, and the long-term benefits can be quite good.

Please support our Sponsors here :