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 gets directed to VS B. Can an irule be written and applied to VS A, B, C, and D that would recognize an F5 created cookie in the HTTP stream, and redirect the client back to the VS that originated the cookie ? This is an ecommerce site and what is happening is costing a lot in money and customer satisfaction since the shopping cart doesn't stay populated. Thanks!

You can also change the mask for LDNS persistence on GTM to /16, and that should keep the mega proxies from bouncing around. Of course YMMV, since all other LDNS are subject to the same grouping. But if you have to deal with it @ LTM, assuming the pools have different names, I think you could do that with a class and an iRule cross-referencing poolname to target virtual. I'd say it would have to collect & hold the request until after the pool is selected & then decide what to do with it:class xPoolname2VSName { PoolA serverA.domain.com PoolB serverB.domain.com PoolC serverC.domain.com }when HTTP_REQUEST { set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "] if { $CookiePool !=""}{ set clength [HTTP::header Content-Length] if { [HTTP::header Content-Length] > 1048576 set clength [HTTP::header Content-Length] } else { set clength 1048576 } set uri [HTTP::uri] HTTP::collect $clength } } when LB_SELECTED if { $CookiePool != "" && \ $CookiePool != [LB::server pool]}{ set VSName [findclass $CookiePool $::xPoolname2VSName " "] if $VSName != ""}{ HTTP::redirect "http://$VSName/$uri } } else { HTTP::release } [ HTH /deb

where is that mask setting on GTM LDNS persistence?

deb, I'll be keying off of cookies issued by LTM. There's a need to possible redirect to VS on another LTM. That would remove pool name as a tool for me to use. How would that change your rule. can I just look for cookie name, and redirect accordingly ?

That's pretty much what that rule does, and will still work as long as the pools have unique names across both LTMs. In either case, the class would need to be adjusted to include IP addresses for the VS's instead of names to avoid a potential circular reference. Because of the redirect to IP address instead of name, there are a couple of problems you might encounter with this approach: 1) clients who have been redirected will see URIs with the IP address rather than the hostname, and if those links are what they bookmark, all redundancy goes out the window. 2) some apps require an actual hostname rather than an IP address in the Host header field to function as expected (and having the IP in the Host header may aggravate issue 1, if links are relative or otherwise derived from the Host header) I'd say you might want to push GTM persistence a bit harder... You can set the GTM LDNS persistence mask here:System / General Properties / Global Traffic / General / Static Persist CIDR (IPv4) or System / General Properties / Global Traffic / General / Static Persist CIDR (IPv6)The value is the number of bits in the persistence mask.

OK dumb question then...since I know what the cookie names will be, willif { [HTTP::cookie exists "Cookie name"] work as well as this? when HTTP_REQUEST { set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "] if { $CookiePool !=""}{ set clength [HTTP::header Content-Length] if { [HTTP::header Content-Length] > 1048576 set clength [HTTP::header Content-Length] } else { set clength 1048576 } set uri [HTTP::uri] HTTP::collect $clength } }

irule feature question

16 Replies

Frank_J_104756
Historic F5 Account
Sep 27, 2007
we needed logic to validate that the destination pool is actually up so the irule now looks like below...problem is that if that original pool is down and the user gets directed to the default pool of the VS they now have 2 cookies. If the original pool comes back up, they'll get sent to it and lose whatever shopping they've done on the default pool. Is there any way to remove the cookie from the original pool if it's down ?

when HTTP_REQUEST {

set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]

if { $CookiePool !=""} {

if {[active_members $CookiePool] > 0} {

pool $CookiePool

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }

else {

pool [LB::server pool]

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"

}

}

}
JRahm
Admin
Sep 27, 2007
when you've determined that the pool is no longer available, remove the cookie:

HTTP::cookie remove BIGipServer
Frank_J_104756
Historic F5 Account
Sep 27, 2007
it's not removing the cookie though

when HTTP_REQUEST {

set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]

if { $CookiePool !=""} {

if {[active_members $CookiePool] > 0} {

pool $CookiePool

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }

else {

pool [LB::server pool]

HTTP::cookie remove "BIGipServer$CookiePool"

log local0. "removing cookie BIGipServer$CookiePool. Remaining cookies are [HTTP::cookie names]"

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"

}

}

}
Frank_J_104756
Historic F5 Account
Sep 27, 2007
the irule shows the cookie gone, see output below, but the cookie still exists on the browser

Rule follow_the_cookie_to_the_pool : removing cookie BIGipServerf502_Web_Top_Pod_4. Remaining cookies are bmScrRes cookieID bmTzOff bmJava bmClrDpt JSESSIONID BIGipServerf502_Web_Top_Pod_5 cmRS
Frank_J_104756
Historic F5 Account
Sep 27, 2007
the site has expressed willingness to use non-session cookies if having expiration dates allows us to make this work.
Frank_J_104756
Historic F5 Account
Sep 27, 2007
Here is the final working irule, until the customer asks me to change it agiain : )

when HTTP_REQUEST {

search cookies in http header for a bigip issued cookie

set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]

if bigip cookie is present AND pool it points at is active, then go to pool...maintians user shopping cart info. Log to local0.

if { $CookiePool !=""} {

if {[active_members $CookiePool] > 0} {

pool $CookiePool

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }

else {

if original pool is down, use the default pool for the new VS...send the 302 to the user to expire out the cookie from the

original pool so that that the only cookie present is for the new pool. User will lose shopping cart from original pool.

log client ip, VS IP, and pool info to local0. for troubleshooting.

pool [LB::server pool]

HTTP::respond 302 Location "http://[HTTP::host]" "Set-Cookie" "BIGipServer$CookiePool=; path=/; Max-Age=0;"

log local0. "removing cookie BIGipServer$CookiePool. Remaining cookies are [HTTP::cookie names]"

log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"

}

}

else {

if no bigip cookie is present - ie new session, then use the default pool for the VS.

pool [LB::server pool]

}

}

Forum Discussion

irule feature question

16 Replies

Recent Discussions

Azure SAML - F5 APM

Converting config to DO

iRule resulting in too many redirects

Wildcard SSL Certificate Deployment on F5 LTM

URL

Related Content

irule redirect question

Standalone BIG-IQ Upgrade Question

question of limitation and expiration for rest api token

Monitor Testing question

SNAT question