Forum Discussion
LB_FAILED not always triggered when all members disabled
Hi there
I'm on a mission to create a generic iRule in order to serve sorry-pages from fallback hosts.
A few criterias that was needed:
1. Strip the subdomain.
2. Preserve the customer URI while rewriting it in the internal request (so that the real page will be served when the user keeps hitting F5).
Potential imporovement:
3. Cache the response
So, I got a good thing going and it looked like it was working as expected. If I go to a random link while there's no available members it serves the page, BUT if I alter the link in the location field of the browser and hit enter it does not serve the fallback page but a 404 instead.
To summarize:
1. Going to http://fallbacktest.test.com/ajsdjasjdjasdjasjd
2. Fallback page is served.
3. Change http://fallbacktest.test.com/ajsdjasjdjasdjasjd to http://fallbacktest.test.com/jkjkjkjkjkjkjkjkjkjkjk
4. A 404 is served.
After some troubleshooting I realized that the reason for this was that the LB_FAILED event was not triggered.
Any ideas of why?
Here's the rule:
when LB_FAILED {
A generic iRule for redirecting users to sorry pages
Create an array separating the host header by .
set hostlist [split [string tolower [HTTP::host]] "."]
Capture the last to items of the array turning ie. subdomain.domain.com to domain.com
set domain "[lindex $hostlist end-1].[lindex $hostlist end]"
Save the length of the host header
set length [llength $hostlist]
set uri [HTTP::uri]
If the length of the hostlist is greater than 1 the value has the correct format.
if { $length > 1 } {
Replace the host header with the string stored in $domain
HTTP::header replace host $domain
Replacing the URI if needed
if { !($uri eq "/default.htm" || $uri starts_with "/img/") } {
HTTP::uri "/index.html"
} else {
log local0. "Correct uri"
}
Reselect pool to the Sorry pool
LB::reselect pool /Site/SorryPages_Pool-80
} else {
HTTP::respond 200 content "Invalid host header format."
}
}
Kind regards,
Patrik
8 Replies
Forgot to mention that the members of the pool is disabled, not down because of a monitor. However, I just tried with a failed monitor as well and the result was the same.
- What_Lies_Bene1
Cirrostratus
Persistence could be the issue here, have you tried to apply a OneConnect profile to the Virtual Server? - Hi there
Thank you for your answer!
Actually, that solved the issue I have but I don't really understand why?
How could persistence be an issue even though both members are disabled/marked down by a monitor?
Kind regards,
Patrik - What_Lies_Bene1
Cirrostratus
OK, just FYI a Pool Member that is disabled will continue to service any existing connections until they are closed or time out, but will not receive new connections (except persisted connections I think).
Keep in mind that persistence effectively bypasses load balancing.
I believe even when a monitor marks a Pool Member as down, if you have Action on Service Down set to the default value of None, then existing and possibly persisted connections will continue to work as long as the F5 sees data being sent and received to and from that Pool Member. OneConnect overcomes this by making a persistence decision on each request (and thus load balancing each request) within a connection, not just when the connection is initially established and it won't persist to a node marked as down or disabled.
Does that make sense? - Hi Steve!
Thanks again for your answer!
It partly makes sense but there's a few things I still don't understand and I'd greatly appreciate your take on them.
"OK, just FYI a Pool Member that is disabled will continue to service any existing connections until they are closed or time out, but will not receive new connections (except persisted connections I think)." - They were never enabled.
"Keep in mind that persistence effectively bypasses load balancing." - No persistence profile was assigned but perhaps that does not matter in this case?
"I believe even when a monitor marks a Pool Member as down, if you have Action on Service Down set to the default value of None, then existing and possibly persisted connections will continue to work as long as the F5 sees data being sent and received to and from that Pool Member." - The Action-On service down was set to "Reject".
"OneConnect overcomes this by making a persistence decision on each request (and thus load balancing each request) within a connection, not just when the connection is initially established and it won't persist to a node marked as down or disabled." - This is very interesting, I will be reading some documentation about it.
Is it not a bit weird that LB_FAILED does not trigger for subsequent requests when the nodes are constantly down?
Again, thanks for your answers, they are much appreciated!
Kind regards,
Patrik - What_Lies_Bene1
Cirrostratus
Based on your statements, yes it's very weird and I can't explain the behavior you've been seeing. However it's possible you're using a command you don't need and OneConnect is masking the issue (it's like magic sauce).
Based on this statement about the LB::reselect command: "This command is used to advance to the next available node in a pool" (from here: https://devcentral.f5.com/wiki/iRules.LB__reselect.ashx) I say you don't need it at all.
Can you try turning off OneConnect and removing the LB::reselect command from your iRule and seeing what happens please? - Hi Steve!
I tried to use pool instead of LB::reselect and it worked perfectly even without the magic sauce.
Thanks a million for your help!
Kind regards,
Patrik - What_Lies_Bene1
Cirrostratus
Great. You're welcome.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
