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.1.6KViews8likes2CommentsF5 XC | Stuck at VIRTUAL_HOST_PENDING_A_RECORD
I have a running OWASP Juice Shop in Azure and have assigned a public IP on it. Trying to build a load balancer using XC. I am stuck at theVIRTUAL_HOST_PENDING_A_RECORD status. Question is do I need to use my own DNS to create a domain name entry for my load balancer? Can I do anything to bypass this or any workaround you may have?Solved3KViews0likes6CommentsIs there plans for F5 Distributed Cloud(XC) horizontal scaling of edge Site nodes?
Hello, The F5 Distributed Cloud(XC) is a great product but is there a plan for future horizontal scaling of edge Site nodes? For example when the traffic is too much to not only increase the CPU and Memory of the already existing node in the public or private cloud customer location but also to create more nodes as maybe one to be the cluster primary node that gets the packets and without processing the packets to send them to the other secondary nodes using mac rerouting (I do not think SSL/Ipsec tunnel between the primary and secondary nodes). As I know that GSLB will comming to the Site Edge nodes and everyday other new things are added to the Distributed Cloud maybe this is on the road map 🙂 Edit: I talked about Mac tunnel and future XC GSLB if each edge node is a GSLB peer and Local HTTP Load balancer at the same time something like GSLB cookie persistence can also be done in the future, where after the DNS resolution and when HTTP traffic is processed a cookie is added and for example DNS times out and a new GSLB resolution is done but this time another Edge Node is selected for servicing the traffic then the cookie can be used for the new edge node to redirect the traffic to the old edge node that was servicing it. The possibilities with XC for new features as this is an SDN solution are almost limitless 🙂Solved1.5KViews2likes1Comment