Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP ASM
Known Affected Versions:
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, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 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, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 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
You notice a lot of session tracking data in your new ASM deployment, showing blocked requests, particularly on one of the high availability peers.
The records of session tracking are never cleaned up, which can present confusing session data.
Enabling Session Tracking and setting "Block All Period" . Block All data points defaults to persist infinitely (with no expiration period).
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)' ------------------
Session Awareness Statuses are now cleaned after the expiration period, so this issue no longer occurs.