From: Claudio Rosa (crmrosaIZZATterra.com.br)
Date: Fri Nov 22 2002 - 15:22:55 EST
Tino,
I found the NortelNetworks paper that I´m looking for. This is the WebOS
10.0.26.6 Release Notes and you can see below the fix in the WebOS
10.0.26.4:
VERSION 10.0.26.4 Fixes and Enhancements [Unreleased Version]
Born on 07/30/02
Priority 2/High Impact Bugs
Bug: Q00492555 [Layer 7]
In Layer7 WCR case, when heap is out of memory, we can no longer buffer
incoming
http requests to see whether it's destined for cache server or origin
server.
In the case of slow origin server response or non-existent origin server, we
will get a lot of half bound connections that hogs up heap memory. This will
cause the switch to refuse any new connections and become unresponsive.
Switch
will now forward these requests to the origin server instead of just doing
random early drops. Also fixed, if we haven't bind to a real server yet,
just
display the destination IP instead of 0.0.0.0 in a session table dump.
Claudio Rosa
-----Mensagem original-----
De: Claudio Rosa [mailto:crmrosaIZZATterra.com.br]
Enviada em: segunda-feira, 18 de novembro de 2002 23:33
Para: 'lb-lIZZATvegan.net'
Assunto: RES: [load balancing] Alteon AD3 - Redirect to IP address
0.0.0.0
Hi Tino,
You have differents problems happening at the same time:
1) 0.0.0.0 in the session table: until version 10.0.26.6, when you are
working with Layer 7 processing(URLWCR, URLSLB, etc...), this is the Alteon
way to inform that it had problems to assign one real server. We are
testing the WebOS 10.0.26.6 and it don´t put anymore 0.0.0.0 in the session
table;
2) Your router problem:
2.1) when a session is closed prematurely(half-closed by server and you not
put time enough in the fastage to wait the ACK returns from the client, for
example) when the server do a "retry" of the FIN, as the session do not
exist anymore in the session table, the "server processing"(at Alteon port)
will not happen. The Alteon will route the packet with SIP=RIP in a place
of VIP. The client will send a RESET, but the packet will not return if the
RIP is a invalid IP(10.x.y.z). The server will send a "retry" again and
again... We had this problem and we correct them with a fastage tunning.
You will have to find a good number of fastage to your environment. We work
with 3.
2.2) if you have a idle session, the Alteon close this session because it is
idle(tmout) and after that the server try to send a packet to the client, it
will happen the same thing that the session closed prematurely. In this
case you have to do a tunning in the server to close the idle session, in a
place of Alteon.
Claudio Rosa
Project Coordenator
Globo.com
claudio.rosaIZZATcorp.globo.com
55 21 22331022(219)
-----Mensagem original-----
De: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net]Em nome de Tino
Enviada em: segunda-feira, 18 de novembro de 2002 19:32
Para: lb-lIZZATvegan.net
Assunto: Re: [load balancing] Alteon AD3 - Redirect to IP address
0.0.0.0
Found the answer to this problem.
Customer had a script running from the real server every 30 seconds health
checking a static page on the VIP. Most of the time, it does not complete
the 3-way handshakes but sometimes it does and would fail on the GET
request. After the script is started, it took 1-2 days for the problem to
occur
when we have to clear the session table to fix it.
We have been monitoring the HalfopenSession using MRTG and this was not the
cause of the problem as it was the same before and after
the fault occur. The problem is no longer there when we stopped the script
but I am just wondering if anyone can explain how the Alteon behave when a
Real server tried to connect to the VIP (no client processing on the Server
port) and we have routing on.
Regards - Tino
----- Original Message -----
From: "Tino" <tinngoIZZAThotmail.com>
To: "Alteon" <lb-lIZZATvegan.net>
Sent: Sunday, October 13, 2002 11:06 PM
Subject: [load balancing] Alteon AD3 - Redirect to IP address 0.0.0.0
> Hi all,
>
> Just got a weird problem on our AD3 running 9.0.41.5-SSH. Certain user on
> the Internet can not get to the Web server and the session
> table showed that the Alteon redirect to 0.0.0.0.
>
> Below is the capture:
>
> 203.13.116.12 is the Proxy IP (Client)
> 203.13.133.172 is the VIP with .164 and .165 being the real servers.
> We are doing Passive Cookie LB and it has been working fine for the last 6
> months.
> The problem was fixed by clearing the session table but it reoccured again
a
> second time after approximately
> 48 hours when I had to clear the session table again.
> When this happened, the Firewall in front of the Alteon showed that the
> session was disonnected due to SYN-Timeout.
> I am tempted to restart the box but hope to find an answer.
>
> 7,32: 203.13.116.12 3681->4128, 203.13.133.172 80 -> 203.13.133.164 80
age
> 10
> 7,34: 203.13.116.12 3639->4130, 203.13.133.172 80 -> 0.0.0.0 80 age 2
EU
> 7,94: 203.13.116.12 3644->4190, 203.13.133.172 80 -> 0.0.0.0 80 age 2
EU
> 7,127: 203.13.116.12 3654->4223, 203.13.133.172 80 -> 0.0.0.0 80 age 2
> EU
> 7,226: 203.13.116.12 3696->4322, 203.13.133.172 80 -> 0.0.0.0 80 age 4
> EU
> 7,229: 203.13.116.12 3695->4325, 203.13.133.172 80 -> 203.13.133.164 80
> age 10
> 7,299: 203.13.116.12 3563->4395, 203.13.133.172 80 -> 0.0.0.0 80 age 0
U
> 7,333: 203.13.116.12 3698->4429, 203.13.133.172 80 -> 0.0.0.0 80 age 4
> EU
> 7,356: 203.13.116.12 3641->4452, 203.13.133.172 80 -> 0.0.0.0 80 age 2
> EU
> 7,400: 203.13.116.12 3642->4496, 203.13.133.172 80 -> 0.0.0.0 80 age 2
> EU
> 7,531: 203.13.116.12 3684->4627, 203.13.133.172 80 -> 0.0.0.0 80 age 4
> EU
> 7,576: 203.13.116.12 3598->4672, 203.13.133.172 80 -> 0.0.0.0 80 age 0
U
> 7,643: 203.13.116.12 3701->4739, 203.13.133.172 80 -> 0.0.0.0 80 age 4
> EU
> 7,673: 203.13.116.12 3561->4769, 203.13.133.172 80 -> 0.0.0.0 80 age 0
U
> 7,959: 203.13.116.12 3614->5055, 203.13.133.172 80 -> 0.0.0.0 80 age 0
U
> 7,977: 203.13.116.12 3678->5073, 203.13.133.172 80 -> 0.0.0.0 80 age 4
> EU
> 7,1105: 203.13.116.12 3687->5201, 203.13.133.172 80 -> 203.13.133.165 80
> age 10
> 7,1238: 203.13.116.12 3622->5334, 203.13.133.172 80 -> 0.0.0.0 80 age 0
> U
> 7,1347: 203.13.116.12 3579->5443, 203.13.133.172 80 -> 0.0.0.0 80 age 0
> U
>
> Regards - Tino
> ____________________
> The Load Balancing Mailing List
> Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
> Archive: http://vegan.net/lb/archive
> LBDigest: http://lbdigest.com
> MRTG with SLB: http://vegan.net/MRTG
> Hosted by: http://www.tokkisystems.com
>
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
Esta mensagem foi verificada pelo E-mail Protegido Terra.
Scan engine: VirusScan / Atualizado em 13/11/2002 / Versão: 1.3.13
Proteja o seu e-mail Terra: http://www.emailprotegido.terra.com.br/
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Fri Nov 22 2002 - 15:28:23 EST