Forum Discussion
Ben_Lamb_227759
Nimbostratus
NimbostratusPersistence causing problems with redirection iRule?
I have a slightly strange case on website where I am seeing traffic being redirected strangely, and I believe it may be down to my persistence. I was wondering if anyone could advise on if what I am seeing is indeed because of persistence and, if so, how to best avoid it.
- I have cookie and source address persistence set up on the VS for and a pool of servers which serve this main part of the site and all subsites except one.
- I have an iRule set up on the VS to redirect any connections to www.website.com/test to a separate pool, which serves only this specific subsite.
I am sometimes seeing connections for www.website.com being redirected to the pool designated solely for the 'test' subsite, despite these connections not matching the iRule.
Specifically I am able to create this behaviour by navigating to www.website.com/test in a browser and then deleting '/test' and hitting enter. The connection is directed to the pool designed to serve just the '/test' subsite, which is unable to serve the main body of the site.
Is this being caused by a persistence record being created for my connection to the '/test' pool, which is then being matched when I later navigate to the main site?
If so, is there any way to avoid this?
You're missing a else-clause (default action) in your iRule. In other words, once a request lands in your test pool, there's no way to return to default pool (since the balancing decision is already locked in).
when HTTP_REQUEST { Save the name of default pool (as configured in VS Resources Tab) as a variable, before it can be modified by conditional actions below set poolDefault [LB::server pool] if { "[HTTP::host][HTTP::uri]" starts_with "www.website.com/test" } { pool test_pool } else { pool $poolDefault } }Similar problem here: https://devcentral.f5.com/questions/incorrect-load-balancing-when-disabling-oneconnect
Tom_De_Boeser_1Post your iRule... we'll be able to help a bit better.
Ben_Lamb_227759when HTTP_REQUEST { if { "[HTTP::host][HTTP::uri]" starts_with "www.website.com/test" } { pool test_pool } }
Hannes_Rapp_162Nacreous
You're missing a else-clause (default action) in your iRule. In other words, once a request lands in your test pool, there's no way to return to default pool (since the balancing decision is already locked in).
when HTTP_REQUEST { Save the name of default pool (as configured in VS Resources Tab) as a variable, before it can be modified by conditional actions below set poolDefault [LB::server pool] if { "[HTTP::host][HTTP::uri]" starts_with "www.website.com/test" } { pool test_pool } else { pool $poolDefault } }Similar problem here: https://devcentral.f5.com/questions/incorrect-load-balancing-when-disabling-oneconnect
- Ben_Lamb_227759Thanks for that. I don't really understand why that is necessary though. The VS has a default pool set up, which works in the majority of cases. If the HTTP request comes in and doesn't match the 'if' clause, should it not default to the default pool selection specified in the VS? This is what happens for 99% of the traffic directed at www.website.com. The default pool is selected and used. I don't understand what's happening differently in the other 1% of cases, and why this change would have any impact.
- Hannes_Rapp_162Maybe this thread will answer your questions. I've given a more detailed answer there, so hopefully you can follow the logic. https://devcentral.f5.com/s/feed/0D51T00006i7caLSAQ
- Ben_Lamb_227759Thanks :) I'll give it a go and report back.
- Hannes_Rapp
You're missing a else-clause (default action) in your iRule. In other words, once a request lands in your test pool, there's no way to return to default pool (since the balancing decision is already locked in).
when HTTP_REQUEST { Save the name of default pool (as configured in VS Resources Tab) as a variable, before it can be modified by conditional actions below set poolDefault [LB::server pool] if { "[HTTP::host][HTTP::uri]" starts_with "www.website.com/test" } { pool test_pool } else { pool $poolDefault } }Similar problem here: https://devcentral.f5.com/questions/incorrect-load-balancing-when-disabling-oneconnect
- Ben_Lamb_227759Thanks for that. I don't really understand why that is necessary though. The VS has a default pool set up, which works in the majority of cases. If the HTTP request comes in and doesn't match the 'if' clause, should it not default to the default pool selection specified in the VS? This is what happens for 99% of the traffic directed at www.website.com. The default pool is selected and used. I don't understand what's happening differently in the other 1% of cases, and why this change would have any impact.
- Hannes_RappMaybe this thread will answer your questions. I've given a more detailed answer there, so hopefully you can follow the logic. https://devcentral.f5.com/questions/incorrect-load-balancing-when-disabling-oneconnect
- Ben_Lamb_227759Thanks :) I'll give it a go and report back.