NHRP encapsulation error

[o.elmohri]

I'm configuring a point to multipoint which is the following:

interface Tunnel1

ip address 10.0.0.2 255.255.255.0

no ip redirects

ip mtu 1440

ip hold-time eigrp 90 120

ip nhrp authentication <key>

ip nhrp map multicast <public ip>

ip nhrp network-id 1

ip nhrp nhs 10.0.0.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 0

end

And I'm getting the following error:

*Mar  1 01:40:47.695: NHRP: Setting retrans delay to 64 for nhs  dst 10.0.0.1

*Mar  1 01:40:47.695: NHRP: Attempting to send packet via DEST 10.0.0.1

*Mar  1 01:40:47.699: NHRP: Send Registration Request via Tunnel1 vrf 0, packet size: 83

*Mar  1 01:40:47.699:       src: 10.0.0.2, dst: 10.0.0.1

*Mar  1 01:40:47.699: NHRP: Encapsulation failed for destination 10.0.0.1 out Tunnel1

*Mar  1 01:41:37.751: NHRP: Setting retrans delay to 64 for nhs  dst 10.0.0.1

*Mar  1 01:41:37.755: NHRP: Attempting to send packet via DEST 10.0.0.1

*Mar  1 01:41:37.755: NHRP: Send Registration Request via Tunnel1 vrf 0, packet size: 83

*Mar  1 01:41:37.755:       src: 10.0.0.2, dst: 10.0.0.1

*Mar  1 01:41:37.759: NHRP: Encapsulation failed for destination 10.0.0.1 out Tunnel1

Any suggestion about this?

Regards,

[Federico Coto Fajardo]

The ''sh ip route'' on either router shows the 10.0.0.x network as directly connected via the tunnel interface?

Both tunnel interfaces are up/up correct?

Federico.

[o.elmohri]

Yes sure, the route is in both routers and the interfaces so they are in up/up state

[Federico Coto Fajardo]

Ok, the strange thing is that you mentioned:

the show interface tunnel 1 doesn't show inputs (on the spoke)

But you do see inputs on the tunnel interface on the Hub correct?

No inputs on the tunne1 interface shows the tunnel is not established correctly.

Is it possible for you to post the entire configs?

Federico.

[Federico Coto Fajardo]

What is the output of ''sh dmvpn detail'' on both routers? (if running 12.4(9)T or later)

I think your problem is still related to NHRP
NHRP is a layer two resolution protocol and cache like
ARP or Reverse ARP (Frame Relay)
It is used in DMVPN to map a tunnel IP address to an
NBMA address
Like ARP, NHRP can have static and dynamic entries

Please attach the following:
On the Spoke: show ip nhrp nhs detail
On the hub: show ip nhrp

Federico.

[o.elmohri]

Here is the other show commands:

(Note that I changed the tunnel IP of the spoke from 10.0.0.2 to 10.0.0.3 just to follow the LAN as 192.168.3.x)

DMVPN-Branch#show ip nhrp nhs detail

Legend:

  E=Expecting replies

  R=Responding

Tunnel1:

  10.0.0.1          E  req-sent 1232  req-failed 1  repl-recv 0

Pending Registration Requests:

Registration Request: Reqid 1, Ret 64  NHS 10.0.0.1

AND:

HUB#sh ip nhrp 10.0.0.3

10.0.0.3/32 via 10.0.0.3, Tunnel1 created 14:46:45, expire 01:25:49

  Type: dynamic, Flags: unique registered used

  NBMA address:

    (Claimed NBMA address: 10.5.1.150)

[o.elmohri]

Here is the configuration of the spoke:

DMVPN-Branch#sh run

Building configuration...

Current configuration : 1650 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname DMVPN-Branch

!

boot-start-marker

boot-end-marker

!

enable password cisco

!

no aaa new-model

!

resource policy

!

memory-size iomem 5

ip subnet-zero

ip cef

!

no ip dhcp use vrf connected

!

no ip ips deny-action ips-interface

!

no ftp-server write-enable

!

crypto isakmp policy 30

encr 3des

authentication pre-share

group 2

crypto isakmp key absurdlong address 0.0.0.0 0.0.0.0

no crypto isakmp ccm

!

crypto ipsec transform-set strong esp-3des esp-md5-hmac

!

crypto ipsec profile cisco

set security-association lifetime seconds 86400

set transform-set strong

!

interface Tunnel1

ip address 10.0.0.3 255.255.255.0

no ip redirects

ip mtu 1440

ip hold-time eigrp 90 120

ip nhrp authentication

ip nhrp map multicast dynamic

ip nhrp map 10.0.0.1

ip nhrp map multicast

ip nhrp network-id 1

ip nhrp nhs 10.0.0.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 0

!

interface Loopback1

description THIS SIMULATES THE LAN

ip address 192.168.3.1 255.255.255.0

!

interface FastEthernet0/0

ip address 10.5.1.150 255.255.255.0

duplex auto

speed auto

no cdp enable

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

router eigrp 90

redistribute connected

network 10.0.0.0

network 192.168.2.0

no auto-summary

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.5.1.1

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

line aux 0

line vty 0 4

password cisco

login

!

end

[Federico Coto Fajardo]

Do you still see this output on the hub?

10.0.0.2/32, Tunnel1 created 00:01:03, expire 00:02:01

  Type: incomplete, Flags: negative

  Cache hits: 2

There still no hits on the tunnel interface on the spoke?

Federico.

[o.elmohri]

Federico,

On the hub I can see hits before the flag registred user, the hits ar getting from 2, 4 to 6 each time I ping from the spoke:

HUB(config-if)#do sh ip nhrp

10.0.0.3/32, Tunnel1 created 00:00:31, expire 00:02:33

  Type: incomplete, Flags: negative

  Cache hits: 6

Next I get this output:

HUB(config-if)#do sh ip nhrp

10.0.0.3/32 via 10.0.0.3, Tunnel1 created 00:01:09, expire 01:59:39

  Type: dynamic, Flags: unique registered used

  NBMA address:

    (Claimed NBMA address: 10.5.1.150)

[o.elmohri]

Hi Federico,

There is another point that, may be it's affecting the tunnel.

As right now, in the Hub. There is another router which is connected to the one where is the DMVPN. In other words, the is the ISP router connected to a leased line which is used as Ethernet connection to the Tunnel termination router.

Is there any MTU at IP or TCP level do you think that it's not correct??

[Federico Coto Fajardo]

If all the interfaces thorughout the path are Ethernet, the maximum MTU should not exceed 1518 bytes.
Ethernet maximum frame size = 1518 bytes

PMTUD can help discover the MTU along the path by sending packets with the DF bit set so the routers
in the path will not fragment the packet.
PMTUD will discover the maximum MTU that can be used along the way without having to fragment the packets.

You already have set a MTU of 1440 on the tunnel interfaces.
You can try lowering the MTU to say 1400 just to be safe.

The worst case is that the routers will fragment the packets which cause a lot of processing overhead.
Where fragmentation happens, it's better if it happens before encryption, so that the receiving router
is only responsible to decrypt the packets and leave the reassembly of the packets to the destination
end host.

What I found strange is that you cannot PING between tunnel interfaces yet, so what you can do is the
following:

access-list 150 permit ip host 10.0.0.1 host 10.0.0.2
access-list 150 permit ip host 10.0.0.2 host 10.0.0.1
debug ip packet 150 detail

If you can apply the above configuration on both hub and spoke, you should see the results of the debugs
that should let us know more details about the problem.

Federico.

[o.elmohri]

Hi Federico,

Here is the debug:

HUB#

*Apr 20 09:03:39.433: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 60, sending, proto=88ping 10.0.0.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:

*Apr 20 09:03:42.909: IP: tableid=0, s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), routed via FIB

*Apr 20 09:03:42.909: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 100, sending

*Apr 20 09:03:42.909:     ICMP type=8, code=0.

*Apr 20 09:03:44.433: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 60, sending,

*Apr 20 09:04:20.413: IP: tableid=0, s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), routed via FIB

*Apr 20 09:04:20.413: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 100, sending

*Apr 20 09:04:20.413:     ICMP type=8, code=0

*Apr 20 09:04:22.325: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 60, sending, proto=88

*Apr 20 09:04:22.413: IP: tableid=0, s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), routed via FIB

*Apr 20 09:04:22.413: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 100, sending

*Apr 20 09:04:22.413:     ICMP type=8, code=0.

*Apr 20 09:04:24.413: IP: tableid=0, s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), routed via FIB

*Apr 20 09:04:24.413: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 100, sending

*Apr 20 09:04:24.413:     ICMP type=8, code=0.

*Apr 20 09:04:26.413: IP: tableid=0, s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), routed via FIB

*Apr 20 09:04:26.413: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 100, sending

*Apr 20 09:04:26.413:     ICMP type=8, code=0

*Apr 20 09:04:26.981: IP: s=10.0.0.1 (local), d=10.0.0.3 (Tunnel1), len 60, sending, proto=88.

Success rate is 0 percent (0/5)

HUB#

DMVPN-Branch#ping

*Mar  1 00:09:03.579: %SYS-5-CONFIG_I: Configured from console by vty0 (10.5.1.104)10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

*Mar  1 00:09:05.947: IP: tableid=0, s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), routed via FIB

*Mar  1 00:09:05.951: IP: s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), len 100, sending

*Mar  1 00:09:05.951:     ICMP type=8, code=0.

*Mar  1 00:09:07.947: IP: tableid=0, s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), routed via FIB

*Mar  1 00:09:07.947: IP: s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), len 100, sending

*Mar  1 00:09:07.947:     ICMP type=8, code=0.

*Mar  1 00:09:09.947: IP: tableid=0, s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), routed via FIB

*Mar  1 00:09:09.947: IP: s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), len 100, sending

*Mar  1 00:09:09.951:     ICMP type=8, code=0.

*Mar  1 00:09:11.947: IP: tableid=0, s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), routed via FIB

*Mar  1 00:09:11.947: IP: s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), len 100, sending

*Mar  1 00:09:11.951:     ICMP type=8, code=0.

*Mar  1 00:09:13.947: IP: tableid=0, s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), routed via FIB

*Mar  1 00:09:13.947: IP: s=10.0.0.3 (local), d=10.0.0.1 (Tunnel1), len 100, sending

*Mar  1 00:09:13.947:     ICMP type=8, code=0.

Success rate is 0 percent (0/5)

Today I'll try to install a sniffer between the HUB and the WAN router and the Spoke and the Internet connection and see what can give us.

Regards,

[o.elmohri]

I did a sniffing on the HUB. But the only packets that I got to the 10.0.0.3 were the NHRP and the EIGRP and not the ping unless I was running a ping on the router!!

[Federico Coto Fajardo]

The sniffing shows NHRP and EIGRP packets but no ICMP packets?

It does not make sense since NHRP is L2, but EIGRP travels over L4 RTP and ICMP is a L3 protocol.

How did you perform the sniffer?

Hub = 10.0.0.1

Branch = 10.0.0.3

There should be a direct communication between both tunnel interfaces.

For this to work, the GRE tunnel should be up between the tunnel interfaces.

The problem we're seeing is the tunnel interface on the branch router that you don't see any packets correct?

Federico.

[o.elmohri]

Hi,

Here is the placement of the sniffer:

HUB LAN |-------------| NHRP SERVER ROUTER |---------------| Switch w/SPAN and sniffer |------------------| INTERNET ROUTER |------------(INTERNET)------->>

I run a continue ping to 10.0.0.3 from the NHRP server router and I tried to sniff for 5 minutes, and the strage point is that I found no ICMP packet!

[Federico Coto Fajardo]

Since you're still not getting any ICMP packets to the Branch router, let's check the status of the NHRP mappings.
Could you possibly capture the conversation between two routers with the sniffer to check where is the failure?

Federico.