11-30-2011 03:07 AM - edited 02-21-2020 05:44 PM
%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 ;-))
11-30-2011 05:17 AM
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
11-30-2011 11:12 AM
-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.
12-01-2011 12:22 AM
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
12-01-2011 05:10 AM
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 ??
08-13-2023 11:18 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide