Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6
Fixed In:
13.0.0
Opened: Jun 06, 2014 Severity: 3-Major
When primary blade in rebooted, the system halts all daemons, including those that maintain the routing table. This might flush routing table before the secondary blade becomes active, and that might cause traffic outages. Because of this issue, you might see the following symptom: Dynamic routes advertised by the BIG-IP system and by the neighbors, are deleted due to the shutdown. OSPF withdraws the routes advertised to the neighbor.
Traffic flow may be impacted. Note: The graceful restart process is initiated on the new primary blade at this point, which recovers the routes.
This occurs when the primary blade in rebooted.
Force blade failover first before rebooting blade. To force an active blade or cluster into a standby state: 1. Navigate to System :: High Availability :: Failover :: Redundancy. 2. Click Force to Standby. With failover, the new blade becomes primary and picks up routing functions before the reboot halts the routing daemons.
The shutdown process now forces blade failover first before rebooting the blade, which enables the secondary to pick up the routing table before becoming primary.