CSS arrowpoint cookie load balancing issue

[remkofrancken]

Hi guys,

I need some advice on a load balancing issue.

We have connections hitting the CSS via a proxy environment. As a result i see only one source ip address. I want to use arrowpoint cookies for session stickeyness. However when i enable the rule the tcp session negotiation fails. The CSS sends a TCP/RST which terminates the session.

Here's the rule config:

content HTTP_rule

add service ZSTS299102

add service ZSTS281101

vip address <filtered>

add service LONS299102

add service LONS281101

balance weightedrr

change service ZSTS299102 weight 5

change service ZSTS281101 weight 5

advanced-balance arrowpoint-cookie

protocol tcp

port 80

url "/*"

active

Any help would be much appreciated.

[Gilles Dufour]

does the RST comes after the SYN or after the GET or later on ?

Can we see a captured trace to see the problem.

This config is very standard and works so we'll need to get more info to understand what is going on.

Gilles.

[remkofrancken]

Hi Gilles,

Thanks for the quick reply

The RST comes after the GET. If i return to a layer3/4 config the tcp negotiation is succesfull.

Thanks, Remko

[Gilles Dufour]

Remko,

is there any other rule using either port 80 or the same ip ?

Any group config ?

Do you see a SYN coming to the server after the client sent the GET ?

Could you get a client sniffer trace and a server sniffer trace ?

Thanks,

Gilles.

[remkofrancken]

Hi Gilles,

There is no other rule using this ip or port.

I do not have any group configured at the moment.

I do not see a SYN packet coming after the GET.

I'll see if i can arrange some captures for you.

Thanks again for the help.

Remko

[remkofrancken]

Hi Gilles,

A trace from the client side needs more time.

I did trace on the server side and on the public CSS Vlan. The CSS starts to send the TCP RST whenever the rule is promoted to layer5 (just add url "/*" statement) or using arrowpoint cookies. I can't see any packets hitting any of the servers at that time. I've attached a capture of the session on the public vlan. Hopefully that will help.

Thanks, Remko

[Gilles Dufour]

Remko,

from the trace, we can see that the client sends a FIN immediately after sending the GET.

If the FIN makes it to the CSS before it had time to open a connection with the real server, the CSS will terminate the connection.

This is a known issue but unfortunately the CSS has been designed like this and this behavior can't be changed.

You will have to somehow force the client not to send the FIN until it receives an HTTP response from the CSS.

Gilles.

[remkofrancken]

Hi Gilles,

Many thanks for that!

One more question..Why do i not have this problem when the CSS is set to L3/4 loadbalancing? Is this due to the connection spoofing on layer5 rules?

Thanks again,

Remko

[Gilles Dufour]

Remko,

in L3/L4 the CSS sends the SYN directly to the server.

So when the FIN comes in, we simply pass it to the server.

With L5 the CSS spoofs the connection and we select the server only after receiving the GET.

If there was some delay between the GET and the FIN, the CSS would have time to establish a connection with the server and the FIN could be simply forwarded.

Unfortunately, in this case the FIN is right after the GET with no delay.

Gilles.