Bug ID 720219: HSL::log command can fail to pick new pool member if last picked member is 'checking'

Last Modified: Nov 07, 2022

Bug Tracker

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

Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 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, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.1.0, 14.1.0.1

Fixed In:
15.0.0, 14.1.0.2, 14.0.1.1, 13.1.3, 12.1.5

Opened: May 15, 2018
Severity: 3-Major
Related Article:
K13109068

Symptoms

This occurs in certain configurations where the HSL::log command is using a remote high speed log (HSL) pool with failing pool members. If a pool member goes into a 'checking' state and the command attempts to send the log via that pool member, it can fail to send and all future log commands from that iRule will also fail, if that pool member is actually unavailable.

Impact

Failure to send log messages via HSL.

Conditions

-- Using HSL::log command. -- iRule with a remote high speed logging configured.

Workaround

Follow this procedure: 1. Change the 'distribution' method of the remote high speed config to something else. 2. Save the configuration. 3. Change the method back.

Fix Information

This issue no longer occurs. If a 'down' pool member is picked, it will eventually be bypassed to find an 'up' pool member, if possible.

Behavior Change