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

Last Modified: May 29, 2024

Affected Product(s):
BIG-IP LTM(all modules)

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

Fixed In:

Opened: Jul 19, 2019

Severity: 2-Critical


Important: Mirroring of IPsec Security Associations for IPsec high availability (HA) is supported only for IKEv2 tunnels. Additionally, code refactoring for IKEv2 for chassis systems and HA mirroring for IPsec was delivered into TMOS version 16.1.0 and we recommend that you use software version 16.1.0 or later if IPsec HA mirroring is a critical requirement. Under 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 HA configurations, tunnels re-establish after renegotiation, for tunnels that would be assigned to a secondary blade. This works, but undercuts the benefit of HA for tunnels other than those on a primary blade.


-- IKEv2 IPsec tunnels -- 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

Assignment of blade ownership is now correct after a restart, even when blades are slowly discovered incrementally, or added dynamically after a system has come up. HA mirroring works, and SAs are present after failover. Tunnels are negotiated on secondary blades, so ike-peer instances with IP addresses handled on a secondary blade function as well as those on a primary blade.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips