Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
Apr 21, 2015

OneConnect, no HTTP profile, still per HTTP request LB?

Hi,

My understanding was that one of the functions of service or protocol profiles is to allow LTM to decode, understand and manipulate protocol data at given layer. In Overview of the OneConnect profile there is statement:

When a OneConnect profile is enabled for a TCP virtual server that does not have an HTTP profile applied, and a client sends multiple requests within a single connection, the BIG-IP system is able to process each request individually. The BIG-IP system sends the requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.

Is OC profile exception from the rule that to understand and handle traffic at given layer appropriate layer profile should be used? From above it looks like having only TCP profile and OC profile allows LTM to understand that TCP stream is carrying HTTP traffic and recognize HTTP requests, and in turn apply LB not per TCP connection but per HTTP request in given TCP connection.

If so what is that mean for VS without persistence set and for example Round Robin LB?

  • Without OC first TCP connection will be LB to first member, second to second and so on
  • With OC first TCP connection (and in turn first HTTP request) will be LB to first server, second HTTP request in the same TCP connection to second server and so on

Piotr

  • Hi Piotr,

     

    As far as I'm aware:

     

    1) Yes 2) Yes, but only if client web-browser has HTTP keep-alives enabled, it can reuse the same TCP connection.

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      Hmm, do you mean pipelining or keep-alive? As far as I understand pipelining is extension to keep-alive allowing to send multiple request not waiting for replays - as it is with not pipelined session. As well I am pretty sure that most of today's HTTP/1.1 connections are persistent so single TCP connection is used for many HTTP transactions - or I am wrong? Piotr
    • Hannes_Rapp_162's avatar
      Hannes_Rapp_162
      Icon for Nacreous rankNacreous
      Keep-alive would also help to ensure the TCP connection is not closed after the HTTP response.
  • Hi Piotr,

     

    As far as I'm aware:

     

    1) Yes 2) Yes, but only if client web-browser has HTTP keep-alives enabled, it can reuse the same TCP connection.

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      Hmm, do you mean pipelining or keep-alive? As far as I understand pipelining is extension to keep-alive allowing to send multiple request not waiting for replays - as it is with not pipelined session. As well I am pretty sure that most of today's HTTP/1.1 connections are persistent so single TCP connection is used for many HTTP transactions - or I am wrong? Piotr
    • Hannes_Rapp's avatar
      Hannes_Rapp
      Icon for Nimbostratus rankNimbostratus
      Keep-alive would also help to ensure the TCP connection is not closed after the HTTP response.
  • With OC first TCP connection (and in turn first HTTP request) will be LB to first server, second HTTP request in the same TCP connection to second server and so on

    i do not think so. i think without http profile, bigip will not know when to detach server-side connection.

     with http profile
    
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
    ltm virtual bar {
        destination 172.28.24.10:80
        ip-protocol tcp
        mask 255.255.255.255
        pool foo
        profiles {
            http { }
            oneconnect { }
            tcp { }
        }
        rules {
            qux
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        vs-index 29
    }
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool foo
    ltm pool foo {
        members {
            200.200.200.101:80 {
                address 200.200.200.101
            }
            200.200.200.111:80 {
                address 200.200.200.111
            }
        }
    }
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
    ltm rule qux {
        when HTTP_REQUEST {
      set host [HTTP::host]
      set uri [HTTP::uri]
    }
    when HTTP_RESPONSE {
      log local0. "client=[IP::client_addr]:[TCP::client_port] \
        host=$host uri=$uri \
        status=[HTTP::status] \
        snat=[IP::local_addr]:[TCP::local_port] \
        server=[IP::server_addr]:[TCP::server_port]"
    }
    }
    
     /var/log/ltm
    
    [root@ve11c:Active:In Sync] config  tail -f /var/log/ltm
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    
     without http profile
    
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
    ltm virtual bar {
        destination 172.28.24.10:80
        ip-protocol tcp
        mask 255.255.255.255
        pool foo
        profiles {
            http { }
            tcp { }
        }
        rules {
            qux
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        vs-index 29
    }
    
     /var/log/ltm
    
    [root@ve11c:Active:In Sync] config  tail -f /var/log/ltm
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    
    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      @nitass, thanks, so what this description from sol means? Is that plain wrong or I just misunderstand what is stated there - what is your interpretation of description from sol? Piotr
    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      BTW, in your test described as without HTTP profile, it looks like it is with http profile but without OC profile - Am I wrong? Piotr
  • With OC first TCP connection (and in turn first HTTP request) will be LB to first server, second HTTP request in the same TCP connection to second server and so on

    i do not think so. i think without http profile, bigip will not know when to detach server-side connection.

     with http profile
    
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
    ltm virtual bar {
        destination 172.28.24.10:80
        ip-protocol tcp
        mask 255.255.255.255
        pool foo
        profiles {
            http { }
            oneconnect { }
            tcp { }
        }
        rules {
            qux
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        vs-index 29
    }
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool foo
    ltm pool foo {
        members {
            200.200.200.101:80 {
                address 200.200.200.101
            }
            200.200.200.111:80 {
                address 200.200.200.111
            }
        }
    }
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
    ltm rule qux {
        when HTTP_REQUEST {
      set host [HTTP::host]
      set uri [HTTP::uri]
    }
    when HTTP_RESPONSE {
      log local0. "client=[IP::client_addr]:[TCP::client_port] \
        host=$host uri=$uri \
        status=[HTTP::status] \
        snat=[IP::local_addr]:[TCP::local_port] \
        server=[IP::server_addr]:[TCP::server_port]"
    }
    }
    
     /var/log/ltm
    
    [root@ve11c:Active:In Sync] config  tail -f /var/log/ltm
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.101:80
    Apr 21 17:29:13 ve11c info tmm1[5649]: Rule /Common/qux : client=172.28.24.8:33073  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33073  server=200.200.200.111:80
    
     without http profile
    
    root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
    ltm virtual bar {
        destination 172.28.24.10:80
        ip-protocol tcp
        mask 255.255.255.255
        pool foo
        profiles {
            http { }
            tcp { }
        }
        rules {
            qux
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        vs-index 29
    }
    
     /var/log/ltm
    
    [root@ve11c:Active:In Sync] config  tail -f /var/log/ltm
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    Apr 21 17:30:02 ve11c info tmm[5649]: Rule /Common/qux : client=172.28.24.8:33086  host=172.28.24.10 uri=/  status=200  snat=200.200.200.14:33086  server=200.200.200.101:80
    
    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      @nitass, thanks, so what this description from sol means? Is that plain wrong or I just misunderstand what is stated there - what is your interpretation of description from sol? Piotr
    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      BTW, in your test described as without HTTP profile, it looks like it is with http profile but without OC profile - Am I wrong? Piotr
  • @nitass, thanks again for time. I am still not sure if I got it right. According to SOL OC with only TCP profile should be able to do per request LB, without any iRules etc. But question is how messages can be recognized (HTTP requests) without HTTP profile.

    There is as well statement in SOL:

    The OneConnect profile may be used with any TCP protocol, but only when applied to virtual servers that process simple request/response protocols where transaction boundaries are explicitly obvious, such as those in which each request and each response is contained within a single packet.

    So it seems like in this situation LTM can consider packet from client as equal to HTTP request and based on that per request LB is performed.

    Still, according to your test it's not true - so info in SOL is not correct.

    Then you state that with OC and TCP profiles and iRule this per request LB can be achieved by using iRule to detach server side connection - Am I right?

    If so what could be an iRule that can do that? There is no HTTP profile so HTTP_RESPONSE or HTTP_REQUEST events can not be used. Is detaching possible using L4 events? Would appreciate a lot some guidance here.

    Piotr

  • What is listed in Current Active Members counter? Members having open connections at the time when show commend was issued?

     

    yes

     

    Total Requests : 0 - why it's 0, it's counter for requests send to pool members but without receiving response yet?

     

    i understand because there is no http profile. bigip does not undestand request/response.

     

    According to SOL OC with only TCP profile should be able to do per request LB, without any iRules etc.

     

    i am not sure about this.

     

    But question is how messages can be recognized (HTTP requests) without HTTP profile.

     

    we can collect http payload and detach server-side connection at the end of payload. the excellent example is unbind ldap written by Nat.

     

    Unbind your LDAP servers with iRules by Colin Walker

     

    https://devcentral.f5.com/articles/unbind-your-ldap-servers-with-irules

     

    Then you state that with OC and TCP profiles and iRule this per request LB can be achieved by using iRule to detach server side connection - Am I right?

     

    yes

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      Thanks for pointing to article, I think I understand the idea more or less - but probably less :-) So in existing TCP connection we need to detect when request is send to server and then use LB::detach to remove relation between client side flow and server side flow. Then when new request will come it can be LB to another server. Well, that is plenty of messing around not mentioned in SOL, but at least I now understand what is real meaning of info form SOL :-) Piotr
  • What is listed in Current Active Members counter? Members having open connections at the time when show commend was issued?

     

    yes

     

    Total Requests : 0 - why it's 0, it's counter for requests send to pool members but without receiving response yet?

     

    i understand because there is no http profile. bigip does not undestand request/response.

     

    According to SOL OC with only TCP profile should be able to do per request LB, without any iRules etc.

     

    i am not sure about this.

     

    But question is how messages can be recognized (HTTP requests) without HTTP profile.

     

    we can collect http payload and detach server-side connection at the end of payload. the excellent example is unbind ldap written by Nat.

     

    Unbind your LDAP servers with iRules by Colin Walker

     

    https://devcentral.f5.com/articles/unbind-your-ldap-servers-with-irules

     

    Then you state that with OC and TCP profiles and iRule this per request LB can be achieved by using iRule to detach server side connection - Am I right?

     

    yes

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus
      Thanks for pointing to article, I think I understand the idea more or less - but probably less :-) So in existing TCP connection we need to detect when request is send to server and then use LB::detach to remove relation between client side flow and server side flow. Then when new request will come it can be LB to another server. Well, that is plenty of messing around not mentioned in SOL, but at least I now understand what is real meaning of info form SOL :-) Piotr
  • @nitass, one last question. Just would like to be sure if I understand why OC is crucial for LDAP example.

     

    My understanding of TCP connection setup is:

     

    • Without OC
    • client initiates connection
    • 3WH is performed with LTM
    • client sends first data packet
    • LTM performs 3WH with server
    • then data is flowing
    • client initiates connection tear down with LTM, client side connection closed
    • LTM initiates tear down with server, connection closed (or maybe LTM passes tear down to server?)
    • With OC
    • as above up to client initiated tear down
    • Client connection is closed but server side connection is maintained for reuse and marked idle
    • Server side connection is kept open until Idle Timeout on LTM or server expires (or one of the thresholds set in OC config is met)

    So the point here is that OC is not passing client side tear down to server side and new packets can be send via this SS connection. I assume that for other protocols than HTTP (where one of the requirement is server support for keep-alive) preservation of SS connection is basically based on Idle Timeout setting for TCP? Or some special support on the side of application (like LDAP server) is required?

     

    Piotr

     

  • Thanks a lot for your patience, great tutorial. I think now it's really clear to me!

     

    Piotr

     

  • Thanks a lt for tour patience, great tutorial. I think now it's really clear to me!

     

    Piotr