PART-2 covers below mentioned details

  • Understanding various NHRP request and resolution packets
  • Role of ‘ip nhrp rediret’ on hub
  • Role of ‘ip nhrp shortcut’ on spoke

In my earlier post DMVPN Phase III PART 1 , we have already gone through the NHRP registration process between hub & spokes and spoke to spoke dynamic tunnel creation.

We will use the same topology and check few more things in detail.



1. Understanding various parameters in NHRP request and resolution packets

Let’s ping SPOKE-2 tunnel IP ( from SPOKE-1 and check the debug nhrp outputs of SPOKE-1


Before looking at the C-1 (CIE – Client Information Element) lets recap the steps.

Step 1:
SPOKE-1 received traffic indication (redirect) (@ Dec 4 16:56:24.484)
Step 2:
SPOKE-1 sent NHRP resolution request to SPOKE-2 (@ Dec 4 16:56:24.492)
Step 3:
SPOKE-2 received the ICMP echo and sent the resolution request. (debug on SPOKE 2 was not captured)
Step 4:
SPOKE-1 received the resolution request from SPOKE-2 (@ Dec 4 16:56:24.495)
Step 5:
SPOKE-1 sent resolution reply to SPOKE-2 (@ Dec 4 16:56:24.496)
Step 6:
SPOKE-1 received resolution reply from SPOKE-2 (@ Dec 4 16:56:24.506)

Let’s have a close look at the NHRP resolution request and resolution packet.


a.      Mandatory (M) field. (Highlighted in green)
The request and reply has exact same source NBMA and source protocol and destination protocol values. This confirms the reply is being sent for the request generated by the source protocol address & source NBMA address.

b.      Request ID value. (Highlighted in red)
The request ID shows the specific reply is being sent to which particular request. Here the request ID of reply is 2 confirms that it is a reply for the request (carrying request ID 2)

c.     C-1 (CIE – Client Information Element) field in NHRP Resolution Reply (Highlighted in aqua)
This contains the real information. This reply message contains the NBMA address and the tunnel ip address. Using this the Spoke can create the dynamic tunnel between them.

d.     Prefix value inside C-1 (Highlighted in grey)
This contains the prefix or subnet mask of the network of the other end device. This will help in creating the NHRP route in the routing table.

To explain this prefix part, let me ping a subnet ( behind SPOKE-2 and capture only the NHRP resolution reply received on SPOKE-1.


The above debug output shows the NHRP resolution reply received for IP address is carrying subnet mask (prefix) information which creates a NHRP route for that subnet.

2.  Role of ‘ip nhrp redirect’ command on hub

While going through the debug outputs, you might have an idea now what ip nhrp redirect command does in DMVPN Phase III.

When hub gets a packet from spoke on its DMVPN tunnel interface and forwards the packet out via the same tunnel interface, it sends a redirect message to sender indicating that going through hub is sub-optimal. This message is sent via Traffic Indication packet. Upon getting this message the spoke sends a NHRP resolution request directly to the destination IP address and waits for the NHRP resolution reply.

Any guess, what will happen if I remove ‘ip nhrp redirect’ command from hub?

If this command is removed, hub will not send the redirect message (Traffic Indication). Hence spoke will never come to know about the sub optimal path and keep sending the packet towards hub. Hub will be sending the packet out to the other spoke. Neither of the Spoke will initiate a spoke-to-spoke dynamic tunnel.

3.  Role of ‘ip nhrp shortcut’ command on spokes

The ‘ip nhrp shorcut’ command is configured on spokes to honor the redirect message (Traffic Indication) coming from hub and then initiates the dynamic spoke to spoke tunnel by sending NHRP resolution request directly to the remote spoke.

Any guess, what will happen if I remove ‘ip nhrp showrtcut’ command from spoke?

Now I have removed from the spoke, let’s see in the debug.


SPOKE-1#show ip route eigrp 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 a - application route
 + - replicated route, % - next hop override

Gateway of last resort is to network

D [90/27008000] via, 00:01:53, Tunnel0
SPOKE-1#ping source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with a source address of 
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/11 ms
*Dec 9 12:10:27.652: NHRP: nhrp_ifcache: Avl Root:B21696B0
*Dec 9 12:10:27.663: NHRP-ATTR: ext_type: 32772, ext_len : 0 
*Dec 9 12:10:27.663: NHRP-ATTR: ext_type: 32773, ext_len : 0 
*Dec 9 12:10:27.663: NHRP-ATTR: ext_type: 9, ext_len : 0 
*Dec 9 12:10:27.663: NHRP-ATTR: ext_type: 32768, ext_len : 0 
*Dec 9 12:10:27.663: NHRP: Receive Traffic Indication via Tunnel0 vrf 0, 
packet size: 84
*Dec 9 12:10:27.664: NHRP: netid_in = 1, to_us = 0
*Dec 9 12:10:27.664: NHRP: No NHRP subblock found in packet
*Dec 9 12:10:27.664: NHRP: nhrp_rtlookup yielded Loopback1
*Dec 9 12:10:27.664: NHRP: netid_out 0, netid_in 1
*Dec 9 12:10:27.664: NHRP: Parsing NHRP Traffic Indication
*Dec 9 12:10:27.667: NHRP: nhrp_ifcache: Avl Root:B21696B0
*Dec 9 12:10:27.675: NHRP: nhrp_ifcache: Avl Root:B21696B0
*Dec 9 12:10:27.685: NHRP: nhrp_ifcache: Avl Root:B21696B0
*Dec 9 12:10:27.693: NHRP: nhrp_ifcache: Avl Root:B21696B0
SPOKE-1#show dmvpn
 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1 UP 00:02:18 S



As the redirect messages from hub are not honored by spoke, there is no Spoke-2-Spoke tunnel being formed and traffic should always be going through Hub.

Let’s confirm the same via traceroute.


SPOKE-1#traceroute source loopback 1
Type escape sequence to abort.
Tracing the route to
VRF info: (vrf in name/id, vrf out name/id)
 1 3 msec 5 msec 7 msec
 2 7 msec 8 msec 7 msec


I hope this post has helped us in understanding DMVPN phase-III and the requirement of ip nhrp redirect and shortcut commands.

One thought on “DMVPN PHASE III – PART 2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s