Next Hop Resolution Protocol (NHRP) is a resolution protocol that allows a Next Hop Client (NHC) to dynamically register with Next Hop Servers (NHSs). With the Dynamic Multipoint Virtual Private Network (DMVPN) design the NHC is the spoke router and the NHS is the hub router. Once all clients are registered, spoke routers can discover other spoke routers within the same non-broadcast multiple access (NBMA) network.
NHRP was originally used in NBMA networks, like Frame-Relay and Asynchronous Transfer Mode (ATM). Devices/routers connected to an NBMA network typically are all on the same IPv4 subnet. Broadcasts and multicasts do not reach all devices like they do on an Ethernet network because legacy NBMA networks are usually Layer 2 WAN implementations with no routing inside the WAN. Without routing inside the NBMA network, spoke routers have to go through the hub router to get to another spoke. This limitation could cause a bandwidth bottleneck at the hub router. One solution is to put the routers in a full mesh topology, but spoke routers would need an extensive configuration and the expense of extra virtual circuits to reach each other in one hop.
For a better understanding of useful NHRP commands see below:
ip nhrp network-id (number) -?enables the NHRP on an interface. Use the command in interface configuration mode, in this case the tunnel interface. All NHRP devices, in this case the routers, within one logical NBMA network must be configured with the same network identifier. Number range is 1 to 4294967295.
ip nhrp nhs — specifies the address of one or more NHRP servers. Use the command in interface configuration mode. The command is configured on the tunnel spokes which identifies to what server (NHS) address each client (NHC) goes to register its address with the NHS. (Notice the NHS itself, the hub router, does not have this command, similar to BGP router reflector configuration, if the reader is familiar with BGP.) Normally, NHRP consults the network layer forwarding/routing table to determine how to forward NHRP packets. Legacy ATM designs used a separate devise as the next hop server which had a next hop forwarding table similar to an ARP table. If an NHS is configured that is not the hub router then the next hop addresses in the next hop table overrides the forwarding path that would otherwise be used for NHRP traffic. That is not the design deployed in this paper. The network layer forwarding/routing table of the hub router is how NHRP packets are forwarded.
ip nhrp map (NHS ip address) (physical ip address of the hub router) -? statically configures the IP of the NHS to map to the physical address of the hub router. One probably needs to configure at least one static mapping in order to reach the next hop server. Command is needed so NHRP registration and discovery packets needing to reach the NHS are linked to the routing table. If there are multiple NHSs then this command can be repeated.
ip nhrp map multicast (physical ip address of the hub router) -? usually configured on a spoke router, this command configures the physical address of the hub router used as a destination for broadcast or multicast packets to be sent over a tunnel network. The command is useful for supporting broadcasts or multicasts over a tunnel network when the underlying physical network does not support IP multicast mode. The Internet does not allow broadcasts and multicast on its physical interfaces so routing protocols like OPSF and EIGRP would not be supported unless they went over a tunnel.
ip nhrp map multicast dynamic — allows NHRP to automatically add routers to the multicast NHRP mappings. Use this command when spoke routers need to initiate mGRE and IPSec tunnels and register their unicast NHRP mappings. This command is needed to enable routing protocols to work over the mGRE and IPSec tunnels because routing protocols often use multicast packets. This command prevents the hub router from needing a separate configuration line for a multicast mapping for each spoke router.
ip nhrp holdtime (seconds) — ?changes the number of seconds that NHRP dynamic entries expire. The default is 7,200 seconds (two hours). The NHRP cache can contain static and dynamic entries. The static entries never expire. Cisco recommends that this setting be changed to 600 seconds, or ten minutes, so the holdtime does not have an adverse effect on the NHRP registration and discovery process.
ip nhrp registration timeout (seconds) — ?sets the time between periodic registration messages. By default this is set to one-third of the value of the NHRP holdtime, or forty minutes. If the defaults of these two settings are not changed and something happens to the mappings on the NHS, the spokes will not attempt to re-register for forty minutes. Thus the maps would work from the spoke to the hub, but not from the hub back to the spoke for forty minutes. A much better practice is the thirty-second re-registration shown in this paper. If a little less overhead is desired, then a sixty-second value may be appropriate. Since the next hop of “Next Hop Registration Protocol” relies on a forwarding/routing table, a routing protocol needs to be configured.
ABOUT THE AUTHOR
Bill Treneer is a Cisco Certified Systems Instructor and subject matter expert in Multicast design, configuration and troubleshooting. He holds CCNP, CCDP, CWLSS, CCNA, CCDA, CompTIA Security+, and Network+ certifications.
This is an excerpt from the Global Knowledge white paper, Dynamic Multipoint Virtual Private Network (DMVPN).
Related Courses
IINS 2.0 — Implementing Cisco IOS Network Security
SASAC — Implementing Core Cisco ASA Security v1.0