F5 BIG-IP health checks and HTTP errors

Shaun Ewing Technology 12 Comments

When a web site or application becomes too large to run on a single server, it’s frequently placed on multiple servers with a load balancer in front of them to spread the load and also to remove faulty servers from the pool. The F5 BIG-IP is one such load balancer.

To ensure that faulty servers are removed from the load balancer pool automatically, you need to set a health check (or monitor). These monitors poll the server every few seconds and based on what it receives can make decisions on whether to leave a server in a pool or mark it as faulty.

When monitoring web applications you create a http (or https) monitor, however the default out of the box behaviour is to check two conditions:

  • That content is returned by the server.
  • That the http/https port is open and responding.

Unfortunately applications can also fail in such a way that the above checks pass but the application is not available to the end user (eg: if it’s returning a 500 Internal Server Error). This will result in users intermittently receiving an error page, or worse – receiving an error page for an extended period of time if session persistence is turned on (ie: once a session is created, they’ll be directed to that one server).

To protect against this you need to create a new health check (monitor) that not only checks the above conditions, but also checks to ensure that the HTTP status code returned with the request is not an error code.

First of all you need to create a new HTTP monitor. You’ll have your typical send string (eg: HEAD / HTTP/1.0) but the receive string is what’s important.

Here’s the receive string I use:

This string will accept any returned HTTP status code from 200-206 and 300-306. Any error codes (ie: 4xx and 5xx) will result in the receive string not being matched and the check failing.

Here’s an example of the fully configured check:

You’ll note that I’m using HTTP/1.0 for the check despite HTTP/1.1 being the current version of the protocol. This is because I use the one health check across multiple clients, and HTTP/1.1 would require me to include a host header, eg:

Using HTTP/1.0 (which does not support virtual hosts) eliminates this requirement and makes using a single check for many different clients much easier.

Once you’ve created your new monitor to your requirements you need to go to go the pool and add the new check.

After you’ve changed this, all you need to do is update the configuration and your new health check is active. If your application starts returning a 500 Internal Server Error, it should automatically be taken out of the pool within seconds!

About the Author
F5 BIG-IP health checks and HTTP errors was last modified: April 24th, 2017 by Shaun Ewing

Comments 12

  1. For what it’s worth, you can use an empty host header with HTTP/1.1, like “GET / HTTP/1.1rnHost: rnConnection: Closernrn”

    We recently had some servers upgraded that no longer supported 0.9 or 1.0 so we had to switch to 1.1 monitors.

  2. Here’s a question Shawn — what if you had a http monitor with no arguments i.e. Blank (and same for receive string actually). We had this scenario recently and raised a case. We were getting a situation whereby one of the cores on our 8 core 8900s (active and standby boxes in the HA pair, as it turned out) was continually maxing out, so the web gui was showing busiest cpu as frequently at 100% (v10.2.0 – I know it’s old code etc). User cpu was around 15% overall, and top command was showing bigd process as the process with highest usage indicating an issue with health monitors.

    F5 advised that from comparison of qkviews that we supplied, we had a http monitor that previously had a send string that had been deleted and this was the reason for the high cpu. As soon as we re-added the old send string this resolved the issue. Are you aware of any SOLs/ bug ids for this issue.

  3. Hi

    We have a f5 and we need to certificate our secure websites in PCI compliance.(disable tls 1.0 enable 1.1 and 1.2)
    Normally we have this options
    Send String : HEAD /test.php HTTP/1.0rnrnrn
    Receive String : HTTP/1.[01] [23]0[0-6]

    But when we disable the TLS 1.0, the f5 takes down the site

    By now, we test the site on tcp (telnet to 443)

    But what is the best rule for our load balancer when tls 1.0 is disabled and 1.1 – 1.2 enabled??


  4. Hi Shaun ,

    I have configured in which there are three pool members and monitor used in tcp_halp_open_server . The error which i get is time out with two members .

    So is it monitor only the reason that marking the member down or there any possiability of other reason too.

  5. This was all great information and I was able to build my send and receive strings thanks to you guys. A special thanks to Phil Surette for including that information on the 11.x code which is what got me up and going. Again, thank you guys for sharing your knowledge and experience.

  6. What if I am specifying 404 as return string?I know that should not be done. But I want to test it and want to know will LB considers it and mark the node active or not?

    1. Hi Kamal,With the string that I’ve included in an example it will not count 404 as a successful result and will therefore cause the node to be marked as inactive.

      You could add 404 to the list of accepted codes by modifying the return string to be something like:HTTP/1.[01] ([23]0[0-6]|404)

  7. We found this article very useful when configuring an active check.However, we were tripped up by one silly thing: we found that the send string needed to be terminated by two carriage return line feed combinations (backslash r, backslash n, backslash r, backslash n) with no spaces. I think that’s what “f5 and iis” was trying to say… I’m guessing the backslashes were mangled by the blog.

  8. This was extremely helpful. One note is with our version of Big IP LTM 11.x we needed the following for the “send” string:HEAD / HTTP/1.0rnn

    This was especially helpful because our IIS 8.x app serves up a 404 error when you shut down the virtual web as opposed to simply not responding.

Leave a Reply

Your email address will not be published. Required fields are marked *