Forum Discussion

kunalPatel_3157's avatar
Mar 30, 2017

SNAT and One-Connect

Big IP LTM performs SNAT before one connect. I want to have both SNAT + Oneconnect

 

Let's assume that because of SNAT my servers sees all the traffic coming from one IP address(10.1.1.1), Now mask on one connect is 255.255.255.255, Load balancing is on Round Robin and Numbers of pool members is 2

 

Now help me to explain this

 

Connection 1: (Very first connection) Host comes from IP 1.2.3.4 to website , IP will be SNAT'd to 10.1.1.1 and server-1 will serve his request. Now because of one connect F5 to server connection stays up for a while.

 

Connection 2:(Second request )

 

Host comes from IP 11.22.33.44 (totally different IP )to website , IP will be SNAT'd to 10.1.1.1 ,

 

What will one connect profile do? SNAT'd address will be same so a perfect match and which server will serve his request ? 1 or 2.

 

6 Replies

  • Assuming the serverside connection selected in "connection 1" is still up, the pool member associated with this serverside connection will be selected for "connection 23"

     

  • Hello,

    For reference here is the OneConnect Overview article.

    The article makes it clear, the F5 does not select a pool member based on available idle connections, it selects a pool member based on the load balancing algorithm.

    OneConnect selection process
    1. Request comes in, pool selection takes place etc.
    2. Load balancing decision based on persistence or algorithm.
    3. Apply mask to translated source address.
    4. Re-use idle connection and mark in-use, or open new connection and mark in-use.
    5. Inspect server response:

      a. 200, 206, 3xx: eligible for re-use, mark connection idle.

      b. anything else: not eligible for re-use, close the connection.

    It is possible to override the default OneConnect re-use behavior via iRule and/or db setting

    sys db tmm.http.oc.droponerror
    .

    OneConnect Mask

    The mask on the OneConnect profile only applies to the server-side connection. If you SNAT all connections to a single address, the mask on the OneConnect profile for all intents and purposes is irrelevant.

    Your scenario

    In your round-robin scenario, the requests that come into the F5 will be balanced round-robin on a per-request basis.

    As long as you don't have persistence:
    • request 1 --> server 1
    • request 2 --> server 2

    If you want to test the behavior, you could try these steps:

    1. Configure a 255.255.255.255 mask in your OneConnect profile.
    2. Write a simple iRule to SNAT to a different IP if the request is from your test browser/client.
    3. Run tcpdump to capture the traffic server-side from the specific SNAT address from the iRule.

    If you capture with noise and view in Wireshark with the F5 plugin, you can see which client-side connections are associated with the server-side connections.

    Reducing connections

    It is true, OneConnect can be used to reduce server-side TCP connections. However, it is important to keep the end goal in mind: performance.

    • It's better to have all servers handling requests from a single client-side connection than 1.
    • Connection setup is time-consuming, it's better to keep a connection open as long as possible.

    The load balancing algorithm on the F5 is one of the tools F5 provides to put you in control of load distribution. I don't think of OneConnect as a way to "reduce server-side connections handled by the F5", the F5 is more than capable of handling lots of server-side connections.

    OneConnect is another tool that works in concert with your load balancing algorithm. It allows the algorithm you choose to distribute HTTP load on a per-request basis instead of a per-connection basis.

    • kunalPatel_3157's avatar
      kunalPatel_3157
      Icon for Cirrus rankCirrus

      Thanks for the answer , But don't you think Oneconnect overrides Load balancing,

       

      I think this will be the case with SNAT + oneconnect request 1 --> server 1 request 2 --> server 1

       

      Because SNAT is performed before Oneconnect oneconnect will see request is coming from the same source and it will send it to same server unless and until oneconnect is maxed out with number of connections. I will ask this to F5 Support also.

       

    • Jeremy_Church_3's avatar
      Jeremy_Church_3
      Icon for Cirrus rankCirrus

      Hello Kuna,

       

      No, OneConnect does not override Load Balancing.

       

      This is a excerpt from K7208: Overview of the OneConnect profile

       

      Content Switching

      When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually. The BIG-IP system sends the HTTP 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.

       

      The statement to take note of is:

       

      The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method.

       

      From a packet-processing point-of-view, idle connections are not evaluated until after the server is selected. Load balancing decision occurs client-side, SNAT and OneConnect re-use occur server-side.

       

      Yes, SNAT occurs before OneConnect, but load balancing occurs before SNAT.

       

      From a "why does OneConnect exist?" point-of-view, allowing OneConnect to override the load balancing algorithm undermines the intended purpose of both the OneConnect profile and the load balancing algorithm on the pool.

       

    • kunalPatel_3157's avatar
      kunalPatel_3157
      Icon for Cirrus rankCirrus

      Got it thanks for the detailed explanation.

       

      This is from k7208 OneConnect and SNATs

       

      When a client makes a new connection to a BIG-IP virtual server configured with a OneConnect profile and Secure Network Address Translation (SNAT), the BIG-IP system parses the HTTP request, selects a server using the load-balancing method defined in the pool, translates the source IP address in the request to the SNAT IP address, and creates a connection to the server. When the client's initial HTTP request is complete, the BIG-IP system temporarily holds the connection open and makes the idle TCP connection to the pool member available for reuse. When a new connection is initiated to the virtual server, the BIG-IP system performs SNAT address translation on the source IP address, and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.

       

  • Hi,

     

    I think there is some mix up with reusing idle serverside connections and distributing clientside connections.

     

    From different posts above it looks like some are stating OneConnect overrides LB others that it is not doing that.

     

    I wonder then what is the "ultimate truth" here :-)

     

    Assume VS with HTTP profile, Round Robin and OneConnect, two members - LB is done on per HTTP request basis.

     

    My understanding of result is like that:

     

    Clientside connection 1, request 1 - LB done - member1 selected, SNAT applied, no serverside connection (so probably no point in checking mask), NEW serverside TCP connection created, request send

     

    Clientside connection 1, request 2 - LB done - member2 selected, SNAT applied, no serverside connection (so probably no point in checking mask), NEW serverside TCP connection created, request send

     

    Clientside connection 1, request 3 - LB done - member1 selected, SNAT applied, idle serverside connection exists, mask checked - connection can be reused, NO new serverside TCP connection created, request send

     

    and so on so on.

     

    In short, LB is still sending requests in RR fashion - new request, new member. Only difference is that no new serverside connections are created if eligible idle connection exists.

     

    So considering TCP connections distribution on serverside will look as uneven but distribution of HTTP requests will be even based on RR.

     

    In simplified situation when we assume one TCP packet = one HTTP request in the Pool stats we will have situation like that:

     

    Even number of Requests for each member Uneven number of Total connections to members

     

    Am I right or wrong here?

     

    In general OC seems to be tightly connected to HTTP, but I am pretty sure that there were statements in docs that it can be used for other protocols that HTTP with notice that it will work correctly for simple messaging L7 protocols where request and reply both fits in one TCP packets.

     

    Wonder if it is really the case and what are examples of other protocols that can be used with OC?

     

    It's as well possible to create VS with only TCP profile and without any L7 profile. How OC is implemented in such case?

     

    Will BIG-IP just try to keep TCP connection open using TCP Keep-Alive? Basically on L4 level we need to somehow convince other side (server) to not immediately close connection, but then how to achieve that?

     

    Piotr