[f-nsp] foundry serveriron HTTP1.1 issues

[Oliver Adam]

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
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20080829/3122552a/attachment.html>