RES: [load balancing] Alteon AD3 - Redirect to IP address 0.0.0.0

From: Claudio Rosa (crmrosaIZZATterra.com.br)
Date: Fri Nov 22 2002 - 15:22:55 EST

  • Next message: Alex Samonte: "Re: [load balancing] Loadbalancing Unix Web Servers"

    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