Dynamic Multipoint VPN (DMVPN) Configuration

DMVPN (Dynamic Multipoint VPN) is a technique where we use multipoint GRE tunnels instead of GRE point-to-point tunneling. These multipoint GRE tunnels will be encrypted using IPSEC so that we have a secure scalable tunneling solution. If you are unfamiliar with tunneling or IPSEC I highly recommend to check the basic configuration for GRE first and how to configure an encrypted GRE tunnel with IPSEC. Having said that let’s look at the configuration of DMVPN. This is the topology that we will use:

Let me explain this topology to you:

·         R1,R2 and R3 are able to reach each other using their FastEthernet 0/0 interfaces. I used the 192.168.123.0 /24 subnet so that they can reach each other.

·         R1 will be the hub router and R2/R3 will be the spoke routers.

·         R2 and R3 will establish a tunnel to R1 as shown with the green dotted line.

·         When R2 and R3 want to communicate with each other they will create a spoke-to-spoke tunnel as shown with the purple dotted line.

·         We will use the 172.16.123.0 /24 subnet for the tunnel interfaces.

·         Each router has a loopback interface with an IP address. The routers will reach each others loopback by going through the tunnel interface.

The configuration consists of a number of steps:

1.       Basic configuration of IP addresses.

2.       GRE Multipoint Tunnel configuration on all routers

3.       Encryption of tunnels using IPSEC.

4.       Routing configuration so the routers can reach each others loopback interfaces.

Let’s get started!

Basic configuration

First we’ll configure the IP addresses on all routers:

R1(config)#interface fa 0/0

R1(config-if)#no shutdown

R1(config-if)#ip address 192.168.123.1 255.255.255.0

R1(config)#interface loopback 0

R1(config-if)#ip address 1.1.1.1 255.255.255.255

R2(config)#interface fa 0/0

R2(config-if)#no shutdown

R2(config-if)#ip address 192.168.123.2 255.255.255.0

R2(config)#interface loopback 0

R2(config-if)#ip address 2.2.2.2 255.255.255.255

R3(config)#interface fa 0/0

R3(config-if)#no shutdown

R3(config-if)#ip address 192.168.123.3 255.255.255.0

R3(config)#interface loopback 0

R3(config-if)#ip address 3.3.3.3 255.255.255.255

With the IP addresses configured we can continue by setting up the tunnels.

GRE Multipoint Configuration

First we will configure the hub router:

R1(config)#interface tunnel 0

R1(config-if)#ip address 172.16.123.1 255.255.255.0

R1(config-if)#tunnel mode gre multipoint

R1(config-if)#tunnel source fastEthernet 0/0

R1(config-if)#ip nhrp map multicast dynamic

R1(config-if)#ip nhrp network-id 1

R1(config-if)#ip nhrp authentication DMVPN

We will configure an IP address on the tunnel 0 interface and instead of specifying a destination IP address we will configure it as gre multipoint. If you want to use a routing protocol like RIP, OSPF or EIGRP you require the ip nhrp map multicast dynamic command to automatically add routers to the multicast NHRP mappings. For each DMVPN setup you require an unique network ID that you can configure with the ip nhrp network-id command. Last but not least, the ip nhrp authentication command enables a password for NHRP queries. I’ve set the password to ‘DMVPN’.

Now let’s configure our spoke routers, R2 and R3:

R2(config)#interface tunnel 0

R2(config-if)#ip address 172.16.123.2 255.255.255.0

R2(config-if)#tunnel mode gre multipoint

R2(config-if)#ip nhrp authentication DMVPN

R2(config-if)#ip nhrp map 172.16.123.1 192.168.123.1

R2(config-if)#ip nhrp map multicast 192.168.123.1

R2(config-if)#ip nhrp network-id 1

R2(config-if)#ip nhrp nhs 172.16.123.1

R2(config-if)#tunnel source fastEthernet 0/0

Above you can see a number of commands that we didn’t configure on the hub router. We use the ip nhrp map command to map the IP address of the NHS (Next Hop Server) to the outside IP address. In this case 172.16.123.1 is the IP address on the tunnel interface of R1 and 192.168.123.1 is the outside IP address of R1. We also require the ip nhrp nhs command to set the IP address of the NHS.

The ip nhrp map multicast commands configures the spoke router to send multicast traffic only to the hub router, not to other spoke routers.

As the source of the tunnel I specified the FastEthernet 0/0 interface with the tunnel source command. It’s best to specify the interface as the source and not an IP address in case you are using dynamic IP address on the spoke router.

If everything went ok you should see a tunnel coming up on R2:

R2#  

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Let’s configure R3 which is pretty much the same as R2:

R3(config)#interface tunnel 0

R3(config-if)#ip address 172.16.123.3 255.255.255.0

R3(config-if)#tunnel mode gre multipoint

R3(config-if)#ip nhrp authentication DMVPN

R3(config-if)#ip nhrp map 172.16.123.1 192.168.123.1

R3(config-if)#ip nhrp map multicast 192.168.123.1

R3(config-if)#ip nhrp network-id 1

R3(config-if)#ip nhrp nhs 172.16.123.1

R3(config-if)#tunnel source fastEthernet 0/0

The configuration is the same with the exception of the IP address on the tunnel interface. The tunnel should come up now:

R3#

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Right now you should have a working multipoint GRE configuration so it’s wise to check this before you continue configuring IPSEC.

Verification of GRE Multipoint Configuration

First we will check the hub router:

R1#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1   192.168.123.2    172.16.123.2    UP    never D   

     1   192.168.123.3    172.16.123.3    UP    never D

Above you see that R1 is the hub router and that is has two peers. There’s a couple of interesting items that we can find here:

·         Ent stands for the number of entries in the NHRP database for this spoke router. Normally you will only see 1 entry here.

·         Peer NBMA Addr is the IP address on the outside interface of the spoke router, in our example 192.168.123.2 and 192.168.123.3.

·         Peer Tunnel Add is the IP address on the tunnel interface of the spoke router.

·         State shows if your tunnel is up or down.

·         UpDn Tm is the up or down time of the current state (up or down). You will see the time here once we are using the tunnels.

·         Attrb means attributes. You can see them at top of the show command. The D stands for dynamic which you will normally see for spoke routers.

Let’s use the same command on the spoke routers:

R2#show dmvpn  

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1   192.168.123.1    172.16.123.1    UP 00:43:44 S

R3#show dmvpn      

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1   192.168.123.1    172.16.123.1    UP 00:46:58 S 

Right now the spoke routers only have a tunnel that connects to the hub router. Let’s try if we can ping from one router to another…

R2#ping 172.16.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

R3#ping 172.16.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

Both spoke routers are able to reach the hub. Now let’s try to ping between the two spoke routers:

R2#ping 172.16.123.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms

The ping is working and this is the interesting part of multipoint GRE. The spoke routers will dynamically create a tunnel between each other as you can see below:

R2#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1   192.168.123.1    172.16.123.1    UP 00:01:41 S   

     1   192.168.123.3    172.16.123.3    UP    never D

R3#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1   192.168.123.1    172.16.123.1    UP 00:01:42 S   

     1   192.168.123.2    172.16.123.2    UP    never D

As you can see another tunnel has been established between R2 and R3. So far so good, multipoint GRE is working but everything is clear text at the moment. It’s time to configure IPSEC to encrypt the tunnels!

Configure IPSEC to encrypt mGRE Tunnels

I’m not going to cover the details of IPSEC, if you don’t know what all the commands are used for, look at the encrypted GRE tunnel with IPSEC article I wrote earlier.

R1,R2 & R3:

(config)#crypto isakmp policy 1

(config-isakmp)#encryption aes

(config-isakmp)#hash md5

(config-isakmp)#authentication pre-share

(config-isakmp)#group 2

(config-isakmp)#lifetime 86400

(config)#crypto isakmp key 0 NETWORKLESSONS address 0.0.0.0

(config)#crypto ipsec transform-set MYSET esp-aes esp-md5-hmac

(config)#crypto ipsec profile MGRE

(ipsec-profile)#set security-association lifetime seconds 86400

(ipsec-profile)#set transform-set MYSET

(config)#interface tunnel 0

(config-if)#tunnel protection ipsec profile MGRE

When you configure the crypto isakmp key you should use IP address 0.0.0.0 if you are using dynamic IP addresses on spoke routers. 0.0.0.0 means it applies to any IP address. Let’s verify if our traffic is encrypted or not…

Verification of IPSEC encrypted tunnels

Just to be sure, do a shut/no shut on the tunnel interfaces after the configuration of IPSEC.

R1,R2 & R3:

(config)#interface tunnel 0

(config-if)#shutdown

(config-if)#no shutdown

Next step is to check if IPSEC is active:

R1#show crypto session

Crypto session current status

Interface: Tunnel0

Session status: UP-ACTIVE     

Peer: 192.168.123.2 port 500

  IKE SA: local 192.168.123.1/500 remote 192.168.123.2/500 Active

  IPSEC FLOW: permit 47 host 192.168.123.1 host 192.168.123.2

        Active SAs: 2, origin: crypto map

Interface: Tunnel0

Session status: UP-ACTIVE     

Peer: 192.168.123.3 port 500

  IKE SA: local 192.168.123.1/500 remote 192.168.123.3/500 Active

  IPSEC FLOW: permit 47 host 192.168.123.1 host 192.168.123.3

        Active SAs: 2, origin: crypto map

As you can see IPSEC is active for both peers. Let’s send some pings to verify if traffic is encrypted or not:

R2#ping 172.16.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

R3#ping 172.16.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Let’s see if packets are encrypted:

R1#show crypto ipsec sa

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 192.168.123.1

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (192.168.123.2/255.255.255.255/47/0)

   current_peer 192.168.123.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26

    #pkts decaps: 26, #pkts decrypt: 26, #pkts verify: 26

As you can see packets in the tunnel are encrypted. There is only one more item for us to configure and that is routing.

DMVPN routing configuration

Our tunnels are up and running and encrypted but the routers are unable to reach each others loopback interfaces because we didn’t configure any routing yet. There are two options:

·         Static routing

·         Dynamic routing

Static routing is easy, just make sure you use the IP address on the tunnel interfaces as the next hop IP address for your static routes. I’ll give you an example how to configure OSPF:

R1(config)#router ospf 1

R1(config-router)#network 1.1.1.1 0.0.0.0 area 0

R1(config-router)#network 172.16.123.0 0.0.0.255 area 0

R1(config)#interface tunnel 0

R1(config-if)#ip ospf network broadcast

R2(config)#router ospf 1

R2(config-router)#network 2.2.2.2 0.0.0.0 area 0

R2(config-router)#network 172.16.123.0 0.0.0.255 area 0

R2(config)#interface tunnel 0

R2(config-if)#ip ospf priority 0

R2(config-if)#ip ospf network broadcast

R3(config)#router ospf 1

R3(config-router)#network 3.3.3.3 0.0.0.0 area 0

R3(config-router)#network 172.16.123.0 0.0.0.255 area 0

R3(config)#interface tunnel 0

R3(config-if)#ip ospf priority 0

R3(config-if)#ip ospf network broadcast

When configuring OSPF for DMVPN there are a number of things you have to consider:

·         Earlier we used the ip nhrp map multicast command on the spoke routers which means that the spoke routers can only send OSPF hellos to the hub router. This means we’ll have an OSPF hub and spoke topology and the spoke routers should never become the DR or BDR.

·         I’m using the OSPF broadcast network type so that the spoke routers will use each others IP addresses as the next hop IP address. If you have no idea what this means you should read my OSPF Next Hop IP Address with different network types article.

Let’s verify our work!