Forum Discussion
Ian_Stewart_390
Nimbostratus
NimbostratusiRules, URL Routing and Cookie Persistance
Hi Everyone,
We have a BigIP 1500, configured with several virtual servers and pools. We use an iRule to make routing decisions to direct traffic to the correct pool based on request URL, since the site is distributed across several pools.
The iRule for one of the virtual servers is as follows. It has a default pool of webnode3_pool.
when CLIENT_ACCEPTED {
set defpool [LB::server pool]
}
when HTTP_REQUEST {
set request_uri [string tolower [HTTP::uri]]
set request_host [string tolower [HTTP::host]]
if { $request_uri contains "/aspnet_client/" } {
pool webnode_pool
}
elseif { $request_uri contains "/ig_common/" } {
pool webnode_pool
}
elseif { $request_uri contains "/cpm/" } {
pool cpmweb_pool
}
elseif { $request_uri contains "/agentrequest/" } {
pool webnode_pool
}
elseif { $request_uri contains "/agents/" } {
pool webnode_pool
}
elseif { $request_uri contains "/home/" } {
pool webnode_pool
}
else {
pool $defpool
}
}
The URL routing works fine. The virtual server is configured to use cookie-insert persistance. If I look at my cookies when I browse the site, I can see BigIP cookies. My concern is that in the administration webpage, under persistance records, every record is showing SOURCE ADDRESS AFFINITY. We recently tried to run a load balancing test, (one machine that makes multiple connections to the site to generate a load), and the BigIP failed to load balance any of the requests.
Does using the iRule not allow the default persistance method defined on the virtual server to take effect? Is there something else I'm missing here -- why isn't cookie-insert persistance working?
Thanks in advance,
Ian
22 Replies
Ian_Stewart_390It enables persistance across virtual servers.
For example, if VS1 puts you on pool1, node2, and then you go to VS2, pool1, you'll get put back on node2, rather than re-balanced to the most availible node.- Unfortunately I think brandorr's right here. This looks like a case for product support.
The rule looks to be in order, and sounds like it's working properly. It sounds like there's a configuration issue on the system (possibly) and we're not equipped to troubleshoot all of the possible causes here.
-Colin
P.S. I would recommend, though, moving the "persist" line up above the "fallback persist" line...just for good measure. - Ian_Stewart_390Ok. I have sent an email to them. I tried here first because in the past I've found the devs and the crowd here pretty sharp. Thanks for the suggestions. =)
-Ian - Ian_Stewart_390There's a detail I've left out here, that I'm wondering if it's a factor.
I'm using the BigIP as a SSL Termination point. So most of the traffic that is hitting the F5 is doing so encrypted, and then it gets decrypted to be sent on to the webserver.
Can I still use the default persistance profiles on the virtual server for that, or do I need to use an iRule to insert my own cookies at that point?
-Ian 
Brian_Gupta_115Actually, you can't do cookie insertion on an SSL VIP unless the BigIP is doing the termination. (So it shouldn't be an issue)
Here's a thought... If your client already has a sourceIP persistence entry, I wonder if it will bother to do the cookie insert?
Also with "across services enable" if you have another VIP using the same pool that isn't using cookie persistence, the pool's persistence table could all get filled with source IP entries.
-Brian
P.S. - I suspect that if an incoming packet matches an existing persistence entry, it's not going to care whether or not it is from the primary or secondary profile. (So you might need to flush the persistence table, and disable the cross service persistence for this to actual work).- Ian_Stewart_390That's an interesting idea..
I do have all my VIP's set to use Cookie_Persistant_Services, so that when a client connects to HTTP, and then jumps to HTTPS, he stays with the same node. But if cookie persistance were to fail and it made a source affinity entry, would it try again later?
Then again, it's not like I have some Source Address Affinity persistance records. They are *all* Source Address Affinity.
-Ian - Brian_Gupta_115Disable persistence on the redirect VIP.
-Brian
P.S. - I added some notes to my previous post.... - Okay okay. Hold on a sec. There should be no problems with SSL termination and cookie persistence. In fact, I don't think there are any problems here at all.
You have configured cookie insert persistence with source address persistence as fallback. First, cookie insert persistence does not create a persistence record. The persistence information is stored in the cookie itself.
When a client connects to BIG-IP and makes a request, BIG-IP will look for a session persistence cookie. If one is found, it will direct the request to the same server as was used for previous connections. If no persistence cookie is found, it will fall back to source address persistence. This means that it will consult the session persistence table for an entry matching the source IP address. For the first request from a new client, no entry will be present, so BIG-IP will create one. This is why you see the SOURCE ADDRESS AFFINITY records.
As for the load balancing test, I would expect every request from the same source address to be directed to the same server. That's source address persistence!
I hope this clears things up... - Ian_Stewart_390*OH*
Ok. That makes a lot of sense.
So the first time someone connects, since they have no cookie and no persistance record, they get a cookie, and a Source Address Affinity record. Then, every subsequent time they connect, they use their cookie, and get routed normally.
However, since that persistance record exists now, if someone else from that IP (Like someone else at the same office, behind a corporate firewall, or a test load box) connects to the BigIP, the BigIP will find their Source Address Affinity record (since they have no cookie to present), and will give them a new cookie, and route them to the same server as the first guy from their office.
Thus, everyone from one source address is being directed to the same node, even though cookie persistance is working. If I wanted to load balance requests from the same IP, I just need to turn off the Fallback Persistance Method.
Sound right?
-Ian - Yes. That's correct.
