OPERATIONAL DEFECT DATABASE
...
...
After big3d_install is run against a target system, and this target system is a multi-blade chassis, the big3d utility may begin restarting in a loop on all secondary blades of the target system. The primary blade is not affected, where big3d continues to run stable.
Big3d does not typically do anything on secondary blades, so this issue should have no immediate material impact. However, should the cluster elect a new primary blade, and should big3d still be restarting on that blade, this could cause iQuery communication failures between that system and remote BIG-IP systems.
The following conditions are required to encounter this issue: -- The big3d_install utility is used against a target system. -- The target system is a multi-blade chassis. -- The big3d_install utility picks the iQuery installation method (and not the SSH one). -- The big3d_install utility incorrectly determines that the local version of the big3d utility should be copied to the remote system. (in other words, can incorrectly overwrite big3d on the remote system with an older version of big3d)
To stop secondary blades from restarting, manually restart big3d on the primary blade using the following command: bigstart restart big3d To prevent this issue from happening, you can run the big3d_install by specifying that the SSH installation method be used using the following command: big3d_install -use_ssh <target IP>
Big3d no longer restarts in a loop on secondary blades of a chassis system.
Click on a version to see all relevant bugs
F5 Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
