A quick post on how F5 XC Health Checks are different from BIG-IP
F5 Distributed Cloud (F5 XC) HTTP Health Checks (HC) behave differently from the basic HTTP Health Check from the beloved BIG-IP platform that F5 is known for. Because of this difference, some of your testing and real-world experiences may be a little different.
One issue you may encounter is the difference in TCP/HTTP connection handling. On BIG-IP, the HTTP HC sends a HTTP/0.9 style GET request. With HTTP/0.9, there is no persistent TCP session, and every check is a brand-new request.
By default, in F5 XC, XC will send HTTP/1.1 requests with the default behaviour of Connection: keep-alive set. This may result in Health Checks continuing to work even though new client sessions may be blocked. If this isn't desired for your health checks, you can change to a single use style health check by adding the HTTP header: Connection: Close to your health check.
Here's a table that shows the GET requests and responses between BIG-IP and XC.
HTTP Requests |
BIG-IP Basic HTTP |
XC Basic HTTP |
Get Request |
Hypertext Transfer Protocol |
Hypertext Transfer Protocol |
Response |
Hypertext Transfer Protocol |
Hypertext Transfer Protocol |
Here is the JSON payload to create your own Health Check with the Connection Close header set:
{
"metadata": {
"name": "hc-http-connectionclose-200-302",
"namespace": "shared",
"labels": {},
"annotations": {},
"disable": false
},
"spec": {
"http_health_check": {
"use_origin_server_name": {},
"path": "/",
"use_http2": false,
"headers": {
"Connection": "Close"
},
"request_headers_to_remove": [],
"expected_status_codes": [
"200",
"302"
]
},
"timeout": 3,
"interval": 15,
"jitter": 0,
"unhealthy_threshold": 1,
"healthy_threshold": 3,
"jitter_percent": 30
}
}
Thanks for reading and best of luck in your journey with F5 Distributed Cloud.