Adding a maintenance page to the pool

you need something like this:

if { [active_members [LB::server pool]] < 1 }

If the page never changes you could also host it on the LTm and use the iFile commands to serve pages directly from the device, that depends on how complicated you want the page though.

Here is a good example: https://devcentral.f5.com/wiki/irules.ltmmaintenancepage.ashx

HTTP::host returns (or sets in v11.5+) the value of the HTTP header "host". This is not related to load balancing / routing.

[LB::server pool] gives you access to the pool the VIP uses, which means that you can (among other things) query it to see how many of its members are available (up).

The order of the iRules can be important; it depends on the functionality of each. It is also possible to force an order by setting it in the individual rules.

So I updated the iRule with "LB::server pool" and it broke the Virtual Server Clients got nothing but a page is not available message (by accident as I did not know the iRule was in use at the time).

Anyway the servers were up and functioning and everything else was good. My question now is why "LB::server pool" broke the system and "HTTP::host" didn't?

HTTP::host may seemingly 'work', but it has nothing to do with active members. HTTP::host holds (or sets) the HTTP-header "host". Most likely HTTP::host returned a value greater than 1.

This should work:

when HTTP_REQUEST {

    if { [active_members [LB::server pool] ] < 1 } {

        HTTP::respond 503 content "down"

    } 

}

By the way, I noticed that in your code you're returning a 200 when the pool is down. However, you'll want to return a 503, not a 200.

Are you by any chance defining the pool in the iRule, and do not have a default pool assigned to the VIP?

There must be other factors involved. The [HTTP::host] evaluation didn't break anything, simply because it didn't return the information the evaluation cared about. The active_members command looks at the count of active members in the pool provided. You provided it the host header of the request (which ironically should have broken it for semantics reasons), which simply didn't return a value that was less than 1. If the [LB::server pool] command is now breaking it, try supplying a specific pool name:

if { [active_members my-pool] < 1 } {

If that works, then you're best bet is probably either a) no pool assigned to the VIP, or 2) some other conflicting information in either of the iRules.

So that makes sense now. You're defining the pool in the iRule, and presumably don't have a pool defined to the VIP itself. When you make an evaluation of [LB::server pool], and no pool has been assigned to the flow yet, you get an error.