cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
746
Views
0
Helpful
2
Replies

DMVPN stopped working! Help!

sdavids5670
Level 2
Level 2

We have a single CISCO2921/K9 and less than 10 spokes (all 881).  Today, abruptly, all of the spokes lost connectivity.  I'm really out of my element with this as I didn't implement this solution and maintaining it is not my responsibility.  I only have my general knowledge and troubleshooting skills to fall back on.  Here are some of the 'show' commands I've issued:

show crypto session

  lists an entry for each of the spokes with "DOWN-NEGOTIATING" in the "Session status" field

show crypto isakmp peers

  nothing

show crypto isakmp sa

  lists a entry for each spoke, all with a state of "MM_KEY_EXCH" with a status of "ACTIVE"

show crypto ipsec sa

  nothing

So at this point, not knowing much about IPSec, I figure it's not completing phase 1.  So I figured that the next thing I should do is turn on isakmp debugging.  I issued:

debug crypto isakmp

debug crypto ipsec

Nothing.  I get nothing.  Then I started wondering if I was even getting traffic from the spokes.  I created an ACL to match the spoke IPs and issued:

debug ip packet 1 detail

Sure enough I'm getting plenty of udp/500 traffic from all of the spokes.  However, nothing in the crypto debugs.  Isn't that strange?  Shouldn't I see something?  I'm wondering if there's a hardware issue with the VPN module. 

show crypto eli

Hardware Encryption : ACTIVE

Number of hardware crypto engines = 1

CryptoEngine Onboard VPN details: state = Active

Capability    : IPPCP, DES, 3DES, AES, IPv6, GDOI, FAILCLOSE, HA

IPSec-Session :     0 active,  3600 max, 0 failed

Any thoughts?  What should I do next?

Thanks,

Steven

2 Replies 2

Jeff Van Houten
Level 5
Level 5

Reload the hub router.

Is there anything between the hub router and the internet? A firewall? An external router? Any changes on those devices?

Sent from Cisco Technical Support iPad App

There's actually a couple of issues.  First, the hub was configured to check a crl but it could not make an HTTP connection to the device which maintains the crl.  This causes the hub to lock up.  I've got a Cisco TAC case open on it.  The TAC engineer is going to investigate to see if it's a bug. I believe that the device stopped accepting connections on tcp/80 because it was under a DoS attack.  There was an unending stream of traffic coming from a device in the United Kingdom and that's not at all normal or expected.  I created an ACL to block that traffic and now the hub is free to talk to the other device so it no longer locks up.  However, the spokes still do not connect unless the revocation check is left off so there's something else going on with that.  In the meantime, we changed revocation checking to none and all of the spokes are able to connect to the hub.