IKEv1 DMVPN Phase3 with PSK

Expand all



Contents

IKEv1 DMVPN Phase3 with PSK

Last updated: January 15, 2015

Diagram

Task

  • Configure DMVPN Phase3 between R1, R2, and R3 as follows:
    • Use R1 as the hub.
    • Protect traffic between VLANs 11, 22, and 33.
    • Use EIGRP 123 as routing protocol.
    • Use 3DES/MD5 as cipher/hash for both IPsec phases.
    • Use DH group2 and a pre-shared-key of CISCO.
    • Authenticate NHRP packets using a string of CISCO.
    • Use the minimum overhead possible.

A Note on Task Initial Configuration Files: For this task, you must load the initial configuration files for the DMVPN & GETVPN & IKEv2 module of this section, which can be found in the Section 7 Introduction by clicking the Resources button.

If you have completed previous tasks in this section, the simplest way to revert back to initial configurations is by using the command configure replace nvram:startup-config instead of reloading the devices. This command, however, is not supported by the ASA.

Overview

DMVPN Phase3 is scoped to remediate some design limitations of Phase2 and also enhance performance and scalability:

  • The hub no longer modifies the next-hop value of routing updates when relayed between spokes, which gives you the Phase1 benefit of having the hub send only a default route or a summary to all spokes.
  • It allows for hierarchical DMVPN deployments.
  • It resolves possible design issues with redundant hubs within the same DMVPN cloud.
  • All spoke-to-spoke packets are now CEF switched, even before the spoke-to-spoke tunnel is established, because there are no more incomplete CEF adjacencies.

To achieve all the benefits above, Phase3 adds two new NHRP features:

  • NHRP Redirect is configured on the hub and functions like IP redirect. If the hub receives traffic inbound on its mGRE interface from a spoke and forwards it outbound on the same mGRE interface to another spoke, it sends an NHRP Redirect message to the traffic initiator spoke, forcing it to find a better direct path for spoke-to-spoke traffic via NHRP Resolution Request.
  • NHRP Shortcut is configured on the spoke side and functions as a CEF shortcut: When the NHRP Resolution Request/Reply process between spokes is finished, it forces an update to the CEF table. It basically overrides the next-hop value for a remote spoke network from the default initial hub tunnel IP address to the NHRP resolved remote spoke tunnel IP address, and this is visible both in CEF and RIB.

DMVPN Phase3 includes the following additional NHRP flags:

  • implicit says that the NHRP mapping was learned from an NHRP packet exchange that was not scoped for this entry; on spokes, all NHRP entries for remote spoke tunnel IP addresses are implicit, because in Phase3 the NHRP Resolution Request is not issued for remote spoke tunnel IP addresses.
  • nho means Next-Hop-Override and says that this entry modified the CEF table because shortcut switching is enabled.

When spoke-to-spoke traffic is generated, the following happens:

  • SpokeA initiates traffic towards SpokeB LAN through the hub.
  • The hub forwards the packet to SpokeB and at the same time sends an NHRP redirect message to SpokeA.
  • SpokeA receives the redirect message and sends an NHRP Resolution Request through the hub for LAN network of SpokeB.
  • The hub receives the NHRP Resolution Request message from SpokeA and relays it to SpokeB.
  • SpokeB receives traffic from SpokeA and replies through the hub.
  • The hub forwards the packet to SpokeA and at the same time sends an NHRP redirect message to SpokeB.
  • SpokeB receives the redirect message and sends an NHRP Resolution Request through the hub for LAN network of SpokeA.
  • The hub receives the NHRP Resolution Request message from SpokeB and forwards it to SpokeA.
  • SpokeA and SpokeB negotiate a spoke-to-spoke IPsec tunnel.
  • SpokeB receives the NHRP Resolution Request message from SpokeA and responds directly to SpokeA.
  • SpokeA receives the NHRP Resolution Request message from SpokeB and responds directly to SpokeB.
  • Traffic flows directly between spokes.

As shown in the Verification section, spoke-to-spoke data traffic flows initially through the hub; after control-plane (NHRP and IPsec) converges, data-plane traffic flows directly between spokes, bypassing the hub. From the control-plane perspective as related to NHRP, the behavior is different from DMVPN Phase2. Spoke-to-spoke NHRP Resolution Request flows through the hub, but spoke-to-spoke NHRP Resolution Reply flows directly between spokes, bypassing the hub.

As shown in the debug outputs in the Verification section, when spoke-to-spoke traffic is detected, both spokes send NHRP Resolution Request messages for the remote spoke advertised subnet, not for the remote spoke tunnel IP address. This is exactly the opposite if compared with DMVPN Phase2. This is because in DMVPN Phase3, the hub does not modify the next-hop value when relaying routing updates between spokes. So on spokes, all DMVPN learned subnets will have a next-hop equal to the hub IP address. For this reason, a spoke initiating traffic to a remote spoke advertised network is not aware of the remote spoke tunnel IP address, so it cannot initiate an NHRP Resolution Request for it; instead it generates an NHRP Resolution Request for the remote spoke network. To make a mapping of this difference between Phase2 and Phase3 with other technologies known to us, we can say that:

  • NHRP Resolution Requests in DMVPN Phase2 is done for the next-hop IP address, which is identified from the routing table; this is similar to how Ethernet ARP works for a static route configured with a next-hop IP address.
  • NHRP Resolution Requests in DMVPN Phase3 is done for the destination network being accessed; this is similar to how Ethernet ARP works for a static route configured with a multipoint exit interface.

From the configuration perspective, compared with DMVPN Phase2, we must ensure that the hub changes the next-hop values in routing updates relayed from spoke to spoke. On the hub side we must enable NHRP redirect, and on the spokes side we must enable NHRP shortcut.

Configuration

R1:
crypto isakmp policy 100
 authentication pre-share
 encryption 3des
 hash md5
 group 2
!
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set 3DES_MD5
!
interface Tunnel0
 ip address 100.100.100.1 255.255.255.0
 no ip split-horizon eigrp 123
 ip next-hop-self eigrp 123
 tunnel source Loopback0
 tunnel mode gre multipoint
 ip nhrp network-id 123
 ip nhrp authentication CISCO
 ip nhrp map multicast dynamic
 ip nhrp redirect
 tunnel protection ipsec profile DMVPN
!
router eigrp 123
 no auto-summary
 network 100.100.100.0 0.0.0.255
 network 136.1.11.0 0.0.0.255



R2:
crypto isakmp policy 100
 authentication pre-share
 encryption 3des
 hash md5
 group 2
!
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set 3DES_MD5
!
!
interface Tunnel0
 ip address 100.100.100.2 255.255.255.0
 tunnel source Loopback0
 tunnel mode gre multipoint
 ip nhrp network-id 123
 ip nhrp authentication CISCO
 ip nhrp map 100.100.100.1 150.1.1.1
 ip nhrp map multicast 150.1.1.1
 ip nhrp shortcut
 ip nhrp nhs 100.100.100.1
 tunnel protection ipsec profile DMVPN
!
router eigrp 123
 no auto-summary
 network 100.100.100.0 0.0.0.255
 network 136.1.22.0 0.0.0.255



R3:
crypto isakmp policy 100
 authentication pre-share
 encryption 3des
 hash md5
 group 2
!
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set 3DES_MD5
!
!
interface Tunnel0
 ip address 100.100.100.3 255.255.255.0
 tunnel source Loopback0
 tunnel mode gre multipoint
 ip nhrp network-id 123
 ip nhrp authentication CISCO
 ip nhrp map 100.100.100.1 150.1.1.1
 ip nhrp map multicast 150.1.1.1
 ip nhrp shortcut
 ip nhrp nhs 100.100.100.1
 tunnel protection ipsec profile DMVPN
!
router eigrp 123
 no auto-summary
 network 100.100.100.0 0.0.0.255
 network 136.1.33.0 0.0.0.255

Verification

Initially, there is no spoke-to-spoke traffic. Verify the NHRP mappings and that the routing table changes if compared with Phase2:

R1#show ip nhrp
100.100.100.2/32 via 100.100.100.2
   Tunnel0 created 00:07:35, expire 01:52:24
   Type: dynamic, Flags: unique registered 
   NBMA address: 150.1.2.2 
100.100.100.3/32 via 100.100.100.3
   Tunnel0 created 00:07:32, expire 01:52:28
   Type: dynamic, Flags: unique registered 
   NBMA address: 150.1.3.3
!
!
R1#show ip eigrp 123 neighbors
EIGRP-IPv4 Neighbors for AS(123)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   100.100.100.3           Tu0                      13 00:07:46    2  1512  0  29
0   100.100.100.2           Tu0                      12 00:07:51   12  1512  0  46
!
!
R2#show ip nhrp
100.100.100.1/32 via 100.100.100.1
   Tunnel0 created 00:05:51, never expire 
   Type: static, Flags: used 
   NBMA address: 150.1.1.1 
!
!
R2#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1       150.1.1.1   100.100.100.1    UP 00:05:58     S
!
!
R2#show ip route eigrp 123 | b Gateway
Gateway of last resort is not set

     136.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
D       136.1.11.0/24 [90/26882560] via 100.100.100.1, 01:20:15, Tunnel0
D       136.1.33.0/24 [90/28162560] via 100.100.100.1, 01:20:15, Tunnel0

Verify that R2 has an IPsec tunnel only with the hub:

R2#show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 100.100.100.2, VRF "" 
   Tunnel Src./Dest. addr: 150.1.2.2/MGRE, Tunnel VRF ""
   Protocol/Transport: "multi-GRE/IP", Protect "DMVPN" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv4 NHS:
100.100.100.1  RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1      150.1.1.1   100.100.100.1    UP 00:06:10    S   100.100.100.1/32



Crypto Session Details: 
--------------------------------------------------------------------------------

Interface: Tunnel0
Session: [0x2CBDA744]
  IKEv1 SA: local 150.1.2.2/500 remote 150.1.1.1/500 Active 
          Capabilities:(none) connid:1049 lifetime:23:53:49
  Crypto Session Status: UP-ACTIVE
  fvrf: (none), Phase1_id: 150.1.1.1
  IPSEC FLOW: permit 47 host 150.1.2.2 host 150.1.1.1
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 92 drop 0 life (KB/Sec) 4341709/3229
        Outbound: #pkts enc'ed 91 drop 0 life (KB/Sec) 4341709/3229
   Outbound SPI : 0xB30473C4, transform : esp-3des esp-md5-hmac 
    Socket State: Open

Verify that R2 no longer has an incomplete CEF adjacency for R3's subnet, because the next-hop value from the routing table points to the hub now; it no longer points to the remote spoke. However, the CEF adjacency for R3's tunnel IP address is still adjacency punt because it is a directly connected host in the DMVPN cloud/subnet, which is not resolved through NHRP; therefore, traffic destined to it will be processed switched:

R2#show ip cef 136.1.33.0 internal
136.1.33.0/24, epoch 0, RIB[I], refcount 5, per-destination sharing
  sources: RIB 
  ifnums:
   Tunnel0(13): 100.100.100.1
  path 2CBD95AC, path list 2CF73298, share 1/1, type attached nexthop, for IPv4
  nexthop 100.100.100.1 Tunnel0, adjacency IP midchain out of Tunnel0, addr 100.100.100.1 2C555EC0
  output chain: IP midchain out of Tunnel0, addr 100.100.100.1 2C555EC0 IP adj out of GigabitEthernet0/0.28, addr 136.1.28.8 2C556020
!
!
R2#show ip cef 100.100.100.3 internal
100.100.100.0/24, epoch 0, flags attached, connected, cover dependents, need deagg, RIB[C], refcount 5, per-destination sharing
  sources: RIB 
  subblocks:
   gsb Connected chain head(1): 0x2D2315C8
   Covered dependent prefixes: 3
     need deagg: 2
     notify cover updated: 1
  ifnums:
   Tunnel0(13)
  path 2CBD94CC, path list 2CF73338, share 1/1, type connected prefix, for IPv4
  connected to Tunnel0, adjacency punt
  output chain: punt

Generate spoke-to-spoke traffic and enable debugs on R2 and R1 to identify the NHRP message exchange process; spoke-to-spoke ICMP traffic will not work as we ping a host on the network, which does not exist:

R2#debug nhrp
NHRP protocol debugging is on
!
R2#debug nhrp packet
NHRP activity debugging is on
!
!
R1#debug nhrp
NHRP protocol debugging is on
!
R1#debug nhrp packet
NHRP activity debugging is on
!
R2#ping 136.1.33.3 source gigabitEthernet 0/0.22
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.33.3, timeout is 2 seconds:
Packet sent with a source address of 136.1.22.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
!
R2#ping 136.1.33.30 source gigabitEthernet0/0.22
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.33.30, timeout is 2 seconds:
Packet sent with a source address of 136.1.22.2 
.....
Success rate is 0 percent (0/5)

Investigate NHRP packets on the hub side; only NHRP Resolution Request packets are relayed via the hub, and NHRP Resolution Reply packets are sent directly between spokes. The hub forwards packets out the same mGRE interface it was received on, so it generates an NHRP redirect message to R2:

R1:
NHRP: Tunnels gave us remote_nbma: 150.1.2.2 for Redirect
NHRP: Attempting to Redirect, remote_nbma: 150.1.2.2
NHRP: inserting (150.1.2.2/136.1.33.30) in redirect table
NHRP-ATTR:  Requester Ext Len: Total ext_len  with NHRP attribute VPE 29

NHRP: Attempting to send packet via DEST 136.1.22.2
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 150.1.2.2
NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97
 src: 100.100.100.1, dst: 136.1.22.2
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 97 extoff: 68
 (M) traffic code: redirect(0)
     src NBMA: 150.1.1.1
     src protocol: 100.100.100.1, dst protocol: 136.1.22.2
     Contents of nhrp traffic indication packet:
        45 00 00 64 00 43 00 00 FE 01 75 33 88 01 16 02 
        88 01 21 1E 08 00 5B 5D 00 11 00 
NHRP: 121 bytes out Tunnel0 

R3 responds to the traffic received from R2 through the hub also. The hub issues an NHRP redirect message for R3, because traffic was received and forwarded on the same interface, which is NHRP redirect enabled:

R1:
NHRP: Tunnels gave us remote_nbma: 150.1.3.3 for Redirect
NHRP: Attempting to Redirect, remote_nbma: 150.1.3.3
NHRP: inserting (150.1.3.3/136.1.22.2) in redirect table
NHRP-ATTR:  Requester Ext Len: Total ext_len  with NHRP attribute VPE 29

NHRP: Attempting to send packet via DEST 136.1.33.3
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 150.1.3.3
NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97
 src: 100.100.100.1, dst: 136.1.33.3
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 97 extoff: 68
 (M) traffic code: redirect(0)
     src NBMA: 150.1.1.1
     src protocol: 100.100.100.1, dst protocol: 136.1.33.3
     Contents of nhrp traffic indication packet:
        45 00 00 64 00 46 00 00 FE 01 75 4B 88 01 21 03 
        88 01 16 02 00 00 EB 7F 00 12 00 
NHRP: 121 bytes out Tunnel0 

R2 receives the NHRP redirect message from the hub and sends an NHRP Resolution Request message for R3's remote subnet through the hub, which forwards it to R3:

R2:
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 85
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 85 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 14 
     src NBMA: 150.1.2.2
     src protocol: 100.100.100.2, dst protocol: 136.1.33.3
 (C-1) code: no error(0)
       prefix: 32, mtu: 17882, hd_time: 7200
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 123, to_us = 0
NHRP: nhrp_rtlookup for destination on 136.1.33.3 yielded interface Tunnel0, prefixlen 24
NHRP: netid_out 123, netid_in 123
NHRP-ATTR: In nhrp_recv_resolution_request NHRP Resolution Request packet is forwarded to 136.1.33.3

NHRP: Attempting to forward to destination: 136.1.33.3
NHRP: Forwarding: NHRP SAS picked source: 100.100.100.1 for destination: 136.1.33.3
NHRP: Attempting to send packet via DEST 136.1.33.3
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 150.1.3.3
NHRP: Forwarding Resolution Request via Tunnel0 vrf 0, packet size: 105
 src: 100.100.100.1, dst: 136.1.33.3
 (F) afn: AF_IP(1), type: IP(800), hop: 254, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 105 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 14 
     src NBMA: 150.1.2.2
     src protocol: 100.100.100.2, dst protocol: 136.1.33.3
 (C-1) code: no error(0)
       prefix: 32, mtu: 17882, hd_time: 7200
  addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 129 bytes out Tunnel0 

The NHRP Resolution Reply message from R3 to R2 is sent directly between spokes; it is not visible on the hub side. R3 also receives the NHRP redirect message from the hub and sends an NHRP Resolution Request message for R2's remote subnet through the hub, which forwards it to R2:

R3:
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 85
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 85 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 12 
     src NBMA: 150.1.3.3 protocol: 100.100.100.3, dst protocol: 136.1.22.2
 (C-1) code: no error(0)
       prefix: 32, mtu: 17916, hd_time: 7200
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 123, to_us = 0
NHRP: nhrp_rtlookup for destination on 136.1.22.2 yielded interface Tunnel0, prefixlen 24
NHRP: netid_out 123, netid_in 123
NHRP-ATTR: In nhrp_recv_resolution_request NHRP Resolution Request packet is forwarded to 136.1.22.2

NHRP: Attempting to forward to destination: 136.1.22.2
NHRP: Forwarding: NHRP SAS picked source: 100.100.100.1 for destination: 136.1.22.2
NHRP: Attempting to send packet via DEST 136.1.22.2
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 150.1.2.2
NHRP: Forwarding Resolution Request via Tunnel0 vrf 0, packet size: 105
 src: 100.100.100.1, dst: 136.1.22.2
 (F) afn: AF_IP(1), type: IP(800), hop: 254, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 105 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 12 
     src NBMA: 150.1.3.3
     src protocol: 100.100.100.3, dst protocol: 136.1.22.2
 (C-1) code: no error(0)
       prefix: 32, mtu: 17916, hd_time: 7200
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 129 bytes out Tunnel0 

On the spoke side, it first receives the NHRP Redirect message from the hub, so the spoke does not initially send an NHRP Resolution Request message as in Phase2:

R2:
NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 97 extoff: 68
 (M) traffic code: redirect(0)
     src NBMA: 150.1.1.1
     src protocol: 100.100.100.1, dst protocol: 136.1.22.2
     Contents of nhrp traffic indication packet:
        45 00 00 64 00 46 00 00 FE 01 75 4B 88 01 16 02 
        88 01 21 03 08 00 E3 7F 00 12 00 
NHRP: netid_in = 123, to_us = 0
NHRP: nhrp_rtlookup yielded GigabitEthernet0/0.22
NHRP: netid_out 0, netid_in 123
NHRP: Parsing NHRP Traffic Indication

At this point, R2 is instructed by the hub to send an NHRP Resolution Request for the remote spoke subnet, and it does so via the hub:

R2:
NHRP: Sending NHRP Resolution Request for dest: 136.1.33.3 to nexthop: 100.100.100.1 using our src: 100.100.100.2
NHRP: Attempting to send packet via DEST 100.100.100.1
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 150.1.1.1
NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85
 src: 100.100.100.2, dst: 100.100.100.1
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 85 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 14 
     src NBMA: 150.1.2.2
     src protocol: 100.100.100.2, dst protocol: 136.1.33.3
 (C-1) code: no error(0)
       prefix: 32, mtu: 17882, hd_time: 7200
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 109 bytes out Tunnel0 

At the same time, R2 receives an NHRP Resolution Request from R3, also sent via the hub. You can see this in the TTL, which has a value of 254 and a message saying This is a forwarded packet:

R2:
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105
 (F) afn: AF_IP(1), type: IP(800), hop: 254, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 105 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 12 
     src NBMA: 150.1.3.3
     src protocol: 100.100.100.3, dst protocol: 136.1.22.2
 (C-1) code: no error(0)
       prefix: 32, mtu: 17916, hd_time: 7200
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 123, to_us = 0
NHRP: nhrp_rtlookup for destination on 136.1.22.2 yielded interface GigabitEthernet0/0.22, prefixlen 24
NHRP: netid_out 0, netid_in 123
NHRP-ATTR: smart spoke and attributes are not configured 
NHRP-ATTR: In nhrp_process_recv_resolution_request eem_decision : TRUE, time : 0, LINE: 6955
NHRP: This is a forwarded packet

R3 directly responds to R2 with an NHRP Resolution Reply message, which can be seen in the source/destination IP of the packet:

R3:
NHRP: Send Resolution Reply via Tunnel0 vrf 0, packet size: 133
 src: 100.100.100.2, dst: 100.100.100.3
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 133 extoff: 60
 (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 12 
     src NBMA: 150.1.3.3
     src protocol: 100.100.100.3, dst protocol: 136.1.22.2
 (C-1) code: no error(0)
       prefix: 24, mtu: 17882, hd_time: 7200
       addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
       client NBMA: 150.1.2.2
       client protocol: 100.100.100.2
NHRP: 157 bytes out Tunnel0 

Finally, R2 receives the NHRP Resolution Reply directly from R3. This can be seen in the TTL, which has a value of 255 and therefore has not been relayed:

NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 133
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 133 extoff: 60
 (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 14 
     src NBMA: 150.1.2.2
     src protocol: 100.100.100.2, dst protocol: 136.1.33.3
 (C-1) code: no error(0)
       prefix: 32, mtu: 17916, hd_time: 7200
       addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
       client NBMA: 150.1.3.3
       client protocol: 100.100.100.3
NHRP: netid_in = 0, to_us = 1

Notice the flags present in the NHRP mapping of the remote spoke:

R2#show ip nhrp 136.1.33.0
136.1.33.0/24 via 100.100.100.3
   Tunnel0 created 00:00:21, expire 01:59:38
   Type: dynamic, Flags: router used rib nho
   NBMA address: 150.1.3.3 

Verify that the NHO bit from the NHRP mapping resulted in an NHO in the RIB/CEF table and traffic between spokes is direct, bypassing the hub:

R2#show ip route next-hop-override | s 136.1.33.0
D   %    136.1.33.0/24 [90/28162560] via 100.100.100.1, 01:09:31, Tunnel0
                       [NHO][90/1] via 100.100.100.3, 00:01:59, Tunnel0
!
!
R2#show ip cef 136.1.33.0
136.1.33.0/24
  nexthop 100.100.100.3 Tunnel0

Verify that a spoke-to-spoke direct tunnel has been established:

R2#show dmvpn peer network 136.1.33.0/24 detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 100.100.100.2, VRF "" 
   Tunnel Src./Dest. addr: 150.1.2.2/MGRE, Tunnel VRF ""
   Protocol/Transport: "multi-GRE/IP", Protect "DMVPN" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv4 NHS:
100.100.100.1  RE priority = 0 cluster = 0
Type:Unknown, Total NBMA Peers (v4/v6): 1

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1      150.1.3.3   100.100.100.3    UP 00:04:16  DT2      136.1.33.0/24



Crypto Session Details: 
--------------------------------------------------------------------------------

Interface: Tunnel0
Session: [0x2CBDA744]
  IKEv1 SA: local 150.1.2.2/500 remote 150.1.3.3/500 Active 
          Capabilities:(none) connid:1074 lifetime:23:55:43
  Crypto Session Status: UP-ACTIVE
  fvrf: (none), Phase1_id: 150.1.3.3
  IPSEC FLOW: permit 47 host 150.1.2.2 host 150.1.3.3
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 1 drop 0 life (KB/Sec) 4179668/3343
        Outbound: #pkts enc'ed 10 drop 0 life (KB/Sec) 4179666/3343
   Outbound SPI : 0x904017FB, transform : esp-3des esp-md5-hmac 
    Socket State: Open
^ back to top