Forum Discussion

fabianlumy's avatar
fabianlumy
Icon for Nimbostratus rankNimbostratus
Sep 03, 2012

F5 LTM (VE) - KeepAlive even if real server close connection

Hello community!

 

 

I'm qualifying an LTM (VE) 11.2.0 for web loadbalancing, and trying to find a solution for this case:

 

Real web server force connection to close for each call to a very common ressource (because it's does not send Content-Length header, neither chunked, I cannot change this).

 

Is there a way to keep connection alive on the client side, and ask to the device to handle this case ? I also try to force the rechunk, but the connection is also closed. I can passthrough this issue but using http compression for example, but it is not what I'm looking for...

 

I will be happy if someone can help to find a solution for this case.

 

Thanks

 

16 Replies

  • Erlo,

     

     

     

    FYI:

     

     

    I posted at 05 - right before you just did - when you posted at 06, so you might have missed it if you don't have notifications active.
  • @Thomas Schockaert: thanks for your answer. Actually, since the F5 doesn't fill a "Content-Length" header, there is no other possibility than closing the connection, since the client consider the content of the response until the end of connection. In the traces I've included, the "tcp end" to the final client first come from F5.

     

    I think that playing with iRule won't give my a workarround for this case ?
  • i agree with you that the problem is from missing content-length header. can you try something like this?

    what i want to do is to use vip targeted vip. the front one uses oneconnect profile and call the back one. the back vip uses stream profile with dummy source/target and load balance traffic to pool. the stream profile will force bigip to add content-length header in response.

    e.g.

    [root@ve10:Active] config  b virtual front list
    virtual front {
       snat automap
       destination 172.28.19.79:80
       ip protocol 6
       rules frontrule
       profiles {
          http {}
          oneconnect {}
          tcp {}
       }
    }
    [root@ve10:Active] config  b rule frontrule list
    rule frontrule {
       when CLIENT_ACCEPTED {
            virtual back
    }
    }
    [root@ve10:Active] config  b virtual back list
    virtual back {
       snat automap
       pool foo
       destination 1.1.1.1:80
       ip protocol 6
       profiles {
          http {}
          mystream {}
          tcp {}
       }
    }
    [root@ve10:Active] config  b pool foo list
    pool foo {
       members 200.200.200.101:80 {}
    }
    [root@ve10:Active] config  b profile mystream list
    profile stream mystream {
       defaults from stream
       source "aaa"
       target "bbb"
    }
    
  • this is tcpdump.

    [root@ve10:Active] config  ssldump -Aed -nni 0.0 port 80
    New TCP connection 1: 172.28.19.251(46046) <-> 172.28.19.79(80)
    1346770377.3176 (0.0011)  C>S
    ---------------------------------------------------------------
    GET / HTTP/1.1
    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
    Host: 172.28.19.79
    Accept: */*
    Connection: keep-alive
    
    ---------------------------------------------------------------
    
    New TCP connection 2: 172.28.19.251(46046) <-> 1.1.1.1(80)
    1346770377.3177 (0.0000)  C>S
    ---------------------------------------------------------------
    GET / HTTP/1.1
    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
    Host: 172.28.19.79
    Accept: */*
    Connection: keep-alive
    
    ---------------------------------------------------------------
    
    New TCP connection 3: 200.200.200.10(46046) <-> 200.200.200.101(80)
    1346770377.3185 (0.0007)  C>S
    ---------------------------------------------------------------
    GET / HTTP/1.1
    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
    Host: 172.28.19.79
    Accept: */*
    Connection: keep-alive
    
    ---------------------------------------------------------------
    
    1346770377.3197 (0.0011)  S>C
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Connection: close
    Date: Tue, 04 Sep 2012 06:59:04 GMT
    Server: Microsoft-IIS/6.0
    Set-Cookie: CFID=26760493;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Set-Cookie: CFTOKEN=85662049;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Content-Type: text/html; charset=UTF-8
    
    ---------------------------------------------------------------
    
    3    1346770377.3197 (0.0000)  S>C  TCP FIN
    1346770377.3197 (0.0020)  S>C
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Connection: close
    Date: Tue, 04 Sep 2012 06:59:04 GMT
    Server: Microsoft-IIS/6.0
    Set-Cookie: CFID=26760493;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Set-Cookie: CFTOKEN=85662049;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Content-Type: text/html; charset=UTF-8
    Transfer-Encoding: chunked
    
    0
    
    ---------------------------------------------------------------
    
    2    1346770377.3197 (0.0000)  S>C  TCP FIN
    1346770377.3198 (0.0021)  S>C
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    X-Cnection: close
    Date: Tue, 04 Sep 2012 06:59:04 GMT
    Server: Microsoft-IIS/6.0
    Set-Cookie: CFID=26760493;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Set-Cookie: CFTOKEN=85662049;expires=Thu, 04-Oct-2012 06:59:04 GMT;path=/
    Content-Type: text/html; charset=UTF-8
    Transfer-Encoding: chunked
    
    0
    
    ---------------------------------------------------------------
    
    2    1346770377.3198 (0.0000)  C>S  TCP FIN
    3    1346770377.3198 (0.0000)  C>S  TCP FIN
    1    1346770377.3215 (0.0017)  C>S  TCP FIN
    1    1346770377.3215 (0.0000)  S>C  TCP FIN
    
  • @nitass:

     

     

    I've tested your example with the virtual back, and big thanks, it works as expected :o)

     

     

    Thank you !
  • Hi,

     

    I have a very similar (if not identical) situation and would like to try this solution too.

     

    As Erlo stated, he managed to get this to work.

     

    Erlo, will you be so kind to put your HTTP::Response iRule which replaced the "Connection: Close" into "Connection: Keep-Alive"?

     

    Also, will this iRule be applied on the Front VIP or on the Back end VIP?