Forum Discussion
Persistence across services
So just to be clear, the HTTP VIP uses a pool that sends traffic to nodes listening on port 80. The HTTPS VIP uses a different pool that sends traffic to the SAME nodes listening on port 443. Is that correct? If so, then you would probably need to roll your own cookie persistence iRule. Given the stated assumption, this is what that iRule might look like:
when RULE_INIT {
set static::key "cookiekey"
}
when HTTP_REQUEST {
if { not ( [HTTP::cookie exists MYSITEPERSIST] ) } {
set needcookie 1
} else {
set ip [HTTP::cookie decrypt MYSITEPERSIST $static::key]
pool local-pool-80 member $ip 80
}
}
when HTTP_RESPONSE {
if { [info exists needcookie] } {
unset needcookie
HTTP::cookie insert name MYSITEPERSIST value [LB::server addr]
HTTP::cookie encrypt MYSITEPERSIST $static::key
}
}
Notice the section:
set ip [HTTP::cookie decrypt MYSITEPERSIST $static::key]
pool local-pool-80 member $ip 80
When the initial request comes in, the client doesn't have a persistence cookie, so normal load balancing happens, and the response event is told to send back the load balanced server IP address in a new encrypted cookie called "MYSITEPERSIST" (arbitrary). On subsequent requests, the client sends this cookie, which the iRule decrypts and uses in the pool command. Here I've statically set the port 80 pool name (local-pool-80) and the listening port 80. You'd have the same iRule on the HTTPS VIP but with a different pool name and different listening port. When the client contacts the HTTPS VIP, using the same host name, it sends the cookie, which the iRule decrypts and uses in the pool command.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* 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