Ace 4710 - Response Sticky Only

[geoffbucar]

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

[Daniel Arrondo Ostiz]

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

[geoffbucar]

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)

[Daniel Arrondo Ostiz · Accepted solution]

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:

• Modify your application so that the session ID field is not sent at all in the first request
• Modify the matching pattern so that session ID 0 is not matched but all the others are (I'm not sure if this is possible)
• Use a different stickiness system.

I wish I had a better answer for you

Daniel

[geoffbucar]

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.

[Borys Berlog · Accepted solution]

Hi Geoff

Maybe I misunderstood something, but isn't your problem looks very similar to SSL ID stickiness described here :

http://docwiki.cisco.com/wiki/Secure_Sockets_Layer_Persistence_Configuration_Example#Sample_SSL_stickiness_Configuration

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.

[geoffbucar]

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

[geoffbucar]

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

[Borys Berlog]

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