Summary

  • RFC 2333 treated NHRP as address resolution built on a routing decision, not as a routing protocol and not as an end-to-end reachability test.
  • Applicability depended on topology, shortcut cost, application needs, NHRP participation and loop-safety assumptions; deciding that NHRP was suitable did not mean a shortcut had been requested or installed.
  • A registration acknowledgement, an authoritative resolution reply and a cache entry each recorded bounded control-plane state with provenance, policy and lifetime; none proved an ATM virtual circuit or packet flow.
  • RFC 2332 preserved routed forwarding while resolution was pending and defined NAK, purge and error paths because successful data service could not be inferred from the existence of a mapping mechanism.
  • Operational proof had to advance through separate stages: route, applicability, mapping, connection, forwarding, remote service and application result.

The most reassuring row was only a map

An operations screen can turn a layered system into one green line.

For NHRP, the line might contain a protocol address, an NBMA address, an authoritative flag and a remaining holding time. It can be tempting to read that combination as “the next hop is up.” The protocol documents never granted the row that meaning.

RFC 2333 was written as an applicability statement. Its central question was not whether an NHRP packet had a valid format. It was whether the mechanism was suitable in a particular NBMA environment and for a particular traffic decision. That distinction immediately limits what later state can prove.

A system can be an appropriate place to use NHRP and still have no current shortcut. A client can possess a valid mapping and still lack an established connection. A connection can exist and still carry no successful IP traffic. Packets can reach a host whose application is unavailable.

The cache row belongs near the beginning of that sequence, not at its end.

Routing spoke before NHRP

RFC 2333 was explicit: NHRP is not a routing protocol.

Ordinary network-layer routing first determines the path toward a destination. If that path uses an NBMA interface, NHRP may resolve the destination or an appropriate exit router into the corresponding NBMA-layer address. Where several exits are available, a dynamically routed NHRP domain reflects the choice made by the routing system.

This ordering matters.

NHRP did not independently certify that the selected egress was best. It inherited a routed decision for an epoch. The routing system might prefer fewer original IP hops, but that preference was not a measurement of every property an application could care about. It did not necessarily minimize latency, price, congestion or failure correlation.

Nor did an NHRP reply freeze the route that produced it. RFC 2333 warned that rapidly changing routed paths could make shortcuts short-lived and, in some router-to-router cases, could contribute to persistent loops.

The resolved address was therefore downstream of routing authority. It could help realize a shortcut based on that authority; it could not replace, authenticate or permanently preserve the route decision.

A shortcut was a choice, not a default truth

NHRP generalized the Classical IP over ATM model.

Inside one Logical IP Subnet, ATMARP could map an IP address to an ATM address. Communication to a different LIS normally crossed an IP router even if both endpoints shared the same physical ATM fabric and a direct virtual circuit was technically possible. NHRP supplied an inter-LIS resolution mechanism that could avoid those extra IP hops within a logical NBMA network. For a destination outside that network, it could return the current egress router's NBMA address.

RFC 2333 did not claim that every possible shortcut should be built.

For a brief exchange with no unusual quality-of-service need, connection setup and retained state could cost more than hop-by-hop forwarding. The cost might be monetary, computational or a strain on network-interface and switching resources. The application or operator therefore had to decide whether the shortcut's utility justified its state.

That made applicability a decision about conditions and trade-offs. It was not an observation that the data path already existed.

The RFC even proposed a restraint on who should initiate shortcuts: the originating host, the first router whose routed next hop was reachable through the NBMA interface, or a required policy router. Without that discipline, several points along an ordinary routed path might each create their own shortcut for the same traffic.

An applicability judgment consequently established permission to try a mechanism under a defined policy. Permission was not execution.

The router-to-router boundary exposed the danger

Host-to-host, host-to-router and router-to-host communication fit the stated model. Router-to-router use revealed a sharper limitation.

Base NHRP could produce persistent forwarding loops when the underlying routing protocol lost information needed for loop suppression, for example across changes in routing metrics between autonomous systems. The applicability statement treated a stable, directly adjacent destination behind the egress as a safer special case.

The Q bit in a request identified a router as the requester. If the destination was not directly adjacent to the egress under the required stable condition, a safe response was a negative reply. Packets would then remain on the routed path.

That negative answer was not a failure of the network's purpose. It preserved a path whose authority remained with routing instead of manufacturing a shortcut whose loop safety had not been established.

This is one of RFC 2333's most important operational lessons. A protocol can be available, a destination can be routable, and a shortcut can still be the wrong state to create.

Registration recorded custody, not liveness

RFC 2332 supplied the message machinery behind the applicability statement.

An NHRP Client could send a Registration Request so that a serving Next Hop Server would retain its protocol-to-NBMA mapping. The NHS processed the request only after error checking and any applicable policy checks. It could refuse because it could not serve the address, lacked resources, was administratively prohibited from accepting it or found a uniqueness conflict.

A successful Registration Reply therefore had real meaning. It showed that the NHS accepted the mapping information under its rules at that time.

It did not show that an end-to-end virtual circuit had been established. It did not probe the destination application. It did not verify that every intermediate NHRP server had synchronized the newest state. It did not prove that a route still pointed through the same logical NBMA domain.

Registration was a custody event in an address-resolution service. Reading it as a remote-health event would assign the NHS knowledge it did not possess.

The refresh rule reinforced that limit. A client had to resend registrations often enough to preserve them despite packet loss, and the specification recommended an interval derived from the advertised Holding Time. Accepted state was expected to age.

A reply carried authority, but not every authority

A Resolution Reply answered a mapping question.

The source first used normal routing to determine a next hop. When it lacked usable resolution state and that next hop was reachable through an NBMA interface, it issued an NHRP request toward the destination. A serving NHS could return the destination's NBMA address when the destination was attached to the logical NBMA network, or the relevant egress router's address for an off-network destination.

RFC 2332 distinguished authoritative and non-authoritative information. A transit NHS could, where allowed, reply from cached non-authoritative state. A client could ask for an authoritative response from the server responsible for the destination.

Authority improved the answer to the question actually asked. It did not broaden the question.

An authoritative reply could be the best available statement of the mapping under NHRP's serving relationship. It did not say that ATM signaling would accept a switched virtual circuit. It did not say that the circuit had the requested bandwidth. It did not say that an ACL, closed user group or address-screening rule would permit communication. RFC 2332's definition of a logical NBMA subnetwork itself assumed unfiltered subnetwork connectivity; the presence of filters could divide what appeared physically shared.

The reply established where a client might try. It did not report what happened after the attempt.

Cache provenance prevented one row from meaning one thing

The NHRP cache was not populated by one exclusive path.

An NHS could learn mappings from registration, resolution exchanges, preconfigured tables, ARP or mechanisms outside RFC 2332. An NHC could learn from replies, manual configuration or other mechanisms. A management view that displayed only “present” would erase those differences.

RFC 2677 made some of the missing context observable. It described cache type, the source and use of an entry, negotiated MTU, holding-time validity and remaining lifetime. A learned entry with a valid Holding Time should disappear when the timer reached zero. An administratively added row could have an undefined lifetime because it might live in non-volatile configuration.

Those are not cosmetic metadata.

A manually configured row and a fresh authoritative reply may contain the same visible address pair while supporting different judgments. A synchronized NHS copy can be useful without proving that the originating client is still reachable. A negative cached answer can prevent repeated lookup pressure without proving permanent impossibility.

The cache is a collection of claims with sources and expiry rules. Treating all rows as identical observations converts a protocol database into a fiction of current reachability.

Purge and error messages kept the mapping revisable

RFC 2332 included Purge messages so stations could invalidate cached next-hop information. It also defined errors for loops, unreachable protocol addresses, invalid replies, authentication failure and exhausted hop count.

These paths reveal the intended posture of the protocol.

A mapping was not a timeless naming assertion. It was operational state subject to topology, policy, resources, security checks and time. The protocol needed a way to retract or reject state because conditions could change after it was learned.

Server synchronization did not remove that uncertainty. SCSP and the NHRP-specific profile in RFC 2335 helped multiple servers distribute and reconcile mappings. Synchronization answered a consistency problem among servers. It did not transform the synchronized value into a fresh packet probe.

Several NHSs can agree on an expired reality if the source information has not yet been corrected. Agreement is evidence about replication, not necessarily about the external system described.

Resolution and connection setup were separate acts

The strongest boundary appears in RFC 2332's own description of a connection-oriented NBMA network.

After resolving the NBMA next hop, a source on ATM might first establish a connection with the desired bandwidth. By contrast, a connectionless NBMA service could allow the source to begin sending packets directly. The protocol description therefore did not collapse address resolution into link establishment.

That separation is easy to lose in modern language. “Resolved” often sounds like “reachable.” Here it meant that an address-mapping stage had supplied an input to the next stage.

ATM signaling could still fail. Resources could be unavailable. The remote interface could reject setup. Negotiated properties could differ from an application's need. A virtual circuit could form while IP forwarding or the return path remained wrong.

Even packet exchange was not the final layer. The remote host might answer at IP while a particular service was stopped. A transport handshake might succeed while an application transaction failed. None of those later outcomes could be written backward into the NHRP reply.

Routed forwarding was the safety path

RFC 2332 allowed a source waiting for resolution to drop the triggering packet, retain it, or forward it along the routed path. It recommended routed forwarding as the default because data might continue to flow while the client searched for a more direct path.

RFC 2333 gave the same architecture a scalability consequence. If an NHRP Request encountered a router that did not understand NHRP, the request could be silently discarded. The shortcut would not be built, but connectivity could remain available hop by hop.

This fallback is not merely a convenience. It preserves a distinction between service continuity and optimization.

NHRP's purpose was to shorten a routed path under suitable conditions. Failure to shorten did not necessarily mean failure to deliver. Conversely, a successful shortening signal did not prove delivery.

A dashboard that uses one indicator for both shortcut state and end-to-end health would make both failure modes harder to diagnose.