<html>
<body>
Is this working now? I am curious to know whether the stuff mentioned
below was of any help or not.<br><br>
Regards,<br><br>
Oliver<br><br>
At 17:17 29.08.2008, Oliver Adam wrote:<br>
<blockquote type=cite class=cite cite="">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:<br><br>
<font face="Courier New, Courier">server l7-tcp-window-size 1460<br><br>
This might help.<br><br>
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. <br><br>
R, Oliver<br><br>
<br><br>
</font>At 11:12 29.08.2008, arne van theemsche wrote:<br>
<blockquote type=cite class=cite cite="">Dear group<br><br>
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<br><br>
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"<br><br>
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<br><br>
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<br><br>
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)<br><br>
are there known issues to using http 1.1 in layer7 switching?<br><br>
this is the relevant info<br><br>
SW: Version 10.0.00bTD4 Copyright (c) 1996-2007 Foundry Networks,
Inc.<br>
Compiled on Aug 04 2007 at 13:40:20 labeled as
WXR10000b<br>
HW: ServerIronGT C-Series Router, SYSIF version 21, Serial #:
Non-exist<br>
==========================================================================<br>
SL 1: WSM6-SSL Management Module, SYSIF 2, M6, ACTIVE<br>
Serial #: <br>
0 MB SHM, 1 Application Processors<br>
16384 KB BRAM, SMC version 5, BM version 21<br>
SW: (1)10.0.00bTF3<br>
==========================================================================<br>
SL 2: J-BxGC16 JetCore Gig Copper Module, SYSIF 2<br>
Serial #: 4096 KB BRAM, JetCore ASIC IGC version
49, BIA version 8a<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 4, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 5, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 6, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 7, version 0449<br>
==========================================================================<br>
SL 3: J-BxGC16 JetCore Gig Copper Module, SYSIF 2<br>
Serial #: 4096 KB BRAM, JetCore ASIC IGC version
49, BIA version 8a<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 8, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 9, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 10, version 0449<br>
32768 KB PRAM and 2M-Bit*1 CAM for IGC 11, version 0449<br>
==========================================================================<br>
Active management module:<br>
1.0 GHz Power PC processor 750GX (version 7002/0102) 66 MHz
bus<br>
512 KB boot flash memory<br>
16384 KB code flash memory<br>
512 KB SRAM<br>
512 MB DRAM<br>
The system uptime is 265 days 20 hours 7 minutes 49 seconds<br>
The system started at 13:44:55 GMT+01 Fri Dec 07 2007<br><br>
<br>
VIP configuration<br><br>
server virtual WEB-VIP 1.2.3.4<br>
sym-priority 100<br>
sym-active<br>
predictor round-robin<br>
port http<br>
port http cookie-name "webnn"<br>
port http cookie-switching<br>
port http insert-cookie<br>
bind http S1 http S3 http S4 http S5 http<br><br>
<br><br>
_______________________________________________<br>
foundry-nsp mailing list<br>
foundry-nsp@puck.nether.net<br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" eudora="autourl">
http://puck.nether.net/mailman/listinfo/foundry-nsp</a></blockquote><br>
_______________________________________________<br>
foundry-nsp mailing list<br>
foundry-nsp@puck.nether.net<br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" eudora="autourl">
http://puck.nether.net/mailman/listinfo/foundry-nsp</a></blockquote>
</body>
<br>
</html>