HTTP Monitor Fails Because the Host Header Is Missing
An LTM 15.1 virtual server app.example.com_vs 192.0.2.10:80 load-balances pool app_pool with members 10.1.20.11:80, 10.1.20.12:80, and 10.1.20.13:80. All three members are healthy from the application team's test host. A custom http monitor is attached with send string GET /health HTTP/1.1 followed by two CRLFs and receive string OK; all three members show red in the BIG-IP. The application is name-based: a request without a Host header returns HTTP/1.1 400 Bad Request, while curl -H 'Host: app.example.com' http://10.1.20.11/health returns HTTP/1.1 200 OK with body OK. The application team does not want to add a default virtual host or change the 400 behavior. The health endpoint is /health, and a 200 response is the only success condition. The monitor interval is currently 5 seconds with a 16-second timeout.
1. Why are the members marked down even though the application is reachable? What exact monitor behavior causes this?
Read the worked answer
Reasoning
The monitor opens a TCP connection to the member and sends GET /health HTTP/1.1 without a Host header. HTTP/1.1 requires a Host header for name-based virtual hosts. The application therefore returns 400 with a body that does not contain OK. The monitor's receive string is not found, so the monitor marks the member down. The members are reachable and the TCP monitor would pass, but the content check is failing. This is a monitor construction problem, not an application outage.
2. Provide the corrected monitor send and receive configuration, including the reasoning for each setting.
Read the worked answer
Reasoning
The monitor must send a valid HTTP/1.1 request for the correct virtual host and close the connection cleanly. The send string should be:
GET /health HTTP/1.1\r\nHost: app.example.com\r\nConnection: close\r\n\r\n
Use receive string 200 OK or OK, but 200 OK is stronger because it checks the status line rather than an incidental body substring. Keep the interval at 5 seconds and timeout at 16 seconds unless the app's health endpoint is known to be slower. If the endpoint redirects to HTTPS, an HTTP monitor that matches only 200 will still fail; in that case use an HTTPS monitor with the same Host header and the correct SNI, or match the redirect only if a redirect truly proves health.
3. What would you check before applying this monitor to production, and what mistake would make the monitor pass while masking a real failure?
Read the worked answer
Reasoning
Test the exact send string against each member from a host with the same routing as the BIG-IP, for example with curl -H 'Host: app.example.com' http://10.1.20.11/health. Confirm the response code and body, and confirm that the monitor source address is allowed by any application ACL. Avoid a receive string so weak that it matches an error page, such as matching only HTTP or a generic word present in the 400 body. Also avoid marking the pool up solely because the TCP port is open; that would hide the missing Host header and allow traffic to a member whose health endpoint is actually failing.