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.
Configuration Steps
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.
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:
| Step 1. | 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: Here is a unique number, and should be defined in the same way on the hub and all spokes.
|
| Step 2. | 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
|
| Step 3. | 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. |
|
|
| Step 4. | 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
| Step 5. | 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.
| | Step 6. | 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. | | Step 7. | 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)#
| | Step 8. | 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. |
|
| | Step 9. | 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.
|
| | 1. | 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
- 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.
| | 2. | 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.
|
|