I've run into a situation with a new SPA-IPSEC-2G. Last night we tried to migrate the first tunnel onto this SPA. The tunnel that was moving was migrating off of identical hardware but it is running 12.2(33)SRA7. We tried clearing the SAs and deleting and rebuilding the other end (PIX 506) but we kept getting the same debug output from the 7613. That debug is included in this post. I should also note that we added this hardware over a year ago and it failed then. A TAC case was opened and they determined it was a bug in the code we were running at the time. (12.2(33)SRA2) We have since upgraded the code twice and are trying to utilize the hardware again.
This morning I migrated a tunnel that was up and running to the lab SPA-IPSEC-2G that is in a 7606 running the same proc and code as the 7613 that is failing. The tunnel failed to come up with the same debug output from the debug crypto isakmp command. My next course of action is to try swapping out the SPA-IPSEC-2G in the 7613 with the one that is currently in the lab since we know that is good hardware. Before I do that though, I was hoping to get some feedback from the group here. Has anyone seen this scenario before? Does it smack of a hardware issue to anyone else?
The included config is virtually identical to what was running fine in the lab. I think I grabbed everything pertinent to this tunnel.
7613 SUP720-3BXL 12.2(33) SRB7
ip access-list extended IPSEC-labtest permit ip 192.168.200.0 0.0.0.255 192.168.1.0 0.0.0.255
crypto isakmp profile IPSEC-labtest vrf test keyring IPSEC-labtest match identity address <some_ip_address> 255.255.255.252
crypto map IPSEC-labtest local-address Loopback0 crypto map IPSEC-labtest 10 ipsec-isakmp set peer <some_ip_address> set transform-set TUNNEL-ESP-3DES-SHA set isakmp-profile IPSEC-labtest match address IPSEC-labtest reverse-route
interface Vlan917 ip vrf forwarding test ip address 10.0.0.1 255.255.255.252 crypto map IPSEC-labtest crypto engine slot 1/0 inside end
Dec 30 09:39:09.941 CDT: ISAKMP (0): received packet from <some_ip_address> dport 500 sport 500 Global (N) NEW SA Dec 30 09:39:09.941 CDT: ISAKMP: Created a peer struct for <some_ip_address>, peer port 500 Dec 30 09:39:09.941 CDT: ISAKMP: New peer created peer = 0x69CB2520 peer_handle = 0x800001DB Dec 30 09:39:09.941 CDT: ISAKMP: Locking peer struct 0x69CB2520, refcount 1 for crypto_isakmp_process_block Dec 30 09:39:09.941 CDT: ISAKMP: local port 500, remote port 500 Dec 30 09:39:09.941 CDT: ISAKMP: Unable to allocate IKE SA Dec 30 09:39:09.941 CDT: ISAKMP: Unlocking peer struct 0x69CB2520 for isadb_unlock_peer_delete_sa(), count 0 Dec 30 09:39:09.941 CDT: ISAKMP: Deleting peer node by peer_reap for <some_ip_address>: 69CB2520 Dec 30 09:39:09.941 CDT: ISAKMP:(0):purging SA., sa=0, delme=69C15028
I ended up opening a Cisco TAC case for this. As it turns out the crypto engine slot x/x outside command is not supported on a router who's upstream interfaces have mpls ipenabled. We have tested this in the lab, and did get it to work, but all of our testing was done with penultimate hop popping enabled. When we tried moving it to production we had the mpls ldp explicit-nullcommand configured on the 7613 and Cisco's theory is that this is preventing this from working the way it did in the lab. Either way it is not supported so probably not an ideal deployment model.
I hope this helps others who have run into this. If I come across any alternative solutions I will be sure to post updates here.
The answer to this for us was to add IP only upstream interfaces from the 7613 to the border routers for the purpose of IPSEC termination. So today the 7613 has 4 uplinks. Two (one to each border) for MPLS traffic. The other two (one to each border) are IP only and connect down into a fVRF on the 7613. I imagine there are a number of ways a person could have done this, but it seems to be working great and TAC confirms that they will support this deployment.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :