Forum Discussion
YUL89YYZ_72915
Nimbostratus
NimbostratusiRule to re-direct a persistent failed node to a "sorry" page
We have an application which is load balanced to one of two nodes using the HTTP cookie Insert persistence method when the customer logs on to the application (that is, all the traffic will then go t...
You shouldn't need an irule to do this. If they are persisting to a failed node this is because either there is no Monitor on the pool, or because of the Pool setting "Action On Service Down":
https://support.f5.com/kb/en-us/solutions/public/15000/000/sol15095.html
which from your description should be set to Reselect. Look in your Pool -> Advanced.
Also, of interest is the HTTP profile setting "Fallback Host", which allows you to redirect to an external page when the whole pool fails:
You shouldn't need an irule to do this. If they are persisting to a failed node this is because either there is no Monitor on the pool, or because of the Pool setting "Action On Service Down":
https://support.f5.com/kb/en-us/solutions/public/15000/000/sol15095.html
which from your description should be set to Reselect. Look in your Pool -> Advanced.
Also, of interest is the HTTP profile setting "Fallback Host", which allows you to redirect to an external page when the whole pool fails:
YUL89YYZ_72915Thanks for your answer. The only problem is that the two nodes do not share state so if the "BIG-IP system manages established client connections by moving them to an alternate pool member without a connection teardown or setup" than the user's state is lost. What I want is for the BIG-IP to re-direct the connection to a web page which explains what has happened. If the BIG-IP does this automatically the user will get a new login screen without understanding what went wrong. Is there a way to do this?- You can use LB_FAILED: https://clouddocs.f5.com/api/irules/LB_FAILED.html but unlike Action On Service Down which gets triggered when the pool member is marked down by the monitor (relatively quickly), LB_FAILED will only trigger when the attempt times out. On the other hand, your app will detect that the client is trying to resume a session it doesn't have any info on (since the state is not shared). So it still seems like it would work to Reselect on Monitor Down and then have the app on the other pool member serve up the explanation page and redirect them to a new session like you want. This is how many apps work if you try to request a session it doesn't have data about for whatever reason.
- YUL89YYZ_72915Thanks for your help.