Bug ID 647828: Historical session data in db and inconsistent GUI info

Last Modified: Mar 21, 2019

Bug Tracker

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

Known Affected Versions:
11.6.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.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 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, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:
13.1.0

Opened: Feb 27, 2017
Severity: 3-Major

Symptoms

You notice a lot of session tracking data in your new ASM deployment, showing blocked requests, particularly on one of the high availability peers.

Impact

The records of session tracking are never cleaned up, which can present confusing session data.

Conditions

Enabling Session Tracking and setting "Block All Period" . Block All data points defaults to persist infinitely (with no expiration period).

Workaround

Clear all session tracking data points (or as many as possible) and prevent them from accumulating. A) To prevent data points from accumulating, consider setting the blocking period to the default of 600 seconds (5 minutes) instead of 'infinite'. B) There is no option of clearing out all data points for a given policy in the GUI. This example provides one-line commands to do so. -- Run the following two commands sequentially, to clear out the data points of a specific policy. -- Apply that procedure for as many policies as possible. For example, given a policy id of 13, the following commands replace 13 (at '{ policy_id => 13 }') with the required policy id: ------------------ perl -MF5::ASMConfig::Entity::Policy -MF5::ASMConfig::Entity::SessionAwarenessDataPoint -e 'F5::ASMConfig::Entity::SessionAwarenessDataPoint->delete_many(dbh => F5::DbUtils::get_dbh(), policy => F5::ASMConfig::Entity::Policy->new(dbh => F5::DbUtils::get_dbh(), get_criteria => { policy_id => 13 }), master_keys => 1)' perl -MF5::ASMConfig::Entity::Policy -MF5::ASMConfig::Entity::SessionAwarenessDataPoint -e 'F5::ASMConfig::Entity::SessionAwarenessDataPoint->reload_session_db(dbh => F5::DbUtils::get_dbh(), policy => F5::ASMConfig::Entity::Policy->new(dbh => F5::DbUtils::get_dbh(), get_criteria => { policy_id => 13 }), delete_existing => 1)' ------------------

Fix Information

Session Awareness Statuses are now cleaned after the expiration period, so this issue no longer occurs.

Behavior Change