sticky-srcip not working!

[admin_2]

I have my CSS 11501 configured as follows:

!Generated on 09/11/2006 11:52:59

!Active version: sg0730203

configure

!************************* INTERFACE *************************

interface e1

bridge vlan 10

phy 100Mbits-FD

interface e2

bridge vlan 10

phy 100Mbits-FD

!************************** CIRCUIT **************************

circuit VLAN10

ip address x.x.198.15 255.255.254.0

!************************** SERVICE **************************

service webserver_8080

ip address x.x.198.8

port 8080

keepalive type http

keepalive port 8080

keepalive frequency 60

active

service webserver_8082

ip address 10.156.198.8

port 8082

keepalive type http

keepalive port 8082

keepalive frequency 60

active

!*************************** OWNER ***************************

owner web

content webserver_80

add service webserver_8080

add service webserver_8082

vip address x.x.198.9

protocol tcp

port 80

url "/*"

active

content webserver_80_asde

vip address x.x.198.9

add service webserver_8080

add service webserver_8082

protocol tcp

port 80

url "/asde/*"

advanced-balance sticky-srcip

sticky-inact-timeout 5

active

Doing a tcpdump on the webserver, I see connections on both 8080 and 8082 when i go to http://webserver/asde/. If I suspend the webserver_80 content rules, I get nothing from the website, even under the /asde url. Can anyone clue me in as to why this isn;t working properly?

[Gilles Dufour]

what do you see in the trace when you suspend a server ?

What is the 'sho summary' telling you when you suspend a service ? Do you see the connection counter increasing ?

Gilles.

[#3]

The problem seems to be intermittent. Looking at the show summary I can see that it is mostly delivering the requests to one server, but occasionally one gets sent to the second server. Suspending one of the services, the counters on the other server increase as you would expect

[Gilles Dufour]

so, there is no problem with suspending services.

Your concern is when both services are active, you see un-even loadbalancing ? Or is it that you see a request that should go to serverA going to serverB ?

Could you please clarify and take a sniffer trace showing the problem and send it to us.

Gilles.

[#5]

No, the problem is that with both services are active, and browsing to an /asde url on the servers, the request does not stay stuck to one server. The web page refreshes every minute, so the timeout value should never be reached, hence the client should remain stuck to one of the two servers. It seems to mostly work, but occasionaly it incorrectly sends the requests to the other service. Looking at the tcpdump output on the server:

12:15:44.045685 10.156.199.90.2173 > 10.156.198.8.8082: P 3433:4053(620) ack 59713 win 32767 (DF)

12:15:44.061428 10.156.198.8.8082 > 10.156.199.90.2173: . 59713:61173(1460) ack 4053 win 13698 (DF)

12:15:44.061447 10.156.198.8.8082 > 10.156.199.90.2173: . 61173:62633(1460) ack 4053 win 13698 (DF)

12:15:44.061456 10.156.198.8.8082 > 10.156.199.90.2173: . 62633:64093(1460) ack 4053 win 13698 (DF)

12:15:44.061463 10.156.198.8.8082 > 10.156.199.90.2173: P 64093:64304(211) ack 4053 win 13698 (DF)

12:15:44.062684 10.156.199.90.2173 > 10.156.198.8.8082: . ack 62633 win 32767 (DF)

12:15:44.062699 10.156.199.90.2173 > 10.156.198.8.8082: . ack 64304 win 32767 (DF)

12:15:44.066683 10.156.199.90.2173 > 10.156.198.8.8082: P 4053:4664(611) ack 64304 win 32767 (DF)

12:15:44.102655 10.156.198.8.8082 > 10.156.199.90.2173: . ack 4664 win 15220 (DF)

12:15:44.120686 10.156.199.90.2174 > 10.156.198.8.8080: S 226097211:226097211(0) win 5840 (DF)

12:15:44.120745 10.156.198.8.8080 > 10.156.199.90.2174: S 2982191461:2982191461(0) ack 226097212 win 5840 (DF)

12:15:44.122180 10.156.199.90.2174 > 10.156.198.8.8080: P 1:543(542) ack 1 win 5840 (DF)

12:15:44.122224 10.156.198.8.8080 > 10.156.199.90.2174: . ack 543 win 6504 (DF)

12:15:44.122775 10.156.198.8.8080 > 10.156.199.90.2174: P 1:124(123) ack 543 win 6504 (DF)

12:15:44.123181 10.156.199.90.2174 > 10.156.198.8.8080: . ack 124 win 5840 (DF)

12:15:44.191513 10.156.198.8.8082 > 10.156.199.90.2173: . 64304:65764(1460) ack 4664 win 15220 (DF)

12:15:44.191532 10.156.198.8.8082 > 10.156.199.90.2173: . 65764:67224(1460) ack 4664 win 15220 (DF)

12:15:44.191539 10.156.198.8.8082 > 10.156.199.90.2173: . 67224:68684(1460) ack 4664 win 15220 (DF)

12:15:44.191546 10.156.198.8.8082 > 10.156.199.90.2173: . 68684:70144(1460) ack 4664 win 15220 (DF)

12:15:44.191553 10.156.198.8.8082 > 10.156.199.90.2173: . 70144:71604(1460) ack 4664 win 15220 (DF)

[Gilles Dufour]

the sticky timeout start ticking down when the connection is open and it is reset each time a new connection is open.

So, if the connection was open more than 5 minutes ago, even if there is still traffic going through, the sticky entry is gone.

The 2nd thing to consider is persistent connections and the css 8sec idle timeout.

The CSS can stop inspecting active flow if it believes the flow is dead which is true if it stays idle more than 8sec.

I would suggest to increase the idle timeout with the following command under each content rule.

'flow-timeout-multiplier 20'

Also increase the sticky timeout to 60.

Just to be sure.

Let me know if that helps.

Gilles.

[#7]

That seems to have solved the problem. I let it run all night and didn't see on misrouted packet! Thanks!