DMVPN and %DMVPN-3-DMVPN_NHRP_ERROR: Tunnel0: NHRP Encap Error for Resolution Request , Reason: protocol generic error (7) Error

[rmishra22]

  %DMVPN-3-DMVPN_NHRP_ERROR:  Tunnel0: NHRP Encap Error for  Resolution Request , Reason:  protocol generic error (7)

I had pre-allocated tunnel ip's to remote spokes , some of them were implemented and put into production. Some of them got the config but the tunnel interfaces were left at shut.

Its because of this reason that the DMVPN HUB keeps getting nhrp request from one of the inactive spokes.  Following is the sh ip nhrp extract :-

10.x.x22/32

   Tunnel0 created 00:02:58, expire 00:00:06

   Type: incomplete, Flags: negative

   Cache hits: 7

I just cant seem to find the spoke WAN ip to identify it. I tried debugs but just cant get it.

From HUB:-

Nov 30 10:36:31: %DMVPN-3-DMVPN_NHRP_ERROR:  Tunnel0: NHRP Encap Error for  Resolution Request , Reason:  protocol generic error (7) on (Tunnel: 10.x.x.1 NBMA: 20.x.x.x)

Nov 30 10:36:32: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 86

Nov 30 10:36:32:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

Nov 30 10:36:32:      shtl: 4(NSAP), sstl: 0(NSAP)

Nov 30 10:36:32:      pktsz: 86 extoff: 52

Nov 30 10:36:32:  (M) flags: "router auth src-stable nat ", reqid: 46113

Nov 30 10:36:32:      src NBMA: 20.x.x.x.

Nov 30 10:36:32:      src protocol: 10.x.x.1, dst protocol: 10.x.x.22

Nov 30 10:36:32:  (C-1) code: no error(0)

Nov 30 10:36:32:        prefix: 32, mtu: 17912, hd_time: 360

Nov 30 10:36:32:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0 Nov 30 10:36:31: %DMVPN-3-DMVPN_NHRP_ERROR:  Tunnel0: NHRP Encap Error for  Resolution Request , Reason:  protocol generic error (7) on (Tunnel: 10.x.x.1 NBMA: 20.x.x.x)

So my question is , How do i find out the spoke wan ip , so i can do something about it.  For now, its just filling up my logs on HUb router...not good ;-))

[Marcin Latosiewicz]

Hi,

We would need a bit more information about the design.

Typically in phase 2 design we do not expect the hub to SEND resolution request, hub might forward/resolve.

I assume 10.x.x.22 is the tunnel interface? It looks like there is something spending packets towards it.

Most likely a misconfig, but hard to say where without additional scope.

Would you consider opening a TAC SR to confirm this?

Marcin

[rmishra22]

-Hub Tunnel 0 ip = 10.x.x.1

-Spoke Tunnel 0 ip's starting from 10.x.x.3 till as much number of spokes, currently only 5 have been transitioned from legacy p2p gre tunnel to dmvpn.

If a old legacy p2p gre tunnel router/spoke is configured with tunnel 0 ( dmvpn ) config but left in shut mode, it still sends out nhrp requests. This is what i believe is happeneing in my case, just cant seem to findout which spoke , which got the config was never activated yet.

What else can i provide to help you look into this further?

Lets think about a TAC case after sometime, I would be surprised if its a misconfig, as i only get this error related to .22 and its no where configured/mentioned in HUB config.

[Marcin Latosiewicz]

If tunnel interface is shut no NHRP activity should be going, on top, in debugs you point the hub is sending resolution request, not receiving it.

If your hub does not have NHS, it will not know where to send it's resolution request.

Are you positive that there is nothing that is sending packets towards 10.x.x.22 on hub side (sniffer trace of classyfing ACL on "LAN")?

If you know it's not a misconfig and there is no traffic on hub side initiated to 10.x.x.22, try removing and adding full tunnel configuration. i.e. we want to make sure that crypto socket gets closed and restrated.

Marcin

[rmishra22]

Hello Marcin,

If tunnel interface is shut no  NHRP activity should be going, on top, in debugs you point the hub is  sending resolution request, not receiving it.

Agree, I expected the same, but unfortunately this is not the case. Spoke does sent out NHRP requests even with Tunnel status as admin shut.

If your hub does not have NHS, it will not know where to send it's resolution request.

I am still on DMVPN Phase 1, so Spokes dont talk to other spokes yet.

Are  you positive that there is nothing that is sending packets towards  10.x.x.22 on hub side (sniffer trace of classyfing ACL on "LAN")?

Other then a spoke, it cant be anthing, as the subnet is dedicted for tunnel interface's.

If  you know it's not a misconfig and there is no traffic on hub side  initiated to 10.x.x.22, try removing and adding full tunnel  configuration. i.e. we want to make sure that crypto socket gets closed  and restrated.

I can do this over weekend, but i am sure this is not going to fix the problem, reason being, that the HUB was setup before anything else and then we started migrating spokes from primary legacy gre tunnels to dmvpn tunnel as primary and legacy as a backup.

Guess, I am still looking for the answer...Is there a WAN acl that i can use to filter the successfully migrated spokes and log the deny message as in to know what remote wan ip carries along the tunnel ip of .22 or any other debug ??

[Jaid]

I had the same problem and found I had an EBGP neighbor statement trying to establish a BGP connection to a non existent far end router.  Once I shutdown the EBGP connection, the error stopped, because EBGP doesn't rely on an IGP, it doesn't know the DMVPN endpoint doesn't exist and therefore continues to try to establish a connection causing DMVPN to try to resolve a NBMA address that doesn't exist.