Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 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, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4
Fixed In:
14.0.0, 13.1.3.5, 12.1.5
Opened: Nov 02, 2017 Severity: 3-Major
For some HTTP requests, a request-log profile can log nothing for the $VIRTUAL_POOL_NAME token (which expands to an empty string in the resulting logs).
For all HTTP requests the client sends except the first one, the $VIRTUAL_POOL_NAME token logs nothing. As a result, a BIG-IP Administrator may struggle to determine which pool serviced which request.
- The virtual server where the request-log profile is used also uses OneConnect. - The client uses HTTP Keep-Alive and sends multiple HTTP requests over the same TCP connection.
The $SERVER_IP and $SERVER_PORT tokens work for all requests, and so if those are also being logged it may be possible to deduce the pool name from that information. However, there is no workaround to make the $VIRTUAL_POOL_NAME token work all of the time.
None