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

Last Modified: Aug 15, 2019

Bug Tracker

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

Known Affected Versions:
14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 14.1.0.6, 15.0.0, 15.0.1

Opened: Jul 19, 2019
Severity: 2-Critical

Symptoms

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.

Impact

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.

Conditions

-- 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.

Workaround

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

None

Behavior Change