[f-nsp] foundry serveriron HTTP1.1 issues

Tue Sep 9 03:07:46 EDT 2008

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