Forum Discussion

hongdi_li_16186's avatar
hongdi_li_16186
Icon for Nimbostratus rankNimbostratus
Aug 04, 2014

IP stickiness on F5 with round-robin

Hi,

 

I am experiencing the IP stickiness on my F5 Virtual Edition, while it is supposed to do round-robin. I have a web page reflecting the server's IP. I always gets the response from the same server while making multiple consecutive requests via the browser. However, it does round-robin for the requests that are coming from across different clients, but each client always gets response from the same server.

 

I am using a BIG-IP 11.5.1 Build 0.4.110 Virtual Edition on Amazon EC2. I set it up as the one-ip topology, which has only one network interface (in addition to the management interface) serving both the incoming/outgoing traffic. This is because we have our clients and servers in the same subnet.

 

The Virtual Server is using the default http profile, SNAT: Auto Map, One Connect Profile: None, Default Persistence Profile: None, Load Balance Method: Round-robin, Priority Group Activation: Disabled,

 

I wonder if I need to overwrite some default configuration to turn off the IP stickiness/persistence. Any suggstions will be appreciated.

 

Thanks, Hongdi

 

application delivery
deployment
LTM
management
virtualization
  • Kevin_Davies_40's avatar
    Kevin_Davies_40
    Aug 04, 2014

    It requires and understanding of HTTP 1.1 behaviour and how this interacts with the BIGIP. Version 1.1 keeps alive the connection to the BIGIP for however long the browser deems necessary. There is a timeout of 5 mins but this is rarely reached. Subsequent requests from the browser will reuse this connection. So when you request a HTML page the browser will open the 1st connection to get the html page. Then it will parse the html page and usually open a 2nd connection and then request the elements for that page such as images, css and the like down both connections.

     

    Now the BIGIP load balances each TCP connection, not each request. This means if the connection does not close then subsequent requests down that same connection will always go back to the same server. So subsequent requests sent down the 1st connection will always go back to the same server. Requests sent down the second connection will be sent to wherever that connection was load balanced by the BIGIP. If you want to change this behaviour then turn on the oneconnect profile.

     

  • Kevin_Davies_40's avatar
    Kevin_Davies_40
    Icon for Nacreous rankNacreous
    Aug 04, 2014

    It requires and understanding of HTTP 1.1 behaviour and how this interacts with the BIGIP. Version 1.1 keeps alive the connection to the BIGIP for however long the browser deems necessary. There is a timeout of 5 mins but this is rarely reached. Subsequent requests from the browser will reuse this connection. So when you request a HTML page the browser will open the 1st connection to get the html page. Then it will parse the html page and usually open a 2nd connection and then request the elements for that page such as images, css and the like down both connections.

     

    Now the BIGIP load balances each TCP connection, not each request. This means if the connection does not close then subsequent requests down that same connection will always go back to the same server. So subsequent requests sent down the 1st connection will always go back to the same server. Requests sent down the second connection will be sent to wherever that connection was load balanced by the BIGIP. If you want to change this behaviour then turn on the oneconnect profile.

     

    • hongdi_li_16186's avatar
      hongdi_li_16186
      Icon for Nimbostratus rankNimbostratus
      Aug 07, 2014
      Thanks Kevin. This is exactly the cause. Although, the client-side "keep-alive" and server-side TCP connection reuse are slightly different. The client-side is HTTP1.1 keep-alive while the server side is a TCP connection pool managed by F5. Multiple requests from different clients can share this F5-server TCP connection. F5 is able to round-robin each TCP connection. For example, I open up two browsers (FF and Chrome) and they will get result from different servers. So "IP stickiness" is not the case. For the consequent requests from the two browsers, each browser session sticks to the same server. What I want is disabling the server-side TCP connection reuse. I am able to achieve that by using a OneConnect profile that has the max reuse to zero. Perviously, I thought setting the OneConnect profile to none will disable the TCP connection reuse on the Server side. That is not the case.