Bug ID 807453: IPsec works inefficiently with a second blade in one chassis

Last Modified: Sep 27, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
14.1.0,,,,,,, 14.1.2,, 15.0.0, 15.0.1

Opened: Jul 19, 2019
Severity: 2-Critical


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.

Fix Information


Behavior Change