Forum Discussion
AVF_7351
Nimbostratus
NimbostratusStateless session persistence
Hi,
I'm trying to set up session persistence in such a way that it doesn't depend on a state table in LTM. This is so that persistence will work when a client moves to a different LTM, when the LTMs aren't in a cluster. (This is for OSPF failover, but this is irrelevant.)
What I basically want to do is to insert (an obscured version of) the backend server's IP into a cookie and then persist just by going to whatever server is specified in the cookie (with some logic to handle the server going down).
Before I go on, maybe I should just ask at this point: how would I do this? I'm new to F5, and in some cases, I can make something work, but it just feels wrong, so I'd rather not share my code at this stage.
I've tried creating a universal persistence profile with a rule that looks at the cookie and says "pool [ LB::server pool ] member $foo". However, I also have a rule which selects a pool based on the URL. With this set-up, the persistence rule runs first and the result is that it's messed up when the pool selection rule says "pool foo".
The way I got it to work is by having no persistence profile and just attaching the persistence rule to the vserver, and making it run after the pool selection rule.
However, this just feels Wrong. It also won't be very transparent when someone else comes to look at the config (this is something we were really hoping to achieve by replacing our old load balancers with F5).
Another related question: what is the difference between "pool $pool member $member" and "LB::reselect pool $pool $member"?
I'd be very grateful for any suggestions.
Alex
hoolioCirrostratus
That makes sense. The cookie name for the cookie insert persistence profile would need to be the same across each LTM unit for this to work.
Aaron
L4L7_53191Assuming that the pool name is different across pairs, you're right Aaron. If they are the same across pairs, it should match with something like BigIPServercookie_poolName if I am not mistaken...
-Matt
Michael_YatesIn the event of a failover, traffic would have to use the same hostname in order for the F5 Session Cookie to be used, have the same pool name, and the server would need to be available on the same port number:
BIGipServer=..0000
The .0000 is reserved for future functionality.- Michael_Yates
BIGipServer=..0000 
AVF_7351> The algorithm to extract this value from the cookie is the same across BigIPs so it
> should Just Work.
I didn't think this was the case because the persistence profile has a "mirror persistence" option. (I don't have any way of verifying this because I only have one BIG-IP at the moment [expecting more this week, hopefully].)
Still, though, I'd like to have more control over what happens with the cookies, so I may still decide to use a universal persistence profile.
What is the correct way to select a node in a rule attached to a universal persistence profile? Is it "LB::reselect $pool $node", "node $node", "pool $pool member $node", or something else??
Presumably I would also need some logic to handle disabled/forced-offline nodes? Do I really need to reimplement all this logic if I want to use a universal persistence profile?
Is there an example somewhere of, say, implementing a cookie-insert persistence profile in iRules?
Thanks!
Alex- hoolioHi Alex,
If you use universal persistence, the persistence record would be stored locally and couldn't be synch'd to an LTM outside of a redundant pair. So cookie insert persistence makes for a nice simple way to handle this assuming (as Michael pointed out) the hostnames the client accesses are all on the same domain and you manually set the domain on the persistence cookie. The pool names would need to be the same across the units (or you could manually set the persistence cookie name in the cookie insert persistence profile).
LB::reselect forces a new load balancing selection. Using the pool or node command would be more efficient. The pool command would give you pool stats whereas the node command wouldn't. If you're manually selecting the pool or node, you would probably want to check that the server is marked up using LB::status. Or you could wait for a failure and add logic to the LB_FAILED event to re-load balance the request.
You can manually configure cookie insert persistence in an iRule using the persist command:
http://devcentral.f5.com/wiki/default.aspx/iRules/persist
Here are a few other related wiki pages:
http://devcentral.f5.com/wiki/default.aspx/iRules/lb__status
http://devcentral.f5.com/wiki/default.aspx/iRules/pool
http://devcentral.f5.com/wiki/default.aspx/iRules/node
Aaron - AVF_7351Thanks Aaron.
> You can manually configure cookie insert persistence in an iRule using the persist
> command
Is there an example of how to do this somewhere? The wiki page just says that the command is there, but doesn't say anything about how to use it.
Another question: what is the difference between using a universal persistence profile with an iRule and attaching the same iRule to a vserver?
(I just tried to enable cookie-insert persistence on my vserver, but it doesn't seem to be doing anything at all...)
Alex - AVF_7351It looks like I'm hitting the same bug as in
http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/afv/topic/aff/5/aft/1166691/Default.aspx
That is, a basic vserver with the iRule
when HTTP_REQUEST {
persist cookie insert "PERSIST_COOKIE"
}
works (that is, the cookie is inserted), but having a "node", "LB::reselect", or "pool" line before the "persist" breaks it.
I'm on 10.1.0.
Alex - L4L7_53191Alex: I'm not entirely sure that this is actually a bug. To me, the behavior you see makes sense: the persist cookie's value is an encoded string that maps to an ip:port combinantion - in other words, a 'node'. By specifying a reselect, node, or pool statement first you're explicitly telling BigIP to send the traffic to a destination as opposed to letting it defer to the cookie's value for this.
What are you trying to accomplish in your rule with those commands? Maybe we can come up with another approach that won't conflict with your persistence requirement.
-Matt - hoolioI think F5's perspective on using the persist command with explicit node or pool member selection is that the iRule should handle the persistence if it's handling the load balancing. So I think it will be a bit of an uphill battle to get the LTM behavior changed. You can manually set a cookie for persistence when you're manually selecting a pool member following the logic outline in this post:
http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/afv/topic/aff/5/aft/1166691/Default.aspx1166717
As for UIE persistence in an iRule or a profile, I'm not aware of any functional differences. You don't need to add a UIE persistence profile in order to use a persist uie command.
For the persist cookie insert command, the only available options are 'persist cookie insert < name > < timeout > ' where is optional < timeout >.
Aaron