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.
Apparently not in some networks. Someone working in a major European country told me their spoke site addresses change every night.
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.
http://blog.ioshints.info/2007/06/dhcp-response-sets-default-route.html
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.
Typing sh ip nhrp tun 0 I get this output:
172.26.1.2/32 via 172.26.1.2, Tunnel0 created 09:47:17, expire 00:01:22
Type: dynamic, Flags: registered
NBMA address: 92.36.156.10
This is my HUB tunnel
interface Tunnel0
description DMVPN-HUB
ip address 172.26.1.1 255.255.255.0
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 172.26.1.2 255.255.255.0
ip mtu 1440
ip nhrp authentication XXXXXXXX
ip nhrp map multicast dynamic
ip nhrp map 172.26.1.1 HUB PUBLIC IP
ip nhrp map multicast HUB PUBLIC IP
ip nhrp network-id 33
ip nhrp holdtime 120
ip nhrp nhs 172.26.1.1
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!