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.
Are you trying to ping from the spoke or something behind?
Sent from Cisco Technical Support iPhone App
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.
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.
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.
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.
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.
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.