Forum Discussion
Lukasz_Knysak
Nimbostratus
NimbostratusAlways send cookie in cookie hash persistence
Hello, The question is what is the purpose of always send cookie setting in cookie hash persistence.
Regards, Lukasz
RaghavendraSYAltostratus
The purpose is to make sure you are sending the traffic to same pool member based on cooke value which is stored in perssitence table.
Understanding cookie hash behavior
The BIG-IP system parses the Set-Cookie header in the server response and applies the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value that the system stores in the persistence table.
When using the cookie hash persistence mode, the following sequence of events occurs:
The BIG-IP system accepts an HTTP request from a client and parses the HTTP request for the cookie as defined by the Cookie Name setting in the persistence profile. If the request does not contain the expected cookie, the BIG-IP system uses the selected load balancing mode to select a pool member and sends the connection to the selected pool member. For example, the first request from a given client does not contain the cookie, and the BIG-IP system uses the load-balancing method to select the pool member. If the request contains the expected cookie, but it does not match an existing persistence table entry, the BIG-IP system uses the selected load-balancing mode to select a pool member, sends the connection to the selected pool member, and stores the value in the persistence table. When the pool member sends the response, the BIG-IP system parses the Set-Cookie header and uses the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value. The Hash Offset is the number of characters in the cookie value to skip before calculating the hash value (ASCII value of each character is a byte in length), and the Hash Length is the number of characters to include when calculating the hash value. The default Hash Offset value of 0 (zero) calculates the hash value at the beginning of the cookie value, and the default Hash Length value of 0 (zero) uses the entire cookie value. The BIG-IP system then stores the value in the persistence table. When the client sends a subsequent request containing the cookie, the BIG-IP system parses the cookie header and uses the offset/length settings to determine if the value matches the one stored in the persistence table. If the values match, the system persists the request to the specified pool member.
- RaghavendraSY
The purpose is to make sure you are sending the traffic to same pool member based on cooke value which is stored in perssitence table.
Understanding cookie hash behavior
The BIG-IP system parses the Set-Cookie header in the server response and applies the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value that the system stores in the persistence table.
When using the cookie hash persistence mode, the following sequence of events occurs:
The BIG-IP system accepts an HTTP request from a client and parses the HTTP request for the cookie as defined by the Cookie Name setting in the persistence profile. If the request does not contain the expected cookie, the BIG-IP system uses the selected load balancing mode to select a pool member and sends the connection to the selected pool member. For example, the first request from a given client does not contain the cookie, and the BIG-IP system uses the load-balancing method to select the pool member. If the request contains the expected cookie, but it does not match an existing persistence table entry, the BIG-IP system uses the selected load-balancing mode to select a pool member, sends the connection to the selected pool member, and stores the value in the persistence table. When the pool member sends the response, the BIG-IP system parses the Set-Cookie header and uses the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value. The Hash Offset is the number of characters in the cookie value to skip before calculating the hash value (ASCII value of each character is a byte in length), and the Hash Length is the number of characters to include when calculating the hash value. The default Hash Offset value of 0 (zero) calculates the hash value at the beginning of the cookie value, and the default Hash Length value of 0 (zero) uses the entire cookie value. The BIG-IP system then stores the value in the persistence table. When the client sends a subsequent request containing the cookie, the BIG-IP system parses the cookie header and uses the offset/length settings to determine if the value matches the one stored in the persistence table. If the values match, the system persists the request to the specified pool member.
Lukasz_KnysakThank you for the answer but this is not the question. This is how cookie hash persistence works, and that is OK. Unfortunately I am not aware and I can't find any information about "Always Send Cookie" for this type od persistence. Everything is clear for me when You use this in Cookie Insert method, where BIG-IP inserts its own cookie. You always use this to update the timeout value.
In Cookie Hash Persistence the cookie and the value is set by the application server and what is stored on BIG-IP is only the hash of the actual value.
In my case it is a session cookie and it's set by the application only once. It is not send in subsequent responses. There is no possibility that big-ip will insert this cookie if the application server will not for subsequent responses (and actually it doesn't - it is been tested). So what really "Always send cookie" actually means I don't know, however it has influence for specific application which "works better" with than without it.
Would be grateful if anyone has met similar issue.
Regards, Lukasz
rob_carr_76748You seem to have a pretty clear idea of what the setting should be able to do, given the circumstance of selecting 'Cookie Hash Persistence'.
When you say that an application "works better" with it, what is the behavioral change you see taking place?
rob_carrCirrocumulus
You seem to have a pretty clear idea of what the setting should be able to do, given the circumstance of selecting 'Cookie Hash Persistence'.
When you say that an application "works better" with it, what is the behavioral change you see taking place?
RaghavendraSY_7Cumulonimbus
The purpose is to make sure you are sending the traffic to same pool member based on cooke value which is stored in perssitence table.
Understanding cookie hash behavior
The BIG-IP system parses the Set-Cookie header in the server response and applies the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value that the system stores in the persistence table.
When using the cookie hash persistence mode, the following sequence of events occurs:
The BIG-IP system accepts an HTTP request from a client and parses the HTTP request for the cookie as defined by the Cookie Name setting in the persistence profile. If the request does not contain the expected cookie, the BIG-IP system uses the selected load balancing mode to select a pool member and sends the connection to the selected pool member. For example, the first request from a given client does not contain the cookie, and the BIG-IP system uses the load-balancing method to select the pool member. If the request contains the expected cookie, but it does not match an existing persistence table entry, the BIG-IP system uses the selected load-balancing mode to select a pool member, sends the connection to the selected pool member, and stores the value in the persistence table. When the pool member sends the response, the BIG-IP system parses the Set-Cookie header and uses the Hash Offset and Hash Length settings in the cookie hash persistence profile to compose a value. The Hash Offset is the number of characters in the cookie value to skip before calculating the hash value (ASCII value of each character is a byte in length), and the Hash Length is the number of characters to include when calculating the hash value. The default Hash Offset value of 0 (zero) calculates the hash value at the beginning of the cookie value, and the default Hash Length value of 0 (zero) uses the entire cookie value. The BIG-IP system then stores the value in the persistence table. When the client sends a subsequent request containing the cookie, the BIG-IP system parses the cookie header and uses the offset/length settings to determine if the value matches the one stored in the persistence table. If the values match, the system persists the request to the specified pool member.
- Lukasz_Knysak
Thank you for the answer but this is not the question. This is how cookie hash persistence works, and that is OK. Unfortunately I am not aware and I can't find any information about "Always Send Cookie" for this type od persistence. Everything is clear for me when You use this in Cookie Insert method, where BIG-IP inserts its own cookie. You always use this to update the timeout value.
In Cookie Hash Persistence the cookie and the value is set by the application server and what is stored on BIG-IP is only the hash of the actual value.
In my case it is a session cookie and it's set by the application only once. It is not send in subsequent responses. There is no possibility that big-ip will insert this cookie if the application server will not for subsequent responses (and actually it doesn't - it is been tested). So what really "Always send cookie" actually means I don't know, however it has influence for specific application which "works better" with than without it.
Would be grateful if anyone has met similar issue.
Regards, Lukasz
- rob_carr
You seem to have a pretty clear idea of what the setting should be able to do, given the circumstance of selecting 'Cookie Hash Persistence'.
When you say that an application "works better" with it, what is the behavioral change you see taking place?
- rob_carr_76748
You seem to have a pretty clear idea of what the setting should be able to do, given the circumstance of selecting 'Cookie Hash Persistence'.
When you say that an application "works better" with it, what is the behavioral change you see taking place?
- RaghavendraSY
If the cookie has an expiration set, the cookie will always be sent in and This prevents an issue when the cookie expires while a session is in progress. Persistence can be lost in that case.
I hope this clears.
- Lukasz_Knysak
Hi, this is still not the case. It works as You say in standard cookie insert persistence. In my case it is a session cookie (without expiration time) and the cookie is not and never will be sent for all the subsequent responses. Only for the first one when the user makes first http transaction. Let's say the user logs in to the application. The application does not insert this cookie for next http transactions if the user sends this cookie. BIG-IP is not aware of the real value of the cookie because what is stored in the persistence table is actually the hash value. It is not possible that LTM will insert this cookie so the question is what is really the meaning of "always send cookie" in cookie hash persistence.
- RaghavendraSY_7
If the cookie has an expiration set, the cookie will always be sent in and This prevents an issue when the cookie expires while a session is in progress. Persistence can be lost in that case.
I hope this clears.
- Lukasz_Knysak
Hi, this is still not the case. It works as You say in standard cookie insert persistence. In my case it is a session cookie (without expiration time) and the cookie is not and never will be sent for all the subsequent responses. Only for the first one when the user makes first http transaction. Let's say the user logs in to the application. The application does not insert this cookie for next http transactions if the user sends this cookie. BIG-IP is not aware of the real value of the cookie because what is stored in the persistence table is actually the hash value. It is not possible that LTM will insert this cookie so the question is what is really the meaning of "always send cookie" in cookie hash persistence.
FozailHi Lukasz Knysak,
As per quick lab and the working nature of "cookie hash persistence", it seems that there would be probably no importance of option "Always Send Cookie" (as BIG-IP is not adding any cookie in the response, BIG-IP is just acting as a relay however at the same time BIG-IP performs hashing of the cookies sent by server in the first response to achieve stickiness).