Forum Discussion
Verifying Cookie Persistence
I'm trying to validate cookie persistence is working on my Lab VE. My profile is using the Cookie Insert method with the default settings from the default cookie persistence profile. I can see that the cookie is being sent to my browser and I can see the session is persisting to the same pool member.
My question is, why can't I see these persistent sessions on the big-ip itself? If I do a 'show ltm persistence persit-records' from TMSH using source-address-affinity I see the persistent sessions. I can also see source-address-affinity sessions by viewing 'Persistence Records' in the LTM statistics module. I don't see anything when using cookie persistence. I've tried this with both 11.5.1 HF4 and 11.4.1 HF4 and get the same result.
8 Replies
- nitass
Employee
why can't I see these persistent sessions on the big-ip itself?
cookie persistence does not utilize persistence table. pool member is encoded in the cookie value.
sol6917: Overview of BIG-IP persistence cookie encoding
- Kevin_Davies_40
Nacreous
Because the client is providing the persistence by way of the cookie there are no records on the BIGIP as they are not needed. This works especially well in HA as no persistence mirroring is required.
- KS-NetEngineer_
Nimbostratus
That makes sense, thanks for the responses.
One thing I noticed was that the IIS iApp uses Cookie persistence with a fallback of Source persistence. When I make a connection through the BIG-IP to the web servers I see the Source persistence records in the persistence table even though I'm (presumably) using Cookie persistence. When I ran some tests I noticed that
- Client connects to the big-ip
- The BIG-IP makes a load balancing decision and then creates a persistence record based on the source IP address (after it applies the mask)
- The BIG-IP make the HTTP request to the server and the server sends back the HTTP response
- The BIG-IP inserts the persistence cookie into the server response and then sends it to the client
-
The client makes a subsequent request to the BIG-IP.
5a. If the client request contains the persistence cookie, the BIG-IP decodes it and then sends the request to the correct webserver.
5b. If the client request does not contain a persistence cookie, the BIG-IP looks for a matching entry in the persistence table. If there is a matching entry the BIG-IP sends the request to correct webserver.
5c. If the client request does not contain a persistence cookie and there is no matching entry in the persistence table, the BIG-IP makes a load-balancing decision.
How do you know for sure that the BIG-IP is using Cookie persistence and not Source persistence? Is there something in the persistence table you can look for that shows "active" connections. If I run the 'show ltm persistence persist-records all-properties' command from TMSH I don't see what I'm looking for but maybe I'm missing something.
I have verified that even after the Source persistence record times out, my session still persists to the same webserver. Is this is the best way to verify cookie persistence?
- Kevin_Stewart
Employee
How do you know for sure that the BIG-IP is using Cookie persistence and not Source persistence?
Because one is the primary and one is the secondary. This implies that the first will always be used unless it doesn't exist in the request. The cookie itself is an obfuscation of the pool-node-port of the selected member. You could then, technically, capture a known good cookie value for a pool member, create a new connection through a proxy-inspection product like Fiddler or Burp, and then swap the current cookie with the saved cookie. Assuming the above is true, the existence of this cookie should send the request to the new pool member, regardless of the secondary source persistence.
- Kevin_Davies_40
Nacreous
The simple answer here is when you specify a secondary persistence it always runs both but only uses the second if the first cannot be found. Its easy to test, try accessing your application until you get sent to the second pool member. Now write the value of BIGipServer cookie down. Clear all cookies and wait for source persistence records to expire. Now with round robin as your load balancing access your application and you should get a cookie for the first server and a persistence record for same. Now clear cookies and try is again. You will go back to the first server because of the persistence record and the cookie will reappear on the client side as the F5 will create one. Now clear cookies again and craft a request using the cookie you wrote down. Now you will go to the second server.
- Kevin_Davies_40
Nacreous
If you want to know if you cookie persistence is being used then check for the existence of the BigIPServer cookie in the request using an iRule. If it exists and cookie persistence is enabled then it will be using it.
when HTTP_REQUEST { if {[HTTP::cookie exists "BIGipServer[LB::server pool]"]} { log local0. "Using cookie persistence" } }
- Subrun
Cirrostratus
Can you tell what you meant as "using cookie persistence"
So after setting this I should be able to see logs from /var/log/ltm ?
log local0. "Using cookie persistence"
- MessiHong_20925Historic F5 Account
great help!!!
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