CCNP-Studies
Routing
6-DMVPN
2.1 What Is Nhrp

About NHRP

Introduction

NHRP, or Next Hop Resolution Protocol, plays a crucial role in addressing the challenges of Non-Broadcast Multi-Access (NBMA) networks within Wide Area Networks (WANs). These networks are often a collection of point-to-point links, including virtual tunnel networks like Generic Routing Encapsulation (GRE) tunnels. To enhance the scalability and connectivity of these networks, they are organized into hub-and-spoke configurations, involving multipoint interfaces like GRE tunnel interfaces.

The Need for Address Mapping

In NBMA networks, multiple tunnel endpoints communicate via a single multipoint interface. To efficiently route packets through multipoint GRE (mGRE) tunnel interfaces in this context, it's essential to map logical tunnel endpoint IP addresses to their physical counterparts. While static configurations are an option, dynamic discovery is preferred.

NHRP: Addressing NBMA Network Challenges

NHRP functions similarly to Address Resolution Protocol (ARP) but is tailored to tackle NBMA network issues. It enables devices within an NBMA network to dynamically learn the NBMA addresses of other devices, facilitating direct communication without an intermediate hop.

Use Cases

Routers, access servers, and hosts can leverage NHRP for various use cases:

NHRP Registration

NHRP allows Next Hop Clients (NHCs) to register dynamically with Next Hop Servers (NHSs). This registration mechanism is valuable when NHCs have dynamic physical IP addresses or are situated behind Network Address Translation (NAT) routers that change IP addresses dynamically. This approach eliminates the need for manual configuration on NHSs.

NHRP Resolution

NHRP enables one NHC (spoke) to dynamically discover the mapping of logical VPN IPs to physical NBMA IPs for other NHCs (spokes) within the same NBMA network. This discovery ensures that IP packets can travel directly between these devices, reducing the reliance on the hub (NHS) router and increasing the overall bandwidth of the NBMA network.

Dynamically Built Hub-and-Spoke Networks

With NHRP in place, the NBMA network is initially structured as a hub-and-spoke network, with multiple hierarchical layers of NHCs as spokes and NHSs as hubs. Spokes are configured with static mapping information to reach their NHSs, and they connect to their NHSs, sending NHRP registrations. This dynamic setup minimizes the configuration required on the hub and allows spokes to obtain dynamic NBMA (physical) IP addresses.

Dynamic Mesh Network

Once the basic hub-and-spoke network is established, NHRP resolution requests and responses come into play, enabling dynamic discovery of spoke-to-spoke mapping information. This feature allows spokes to communicate directly without involving the hub, effectively creating a dynamic mesh of connections between spokes based on data traffic patterns. This dynamic mesh network approach is especially useful when smaller spoke routers lack the resources to participate in a fully meshed network, as they only need to build connections they are actively using.

Next Hop Server Selection in NHRP

In NHRP (Next Hop Resolution Protocol), the process of selecting the next hop server is crucial for efficient communication within a hub-and-spoke NBMA (Non-Broadcast Multi-Access) subnetwork. Here's a summary of how this selection takes place:

  1. Request Routing: NHRP resolution requests must travel through one or more intermediate hubs within the subnetwork before they reach the intended destination station. Each station involved, including the source station, selects a neighboring NHS (Next Hop Server) to which it forwards the request. This selection is typically based on a routing decision made using the network layer destination address of the NHRP request.

  2. Resolution Reply Generation: The NHRP resolution request eventually reaches a station responsible for generating an NHRP resolution reply. This station can either serve as the destination or forward the request to the actual destination. When generating the reply, the responding station uses the source address contained within the NHRP packet to determine the appropriate destination for the reply.

  3. Cisco Implementation: It's important to note that Cisco's NHRP implementation not only adheres to but also extends the standards defined in IETF RFC 2332, which outlines the NBMA Next Hop Resolution Protocol (NHRP).

In essence, the selection of the next hop server in NHRP is a critical step in ensuring efficient and reliable communication within hub-and-spoke NBMA networks. It involves intelligent routing decisions and the use of NHRP resolution replies to establish effective connections.

Address Resolution and Data Transmission with NHRP

With NHRP (Next Hop Resolution Protocol), the process of data transmission and address resolution is key to efficient communication. Here's a breakdown of how this process works:

  1. Connection Establishment: With NHRP, after the NBMA (Non-Broadcast Multi-Access) next hop is determined, the source station initiates data packet transmission to the destination. In connectionless NBMA networks like GRE IP or SMDS, data packets are sent directly to the destination.

  2. Virtual Circuit (VC) Establishment: In connection-oriented NBMA networks, such as Frame Relay or ATM, or when using Dynamic Multipoint VPN (DMVPN), a virtual circuit (VC) connection is established. This VC is configured with specific attributes like bandwidth and quality of service (QoS) for effective communication.

  3. Address Resolution Compatibility: While deploying NHRP, other address resolution methods can still be used. For instance, in IP hosts following the Logical IP Subnet (LIS) model, ARP (Address Resolution Protocol) servers and services may be required over the NBMA network. Additionally, some hosts might not implement NHRP but continue to support ARP variations.

  4. NHRP Integration: NHRP is designed to eliminate suboptimal routing inherent in the LIS model. It can seamlessly coexist with existing ARP services without causing interference.

In summary, NHRP streamlines data transmission, establishes connections based on network type, and ensures compatibility with other address resolution methods, making it a versatile protocol for efficient networking.

NHRP Registration

NHRP registrations play a vital role in the functioning of NHRP (Next Hop Resolution Protocol). Here's a summary of how NHRP registrations work:

  • Registration Timing: NHRP registrations are initiated by NHCs (Next Hop Clients) and are sent to their configured NHSs (Next Hop Servers). These registrations occur every one-third of the NHRP holdtime, which can be configured using the ip nhrp holdtime command. Alternatively, registrations can be scheduled according to a timeout value configured with the ip nhrp registration timeout command.

  • Retransmission Strategy: In case an NHRP registration reply is not received for an NHRP registration request, the request is retransmitted at specific time intervals. The retransmission intervals are 1, 2, 4, 8, 16, 32, and 64 seconds before the sequence starts over again at 1.

  • NHS Status: If an NHRP registration reply is not received after three retransmissions (7 seconds), the NHS is declared as down. In such cases, NHRP resolution packets will no longer be sent to or via that NHS. However, NHRP registrations will continue to be sent at 1-, 2-, 4-, 8-, 16-, 32-, and 64-second intervals to probe the NHS until an NHRP registration reply is received. Once an NHRP registration reply is received, the NHS is immediately declared up, and NHRP registration requests return to their regular schedule (one-third of NHRP holdtime or the configured timeout value). This enables the NHS to once again receive NHRP resolution requests. You can use the show ip nhrp nhs detail command to check the status of NHRP NHSs.

  • NHRP in DMVPN: NHRP can be a valuable component in establishing a Virtual Private Network (VPN). In this context, a VPN creates a virtual Layer 3 network layered on top of an actual Layer 3 network. The VPN's topology is independent of the underlying network, and the protocols used over the VPN are also independent. The Dynamic Multipoint VPN (DMVPN) is based on GRE IP logical tunnels that can be enhanced with IPsec to encrypt the GRE IP tunnels for added security.

Understanding NHRP registrations is essential for managing the dynamic aspects of network connectivity, especially in the context of DMVPN and VPNs.

Developmental Phases of DMVPN and NHRP

In this section, we will explore the developmental phases of DMVPN, which combine mGRE, NHRP, and IPsec. Phase 2 is particularly crucial as it offers the functionality required to support dynamic spoke-to-spoke tunnels.

  • Phase 1: This phase exclusively supports hub-and-spoke capability. Spoke-to-spoke tunnels are not supported in Phase 1 and will not be discussed further.

  • Phase 2: Phase 2 introduces spoke-to-spoke capability. NHRP plays a significant role in gathering the necessary information for building spoke-to-spoke tunnels. It achieves this through NHRP resolution request and reply packets, transmitted via the spoke-hub-spoke path across the NBMA network. NHRP initiates the creation of spoke-to-spoke tunnels when data traffic requires them. The two methods employed by NHRP for this purpose are explained in the following sections.

Phase 1

NHRP collects the essential information for constructing spoke-to-spoke tunnels using NHRP resolution request and reply packets sent over the spoke-hub-spoke path within the NBMA network. NHRP's activation is dependent on the detection of data traffic, prompting the establishment of spoke-to-spoke tunnels.

For the proper functioning of an NHRP-based network, the IP routing table and routes learned via the hub are of utmost importance. Hence, the availability of the NHSs (hubs) is critical. If there is only one hub, and it goes offline, the spoke removes the routes obtained from the hub from its routing table because it has lost the hub as its routing neighbor. The spoke does not, however, delete any of the existing spoke-to-spoke tunnels (NHRP mappings). Even though the spoke-to-spoke tunnel remains intact, the spoke cannot utilize it because its routing table lacks a route to the destination network. The spoke has a path (spoke-to-spoke tunnel) but lacks the knowledge to use it due to the absence of a routing table entry.

also, when routing entries are removed, there is no trigger for NHRP to remove NHRP mapping entries. NHRP will eventually time out the existing dynamic NHRP mapping entries that were active when the hub went down, as they are no longer in use. Only then does NHRP remove these mapping entries.

Phase 2

In Phase 2, a scenario may occur where a route in the routing table (which could be a static route) contains the correct IP next hop. In this case, the spoke can still utilize the spoke-to-spoke tunnel even if the hub is unavailable. However, NHRP is unable to refresh the mapping entry because the NHRP resolution request or response would typically need to pass through the hub.

When a single NBMA network (with a single mGRE, Frame Relay, or ATM interface) has two or more NHS hubs, a different situation arises. If the primary hub goes down, the spoke router removes the routes from the routing table learned from this hub. Simultaneously, it begins to learn the same routes (with a higher metric) from the second (backup) hub. Consequently, the spoke-to-spoke traffic continues to flow over the spoke-to-spoke tunnel, unaffected by the primary hub outage.

In Phase 2, NHRP establishes the NHC-to-NHS tunnel, and a dynamic routing protocol is employed to disseminate routing information about all networks available behind the hub and other spokes. This information includes the IP next hop for the specific destination spoke supporting a particular destination network.

When forwarding a data packet, it acquires the outbound interface and IP next hop from the matching routing table network entry. If the NHRP interface serves as the outbound interface, it checks for an NHRP mapping entry associated with that IP next hop. In the absence of a matching NHRP mapping entry, NHRP is activated to send an NHRP resolution request, seeking the mapping information (IP next-hop address to physical layer address). The NHRP registration reply packet contains this mapping information. Upon receiving this data, the spoke possesses sufficient details to encapsulate the data packet accurately, allowing it to travel directly to the remote spoke with just one hop across the infrastructure network. It's worth noting that a drawback of this method is that each spoke must maintain all individual routes in its routing table for all possible destination networks behind the hub and other spokes. This can impose a significant load on the routing protocol running over the VPN.

NHRP Packet Format (RFC 2332 section 5 page 11)

NHRP Fixed header (RFC 2332 section 5.1 page 12)

NHRP Mandatory Part Format (RFC 2332 section 5.2.0.1 page 16)

Source: Cisco NHRP Configuration Guide (opens in a new tab) Reference: RFC 2332 (opens in a new tab)

2 Dmvpn Gre3 Dmvpn Phase I