12-16-2011 11:31 AM
Hi everyone,
I've been using my pair of ACE-4710s for quite some time and have usually stuck to the Class C Subnet sticky settings, as that's what we migrated from in Windows NLB. In one instance of load balancing I'm trying to create an L4 inspection policy that looks for a certain payload (much like a http header) and would like to persist on this. The problem is that the client portion of the conversation starts with a 'SessionID' of 0, and the server responds with a unique 'SessionID'. If I setup the sticky policy with 'Enable Sticky For Response', I get entries populated in the sticky database, but they all go to the same server as there is a sticky session setup for the SessionID = 0. Is there a way to setup sticky entries on server response only? Has anyone else encountered this? Currently using ACE DM v4(1.0).
Regards,
Geoff
Solved! Go to Solution.
12-20-2011 01:39 AM
Hi Geoff,
Thank you for the clarification. Unfortunately, I'm afraid there is no easy solution to this problem, because the ACE will always try to learn sticky entries from the client if they send the string. In your case, as you mentioned, all clients will end up in the same server because they share the same Session ID value for the first connection.
Moving forward, I'm afraid you don't have many options:
I wish I had a better answer for you
Daniel
12-27-2011 06:01 AM
Hi Geoff
Maybe I misunderstood something, but isn't your problem looks very similar to SSL ID stickiness described here :
This is a most important/related part :
ACE-1/routed(config-sticky-l4payloa)# layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST)"
It means - don't touch first 43 bytes of TCP payload, then start looking for :
\x20 or \x00
If \x20 is found first, start hashing everything starting from it till the end (till 75th byte (43+32)) and then populate sticky DB with this hash if it's new, or use/update timers in existing entry.
if \x00 is found first - stop parsing, don't populate sticky DB at all (as no hash is created, so DB won't be check at all), forward this packet to rserver based on LB decision.
The idea of SSL ID stickiness seems to be close to yours, as SSL client has SSL ID = 0 in first packet, and then server sets it (except session reuse). One thing you should be carefull with - to chose the begin-patterns. In SSL packet , we are sure that we won't meet \x00 till Session ID field.
12-19-2011 02:36 AM
Hi Geoff,
If I understdood you correctly, sticky entries are being properly populated in the database, but then, new connections always come with SessionID=0. Is this correct?
If it's like that, you are never going to be able to get this stickiness method to work. You may create a sticky entry based on the server reply, but then, the client requests must include that entry for stickiness to work.
Regards
Daniel
12-19-2011 11:01 AM
Hi Daniel,
Let me try to clear this up a bit. Here is how the exchange works:
Client ->SessionID:0-> Server
Client <-SessionID:5<- Server
Client ->SessionID:5-> Server
So the initial contact with the server has a SessionID of 0, once the server responds with the SessionID, then the client will continue to use it. The problem with this situation is that each new client will use SessionID of 0 in the first packet, which if sticky is setup will map it to the same server (aka server1 in the farm). The SessionID is local to the server for session tracking, so being put on another server will break the session and it will have to start over. Sticky entries are being populated in the database, the only problem is they all map to server 1 (due to all clients coming in with SessionID:0)
12-20-2011 01:39 AM
Hi Geoff,
Thank you for the clarification. Unfortunately, I'm afraid there is no easy solution to this problem, because the ACE will always try to learn sticky entries from the client if they send the string. In your case, as you mentioned, all clients will end up in the same server because they share the same Session ID value for the first connection.
Moving forward, I'm afraid you don't have many options:
I wish I had a better answer for you
Daniel
12-22-2011 02:10 PM
Thank you Daniel. It was as I suspected. I don't imagine Cisco has plans of changing this so I'll have to find another way.
12-27-2011 06:01 AM
Hi Geoff
Maybe I misunderstood something, but isn't your problem looks very similar to SSL ID stickiness described here :
This is a most important/related part :
ACE-1/routed(config-sticky-l4payloa)# layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST)"
It means - don't touch first 43 bytes of TCP payload, then start looking for :
\x20 or \x00
If \x20 is found first, start hashing everything starting from it till the end (till 75th byte (43+32)) and then populate sticky DB with this hash if it's new, or use/update timers in existing entry.
if \x00 is found first - stop parsing, don't populate sticky DB at all (as no hash is created, so DB won't be check at all), forward this packet to rserver based on LB decision.
The idea of SSL ID stickiness seems to be close to yours, as SSL client has SSL ID = 0 in first packet, and then server sets it (except session reuse). One thing you should be carefull with - to chose the begin-patterns. In SSL packet , we are sure that we won't meet \x00 till Session ID field.
01-05-2012 10:44 AM
Borys my friend, you have the answer! I didn't know about that metacharacter. I was able to configure what I needed using a begin-pattern of:
"(SessionId: [^0]|\r\n\r\n\xST)"
Which essentially looks for a non-zero SessionId in the application header, and if none is found, it will just pass the packet on to a server. I also turned on 'Response Sticky' and it is working flawlessly so far. Thank you very much for pointing me in the right direction!
Regards,
Geoff
01-06-2012 12:23 PM
Hmmm...I was going to post a new thread, but it is related to this issue. Apparently my ACE 4710 (A4 1.0) is not persisting on new client TCP sessions that have the same 'SessionID'. Here is a breakdown of issue:
Example of it working:
Client port 1234 ->SessionID:0-> Server1
Client port 1234 <-SessionID:5<- Server1
Client port 1234 ->SessionID:5-> Server1
Client port 1234 <-SessionID:5<- Server1
Example of it not working:
Client port 1234 ->SessionID:0-> Server1
Client port 1234 <-SessionID:5<- Server1
Client port 1235 ->SessionID:5-> Server2
Server 2 says go away since it doesn't know about that SessionID
Obviously in some cases a port may have to be closed, so this is obviously not going to work for us. Any ideas?
Applicable config below:
serverfarm host sf_test1
description 1.2.3.4
rserver rs_srv1
inservice
rserver rs_srv2
inservice
sticky layer4-payload sticky_test_sessionid
timeout 30
replicate sticky
serverfarm sf_test1
response sticky
layer4-payload offset 70 length 10 begin-pattern "(SessionId: [^0]|\r\n\r\n\xST)"
class-map match-all vs_test1
2 match virtual-address 1.2.3.4 tcp eq www
policy-map type loadbalance generic first-match vs_test1-l7slb
class class-default
sticky-serverfarm sticky_test_sessionid
policy-map multi-match int502
class vs_test1
loadbalance vip inservice
loadbalance policy vs_test1-l7slb
loadbalance vip icmp-reply active primary-inservice
01-09-2012 01:26 AM
Hi Geoff
Do you see any sticky entry created for this
Client port 1235 ->SessionID:5-> Server2
session ? It's good to know what exactly happened with this session,maybe something wrong with pattern/length.
Maybe you could try to specify begin-pattern, I mean as I see for now you have only part which does nothing(i.e. when ACE meet SessionId: [^0]|\r\n\r\n it does nothing) Maybe you should it in something like this :
layer4-payload offset 70 length 10 begin-pattern "(SessionId:10|SessionId: [^0]|\r\n\r\n\xST)"
I'm not sure about first pattern, the best way to figure it out it's to check capture. I've just assumed that session ID length will be 10
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: