02-07-2014 01:13 PM - edited 02-21-2020 07:29 PM
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
02-09-2014 12:19 PM
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
02-09-2014 09:47 PM
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.
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