Worldwide Locations
With the vast amounts of data surging through modern networks, it can be difficult to ensure an efficient, effective data management process. Because businesses are constantly growing and restructuring their networks, you need a way to ensure that clients and servers have flexibility when communicating with each other—especially since new machines and processes can be added at any time.
Next Hop Resolution Protocol enables businesses to have a way for next-hop servers and next-hop clients to communicate with each other directly, bypassing a central hub and preventing potential bottlenecks.
What Are Next Hop Resolution Protocol Commands?
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.
Another way to look at it is through the lens of another kind of communication: telephone calls.
An NHRP-equipped network is like a town where everyone has cell phones. On the other hand, a network that needs to route all communications between clients and servers through their internet service provider (ISP) is like a town with an old-fashioned switchboard operator.
In a town with a switchboard-centered phone system, when too many people make calls at the same time, the switchboard operator can easily get overwhelmed with all the cables that need to be unplugged and plugged, unplugged, and plugged in again, over and over. Similarly, with your ISP acting as a central hub for all communications, it can get overwhelmed with receiving and forwarding request after request after request.
With NHRP commands, your network works more like a town with cell service. Clients can interact with each other directly because they, in effect, have each other’s “numbers.” In this case, the “number” is the public IP address of each client in the next-hop network.
There’s no need for huge loads of data to be routed through your ISP’s hub. NHRP ensures that clients and servers can communicate directly with each other using their public IP addresses.
Read also: Building Toward Your ’99.999%’ Availability Goal with a First Hop Redundancy Protocol
The Problem NHRP was Designed to Solve
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 as 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.
Read Next: Policy-Based Routing: What Is It and How Is It Used?
Why Not Use a Full Mesh Topology Instead of NHRP?
Although one solution could be to put the routers in a full mesh topology, this could be problematic for the following reasons:
- Spoke routers would need extensive configuration
- There would be significant expense related to the extra virtual circuits needed for each network entity to reach the others in one hop
- The time it takes to set up—and troubleshoot—the system could overwhelm an already busy IT team
It’s far more efficient to use Next Hop Resolution Protocol because it enables the components on the network to “see” each other without having to put each node through extensive, time-consuming, and expensive configurations.
How Do NHRP Commands Work?
Suppose you have a relatively simple network with a server, S1, two clients, A2 and A3, and your ISP. In a traditional setup, you would have a virtual private network (VPN) connection between the ISP and the servers and clients, with all information going through the ISP.
However, with NHRP enabled, you create a static tunnel between each of the clients and the server, and you get a dynamic tunnel between the clients, meaning they can learn the best routes by communicating with each other.
NHRP makes it possible for the clients, A2 and A3, to see each other’s public IP addresses and then use these to communicate. It also reveals the public IP address of the server, enabling direct communication with that as well.
Now, with NHRP sending a message to your ISP, which then sends it to A3, A2 and A3 can use their dynamic routing to communicate more directly. In effect, your data can skip a step along its journey. This results in:
- Less traffic being managed by your ISP
- Faster communications between clients and servers
- More efficient transmissions between clients
- The ability to add more clients and servers to the network without overwhelming the routing processes performed by your ISP
The Commands That Drive NHRP
NHRP works using a series of commands that are implemented by entities on your next hop-enabled network.
For a better understanding of useful NHRP commands, see below:
ip nhrp network-id (number)
This command 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. The number range is 1 to 4294967295.
ip nhrp nhs
This 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.
Normally, NHRP consults the network layer forwarding/routing table to determine how to forward NHRP packets. Legacy ATM designs used a separate device 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 override the forwarding path that would otherwise be used for NHRP traffic. That is not the design deployed here. 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)
This command 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. The command is needed so NHRP registration and discovery packets that need to reach the NHS link 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)
This is 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
This command 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)
This 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 10 minutes, so the hold time 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 hold time or 40 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 40 minutes. Thus, the maps would work from the spoke to the hub, but not from the hub back to the spoke for 40 minutes.
A much better practice is the 30-second re-registration shown here. If a little less overhead is desired, then a 60-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.
What NHRP Means for Your Network
With NHRP, your next-hop-enabled network gains the efficiency and flexibility it needs to avoid data bottlenecks now and into the future. This empowers all those connecting—regardless of where they are—to enjoy smooth, uninterrupted communication and use of applications.
See Popular Network Protocol Courses
Understanding Networking Fundamentals
Build a foundation of networking knowledge in a real-world, multi-vendor environment.
IPv6 Foundations: Protocols, Services, and Migration
Learn the essentials for integrating IPv6 into your existing IPv4 network.
Learn IPv6 security mitigation techniques and best practices in this interactive course.