Bug ID 428895: active_members iRule command doesn't take into account priority groups for pools with minactive members set

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
10.1.0, 10.2.0, 10.2.1, 10.2.2, 10.2.3, 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

Fixed In:
11.5.0

Opened: Aug 26, 2013

Severity: 3-Major

Related Article: K14694

Symptoms

The result of the iRule command "active_members <pool>" differs from the length of the list returned by "active_members -list <pool>".

Impact

Potential confusion about how many pool members are really "active".

Conditions

Priority groups must be configured on the pool along with min-active-members, and enough members must be available in the higher priority group to avoid load-balancing to at least some of the lower-priority groups.

Workaround

The correct number of truly active pool members can be determined by looking at the size of the list returned with the -list option: set active [llength [active_members -list <pool_name>]]

Fix Information

The return value of the iRule "active_members" command now matches the length of the list returned by the "active_members -list" command, whether or not priority groups with minimum active members is configured on the pool.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips