In an old post, dated 2011, I explained various types of VPN technologies. In seven years several things have changed: SHA1 is deprecated, des and 3des are no more used for security issues, but some VPN technologies are still used with protocols more secure (SHA256, AES, …). In this article, I explain how DMVPN works and what are the key components of it.
Cisco DMVPN uses a centralized architecture to provide easier implementation and management for deployments that require granular access controls for diverse user communities, including mobile workers, telecommuters, and extranet users. Key components are:
- Multipoint GRE (mGRE) tunnel interface: allows a single GRE interface to support multiple IPsec tunnels, simplifying the size and complexity of the configuration.
- Dynamic discovery of IPsec tunnel endpoints and crypto profiles: eliminates the need to configure static crypto maps defining every pair of IPsec peers, further simplifying the configuration.
- Routing Protocol: used to learn network between hub and spokes.
- NHRP: Allows spokes to be deployed with dynamically assigned public IP addresses (i.e., behind an ISP’s router). The hub maintains an NHRP database of the public interface addresses of the each spoke. Each spoke registers its real address when it boots; when it needs to build direct tunnels with other spokes (only on phase2 and phase3), it queries the NHRP database for real addresses of the destination spokes.
There are three different types of DMVPN design:
Phase1
Provides hub-and-spoke tunnel deployment. This means GRE tunnels are only built between the hub and the spokes. Traffic destined to networks behind spokes is forced to first traverse the hub.
For instance, to reach 192.168.3.0/24 network from 192.168.2.0/24 network (ethernet0/0) the HUB router is always traversed:
Spoke2#traceroute 192.168.3.5 source ethernet 0/0 Type escape sequence to abort. Tracing the route to 192.168.3.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.1.1 5 msec 5 msec 4 msec 2 10.0.1.3 5 msec 5 msec 5 msec Spoke2#
Note: Because all spoke-to-spoke traffic in DMVPN Phase1 always traverses the hub, it is actually inefficient to even send the entire routing table from the hub to the spokes.
Phase2
Allow spokes to build a spoke-to-spoke tunnel on demand with these restrictions: the spokes must receive specific routes for all remote spoke subnets.
For instance, to reach 192.168.3.0/24 network from 192.168.2.0/24 network (ethernet0/0), the first packet reaches the HUB, then the Spoke3 router:
Spoke2#traceroute 192.168.3.5 source ethernet 0/0 Type escape sequence to abort. Tracing the route to 192.168.3.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.1.1 5 msec 4 msec 2 msec 2 10.0.1.3 2 msec 5 msec 5 msec Spoke2#
This is due to the incomplete next-hop (10.0.1.3) adjacency:
Spoke2#show adjacency 10.0.1.3 Protocol Interface Address IP Tunnel1 10.0.1.3(7) (incomplete) Spoke2#
Spoke2#show ip cef 10.0.1.3 internal
10.0.1.0/24, epoch 0, flags attached, connected, cover dependents, need deagg, RIB[C], refcount 5, per-destination sharing
sources: RIB
feature space:
IPRM: 0x0003800C
subblocks:
gsb Connected chain head(1): 0xF4334728
Covered dependent prefixes: 3
need deagg: 2
notify cover updated: 1
ifnums:
Tunnel1(23)
path F34EABE8, path list F297DA14, share 1/1, type connected prefix, for IPv4
connected to Tunnel1, adjacency punt
output chain: punt
Spoke2#
This causes Spoke2 to send a NHRP resolution request to HUB for Spoke-3 NBMA address. The request gets forwarded from HUB to Spoke3. Spoke3 replies directly to Spoke2 with its mapping information.
After the NHRP resolution is complete, Spoke2 can build a dynamic tunnel to Spoke3, and traffic will not pass through HUB anymore:
Spoke2#show adjacency 10.0.1.3 Protocol Interface Address IP Tunnel1 10.0.1.3(13) Spoke2#
Spoke2#show ip nhrp dynamic 10.0.1.3/32 via 10.0.1.3 Tunnel1 created 00:00:16, expire 00:04:43 Type: dynamic, Flags: router nhop NBMA address: 57.57.57.5 Spoke2#
Spoke2#traceroute 192.168.3.5 source ethernet 0/0 Type escape sequence to abort. Tracing the route to 192.168.3.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.1.3 5 msec 5 msec 8 msec Spoke2#
Phase3
Allow spokes to build a spoke-to-spoke tunnel and overcomes the phase2 restriction using NHRP traffic indication messages from the hub to signal to the spokes that a better path exists to reach the target network. This functionality is enabled by configuring ip nhrp redirect on the hub and ip nhrp shortcut on the spokes.
For instance, to reach 192.168.3.0/24 network from 192.168.2.0/24 network (ethernet0/0), the first packet reaches the HUB, then the Spoke3 router:
Spoke2#traceroute 192.168.3.5 source ethernet 0/0 Type escape sequence to abort. Tracing the route to 192.168.3.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.1.1 5 msec 4 msec 2 msec 2 10.0.1.3 2 msec 5 msec 5 msec Spoke2#
Then HUB “link” this traffic back onto the DMVPN network, triggering the NHRP process on HUB to generate the traffic indication to Spoke2 to resolve a better next hop for the remote network 192.168.3.0 (Spoke3).
At this point, the spokes can now modify their routing table entries to reflect the NHRP shortcut route and use it to reach the remote spoke.
Spoke2#traceroute 192.168.3.5 source ethernet 0/0 Type escape sequence to abort. Tracing the route to 192.168.3.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.1.3 5 msec 5 msec 8 msec Spoke2#
Spoke2#show ip route !omitted! D* 0.0.0.0/0 [90/281600] via 10.0.1.1, 00:11:12, Tunnel1 H 192.168.3.0/24 [250/1] via 10.0.1.3, 00:02:01, Tunnel1 Spoke2#
As you can notice, the network 192.168.3.0/24 is learned by the NHRP protocol with administrative distance 250.
Spoke2#show ip route 192.168.3.0
Routing entry for 192.168.3.0/24
Known via "nhrp", distance 250, metric 1
Last update from 10.0.1.3 on Tunnel1, 00:00:09 ago
Routing Descriptor Blocks:
* 10.0.1.3, from 10.0.1.3, 00:00:09 ago, via Tunnel1
Route metric is 1, traffic share count is 1
MPLS label: none
Spoke2#
References:
