Re: SPA-IPSEC-2G unable to allocate IKE SA

David Williams · ‎12-30-2009

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 keyring IPSEC-labtest
pre-shared-key address <some_ip_address> key <topsecret>

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

David Williams · ‎01-05-2010

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 ip enabled. 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-null command 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.

DW

David Williams · ‎05-10-2010

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.