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 GET /\r\n \r\n [HTTP request 1/1] Hypertext Transfer Protocol GET / HTTP/1.1\r\n host: demo.com\r\n user-agent: Envoy/HC\r\n \r\n [Full request URI: http://demo.com/] [HTTP request 1/1] Response Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n X-Frame-Options: ALLOW-FROM \r\n Content-Type: text/html; charset=utf-8\r\n Vary: Accept-Encoding\r\n Date: Tue, 21 Mar 2023 15:59:11 GMT\r\n Connection: close\r\n \r\n [HTTP response 1/1] [Time since request: 0.001904999 seconds] [Request in frame: 14] [Request URI: /] Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n X-Frame-Options: ALLOW-FROM \r\n Content-Type: text/html; charset=utf-8\r\n Vary: Accept-Encoding\r\n Date: Tue, 21 Mar 2023 16:18:44 GMT\r\n Connection: keep-alive\r\n Keep-Alive: timeout=5\r\n Transfer-Encoding: chunked\r\n \r\n [HTTP response 1/1] [Time since request: 0.080959858 seconds] [Request in frame: 4] [Request URI: http://demo.com/] HTTP chunked response 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.
Multiple port monitoring on LTM
I need help to write an iRule which helps to monitor three different service ports running on member server. I have a web-server which accept connections on port 5555 but internally this service depends on service port 8024 or 8026. F5 should monitor all these three ports but bring down node when both 8024 and 8026 stop responding. Member web server should remain UP till either of service port 8024 or 8026 responding well. Same time I want active monitoring on port 5555 which means if port 5555 stop responding, member server status should be Down irrespective status of port 8024 and port 8026. Port 5555 support https and rest two ports HTTP. Thanks, Mihir
Configuring custom health check (send string)
I need to configure custom health monitors (http & https) and I'm stuck at configuring the Send string. I have it configured to go to and receive "yes". When I configured the Send string I used the following which isn't working; GET /sso.companyname/sortingpen/sortingpen.aspx\r\n I've tried multiple variations and nothing is working. Thanks in advance for your help!!
How to check Health Status of BIG-IP LTM
We are using BIG-IP LTM in our production environment. I am asked to submit "health check report" of the device on weekly basis. I am a bit confused in "Monitors , QKview, and Statistics" What should I use to check the health of the device. What is the recommended and best way to report about health status? Keeping in mind, the devices are in production so we cannot afford any downtime. Any help will be appreciated. Thanks.
Disable all nodes in pool if one node health check failed
I have a pool of 20 search engines in federated mode. If one node (or more) is down, the search query against this pool will not return a full search results, which is bad for customer. Currently in this scenario I manually disable all nodes and then a GTM will automatically divert traffic to another in different DC while bring all nodes healthy before enabling all nodes again. I would like automate the disabling/enabling of all nodes in such scenario. Can this be done?
Issues with the FTP health monitor
Hello, We're experiencing some strange issue with the FTP health monitor and I'd appreciate any hints. We have a pair of two BIG-IP appliances (10.2.2 build 763.3 Final) in active/standby mode with the simple FTP health monitor: Type: FTP Interval: 300 sec Up Interval: Disabled Time Until Up: 0 sec Timeout: 600 sec Manual Resume: No Mode: Passive Alias Address: * All Addresses The problem is that occasionally (once or twice per day) the FTP health monitor on both F5 nodes fails to access the FTP server. Here is the debug info: ********** Debugging session beginning at: Wed Aug 21 21:02:45 2013 Arguments 1-2: ::ffff:10.9.36.165 21 Environment variables: DEBUG=yes GET=/test.txt MODE=passive MON_TMPL_NAME=TEST-FTP NODE_IP=::ffff:10.9.36.165 NODE_PORT=21 PASSWORD=xxxxx USERNAME=test -- Recvd: '220 Serv-U FTP Server v15.0 ready... ' Recvd: '331 User name okay, need password. ' Failed to login... ********** The snippet from the FTP server log: [02] Wed 21Aug13 21:02:45 - (002818) Connected to 10.9.36.172 (local address 10.9.36.165, port 21) [21] Wed 21Aug13 21:02:45 - (002818) 220 Serv-U FTP Server v15.0 ready... [20] Wed 21Aug13 21:02:45 - (002818) USER test [21] Wed 21Aug13 21:02:45 - (002818) 331 User name okay, need password. [20] Wed 21Aug13 21:02:45 - (002818) PASS ********** [20] Wed 21Aug13 21:02:53 - (002818) QUIT [21] Wed 21Aug13 21:02:53 - (002818) 221 Goodbye, closing session. [02] Wed 21Aug13 21:02:53 - (002818) Closed session It fails on a random basis, the only common thing that I noticed is that there is 10-15 sec delay between PASS and QUIT. The self/cluster IP of F5's and the IP of FTP server are in the same network segment hence no firewall in between. I initially blamed the FTP server, so I setup five clients simultaneously accessing it every minute (using bat scripts) and none of them experienced any issues with the login. Could it be related to the F5 software version we're using or I miss some timeout settings in the configuration? Thank you in advance.
