skip to content

In multipoint GRE with NHRP, how does one spoke learn another spoke's public address to build a direct tunnel, and what part does the hub play?

level: seniorimportance: should knowfreq 15%

answer

  1. one tunnel interface, many destinations
  2. the hub is a directory
  3. register first, then resolve
  4. one-third of the Holding Time

basics

~20 s

Each spoke registers its tunnel and public addresses with the hub, an NHRP Next Hop Server. To reach another spoke it sends an NHRP Resolution Request; the Resolution Reply carries that spoke's public address, and a direct GRE tunnel follows.

solid answer

~50 s

Multipoint GRE gives each router one tunnel interface with no fixed destination; the outer destination for each packet comes from a cache that maps overlay addresses to underlay addresses, which NHRP (RFC 2332) calls NBMA addresses. NHRP fills that cache. Each spoke is a Next Hop Client: it sends an NHRP Registration Request to the hub, the Next Hop Server, and must refresh it — the RFC recommends every one-third of the Holding Time — or the entry expires. When spoke A needs spoke B's subnet, it sends a Resolution Request; the NHS serving B returns a Resolution Reply with B's public address and a Holding Time, and A builds a direct GRE tunnel, normally under IPsec. Meanwhile the RFC's recommended default is to keep forwarding along the routed path, through the hub, so traffic never waits. The hub stays the directory and the fallback path.

go deeper

for a junior

Recall that the hub keeps a directory of spokes' public addresses, and spokes ask it so they can tunnel directly to each other.

for a middle

Explain the Next Hop Server and Client roles, the registration and resolution messages, and why one multipoint interface replaces many point-to-point tunnels.

for a senior

Walk the first packet between two spokes, the Holding Time refresh and expiry, what a hub failure breaks, and how IPsec and NHRP authentication stop forged registrations.

for a principal

Decide where on-demand spoke-to-spoke tunnels pay off against a plain hub-and-spoke or a full mesh, weighing hub capacity, redundancy and how many shortcuts spokes can hold.

## Why point-to-point GRE stops scaling A point-to-point GRE tunnel has one configured destination. Connecting every pair of *n* sites needs n(n−1)/2 tunnels — 1,225 for 50 sites — each configured on both ends. Connecting every site only to a hub keeps the configuration small but sends all branch-to-branch traffic through the hub, doubling its load and the path's latency. Which shape a network should have is a topology decision; **multipoint GRE with NHRP** is the mechanism that lets a hub-and-spoke configuration build spoke-to-spoke tunnels on demand. One vendor's name for this design, DMVPN, is the one most engineers know. ## Multipoint GRE: one interface, a mapping cache On a **multipoint GRE** interface, every router in the overlay sits in one shared subnet, for example `172.16.0.0/24`, and the interface has **no fixed destination**. For each packet, the router takes the overlay next hop — say `172.16.0.12` — and looks up which **underlay** (public) address to put in the delivery header — say `203.0.113.12`. Something has to fill that mapping cache, and that is NHRP. ## NHRP's roles and messages The **Next Hop Resolution Protocol** (RFC 2332) was written for non-broadcast multi-access (**NBMA**) networks, where a station cannot broadcast to discover its neighbours. A GRE overlay across the internet has the same property, so the design treats the routers' public addresses as their NBMA addresses. - **Next Hop Server (NHS)** — answers resolution requests and holds registrations: the hub. - **Next Hop Client (NHC)** — registers itself and asks for resolutions: each spoke. | Type | Message | Purpose | |---|---|---| | 1 | NHRP Resolution Request | Ask for the NBMA address towards a destination | | 2 | NHRP Resolution Reply | Return the NBMA address and its Holding Time, or a NAK | | 3 | NHRP Registration Request | Tell the NHS "this overlay address is at this NBMA address" | | 4 | NHRP Registration Reply | Accept the registration, or refuse it with a NAK | | 5 | NHRP Purge Request | Invalidate cached mappings that are no longer true | | 6 | NHRP Purge Reply | Acknowledge a purge | | 7 | NHRP Error Indication | Report a problem with a received NHRP packet | ## Spoke-to-spoke resolution, step by step 1. Each spoke starts with one static fact: the hub's overlay and public addresses. 2. Each spoke sends a **Registration Request** to the hub, mapping its overlay address to its public address with a **Holding Time**. RFC 2332 recommends re-sending it at **one-third of the Holding Time**, so the registration survives an occasional lost packet; when the Holding Time expires, the cached entry **SHALL** be discarded. 3. Routing runs over the overlay, so spoke A learns that `10.2.0.0/24` lies behind spoke B. 4. A's first packet for `10.2.0.0/24` triggers a **Resolution Request** carrying the destination. RFC 2332 says a request must not be triggered on every packet. 5. While it waits, RFC 2332 lets A drop the packet, hold it, or forward it along the routed path; **forwarding via the routed path — here, the hub — is the recommended default**, so traffic flows during resolution. 6. The NHS that serves B answers with an authoritative **Resolution Reply** containing B's public address and a Holding Time. 7. A installs the mapping and sends later packets in GRE straight to B's public address, under IPsec in practice. The shortcut lasts as long as the mapping stays valid. ## Operating it - **The hub is the control point.** It holds every registration, answers resolutions and carries traffic until shortcuts exist; designs run two hubs and register spokes with both. - **Routing adjacencies form spoke-to-hub.** Implementations replicate multicast routing traffic from the hub to every registered spoke; spokes normally do not peer with each other. - **Mappings age out.** A spoke that stops refreshing disappears when its Holding Time ends, and a **Purge Request** removes stale mappings sooner. - **The underlay must stay out of the overlay.** Every public address a spoke learns must remain reachable through the internet path, never through the overlay, or the tunnels recurse. ## Securing it RFC 2332 gives NHRP a hop-by-hop **Authentication Extension**, a keyed hash with HMAC-MD5-128 as the default algorithm. Its security considerations warn that without it NHRP entities are open to spoofing, and that NHRP has no encryption of its own, assuming a layer-3 confidentiality mechanism. From a defender's side, a forged registration could map a victim's overlay address to the wrong public address and pull its traffic. Running GRE — and NHRP inside it — under IPsec authenticates every peer before any registration is believed.

  • In multipoint GRE with NHRP, what happens to spoke-to-spoke traffic when the only hub fails?
    Spokes learned their routes to each other through adjacencies with the hub, so those routes disappear and the shortcuts stop being used. New resolutions and registrations fail, and cached mappings age out at their Holding Time. That is why designs run a second hub and spokes register with both.
  • Why does multipoint GRE with NHRP need IPsec or NHRP authentication?
    Without authentication, a forged Registration Request could map a victim's overlay address to the wrong public address and draw its traffic away. RFC 2332 defines a hop-by-hop Authentication Extension and states that NHRP has no encryption, assuming a layer-3 confidentiality mechanism; in practice IPsec protects GRE and NHRP together.
  • What does an NHRP Purge Request do?
    It tells a station to invalidate cached mappings that are no longer valid, for example when a registration is withdrawn, so peers stop sending to a stale public address before its Holding Time would have expired. It is NHRP packet type 5, answered by a Purge Reply unless the requester says none is expected.

saying these in an interview costs you the question

  • Each spoke keeps a static GRE tunnel configured to every other spoke.
  • A spoke must drop or hold packets until its NHRP Resolution Reply arrives.
  • Once registered, an NHRP mapping stays valid until the spoke reboots.
  • NHRP encrypts its own messages, so multipoint GRE needs no IPsec.
  • A spoke sends an NHRP Resolution Request for every packet to a remote subnet.