cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10763
Views
5
Helpful
3
Replies

DMVPN NHRP-3-PAKERROR

Mokhalil82
Level 4
Level 4

Hi

I have setup a DMVPN. I have 2 DMVPN clouds, 2 hubs each terminating each cloud. At the spoke sites I have 2 routers each terminating each DMVPN.

On one of my spoke routers I am getting the following constant log

*Oct 30 00:57:45.092: %NHRP-3-PAKERROR: Received Error Indication from 10.254.2.2, code: protocol generic error(7), (trigger src: 10.254.2.3 (nbma: 213.xx.xx.241) dst: 10.254.2.1), offset: 0, data: 00 01 08 00 00 00 00 00 00 FF 00 79 2B CA 00 34

The hub is 10.254.2.2

The spoke where the log appears is 10.254.2.3

10.254.1.1 is an ip that does not exist any longer. I have 2 hubs, it used to exist on my other hub but no longer. 

The debug shows the following messages

*Oct 30 00:48:53.389: NHRP: Sending NHRP Resolution Request for dest: 10.254.2.1 to nexthop: 10.254.2.1 using our src: 10.254.2.3 vrf:global(0x0)
*Oct 30 00:48:53.389: NHRP: Attempting to send packet through interface Tunnel200 via DEST dst 10.254.2.1
*Oct 30 00:48:53.390: NHRP: Send Resolution Request via Tunnel200 vrf global(0x0), packet size: 121
*Oct 30 00:48:53.390: src: 10.254.2.3, dst: 10.254.2.1
*Oct 30 00:48:53.390: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 213.81.120.98
*Oct 30 00:48:53.390: NHRP: 149 bytes out Tunnel200
*Oct 30 00:48:53.403: NHRP: Receive Error Indication via Tunnel200 vrf global(0x0), packet size: 161
*Oct 30 00:48:53.403: %NHRP-3-PAKERROR: Received Error Indication from 10.254.2.2, code: protocol generic error(7), (trigger src: 10.254.2.3 (nbma: 213.81.120.241) dst: 10.254.2.1), offset: 0, data: 00 01 08 00 00 00 00 00 00 FF 00 79 2B CC 00 34

The tunnel on the spoke is configured as :

interface Tunnel200
description ** DMVPN Tunnel over MPLS **
bandwidth 50000
ip address 10.254.2.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication NhrpAuth
ip nhrp map 10.254.2.2 213.xx.xx.98
ip nhrp map multicast 213.xx.xx.98
ip nhrp network-id 102
ip nhrp holdtime 600
ip nhrp nhs 10.254.2.2
ip nhrp registration no-unique
ip nhrp shortcut
ip tcp adjust-mss 1360
delay 60
nhrp group SPOKE_44MBPS
performance monitor context PrmAM_AVP4_c
keepalive 10 3
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 102
tunnel vrf DMVPN2
tunnel protection ipsec profile DMVPN-PROFILE2
end

sh ip nhrp br

Intf NextHop Address NBMA Address
Target Network T/Flag
-------- ------------------------------------------- ------ ----------------
Tu200 10.254.2.1 213.81.120.98
10.254.2.1/32 D/e

sh dmvpn

Interface: Tunnel200, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
2     213.xx.xx.245       10.254.2.4 UP 00:03:08 D
                                     10.254.2.4 UP 00:03:08 D
2     213.xx.xx.98         10.254.2.1 UP 00:01:50 D
                                     10.254.2.2 UP 00:44:15 S

Does anyone have any ideas what is may be. I have checked and 10.254.2.1 does not exist.

3 Replies 3

Hello

Have you tried clearing the NHRP cache?

clear ip nhrp x.x.x.x

res

Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul

Yes Ive tried clearing nhrp but no luck. After further investigation I found that if I pinged an IP address in that same subnet but one that does not exist, then I would get a Pak error with the IP I tried pinging.

This meant there was something trying to get to 10.254.2.1 and as it was an IP that used to be configured on my primary hub , So I carried out sh show run | inc 10.254.2.1 on the routers

I found a static route on the spoke with a next hop of the 10.254.2.1 which obviously was the culprit. Removed the static and no more PAK Errors

Thanks for the help

devpuniya
Level 1
Level 1

 

I experienced a similar problem, and this is the solution:

Check to see if the spoke router has any routes or IP sla set.

In my situation, I discovered sla set up on the spoke.

10.1.1.1 frequency, IP SLA

The NHRP session was still present, so go to HUB and delete the NHRP session from hub.

ip clear nhrp 10.x.x.1 

Return to the spoke now, and then run 'sh dmvpn'.

This will solve the problem.

 

Review Cisco Networking products for a $25 gift card