Whenever I enable my crypto map on both sides of a serial interface, I get the following error:
"CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at <IP Address>"
This started happening all of a sudden with no changes to anything on my part.
The only thing that happened when this was working was a power failure at the location where the router is. When power was recovered a few minutes later, this crypto map hasnt worked since. I have disabled the crypto map to allow the interface to continue functioning. Anyone know why this is occuring?
I know that you say that there were no changes on your part, but something must have changed. Do you have control of both routers, or just the router on your end? Is it possible that something changed on the other end?
When I hear description of a power failure and router behavior changing one of the first things I look for is the possibility that changes were made (perhaps long in the past) that were not written to NVRAM so that when the router boots it is loading the "old" config with the old behavior? Is it possible that is what happened here?
Regardless of what caused it, you have an issue where crypto and IPSec are not working and you need to find a solution. Most likely it is caused by some mismatch between the crypto configuration of the two routers. I would start by verifying that the same shared key is configured on both routers - and perhaps by removing the current key configuration and configuring it fresh. If it still does not work I would look closely at the crypto parameters configured and make sure that they match.
If you try that it is still is not working then the next step would probably be to post the configuration from both sides. And running the debug for crypto isakmp might also be helpful.
It is possible that an old config may have been loaded after the power outage. I do have control of both routers. I compared that config with the config that should be there and I did see one thing wrong at the router in question...it had a line in the config that I do not recognize and never used before. There is a line that says "no fair-queue" on the serial interace. I have never used this command and dont know why it appeared.
The no fair-queue sometimes shows up in the config, especially on the first serial interface. I believe that it is an artifact of the router attempting auto-install. It is highly unlikely to be related to this problem.
I suggest that you access both routers and use show running-config to verify that the config on both routers is what you expect it to be (and that the crypto parts do match) and to verify that the shared key is the same on both ends (assuming that you are using shared key). It might also be worthwhile to do show version on each router and verify that they are running the code version that you expect. I recently saw an instance where router behavior changed at reboot because someone had replaced the old image with a new image in flash
The output of show crypto map from both routers might be helpful.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...