Last Modified: Apr 10, 2019
See more info
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
Opened: May 30, 2015
ntlmconnpool daemon is restarting continuously on secondary blades in VIPRION systems.
Loss of traffic after installation. This issue is likely encountered only during maintenance windows.
This occurs when changing FPGA firmware provisioning just before changing system provisioning.
To avoid the condition, simply give the system additional time (~1 minute) to let the FPGA provisioning settle before initiating system provisioning tasks. To mitigate the issue once the secondaries are showing ntlmconnpool restarting about once a second: 1. ssh into each affected secondary and halt them. 2. When they are completely halted, issue a reset from the primary using either of these methods: -- Using the AOM/LOP console. -- Running the following command (where # is the slot number of the secondary blade to reset): bladectl -b # -r. Once the secondary is an Active cluster member, you may wish to failover the primary and reset it as well. To do so, disable the current cluster primary member, and a natural failover will transition primary to an active secondary. The old primary may then be halted and reset.
The system now prevents the ntlmconnpool daemon from continually restarting, and presents messages when changing FPGA firmware provisioning just before changing system provisioning. Messages that appear might be similar to the following: -- 010718e1:3: Changing the firmware type is not permitted in vCMP mode. -- 01071003:3: A previous provisioning operation is in progress. Try again when the BIG-IP system is active.