Forum Discussion
NimbostratusSorry Page Redirect iRule for HTTPS VIP
I have configured our BIG-IP 10.1.x F5 in a testing environment with a new automated maintenance page solution, but ran into some issues during the testing phase. The iRule works by directing traffic to a maintenance pool whenever there are 0 nodes active in our application's pool. This implementation uses the CLIENT_ACCEPTED event instead of HTTP_REQUEST because the pool nodes are using SSL/443 without SSL acceleration. At this time I cannot move the SSL certificates to the F5 as our application would break. :(
Here's what I've got:
iRule:
rule AutoMaintenance {
when CLIENT_ACCEPTED {
if { [active_members TestSite_HTTPS_Pool] < 1} {
pool Maint_HTTP_Pool
}
}
}
Maint Pool (I'm not sure why below it says webcache instead of 8080, the port I'm using?):
pool Maint_HTTP_Pool {
monitor all https
members 172.29.1.110:webcache {}
}
VIP
virtual TestSite_443 {
snat automap
pool TestSite_HTTPS_Pool
destination 172.29.2.30:https
ip protocol tcp
rules AutoMaintenance
}
Everything works as expected. I can view the site, mark my nodes offline and immediately refresh for the maintenance site. But when I bring the nodes back up, simply refreshing doesn't bring back the regular site, which would be very confusing for users. It's as if I'm using sticky sessions and the session gets "stuck" on the maintenance page, but I do not have a Persistence Profile set up on the VIP. If I make new connections from other browser windows I will get the regular site and not the maintenance page.
What do you think I am missing? I have tried adding a Javascript auto-reload into the page but that doesn't trigger what I need -- to do basically whatever closing the browser and coming back to the site does, create a brand new session.
1 Reply
- Kevin_Stewart
Employee
This may be a browser issue. Can you do a trace from the browser and see if it's actually caching the information or making a new request? I tested your iRule on an SSL-tunneling VIP and got mixed results with different browsers, but for the most part it worked in both directions.
Also, "webcache" is just what is in /etc/services for port 8080, so it's just a name translation (like 80 = "http").
