Last Modified: Sep 27, 2019
See more info
Known Affected Versions:
14.1.0, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 14.1.2, 220.127.116.11, 15.0.0, 15.0.1
Opened: Jul 19, 2019
Under high availability (HA) configurations, a secondary blade does not receive mirrored updates for security associations (SAs). When a new ike-peer is created, if that peer's IP address is handled by a secondary blade, all IKE negotiation packets are dropped after forwarding between primary and secondary blades. But an ike-peer that is present from the start is mistakenly assigned to a primary blade, and thus works correctly.
After failover from Active to Standby, missing SAs that could not be mirrored are renegotiated, causing tunnel outage until new negotiation concludes. After adding a new ike-peer that should negotiate on a secondary blade, all IKE packets vanish, so no tunnel is ever created for such an ike-peer. In high availability (HA) configurations, tunnels re-establish after renegotiation, for tunnels that would be assigned to a secondary blade. This works, but undercuts the benefit of high availability (HA) for tunnels other than those on a primary blade.
-- More than one blade: a secondary blade in addition to a primary blade. -- Remote ike-peer IP addresses that happen to hash to a secondary blade by the BIG-IP system disaggregation (DAG) mechanism. -- Configuration for Active-Standby, which works on Active but fails to mirror SAs to Standby, when the IP address would be handled by a secondary blade.
For a new ike-peer assigned to a secondary blade, restart tmm or the blade, and when the system comes back up, this peer is handled on the primary blade. Note: Although this peer can then create a tunnel, any secondary blade is unused by IPsec.