DMVPN: Non-Unique NHRP Registrations

During my last DMVPN webinar, one of the students mentioned the need for non-unique NHRP registrations in environments where the public IP address of a DMVPN spoke site changes due to DHCP lease expiration or PPPoE session termination. Finally I found some time to recreate the scenario in my DMVPN lab; here are the results.

Default Behavior

Next-Hop Resolution Protocol (NHRP) was designed for large layer-2 switched network environments (example: ATM networks with SVC support). In those environments, the layer-2 address of a site never changes and thus NHRP clients uses unique registrations by default; the mapping between IP address (protocol address in terms of RFC 2332) and underlying layer-2 address (RFC 2332: NBMA address) is not supposed to change.

NHRP clients set the uniqueness bit in the registration packets and Next-Hop Server (NHS) subsequently refuses all registration packets that try to set a different NBMA address for an already-known protocol address.

Impact on DMVPN Networks

In DMVPN world, protocol address is tunnel interface’s IP address and NBMA address is the IP address of the tunnel source (usually the outside – Internet-facing – interface). The tunnel interface flaps when the IP address on the outside interface changes, triggering NHRP registration request, but the registration requests are rejected by the NHS until the old registration expires (registration hold time is set by the client and configured with the ip nhrp holdtime interface configuration command).

Non-Unique Registrations

If you’re experiencing DMVPN downtime due to changing public IP addresses of your DMVPN spokes, apply the ip nhrp registration non-unique interface configuration command to the DMVPN tunnel interface. This command will reduce the recovery time to less than a minute. Faster recovery is harder to achieve as the router has to execute a number of steps following a physical interface flap:

  • Install new static routes to the hub sites;
  • Create IPSec session with the hub sites;
  • Register new public IP address with NHRP;
  • Establish routing adjacency.

You can fine-tune steps 1-3 on the spoke router; step 4 sometime requires coordinated changes throughout the network.


  1. But usually, you would get the same IP address back after DHCP lease expiration or PPPoE session restart. I have always seen a static IP address from the SP to the clients. Nonetheless, non-unique keyword is a good trick. And as u mentioned, it will still stuff up IPSec and routing.
  2. "you would get the same IP address back"

    Apparently not in some networks. Someone working in a major European country told me their spoke site addresses change every night.
  3. Just to agree with what Ivan said.
    Unless I have asked for a static IP address assignment (and pay a monthly subscription fee for that service) I will get a new IP addresses in most cases if I disconnect my PPPoE (over xDSL) and reconnect again.
  4. Obviously, ISPs in Aus work differently than in Europe. We get static IP addresses for our ADSL connections. On the other hand, ADSL (PPPoE) connections for an enterprise spoke site (although inexpensive) is not very common compared to SHDSL which are a norm and have static IPs. DMVPN connections on the latter are heard of. :-D
  5. I have been wondering how to do the real dynamic addressed DMVPN spoke for a while. Just figured it out after reading Ivan's post of
    IOS dhcp client will have a default route to the default gateway provided by dhcp server.

    Amazingly, this behavior is still true even you are using a front vrf which you put the WAN interface to a vrf and make it as dhcp client also. It will install a default route to the default gateway in the vrf RT. I just tested it in a CISCO ISR 881 spoke and CISCO ISR 871 as hub. All are good and working as expected.
  6. In another example of parallel thinking processes, I did exactly the same thing (DHCP-based route in VRF) two days ago when developing configs for my Enterprise MPLS/VPN webinar and was as surprised as you were to see it work flawlessly.
  7. So we have to enter the ip nhrp registration non-unique only on the Spokes?

    Typing sh ip nhrp tun 0 I get this output: via, Tunnel0 created 09:47:17, expire 00:01:22
    Type: dynamic, Flags: registered
    NBMA address:

    This is my HUB tunnel

    interface Tunnel0
    description DMVPN-HUB
    ip address
    no ip redirects
    ip mtu 1440
    no ip next-hop-self eigrp 333
    ip nhrp authentication XXXXXXXXX
    ip nhrp map multicast dynamic
    ip nhrp network-id 33
    ip nhrp holdtime 120
    ip nhrp registration no-unique
    no ip split-horizon eigrp 333
    tunnel source GigabitEthernet0/0
    tunnel mode gre multipoint
    tunnel key 0
    tunnel protection ipsec profile SPOKES shared

    This is the Spoke, later there will be more spokes

    interface Tunnel0
    ip address
    ip mtu 1440
    ip nhrp authentication XXXXXXXX
    ip nhrp map multicast dynamic
    ip nhrp map HUB PUBLIC IP
    ip nhrp map multicast HUB PUBLIC IP
    ip nhrp network-id 33
    ip nhrp holdtime 120
    ip nhrp nhs
    ip nhrp registration no-unique
    tunnel source Dialer0
    tunnel destination HUB PUBLIC IP
    tunnel key 0
    tunnel protection ipsec profile HUB

    I typed tunnel protection ipsec profile SPOKES shared on the HUB, as you can see.

    Do I really have to add this command (shared) when I have multiple Spoke routers?

    Do I have to add something on the tunnel in order to optimize the DMVPN cloud?

    The spokes have dynamic IPs (PPPoE).

    Thank you!
  8. "ip nhrp registration non-unique" is required on the NHRP client, not on NHS.
Add comment