This case study section centers on Dynamic Multipoint VPN, which is a new feature introduced in IOS code to address the scalability issue for LAN-to-LAN tunnel with GRE and IPsec.
In the LAN-to-LAN troubleshooting section, you have seen how GRE over IPsec works and addresses some of the issues that Basic LAN-to-LAN hasunable to encrypt non-IP, multicast, and broadcast traffic.
In a large-scale VPN deployment, several spokes need to talk to each other. So, you have the option of building either a full mesh, or a hub and spoke network. Because full mesh does not scale very well, hub and spoke networks are mainly deployed, in which every spoke builds up the tunnel with the hub and communicates through the hub.
The problem with this deployment is that that the hub has to encrypt and decrypt the packet twice to pass one data stream between the spokes, which overburdens the hub's CPU. Also, in regard to configuration, for every spoke, the hub needs to have configuration so that spokes can build up the tunnel. If there are hundreds of spokes, the situation becomes quite complex, and sometimes impossible. Dynamic multipoint VPN comes to your rescue under this type of circumstance. With DMVPN set up, all the spokes build up the tunnel with only the hub using the Multipoint GRE interface, and with the help of NHRP, spokes dynamically learn about the peer's IP address and learn all the information necessary from the hub to build up the tunnel dynamically. DMVPN not only builds tunnels on demand, but also tears down tunnels dynamically. Hub configuration is reduced dramatically, and with the addition of new spokes, hub configuration does not have to be modified. A detailed discussion of DMVPN is beyond the scope of this book, so a brief discussion of its operation will have to suffice.
DMVPN relies on two proven Cisco technologies:
Multipoint GRE Tunnel Interface (mGRE Interface)
This allows a single GRE interface to build multiple IPsec tunnels, and significantly simplifies the size and complexity of the configuration.
An mGRE interface has an IP address, a tunnel source interface, and a tunnel key as follows:
spoke-A# show running-config ! This is the physical interface that is used as source for the mGRE tunnel interface Ethernet0 ip address 172.17.16.1 255.255.255.0 ! Following is a mGRE tunnel interface interface Tunnel 0 ip address 192.168.0.10 255.0.0.0 tunnel source Ethernet0 tunnel mode gre multipoint tunnel key 1 spoke-A#
The tunnel address is the IP address defined on the tunnel interface. The NBMA (Non-Broadcast Multiple Access) address is the IP address used as a tunnel source (or destination). Therefore in the preceding example, the 192.168.0.10 is spoke-A's tunnel address and 172.17.16.1 is spoke-A's NBMA address.
Unlike point-to-point GRE interface, mGRE interfaces do not have a tunnel destination defined. Because mGRE tunnels do not have a tunnel destination address, they need to rely on another protocol that tells mGRE tunnel interface the destination of the packets it sends out. Next Hop Resolution Protocol (NHRP) comes to rescue for mGRE tunnel interface to get the destination address dynamically, as discussed in the next section.
Next Hop Resolution Protocol (NHRP)
NHRP is a client/server model protocol which is defined by RFC2332. The hub is considered to be the Next Hop Server (NHS) and the spokes are considered to be the Next Hop Client (NHC). The hub or the NHS maintains a NHRP cache just like ARP cache, for all the spokes Real IP (NBMA address) and the GRE tunnel interface IP address (VPN layer address).
The cache on the hub and spoke can be built up in one of the following ways:
Manually add static entries
Hub learns via registration requests by spoke
Spokes learn via resolution requestsused for spoke-to-spoke communication only
Each spoke registers its real address (NBMA address) when it boots (it obtains it dynamically). The spokes send registration requests to the hub with their actual physical IP addresses, which are called NBMA addresses, along with the tunnel IP address (VPN layer address) with the cache timeout value. Upon receiving the registration requests, the hub caches the NHRP mapping in the NHRP cache database.
Spokes have a permanent IPsec tunnel to the hub, but not to the spokes. When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination spoke. Then the originating spoke can initiate a dynamic IPsec tunnel to the target spoke (because it knows the peer address). The spoke-to-spoke tunnel is built over the mGRE interface.
DMVPN was first introduced in 12.2(12)T. It is supported in 7204/6, 37xx, 26xx, 17xx. Only the latest T trains are supported on 9xx and 8xx routers as well.
DMVPN can be deployed in one of the following modes:
Hub and Spoke All traffic moves via the hub.
Spoke-to-Spoke Spoke-to-spoke traffic moves directly, bypassing the hub. Initial traffic during NHRP resolution and tunnel buildup phase still may go through the hub.
To understand both of these scenarios fully with DMVPN, go through the configuration discussed in the next section.
To illustrate both hub and spoke and spoke-to-spoke deployment of DMVPN network, you will be configuring the DMVPN based on Figure 6-8.
Figure 6-8. DMVPN for Dynamic Spoke-to-spoke
For hub and spoke on the hub you must create an mGRE tunnel interface, and on the spoke you can create a point-to-point tunnel interface or the mGRE interface. For spoke-to-spoke setup, you must use mGRE interface on the hub and the spokes. The configuration discussed will be using the mGRE interface on the hub and the spokes.
Work-through the following steps to configure hub and spoke and spoke-spoke tunnels in DMVPN network:
Define Network ID under mGRE tunnel interface on the hub and the spokes.
To define network ID under the mGRE tunnel interface so that the mGRE tunnel interface can use NHRP, use the following command on hub and spokes:
ip nhrp network-id <id>
Here <id> is a unique number, and should be defined in the same way on the hub and all spokes.
Configure spokes so that the initial NHRP cache can be built on the hub.
Initially, the hub has an empty cache unless you have the static NHRP mapping configured. On the other hand, the spoke has one static entry mapping with the hub's tunnel address to the hub's NBMA address as follows:
ip nhrp map 10.0.0.1 172.17.0.1
Be sure to configure the following to send the Multicast traffic to the hub from the spoke, so that dynamic routing protocols can communicate between the hub and spoke:
ip nhrp map multicast 172.17.0.1
Configure the spokes to register to the hub.
For the spokes to register themselves to the hub, the hub must be declared as a Next Hop Server (NHS) as follows:
ip nhrp nhs 10.0.0.1 ip nhrp holdtime 3600 ip nhrp registration no-unique
The spokes control the cache on the hub. The spokes send Registration-requests to the hub, and the request contains the spoke's Tunnel, NBMA addresses, the hold time, and some flags. The hub creates an entry in its NHRP cache, and this entry will be valid for the duration of the hold time defined in the registration by the spoke.
Configure the hub to send Multicast packets to the spokes.
The hub must send multicast traffic to all the spokes that registered to it for dynamic routing protocol. As the spoke's NBMA or the physical IP address is not known, this must be done dynamically (this is introduced in IOS Version 12.2(13)T) with the following command under mGRE tunnel interface:
ip nhrp map multicast dynamic
Configure the routing protocol on the hub and spokes.
Configure the spokes with dynamic routing protocol to advertise their private networks to the hub. You can use BGP, EIGRP, OSPF, RIP or ODR. It is strongly recommended to use EIGRP.
Send Hello messages for dynamic routing protocol exchanges.
With the Tunnel defined, static NHRP entry to hub presence, and NHRP entry marked for multicast, spokes immediately send the Hellos to the Hub.
Upon receiving NHRP registrations from spokes, the hub inserts the NHRP information into the cache and marks it as "Multicast" because of the following configuration under mGRE tunnel interface:
ip nhrp map multicast dynamic
The hub sends Hellos to all the registered spokes simultaneously.
Readjust the default bandwidth on the mGRE tunnel interface.
The default bandwidth of a GRE tunnel interface is 9 Kbps. This has no influence on the traffic, but EIGRP will take half of the interface bandwidth maximum (4.5 Kbps), which is too low. So adjust the bandwidth to 10000 Kbps with the following command:
Hub(config)# interface tunnel 0 Hub(config-if)# bandwidth 10000 Hub(config-if)#
Turn off split-horizon on the hub.
To allow spoke-to-spoke communication via the hub (Hub and Spoke setup), turn off split-horizon on the hub with the following command:
Hub(config)# Hub(config)# router eigrp 1 Hub(config-router)# no ip split-horizon eigrp 1 Hub(config-router)#
You must consider summarization, and be sure to set the bandwidth in the hub to spoke direction.
Enable IPsec protection on mGRE tunnel interfaces.
Because the GRE tunnel is insecure, it must be protected with IPsec. DMVPN introduced tunnel protection. Work through the following step to enable IPsec on the tunnel interface:
- (a). Define a transform set with the following command:
crypto ipsec transform-set ts esp-sha-hmac esp-3des mode transport
- (b). Configure IPsec profile (this is replacement for the crypto map for DMVPN) with the following commands. IPsec Profile is just like the crypto map command without "set peer" and "match address," and this information is unknown until the registration process takes place for NHRP.
crypto ipsec profile prof set transform-set ts
- (c). Apply the profile on the tunnel interface with the following command. Internally IOS will treat this as crypto map and will get the missing information (set peer and match address parameters from the NHRP cache). The following command must be applied on hub and spokes.
tunnel protection ipsec profile prof
So far based on the configuration, spoke-to-spoke can communicate with each other through the hub. If you want to enable direct spoke-to-spoke tunnel communication, you need to rely on the following:
The routing table
The NHRP table
To create a spoketo-spoke tunnel, a spoke must learn a routing entry to the destination network (this is the private network of the other spoke). The next hop must be the spoke tunnel IP address. The spoke must learn the NBMA address of the next hop. The IPsec tunnel between the spokes is built only after that.
Route learning on the spokes
The routing protocol is always between the hub and the spokes (hub and spoke has neighbor relationships, not spoke-to-spoke). All the spokes learn the route of the private network of other spokes via the hub. For spoke-to-spoke to work correctly, the hub must preserve and advertise the private network's next hop as advertised by the spokes themselves (as the tunnel interface IP address). Different routing protocols behave differently in terms of preserving the next-hop information.
- a. RIP keeps the next-hop information by default. This can not be disabled.
- b. The next-hop preservation in EIGRP is not a default. It is turned on with the interface command.
no ip next-hop-self eigrp <as>
- c. Next hop preservation in BGP is a default. It can be disabled with the BGP command.
neighbor <n> next-hop-self
- d. In OSPF, next-hop preservation happens naturally except in point-to-multipoint mode.
NHRP learning on spokes
A spoke will send an NHRP resolution request to its NHS to learn an NBMA address. The queried address can be a network address. Ideally, the queried address should be a next-hop address. The NHS will respond with an NBMA address from its cache. The spoke will populate its cache with the answer. The resolution reply will have a lifetime set to the remaining lifetime in the hub cache. If the NHS does not have the entry in its cache, it returns an error and the spoke will install an entry pointing to the NHS.
During the learning process, the spoke will forward all the packets to its NHS, and this happens in process switching. As soon as the NHRP entry is created but NOT inserted in the cache, an IPsec tunnel will be negotiated. The NHRP entry will be inserted in the cache and used when the IPsec tunnel is actually ready The IPsec tunnel will disappear when the NHRP entry times out.
Example 6-32 shows the hub configuration of Figure 6-8.
Example 6-32. Hub Configuration of DMVPN
Hub# show running-config crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address 0.0.0.0 ! crypto IPsec transform-set trans2 esp-des esp-md5-hmac ! crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.1 255.255.255.0 ip mtu 1416 ip nhrp authentication donttell ip nhrp map multicast dynamic ip nhrp network-id 99 ip nhrp holdtime 300 no ip split-horizon eigrp 1 no ip next-hop-self eigrp 1 delay 1000 tunnel source Ethernet0 tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile vpnprof interface Ethernet0 ip address 172.17.0.1 255.255.255.0 ! interface Ethernet1 ip address 192.168.0.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.0.0 0.0.0.255 !
Example 6-33 shows spoke configuration.
Example 6-33. Spoke Configuration of DMVPN Network
Spoke-AA#show running-config crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address 0.0.0.0 ! crypto IPsec transform-set trans2 esp-des esp-md5-hmac ! crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.3 255.255.255.0 ip mtu 1416 ip nhrp authentication donttell ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 99 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1000 tunnel source Ethernet0 tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile vpnprof ! interface Ethernet0 ip address dhcp hostname Spoke1 ! interface Ethernet1 ip address 192.168.1.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.1.0 0.0.0.255
Problems on the DMVPN network can categorized as follows:
NHRP mapping problems
Crypto socket creation problems
Crypto VPN problems
Dynamic routing protocol problems
Problems with passing data across an established tunnel
Most of the problems that occur in these areas are caused by misconfiguration or a bug in the code. This section helps you identify and troubleshoot configuration-related issues. Most of the problem areas can be identified with show commands output. You might end up running debug commands to find additional details about the DMVPN problem.
NHRP Mapping Problem
NHRP (cache) Mapping problems can be identified by executing show ip nhrp command as shown in Example 6-34.
Example 6-34. Showing the Successful Mappings of NHRP with show ip nhrp Command
Hub1# show ip nhrp ! This is the first dynamic NHRP Mapping ! Tunnel0 is the interface of the NHRP cache entry that was created. 00:11:03 is the time ! since the NHRP entry was created. 00:04:52 is the time in which the positive and ! negative authoritative NBMA address will expire (hours:minutes:seconds). This value is ! based on the ip nhrp holdtime command. 10.0.0.11/32 via 10.0.0.11, Tunnel0 created 00:11:03, expire 00:04:52 ! Type dynamic means NBMA address was obtained from NHRP Request packet. staticNBMA ! address means statically configured. ! The flag in the following shows Authoritative unique registered which means ! that the NHRP information was obtained from the Next Hop Server or router that ! maintains the NBMA-to-IP address mapping for a particular destination. Implicit ! Indicates that the information was learned not from an NHRP request generated from the ! local router, but from an NHRP packet being forwarded or from an NHRP request being ! received by the local router. Negative caching indicates that the requested NBMA ! mapping could not be obtained. Type: dynamic, Flags: authoritative unique registered ! The following shows the NBMA (Nonbroadcast Multi-access Address). The address format is ! Appropriate for the type of network being used (for example, ATM, Ethernet, Switched ! Multimegabit Data Service (SMDS), or multipoint tunnel). NBMA address: 172.16.1.1 ! This is the Second dynamic NHRP Mapping 10.0.0.12/32 via 10.0.0.12, Tunnel0 created 01:03:31, expire 00:05:46 Type: dynamic, Flags: authoritative unique registered NBMA address: 172.16.2.1 . . . Hub1#
If the NHRP does not work correctly, analyze the problem further with the debug nhrp command.
Following is a list of some of the important NHRP-related issues that you need to keep in mind:
NHRP Key must match on all the spokes and the hub in the DMVPN network
Go through the following list and be sure that you are not configuring something that is not supported. For example, on the cat6500 and 7600 series switch, the defining key is not supported. For more information, check the following URL:http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftgreips.htm#wp1069602
Crypto Socket Creation Problem
Crypto socket is a bridge between the NHRP and the IPsec crypto tunnel. If the crypto socket creation fails, the NHRP also will fail. Example 6-35 shows successful crypto socket creation.
Example 6-35. Successful Crypto Socket Built Up
Hub1# show crypto socket ! This is the first crypto socket. Tu0 Peers (local/remote): 172.17.0.1/172.16.1.1 Local Ident (addr/mask/port/prot): (172.17.0.1/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (172.16.1.1/255.255.255.255/0/47) ! Following two lines are indication of successful socket creation Socket State: Open Client: "TUNNEL SEC" (Client State: Active) ! This is the second socket Tu0 Peers (local/remote): 172.17.0.1/172.16.2.1 Local Ident (addr/mask/port/prot): (172.17.0.1/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (172.16.2.1/255.255.255.255/0/47) Socket State: Open Client: "TUNNEL SEC" (Client State: Active) . . . Crypto Sockets in Listen state: 1 TUNNEL SEC Profile: "vpnprof" Map-name "Tunnel0-head-0" Hub1#
If you experience a problem with crypto socket creation, the only remedy as of the writing of this book is to reboot the router, which frees the stuck crypto socket. There is no CLI command to unstick a crypto socket.
Crypto VPN problem
To find out if IPsec is causing the problem, simply remove the tunnel protection ipsec profile profile_name command from the tunnel interface and see if everything works well. After removing this command, NHRP will go over IP instead of IPsec. If this test reveals an IPsec issue, troubleshoot it just as discussed in the "LAN-to-LAN" troubleshooting section.
Dynamic Routing Protocol Problem
Following is a list of dynamic routing protocols you can configure in the DMVPN network:
Enhanced Interior Gateway Routing Protocol (EIGRP)
Be sure that the following line is configured for the hub and spoke deployment:
no ip split-horizon eigrp <as> no auto-summary
If you have spoke-to-spoke deployment, configure the following command.
no ip next-hop-self eigrp <as>
You must be running Cisco IOS Version 12.3(1) to run the this command.
Open Shortest Path First (OSPF)
To use OSPF in the DMVPN network, configure the following commands:
ip ospf network broadcast ip ospf priority (2(hub)|0(spoke))
Border Gateway Protocol (BGP)
If you configure BGP, you must configure the hub as the route reflector.
Routing Information Protocol (RIP)
If RIP is configured on the DMVPN network, configure the following under the RIP routing process:
no ip split-horizon no auto-summary
It is strongly recommended that you configure EIGRP on the DMVPN network.
If you have problems with neighbor relationships with the dynamic routing protocol, pay close attention on the following:
Make sure that on the hub router, you have the following command in the tunnel interface:
ip nhrp map multicast dynamic
You must avoid this configuration on the spoke; otherwise you might experience neighbor flaps. On the spoke you should have the following configured for the multicast:
ip nhrp map multicast NBMA_Address (Physical_Interface)_Of_Hub
This is because the spokes do not have to send any multicast to other spokes; they have to send multicast to the hub to build up the neighbor relationship.
On the spokes, you must not configure more than two multipoint GRE tunnels sharing the same source interface.
Passing Data Across an Established Tunnel Problem
If everything looks good, but you are unable to pass traffic, remember the following points:
When the hub is behind the PAT device, there are no restrictions.
If you are using IPsec Transport mode (highly recommended), two spokes may have the same pre-NAT (outside physical address) but must have unique post-NAT addresses. This means that two spoke routers behind the same NAT box must be translated to unique post-NAT IP addresses. Two spokes behind different NAT boxes may have the same pre-NAT IP address (of course they would have different post-NAT IP addresses).
If you are using IPsec Tunnel mode, all spokes must have unique pre-NAT IP addresses, but may have the same post-NAT IP addresses. This means that two spokes behind different NAT boxes must have unique pre-NAT IP addresses. Two spokes behind the same NAT device (of course will have unique pre-NAT IP addresses), may have the same post-NAT IP address.
You must turn on CEF switching.