The spoke can't ping the DMPVN NHS but do pings the NBMA address

[Mike Masalla]

Hi there,

I just wonder if any of you guys has gone through similar experience. I am working on a DMVPN problem, where only one spoken can't ping the NHS adddress, while it can bing the NBMA address. Around 100-spokes are working fine.

I do not have access to the Hub router, the only access I have is to the spokes. I run some debugs on the spoke which had the problem and found no errors. The "show ip nhrp packet" says the spoke is sending registration requests but receives nothing.

The physical link is definitely up, I can see the prefixes I am getting from BGP IP/MPLS. I can ping the Hub NBMA address.

Appreciate your input.

Mike

[Diego Armando Cambronero Arias]

Are you trying to ping from the spoke or something behind?

Sent from Cisco Technical Support iPhone App

[RYAN BARNES]

Check your crypto is established and correctly set as NHRP rides inside IPSec. The spoke NHRP request should trigger IPSec to initiate, but you won't get a response from the hub if your initial negotiation fails.

Phase I - "show crypto isa sa" - you want to see "QM_IDLE".   "MM_No_State" isn't what you want to see.

Phase II - "show crypto session"  or "show crypto ipsec sa"

This has to occur prior to NHRP actually being able to contact the NHS.

[Mike Masalla]

Thanks rbarne1 for your input, tt sounds interesting, but it confliects with two Cisco documents on troubleshooting DMVPN, where both identify the physical network as the first thing you start with on isolating DMVPN problem.

As far as "show crypto isakmp sa" concern, what i see is  MM_No_State.

Based on what you said, I need to identify the Crypto problem. Any recommendation which debug and what to look for on debug output. Please note, I am using CA signed by IOSCA.

Many thanks.

Mike

[Jason Gervia]

Mike,

On the spoke that you can't bring up, try a

debug crypto isakmp

debug crypto ipsec

To see if the VPN is being completed.  If you're getting a "MM_NO_STATE" that means that the VPN is *not* up and that is why you aren't getting NHRP replies and can't ping the hubs tunnel address

Those debugs should reveal what the VPN issue is so it can be corrected.

--Jason

[RYAN BARNES]

Hey Mike,

Well, I'm not one to go against official Cisco docs, but you did mention you could ping the NBMA address of the hub, which I assume is over the physical network.

If you can post the output of the debugs that Jason suggested it might indicate where the issue is. One other thing you can to check is a 'show crypto isakmp sa' on the hub router as well and see you can find a corresponding entry of "MM_NO_STATE' there for the spokes NBMA address. Thats an easy way (without debugs on the hub) which will confirm the hub is indeed participating in the ISAKMP negotiation, but failing... that confirms at least you've got some sort of dialogue between the two boxes as opposed to the spoke sending IKE into a black hole. Then the next step is sorting out IKE which might have something to do with cert validity...the ike debug should indicate if that's the issue.

[Mike Masalla]

Gentlemen.

I really appreciate your input. The problem is resolved by downgrading the IOS image of the new spoke to make it identical to the other spokes. It makes no sense, but it is the reality.

[RYAN BARNES]

Thanks for the update Mike. Actually, I attended Live! this year and the presenter mentioned there is indeed differences in the way the negotiation is handled between software versions, as they occasionally change their strategies with protocol handling. Glad you figured it out, and thanks for posting a resolution.

Not sure if you can access or not, but the presentation by Mike Sullenberger - BRKSEC-4052: Advanced Concepts of Dynamic Multipoint VPN is available in Cisco Live! 2011 which alluded to this.

www.ciscolivevirtual.com

Cheers,

Ryan