Re: NHRP encapsulation error

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

Re: NHRP encapsulation error

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?

Re: NHRP encapsulation error

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 NHRPNHRP is a layer two resolution protocol and cache likeARP or Reverse ARP (Frame Relay)It is used in DMVPN to map a tunnel IP address to anNBMA addressLike ARP, NHRP can have static and dynamic entries

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

Re: NHRP encapsulation error

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

Re: NHRP encapsulation error

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:

Re: NHRP encapsulation error

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?

The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
view more

The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
view more

IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...
view more