Dear Oliver
We didn't have had the time to apply this change. Since this is a global
settings change on a live environment, We are only allowed to do this
change during existing maintenance windows. Such a window has not passed
yet. We'll keep the list update as soon as results are there.
thanks for your help
Arne
Is this working now? I am curious to know whether the stuff mentioned
below was of any help or not.
Regards,
Oliver
At 17:17 29.08.2008, Oliver Adam wrote:
First of all I would suggest to get rid of the old L7 legacy
switching configuration and move to the modern CSW way of doing it
(see documentation about csw rules and policies). Try to set the
following to solve the performance issue:
server l7-tcp-window-size 1460
This might help.
The reason why "server l7-tcp-window-size 1460" works is that client
always waits for the SI to send an ack before sending an additional
packet. Thus, if SI finds the cookie in the first packet, it takes a
switching decision and send an ack immediately. If it does not find
the cookie in the first packet then it stores the packet, sends an
ack, and wait for the second packet.
R, Oliver
At 11:12 29.08.2008, arne van theemsche wrote:
Dear group
we are using foundry for quiet some time, but we have an issue
regarding enabling http 1.1 (port http keep-alive) on a virtual IP
we noticed that the real servers gave a better performance than the
virtual IP, after debugging it seemed that the VIP didn't reuse it's
tcp sessions, and that this was solvable by enabling the HTTP 1.1
feature through "port http keep-alive"
this did indeed solve the performance issue, but we created new
ones. After some time, sessions on the page started to "hang". In
wireshark/tcpdump I could see 2 things. I did a tcpdump before and
after the serveriron
1) for big request packets (POST from client -> server) which were
fragmented somewhere (don't know where, could be the serveriron
itself) the serveriron suddenly started to send tcp-ack's in name of
the webserver (there where before in the session all the ack's were
send by the webserver). The problem is he only send an ACK for the
first fragment (1500 bytes of a 2300 bytes packet). Because of the
retransmit, the webserver seemed to got confused and suddenly sended
an ACK for the byte-position BEFORE the big backet. So the client
first got an ACK for N+1500 from the foundry (where he sended
N+2300), and a few seconds later he got an ACK for N (from the
webserver). No doubt that this messed up everything, and only got
solved by an tcp-reset after a few seconds. During those seconds,
the session of course hung, which was not the meaning
2) in other cases (read other browsers?) the packet (not a big one)
was sended, but never got it behind the foundry (also resulting in
the same experience (website hangs for a few seconds)
are there known issues to using http 1.1 in layer7 switching?
this is the relevant info
SW: Version 10.0.00bTD4 Copyright (c) 1996-2007 Foundry Networks, Inc.
Compiled on Aug 04 2007 at 13:40:20 labeled as WXR10000b
HW: ServerIronGT C-Series Router, SYSIF version 21, Serial #: Non-exist
==========================================================================
SL 1: WSM6-SSL Management Module, SYSIF 2, M6, ACTIVE
Serial #:
0 MB SHM, 1 Application Processors
16384 KB BRAM, SMC version 5, BM version 21
SW: (1)10.0.00bTF3
==========================================================================
SL 2: J-BxGC16 JetCore Gig Copper Module, SYSIF 2
Serial #: 4096 KB BRAM, JetCore ASIC IGC version 49, BIA version 8a
32768 KB PRAM and 2M-Bit*1 CAM for IGC 4, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 5, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 6, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 7, version 0449
==========================================================================
SL 3: J-BxGC16 JetCore Gig Copper Module, SYSIF 2
Serial #: 4096 KB BRAM, JetCore ASIC IGC version 49, BIA version 8a
32768 KB PRAM and 2M-Bit*1 CAM for IGC 8, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 9, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 10, version 0449
32768 KB PRAM and 2M-Bit*1 CAM for IGC 11, version 0449
==========================================================================
Active management module:
1.0 GHz Power PC processor 750GX (version 7002/0102) 66 MHz bus
512 KB boot flash memory
16384 KB code flash memory
512 KB SRAM
512 MB DRAM
The system uptime is 265 days 20 hours 7 minutes 49 seconds
The system started at 13:44:55 GMT+01 Fri Dec 07 2007
VIP configuration
server virtual WEB-VIP 1.2.3.4
sym-priority 100
sym-active
predictor round-robin
port http
port http cookie-name "webnn"
port http cookie-switching
port http insert-cookie
bind http S1 http S3 http S4 http S5 http
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
