DMVPN and NHRP debug commands

March 31, 2019

Warning: Undefined variable $match_no_and in /home/kennie/www/www/wordpress/wp-content/plugins/crp-taxonomy/includes/filters.php on line 245

Please see the full RFC2332 for complete information pertaining to NHRP. What I am going to document here is some commands and their outputs for some various scenario’s.

Scenario 1 – R4 is the NHS (Next Hop Server). R3 is the NHC (Next Hop Client). R3 will have a static route towards the NBMA of R4. R3 will have a static mapping for the NHS address.

R4’s IP addresses are 192.1.4.4/24 for the Ethernet interface and the Tunnel IP address for DMVPN will be 10.1.1.4/24.

R3’s IP address is 192.1.3.3/24 for the Ethernet interface and the Tunnel IP address for DMVPN will be 10.1.1.3/24

Some basic debugs to run on R4 would be the following

Debug nhrp cache

Debug nhrp packet

Below is an output of these debugs running:

R4#
*Mar 31 12:45:46.676: NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 92
*Mar 31 12:45:46.676: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Mar 31 12:45:46.676: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 31 12:45:46.676: pktsz: 92 extoff: 52
*Mar 31 12:45:46.676: (M) flags: “unique nat “, reqid: 3
*Mar 31 12:45:46.676: src NBMA: 192.1.3.3
*Mar 31 12:45:46.676: src protocol: 10.1.1.3, dst protocol: 10.1.1.4
*Mar 31 12:45:46.676: (C-1) code: no error(0)
*Mar 31 12:45:46.676: prefix: 32, mtu: 17916, hd_time: 7200
*Mar 31 12:45:46.676: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 31 12:45:46.676: NHRP: Tunnel0: Cache add for target 10.1.1.3/32 next-hop 10.1.1.3
*Mar 31 12:45:46.676: 192.1.3.3
*Mar 31 12:45:46.676: NHRP: Inserted subblock node for cache: Target 10.1.1.3/32 nhop 10.1.1.3
*Mar 31 12:45:46.676: NHRP: Converted internal dynamic cache entry for 10.1.1.3/32 interface Tunnel0 to external
*Mar 31 12:45:46.676: NHRP: Tunnel0: Cache update for target 10.1.1.3/32 next-hop 10.1.1.3
*Mar 31 12:45:46.676: 192.1.3.3
*Mar 31 12:45:46.676: NHRP: Updating our cache with NBMA: 192.1.4.4, NBMA_ALT: 192.1.4.4
*Mar 31 12:45:46.676: NHRP: Send Registration Reply via Tunnel0 vrf 0, packet size: 112
*Mar 31 12:45:46.676: src: 10.1.1.4, dst: 10.1.1.3
*Mar 31 12:45:46.676: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Mar 31 12:45:46.676: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 31 12:45:46.676: pktsz: 112 extoff: 52
*Mar 31 12:45:46.676: (M) flags: “unique nat “, reqid: 3
*Mar 31 12:45:46.676: src NBMA: 192.1.3.3
*Mar 31 12:45:46.676: src protocol: 10.1.1.3, dst protocol: 10.1.1.4
*Mar 31 12:45:46.676: (C-1) code: no error(0)
*Mar 31 12:45:46.676: prefix: 32, mtu: 17916, hd_time: 7200
*Mar 31 12:45:46.676: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 31 12:45:46.676: NHRP: Setting ‘used’ flag on cache entry with nhop: 10.1.1.3
R4#
*Mar 31 12:45:46.676: NHRP: NHRP successfully mapped ‘10.1.1.3’ to NBMA 192.1.3.3
R4#

Useful commands to check the status could be the following from R4

show ip nhrp brief

2. show ip nhrp detail

3. show ip nhrp dynamic

4. show ip nhrp multicast

5. show ip nhrp redirect

6. show ip nhrp summ

7. show ip nhrp traffic

8. show ip nhrp tunnel 0

Most of these can also be ran on the NHC. Additionally these might be useful on the NHC’s

show ip nhrp nhs

2. show ip nhrp static

I will post the remaining commands together since we have seen them for the NHS

Packet Captures

This shows the summary of the Packet Capture values. Things to note are that the IP Src and Dst are the NBMA values. Followed by the GRE Header. And finally the NHRP Information

If we drill further into the NHRP Registration Request Packet:

The two most significant fields to start with are the NHRP Fixed and the NHRP Mandatory portion.

In the NHRP Fixed header we get information such as the Address Family Number which for this is IPv4. The Protocol Type is IPv4. Version is 1 which is RFC2332. And the type of NHRP Packet is type 4 called the NHRP Registration Reply.

The Mandatory Part has a lot of the significant values specific to each NHC and NHS.

I have called out some of the values important in this scenario. However, for a full understanding refer to RFC2332. The Uniqueness Bit would be significant if the clients were to use DHCP or change their NBMA often. For this lab they will be Unique so the flag can be true.

The Request ID is to ensure the NHC and NHS are referring to the same Request. Each Request ID must be different.

The Source NBMA address would be the IP address for the sending device on its underlay network.

The “Protocol Address” is the DMVPN IP address. In this situation the NHC R3 has a Tunnel IP address of 10.1.1.3 and the NHS R4 has a Tunnel IP of 10.1.1.4.

Finally to note is the Holding time of 7200 which is the default of 2 hours. This is the default time. To change this from the NHC you can enter the command “ip nhrp holdtime xx” on the tunnel interface. Where xx is the hold time in seconds.

For the NHRP Registration Reply from the NHS here is the packet summary. It is an IP packet with a GRE Header and NHRP information inside of it.

We can see the NHRP Fixed Header is the same general information with the exception of the NHRP Packet Type is 4 which is the Registration Reply.

The Mandatory header again has the more specific for this actual interaction. The Registration Reply.

Pointing out the specifics for this scenario

Note that the Source NBMA is the Ethernet IP of the NHS. The Source Protocol is the DMVPN or Tunnel IP address of the NHS and the Destination Protocol is the DMVPN or Tunnel IP address of the NHC. And the Code is 0 for Success.

NOTE: One important item that is not in the configuration or the packet captures is the default timeout value for the tunnel registration. By default this is one third of the hold time configured. (This means changing the hold time changes the registration timeout.) If the default holdtime is configured, the the default registration timeout will be 2400 seconds which is 40 minutes. So if something occurs to the tunnel it will be 40 minutes before the tunnel tries to register again with default timers. In a production environment this could be very damaging. If you will be performing changes that might interrupt the GRE Tunnel it might be a good idea to reduce the timeout prior to making the changes.

NOTE2: Also if you look into the packets you will not that the Network-ID is not in the capture. You can use this to determine that the Network-ID is in fact locally significant. If it was not it would be in the packet capture. The Network-ID for R4 (NHS) and and R3 (NHC) do not have to match.

Additional debug from R5 being added to this network

*Mar 31 15:21:52.058: NHRP: Tunnel0: Cache add for target 10.1.1.5/32 next-hop 1 0.1.1.5
*Mar 31 15:21:52.058: 192.1.5.5
*Mar 31 15:21:52.058: NHRP: Tunnel0: Cache add for target 10.1.1.4/32 next-hop 1 0.1.1.4
*Mar 31 15:21:52.058: 192.1.4.4
*Mar 31 15:21:53.055: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c hanged state to up
*Mar 31 15:21:53.055: NHRP: Tunnel0: Cache update for target 10.1.1.4/32 next-ho p 10.1.1.4
*Mar 31 15:21:53.055: 192.1.4.4
*Mar 31 15:21:53.055: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 92
*Mar 31 15:21:53.055: src: 10.1.1.5, dst: 10.1.1.4
*Mar 31 15:21:53.055: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Mar 31 15:21:53.055: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 31 15:21:53.055: pktsz: 92 extoff: 52
*Mar 31 15:21:53.055: (M) flags: “unique nat “, reqid: 1
*Mar 31 15:21:53.055: src NBMA: 192.1.5.5
*Mar 31 15:21:53.055: src protocol: 10.1.1.5, dst protocol: 10.1.1.4
*Mar 31 15:21:53.055: (C-1) code: no error(0)
*Mar 31 15:21:53.055: prefix: 32, mtu: 17916, hd_time: 7200
*Mar 31 15:21:53.055: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 31 15:21:53.056: NHRP: Receive Registration Reply via Tunnel0 vrf 0, packet size: 112
*Mar 31 15:21:53.056: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Mar 31 15:21:53.056: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 31 15:21:53.056: pktsz: 112 extoff: 52
*Mar 31 15:21:53.057: (M) flags: “unique nat “, reqid: 1
*Mar 31 15:21:53.057: src NBMA: 192.1.5.5
*Mar 31 15:21:53.057: src protocol: 10.1.1.5, dst protocol: 10.1.1.4
*Mar 31 15:21:53.057: (C-1) code: no error(0)
R5(config-if)#end
R5#
*Mar 31 15:21:53.057: prefix: 32, mtu: 17916, hd_time: 7200
*Mar 31 15:21:53.057: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

Two great IPv6 Goodies This posts provides some great commands lines to utilize with IPv6 to see the status of IPv6 neighbors such as show ipv6 neighbor and show ipv6 cef exact-route.
Who doesn't need a little PPPoE love in their day The following post provides the configuration of PPPoE. It provides the lab requirements and a drawing. It also provides line by line configuration along with some wireshark captures.
OSPFv3 with Address Family Verification Commands to verify OSPFv3 information when configured with IPv6.
MPLS VPNV4 with and Without BGP IPv4 Default Unicast Routing This post will provide wireshark outputs of a MPLS network configured both with and without Unicast BGP default enabled.

I think he probably no longer provides training. I couldn't find his new site. I removed the link. Thanks for…

https://jaziri.training/ Above does not open...

There are a few differences between the three books. I would say a good 60-70% of the content is the…

I passed the 5.1 written. I've taken the lab once so far. Unfortunately, I just had to move, so that…

INE Recommendation: 'IPv6 Theory, Protocol, and Practice' and 'Implementing Cisco IPv6 Networks'.But am sure its lot of the same information...…

DMVPN and NHRP debug commands

March 31, 2019

Related Posts:

Leave a Reply Cancel reply

Our Pages