Forum Discussion
Frank_J_104756
Sep 24, 2007Historic F5 Account
irule feature question
Site has multiple VS, A, B, C, D...user 1 comes in and gets directed to VS A. VS A has coookie insert persistence. User gets a cookie. Something on the user side (AOL proxy) changes and user then g...
Deb_Allen_18
Sep 26, 2007Historic F5 Account
In that example, you still would need to collect & hold the connection until a decision can be made as to its disposition.
In that example, I was parsing out the poolname from the cookie, but you could instead construct the class to contain whatever full cookie names make sense:
class xPoolname2VSIP {
SiteACookieName 192.168.1.1
SiteBCookieName 192.168.2.1
}
and then use some condition to determine the appropriate redirect. There are 2 very helpful hooks in the approach I mentioned:1) since the LTM persistence cookie has nice built-in delimiters (starts with "BIGipServer", ends either with whitespace or end of string), you can isolate a unique lookup key (pool name) and look up a keyed record in the class, returning a row containing the redirect target.
and
2) you can tell immediately if the connection is on the correct VS or needs to be redirected by comparing the selected pool to the pool indicated by the cookie.
So re: 1), with the different cookie names mentioned in this new example, to take the same approach you'd need to be sure the string "Site" didn't appear anywhere else in the list of cookie names. (IOW, YMMV)
An alternative approach if you can't isolate the cookie name successfully would be to build a switch to find the right redirect.
HOWEVER...
I think in either case you run the risk of having 2 differently named persistence cookies that would match the specified pattern, and you'd only ever pick up on the first.
I think a better solution is for all servers to insert a cookie by the same name, with a unique value you can look up in the class, and include in the class the possible cookie values and the IP of the vs to which they correspond. An added bonus of this approach is that we can now redirect in the request event if the vs and cookie name don't line up, rather than collecting and waiting for a pool to be chosen:
class xCookieValue2VSIP {
SiteACookieValue 192.168.1.1
SiteBCookieValue 192.168.2.1
}
when HTTP_REQUEST {
set VSCookie [HTTP::cookie VSCookie]
if { $VSCookie != ""}{
set VSIP [findclass $VSCookie $::xCookieValue2VSIP " "]
compare local VS IP to the one corresponding to that cookie value
& redirect if they dont' match
if {$VSIP != [IP::local_addr]}{
HTTP::redirect "http://$VSIP[HTTP::uri]"
}
}
}
HTH, and let me know if I didn't explain any of that clearly...
/deb
Recent Discussions
Related Content
DevCentral Quicklinks
* 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
Discover DevCentral Connects