Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 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
Fixed In:
13.0.0
Opened: Apr 13, 2016 Severity: 3-Major Related Article:
K83123783
The result returned from the "IP::tos" iRule in the FLOW_INIT event is always zero (Normal-Service), even when the actual packet from the client has TOS set to a different value.
Cannot make the correct service or routing decision at FLOW_INIT, based on the TOS provided in the initial packet in the flow.
Calling the IP::tos iRule from within a FLOW_INIT event handler for a virtual server always returns zero. The following iRule demonstrates the issue: when FLOW_INIT { log local0. "TOS from [IP::client_addr] is [IP::tos]" } when CLIENT_ACCEPTED { log local0. "TOS from [IP::client_addr] is [IP::tos]" } The logs will show that the IP::tos value is always 0 at FLOW_INIT, and always correct at CLIENT_ACCEPTED.
None.
The IP::tos iRule now correctly returns the TOS value from the initial client packet initiating a flow in the FLOW_INIT event handler.