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
Fixed In:
11.5.2, 11.4.1 HF9, 10.2.4 HF12
Opened: Nov 25, 2013 Severity: 3-Major Related Article:
K16283
The send weight messages message id field does not serve any purpose as per the SASP rfc 4678. Consider a scenario where the SASP monitor sents a registration request message containing message id x. It expects a registration reply with message id x. However, if it receives a send seight message with message id x then it throws the monitor out of sync. It stops processing any further messages.
The SASP monitor stops processing of any messages after it receives the unexpected send weights message.
The SASP monitor sends a request message with a message id in it to the GWM server. It expects a reply from the GWM server to the request message containing the same message id. But instead it receives a send weights reply containing the expected message id.
None.
The SASP monitor ignores up to 5 consecutive unexpected send weight messages and keep looking for registration reply response from GWM. If it does not get the reply in 5 attempts then the monitor shall restart.