What you're most likely seeing is (TCP) session-based persistence. In lieu of any defined direction, a node will be persisted to within a single TCP session once a load balancing decision has been made. So if you have logic that sends traffic to a specific pool based on a URI, but do not have logic for requests that do not contain that URI, it's very likely that TCP persistence will send the next request to the same node. There are generally three ways to overcome this behavior:
-
Be explicit in your iRules for every possible URI path and pool assignment (as you've witnessed).
-
Apply a OneConnect profile - this is generally intended to aggregate multiple requests into a single TCP connection, but has the added benefit of protecting against TCP-based persistence.
-
Issue an LB::detach command on each request
The easiest option is usually to simply enable a OneConnect profile, but if you wanted to use the first option and still use the default VIP-configured pool assignment, your iRule might look like this:
when CLIENT_ACCEPTED {
set default_pool [LB::server pool]
}
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::uri]] {
"/images*" {
pool pool_images
}
default {
pool $default_pool
}
}
}