Stateless 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

12 Replies

hooleylist
Cirrostratus
Jun 22, 2010
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_53191
Nimbostratus
Jun 22, 2010
Assuming 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_Yates
Nimbostratus
Jun 22, 2010
In 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
Nimbostratus
Jun 22, 2010
BIGipServer=..0000
AVF_7351
Nimbostratus
Jun 23, 2010
> 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
hooleylist
Cirrostratus
Jun 23, 2010
Hi 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_7351
Nimbostratus
Jun 23, 2010
Thanks 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_7351
Nimbostratus
Jun 23, 2010
It 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_53191
Nimbostratus
Jun 23, 2010
Alex: 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
hooleylist
Cirrostratus
Jun 23, 2010
I 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