DMVPN (dynamic multipoint virtual private network) is a design approach that allows full mesh connectivity with the use of multipoint GRE tunnels. DMVPN itself is not a protocol but rather it is a design approach that consists of the following technologies:
- NHRP (next-hop resolution protocol)
- mGRE(multipoint GRE)
- Routing protocol
- IP sec encryption (optional)
Most of these technologies are familiar to networking professionals, except for the NHRP protocol. NHRP is a resolution protocol that behaves like ARP. In an NHRP environment, there are two roles, the NHS (next-hop server) and the NHC (next-hop client). The NHCs register themselves with the NHS and provide information, such as their logical VPN IP addresses and the physical NBMA mapping. The NHCs also request information from the NHS about how to reach the other NHCs by learning the logical IP to NBMA mapping information. NHRP was used before in the legacy overlay VPN environment particularly in building frame-relay SVCs (switched virtual circuits). Today the protocol is used in the DMVPN environment as well using the same behavior.
DMVPN is typically deployed using MPLS and Internet services because DMVPN has the capability to build dynamic tunnels to other spokes or branches without going through the hub site. This makes efficient use of the full mesh topologies mentioned above. If DMVPN is deployed using the Internet, the hub router requires a static public IP address as this will be configured in the NHC routers as the NHS IP address. The spokes don’t require a static public IP address as a tunnel source because they will report their physical IP to logical mappings to the NHS or the hub. In an MPLS environment, using the IP address of the Loopback is an acceptable design. DMVPN provides zero-touch configuration on the hub router if a new spoke is added.
DMVPN has so far three phases of evolution: Phase 1 had only hub-and-spoke, in Phase 2 direct spoke-to-spoke capability for DMVPN was added, and Phase 3 has features that help a hierarchical DMVPN design scale better through the use of NHRP Shortcut and other enhancements. Our lab will focus on more on Phase 2.
In this GNS3 Lab, we will have the following tasks below. Verification will be done for each of the steps.
- Configure DMVPN on the hub router R1.
- Configure spokes R2, R3 and R4.
- Configure EIGRP as the routing protocol and enable spoke-to-spoke tunnels. Add Loopback10 to each of the routers and announce it in EIGRP.
- Configure encryption.
Below are the physical and logical diagrams.
Figure 1. Network Topology
Figure 2. DMVPN Topology
Task 1: Configure DMVPN on the Hub Router R1
The MPLS router in the GNS3 topology has already been pre-configured to peer with all the routers using BGP. The routers in this topology are already announcing their Loopback0s through BGP. Before proceeding with the configuration, let’s check if we can see the loopback IP addresses of all the routers from R1.
R1#sh ip bgp BGP table version is 5, local router ID is 220.127.116.11 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 18.104.22.168/32 0.0.0.0 0 32768 i *> 22.214.171.124/32 126.96.36.199 0 65000 65002 i *> 188.8.131.52/32 184.108.40.206 0 65000 65003 i *> 220.127.116.11/32 18.104.22.168 0 65000 65004 i
Then we configure Tunnel100 with the DMVPN configuration for hub routers.
R1(config)#int tun100 R1(config-if)#ip add 10.1.1.1 255.255.255.0 R1(config-if)#ip nhrp map multicast dynamic R1(config-if)#ip nhrp authentication cisco R1(config-if)#ip nhrp network-id 100 R1(config-if)#tunnel source Loopback0 R1(config-if)#tunnel mode gre multipoint R1(config-if)#tunnel key 100
Let’s break down the commands one by one.
ip nhrp map multicast dynamic: Normally this is configured in the hub routers to allow NHRP to automatically add routers to the multicast NHRP mappings so a static mapping is not required any more for each of the spokes. This command also enables routing protocols to work over the mGRE.
ip nhrp authentication <string>: This is an optional command. All the routers with NHRP within the same DMVPN network must have the same string or password.
ip nhrp network-id <number>: This is a required command to start NHRP. All routers in the same NHRP network should have the same network-id. This can also be used along with the “tunnel key” command to segregate different DMVPN networks using the same interface/ IP address as the tunnel source.
tunnel source Loopback0: This is the “physical” or real IP address which the tunnel should be sourced from. In the typical GRE configuration, a tunnel destination is required, but in DMVPN the tunnel destination is resolved through NHRP.
tunnel mode gre multipoint: Sets the GRE tunnel to behave as a multipoint tunnel.
tunnel key <number>” Like “ip nhrp network-id,” this allows separation of DMVPN networks using the same interface/ IP address as the source of the tunnel. This was mandatory in the previous IOS versions but, for the most recent ones, the DMVPN tunnel can come up without this command.
Task 2: Configure Spokes R2, R3 and R4
Let’s proceed to configure DMVPN on the spokes and explain each command later. The spokes will have a different command set than that of the hub.
R2(config)#interface Tunnel100 R2(config-if)# ip address 10.1.1.2 255.255.255.0 R2(config-if)# ip nhrp map multicast 22.214.171.124 R2(config-if)# ip nhrp map 10.1.1.1 126.96.36.199 R2(config-if)# ip nhrp nhs 10.1.1.1 R2(config-if)# ip nhrp network-id 100 R2(config-if)# ip nhrp registration timeout 60 R2(config-if)# ip nhrp holdtime 120 R2(config-if)# ip nhrp authentication cisco R2(config-if)# tunnel source Loopback0 R2(config-if)# tunnel mode gre multipoint R2(config-if)# tunnel key 100 R3(config)#interface Tunnel100 R3(config-if)# ip address 10.1.1.3 255.255.255.0 R3(config-if)# ip nhrp map multicast 188.8.131.52 R3(config-if)# ip nhrp map 10.1.1.1 184.108.40.206 R3(config-if)# ip nhrp nhs 10.1.1.1 R3(config-if)# ip nhrp network-id 100 R3(config-if)# ip nhrp registration timeout 60 R3(config-if)# ip nhrp holdtime 120 R3(config-if)# ip nhrp authentication cisco R3(config-if)# tunnel source Loopback0 R3(config-if)# tunnel mode gre multipoint R3(config-if)# tunnel key 100 R4(config)#interface Tunnel100 R4(config-if)# ip address 10.1.1.4 255.255.255.0 R4(config-if)# ip nhrp map multicast 220.127.116.11 R4(config-if)# ip nhrp map 10.1.1.1 18.104.22.168 R4(config-if)# ip nhrp nhs 10.1.1.1 R4(config-if)# ip nhrp network-id 100 R4(config-if)# ip nhrp registration timeout 60 R4(config-if)# ip nhrp holdtime 120 R4(config-if)# ip nhrp authentication cisco R4(config-if)# tunnel source Loopback0 R4(config-if)# tunnel mode gre multipoint R4(config-if)# tunnel key 100
Let’s break down and discuss each of the commands.
ip nhrp map multicast <22.214.171.124>: To put it simply, this command adds the NBMA address, in our case the loopback address of R1, to be a recipient of multicast/broadcast traffic coming from this spoke. The source IP address of the hub router’s DMVPN tunnel is configured as well as the other hub IP address if the design should go for multiple hubs.
ip nhrp map <10.1.1.1> <126.96.36.199>: To put it simply, this command states that 188.8.131.52 is the NBMA or real IP address of R1’s tunnel IP address of 10.1.1.1.
ip nhrp nhs <10.1.1.1>: This basically tells the router that the NHS is 10.1.1.1. This is the tunnel IP address of the hub router R1 in our example. The router will know who to consult to if it wishes to form a spoke-to-spoke tunnel. Multiple NHS configurations can be made if there are multiple hubs in the DMVPN network.
The rest of the NHRP commands are self-explanatory. The network-id and tunnel key in the spokes should match what is configured in the hub router.
Task 3: Configure EIGRP as the routing protocol and enable spoke-to-spoke tunnels. Add Loopback10 to each of the routers and announce it in EIGRP.
Let’s enable EIGRP and announce the DMVPN network. Any routing protocol can be used, but EIGRP or OSPF are favorable in most designs. One thing to look out for is that for DMVPN spoke-to-spoke to work and bypass the hub, the next-hop IP address of the route should be unchanged, meaning it should not be the IP address of the hub’s tunnel but should be the corresponding spoke tunnel IP address. In OSPF, changing the interface network type to “broadcast” is the solution. EIGRP requires split-horizon to be disabled and next-hop-self on the hub router.
R1(config-if)#interface Loopback10 R1(config-if)#ip address 184.108.40.206 255.255.255.255 R1(config)#router eigrp 100 R1(config-router)#no auto-summary R1(config-router)#network 10.1.1.0 0.0.0.255 R1(config-router)#network 220.127.116.11 0.0.0.0. ! R1(config-if)#int tun100 R1(config-if)#no ip split-horizon eigrp 100 R1(config-if)#no ip next-hop-self eigrp 100 ! R2(config)#int lo10 R2(config-if)#ip address 18.104.22.168 255.255.255.255 R2(config-if)#router eigrp 100 R2(config-router)#network 22.214.171.124 0.0.0.0 ! R3(config-if)#int l10 R3(config-if)#ip address 126.96.36.199 255.255.255.255 R3(config-if)#router eigrp 100 R3(config-router)#network 188.8.131.52 0.0.0.0 ! R4(config-if)#int l10 R4(config-if)#ip address 184.108.40.206 255.255.255.255 R4(config-if)#router eigrp 100 R4(config-router)#network 220.127.116.11 0.0.0.0
Let’s check and verify EIGRP neighbor adjacencies and routes:
R1#sh ip eigrp ne IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 10.1.1.4 Tu100 14 00:03:18 79 474 0 7 1 10.1.1.3 Tu100 12 00:04:42 76 456 0 6 0 10.1.1.2 Tu100 14 00:04:42 66 396 0 5 R1#sh ip route eigrp 18.104.22.168/32 is subnetted, 1 subnets D 22.214.171.124 [90/14208000] via 10.1.1.3, 00:01:24, Tunnel100 126.96.36.199/32 is subnetted, 1 subnets D 188.8.131.52 [90/14208000] via 10.1.1.2, 00:02:58, Tunnel100 184.108.40.206/32 is subnetted, 1 subnets D 220.127.116.11 [90/14208000] via 10.1.1.4, 00:00:44, Tunnel100
Let’s check how many NHRP entries before we ping 18.104.22.168 from R2, using 22.214.171.124 as source. We will only see one static mapping which is going to R1, the NHS.
R2#sh ip nhrp 10.1.1.1/32 via 10.1.1.1, Tunnel100 created 00:12:55, never expire Type: static, Flags: authoritative used NBMA address: 126.96.36.199
We will now test if spoke-to-spoke is possible. Let’s trace from R2 to R4. Take note that in some cases the trace will go to R1 for the initial traffic. The succeeding packets will go directly to R4. The reason for this is that. when the initial traffic is sent, R2 is still in the process of getting information about how to reach R4 directly through NHRP.
R2#traceroute 188.8.131.52 source 184.108.40.206 Type escape sequence to abort. Tracing the route to 220.127.116.11 1 10.1.1.4 36 msec 36 msec 36 msec R2#sh ip route 18.104.22.168 Routing entry for 22.214.171.124/32 Known via "eigrp 100", distance 90, metric 27008000, type internal Redistributing via eigrp 100 Last update from 10.1.1.4 on Tunnel100, 00:02:20 ago Routing Descriptor Blocks: * 10.1.1.4, from 10.1.1.1, 00:02:20 ago, via Tunnel100 Route metric is 27008000, traffic share count is 1 Total delay is 1005000 microseconds, minimum bandwidth is 2000 Kbit Reliability 255/255, minimum MTU 1200 bytes Loading 1/255, Hops 2 R2#sh ip nhrp 10.1.1.1/32 via 10.1.1.1, Tunnel100 created 00:14:45, never expire Type: static, Flags: authoritative used NBMA address: 126.96.36.199 10.1.1.4/32 via 10.1.1.4, Tunnel100 created 00:00:04, expire 00:01:14 Type: dynamic, Flags: router used NBMA address: 188.8.131.52
The traceroute above shows that the path taken was directly to the tunnel IP address of R4. The “show ip nhrp” command showed as well that the R2 built a direct spoke-to-spoke to R4 and traffic did not pass through R1.
Task 4: Configure Encryption
A good network design includes a way to secure traffic. This is a must, given that DMVPN is deployed into shared topologies like internet and MPLS. Let’s proceed to configure IP sec encryption. We will begin with configuration of the IP sec policy, SA, and profiles.
On All Routers: crypto isakmp policy 5 encr aes 256 group 2 authentication pre-share ! crypto isakmp key 0 cisco address 0.0.0.0 0.0.0.0 ! crypto isakmp invalid-spi-recovery crypto isakmp keepalive 10 ! crypto ipsec security-association lifetime kilobytes 536870912 crypto ipsec security-association replay disable ! crypto ipsec transform-set DMVPN esp-aes 256 esp-sha-hmac comp-lzs crypto ipsec df-bit clear ! crypto ipsec profile DMVPN set transform-set DMVPN
Then let’s apply the crypto IP sec profile as tunnel protection mode on the tunnels for each router.
R1(ipsec-profile)#int Tunnel100 R1(config-if)# tunnel protection ipsec profile DMVPN R1(config-if)#end R1#! R1# *Mar 1 00:25:45.115: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON *Mar 1 00:25:45.191: %SYS-5-CONFIG_I: Configured from console by console R1# *Mar 1 00:25:45.731: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /184.108.40.206, src_addr= 220.127.116.11, prot= 47 ! R2(ipsec-profile)#int Tunnel100 R2(config-if)# tunnel protection ipsec profile DMVPN ! R3(config)#crypto ipsec profile DMVPN R3(ipsec-profile)# set transform-set DMVPN ! R4(config)#int Tunnel100 R4(config-if)# tunnel protection ipsec profile DMVPN
The network adjacencies will be lost and will only recover until the configurations are complete for each router. Now, let’s verify if traffic is encrypted and network connectivity is still up.
R1#ping 18.104.22.168 source 22.214.171.124 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds: Packet sent with a source address of 188.8.131.52 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/62/76 ms R1#ping 184.108.40.206 source 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: Packet sent with a source address of 22.214.171.124 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/52/64 ms R1#ping 126.96.36.199 source 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: Packet sent with a source address of 220.127.116.11 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/80/100 ms R1#sh crypto isakmp sa dst src state conn-id slot status 18.104.22.168 22.214.171.124 QM_IDLE 2 0 ACTIVE 126.96.36.199 188.8.131.52 QM_IDLE 1 0 ACTIVE 184.108.40.206 220.127.116.11 QM_IDLE 3 0 ACTIVE
The “QM_IDLE” means that IP sec is working properly. EIGRP adjacencies are restored. Now we have successfully created a secure and encrypted DMVPN network.