NHRP encapsulation error

Unanswered Question
Apr 12th, 2010

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,
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4 (1 ratings)
coto.fusionet Mon, 04/12/2010 - 04:29

Hi,

Are you setting up a DMVPN?

Do you have IP connectivity between the two routers?

NHRP encapsulation fails most likely is a L2 issue.

Can you PING 10.0.0.1 sourcing the PING from the tunnel interface 10.0.0.2?

Please elaborate a bit on your setup.

Federico.

o.elmohri Mon, 04/12/2010 - 04:57

Federico,

I got the problem when I try to ping the other side 10.0.0.2.

Here is the server side configuration:

interface Tunnel1

ip address 10.0.0.1 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 network-id 1

no ip split-horizon eigrp 90

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 0

o.elmohri Mon, 04/12/2010 - 06:16

Yes it's with IPSec, and I removed the profile to test the tunnel before.

Right now I have no problem with the encapsulation. And I still cannot ping, here is the both sides configuration of the tunnel:

HUB:

interface Tunnel1

ip address 10.0.0.1 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 network-id 1

no ip split-horizon eigrp 90

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 0

end

Spoke:

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

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

end

coto.fusionet Mon, 04/12/2010 - 06:20

NHRP is working fine now?
If the answer is yes, then most likey there are no L2 issues.
What about L3? (you cannot PING)
Are you pinging 10.0.0.1 from 10.0.0.2 (i mean making sure the source of the PING packet goes from 10.0.0.2?)


Please attach the output of the sh interface t1 on both units.

Federico.

o.elmohri Mon, 04/12/2010 - 06:33

I have the following output of the command debug nhrp packet (on the spoke):

*Mar  1 00:43:01.735: NHRP: No node found.

*Mar  1 00:43:01.739: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel1 netid-out 1

*Mar  1 00:43:01.739: NHRP: Checking for delayed event 0.0.0.0/10.0.0.2 on list (Tunnel1).

*Mar  1 00:43:01.739: NHRP: No node found.

*Mar  1 00:43:01.747: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel1 netid-out 1

*Mar  1 00:43:01.747: NHRP: Checking for delayed event 0.0.0.0/10.0.0.2 on list (Tunnel1).

*Mar  1 00:43:01.751: NHRP: No node found.

*Mar  1 00:43:01.751: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel1 netid-out 1

*Mar  1 00:43:01.755: NHRP: Checking for delayed event 0.0.0.0/10.0.0.2 on list (Tunnel1).

*Mar  1 00:43:01.755: NHRP: No node found.

DMVPN-Branch#sh ip nhrp

10.0.0.1/32 via 10.0.0.1, Tunnel1 created 00:41:08, never expire

  Type: static, Flags: authoritative used

  NBMA address:

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

  Type: incomplete, Flags: negative

  Cache hits: 2

o.elmohri Mon, 04/12/2010 - 07:51

Do you think that NAT is doing something wrong right here?

Here is the map of our topology:

Hub router (public IP) ||---|| WAN Router ||---||-------Internet-----------||---|| NAT router ||---|| (private IP) Spoke router

Any suggestion?

coto.fusionet Mon, 04/12/2010 - 07:54

You're not NATing the tunnel IP address are you?

What is the output of the ''sh interface tunnel 1''

Do you see on the Hub and arp entry for the spoke (through the tunnel interface)?

Federico.

o.elmohri Mon, 04/12/2010 - 07:59

Here is the show interface tunnel 1:

Tunnel1 is up, line protocol is up

  Hardware is Tunnel

  Internet address is 10.0.0.1/24

  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source (FastEthernet0/0), destination UNKNOWN

  Tunnel protocol/transport multi-GRE/IP

    Key 0x0, sequencing disabled

    Checksumming of packets disabled

  Tunnel TTL 255

  Fast tunneling enabled

  Tunnel transmit bandwidth 8000 (kbps)

  Tunnel receive bandwidth 8000 (kbps)

  Last input 00:00:01, output 00:00:01, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/0 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     482 packets input, 43244 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     471 packets output, 43860 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

The output seems to be OK. But there is no ARP entry for the spoke!!

coto.fusionet Mon, 04/12/2010 - 08:04

As a side note you might want to change the bandwidth on the tunnel interface from the default 9 Kbit.

Is the NAT router NATing the tunnel IP of the spoke router?

Federico.

o.elmohri Mon, 04/12/2010 - 09:13

Hi,

Yes, the router on the spoke is doing NAT, as the router is connected as a host in an internal router. For the final solution it will not in the same case, but still behinde a router that's doing NATting.

Also, both sides (hub and spoke) are doing NAT for internet traffic at the same time. And there is exception (ACL deny for the traffic between the two sides). The hub router is in production, but the spoke is not, so there is no NAT in it for the moment.

For changing the BW, it's OK. But I think that's not causing a problem at this point. right?

Regards,

Omar

coto.fusionet Mon, 04/12/2010 - 09:16

The bandwidth should not be causing this problem correct. (just to keep in mind).

The tunnel should be established between Hub & Spoke, so the tunnel's IP should not be NATed.

Do you see a translation for the IPs of the tunnel (10.0.0.1 and 10.0.0.2) on the NAT router?

You can check with the command ''sh ip nat translation''

Federico.

o.elmohri Mon, 04/12/2010 - 09:20

No Federico,

There is not translation on the HUB router to the other side.

The ip nat outside is only on the inside and the physical outside interface.

o.elmohri Mon, 04/12/2010 - 08:02

On the spoke router, the show interface tunnel 1 doesn't show inputs.

coto.fusionet Mon, 04/12/2010 - 09:23

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 Mon, 04/12/2010 - 09:32

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

coto.fusionet Mon, 04/12/2010 - 10:34

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.

coto.fusionet Mon, 04/12/2010 - 12:35

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 Tue, 04/13/2010 - 00:54

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 Tue, 04/13/2010 - 00:49

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

coto.fusionet Tue, 04/13/2010 - 20:21

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 Wed, 04/14/2010 - 01:21

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 Sun, 04/18/2010 - 02:06

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??

coto.fusionet Sun, 04/18/2010 - 11:26

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 Tue, 04/20/2010 - 02:20

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 Tue, 04/20/2010 - 04:51

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!!

coto.fusionet Tue, 04/20/2010 - 13:10

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 Wed, 04/21/2010 - 02:41

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!

coto.fusionet Wed, 04/21/2010 - 07:19

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.

o.elmohri Sun, 05/02/2010 - 06:46

Hi,

I finaly did the sniffing on the spoke side.

But, all pings from that router can monitor a reply. And not the one through 10.0.0.1 (the hub tunnel side) unless the public IP of the hub can show a reply.

Any idea??

ropakalns Mon, 08/23/2010 - 04:19

Just in case somebody else runs into the same problem. I resolved it with a shut/no shut on tunnel interfaces...

ropakalns Tue, 08/24/2010 - 03:25

Also, try to check authentication key, because it will show you that something is wrong with authentication only if you enable debug nhrp packet

Actions

Login or Register to take actions

This Discussion

Posted April 12, 2010 at 3:56 AM
Stats:
Replies:32 Avg. Rating:4
Views:4655 Votes:0
Shares:0

Related Content

Discussions Leaderboard