Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
10.2.4, 11.0.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.5.1 HF1, 11.6.1 HF1, 11.5.1 HF2, 11.6.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.6.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.1.0, 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
Fixed In:
13.0.0, 12.1.2 HF1
Opened: Nov 03, 2016 Severity: 3-Major
Running the command "tmsh reset-stats auth login-failures <username>" on a bladed system can cause the mcpd process to restart on secondary blades if the <username> is not an actual user on the system. The /var/log/ltm log file will contain errors messages similar to: Configuration error: Configuration from primary failed validation: 01020036:3: The requested username (username) was not found.... failed validation with error 16908342
mcpd processes on secondary blades restart, possibly causing loss of traffic and a failover (if in a device cluster).
This occurs on VIPRION systems when running the command for a user that doesn't exist on the other blades.
Run the command "tmsh reset-stats auth login-failure <username>" using only valid usernames.
Prevented the command "tmsh reset-stats auth login-failure <username>" from restarting mcpd instances on secondary blades when <username> is an unknown user. The bad command is intercepted at the primary blade and is dealt with there.