Forum Discussion

Frank_69873's avatar
Frank_69873
Icon for Nimbostratus rankNimbostratus
Jun 17, 2014

F5 Load Balancer using Cookies to route traffic.

We have many F5 Load balancers. I am investigating using Cookies to ensure that my traffic gets routed to servers behind a load balancer. The cookies that we are planning to use are for devices that will be served by the server behind the LB. The cookies will be inserted by the requesting devices. These servers will be doing protocol Conversion for the device downstream.

 

An HTTP request will hit the LB with a cookie that points to a device the we want served. The LB looks into its cache and sees that there is no cached relationship for this cookie so it will set one up. From then on any request with this cookie will get routed to the previously picked protocol converter. Yes/No?

 

What happens if 2 new requests come in with the same cookie that is not yet in the cache? I hope the LB will only assign one server to them.

 

The LB will have a health check going on with the server behind it. What happens if the health check fails? Does the cache become invalidated? The new requests for that cookie get routed to a new server?

 

Is there a way to send a command to the LB to have it clear the entire cache so that all new requests get routed to new servers?

 

7 Replies

  • What cookie method are you using? Hash?

     

    Assuming so, The cookie gets mapped when the server has a set cookie in the response, the first response from a will create the mapping, so when the second occurs it will already be mapped. This is a bit different than you described, the mapping does not occur when the client request comes in with a cookie, but when the server responds with the cookie.

     

    See http://support.f5.com/kb/en-us/solutions/public/6000/500/sol6586.html for more info.

     

    When a member is down, the F5 will send requests to another member just like no cookie was present(dependent on your action on service down setting). That server will set the cookie to its value and persistence is now established with that server.

     

    Not sure if you can clear the cache, I don't think you would want to anyway.

     

    Also be aware that if a client is idle for the entire time a server goes down and then comes back, when they finally make their request with the old cookie, since that server is now back they will land on it again. Probably not a big deal, but sometimes I have people down a server for 1 minute thinking they will get everyone off of it and then re-enable it and are surprised to see how many people are still stuck to it. If they don't make a request while it is down, they won't get a new cookie value and their old cookie value will now be valid again.

     

    • Frank_69873's avatar
      Frank_69873
      Icon for Nimbostratus rankNimbostratus
      I have clients that want to make a request for many devices that must pass through these protocol servers. Cany one of 12 server can make the request for these devices. I will make the request with a cookie or other header flag that says here is the ultimate destination of the message. The destination is not the device in the LB pool but a server behind that. Once I make the first request I want the LB to remember the cookie of header entry to always route any future messages with the same header to the same device in the pool whose destination is the device behind it. How can I do that?
  • Looks like you want manual persistence based on what values you supply. Easy enough.

    when HTTP_REQUEST {
      persist uie [HTTP::header select-server]
    }
    

    That will choose a server based on load balancing then when it sees the same data in the select-server header next time it will send the request back to the same server.

    • Frank_69873's avatar
      Frank_69873
      Icon for Nimbostratus rankNimbostratus
      Thanks for answering all of this... I want to force persistence up front. I will add the cookie to all the messages that are coming from my requesting servers. Then as you have said the LB first time load balances. After that it re-selects the same server. What happens if I hit the LB with 2 requests with the same cookie in almost the same instant? Also assume the pooled server that is now being routed to because of the cookie, simply dies? LB gets a request, looks up that server because of cookie and tries to route to it but it is dead? What will the LB do? What if there are numerous requests at the same moment? Can I speak to a warm body about this? Thanks very much.
    • Frank_69873's avatar
      Frank_69873
      Icon for Nimbostratus rankNimbostratus
      I have been reading about Universal persistence using cookies...It always assumes the pooled server will supply the cookie. Here is what we need... 1) An initial HTTP request arrives with a cookie (IP address of a downstream destination device being served by the pool member) 2 ) The BIG-IP LTM UIE parses the request and sees the cookie. If now looks in the persistence table of the association. There is none so it sets one up using Load balancing. 3) The response comes back. There is no cookie in the response but we do no care as the clients manually set and send the cookie. The next HTTP request arrives from a different client trying to get the the same downstream destination device. 1) The BIG-IP LTM UIE parses the client request for the Cookie header, finds the destination server IP cookie, and matches the cookie to the entry in the persistence table. 2) The BIG-IP LTM persists the client request to the same pool member as was set up in the last request. Is this possible?
    • Kevin_Davies_40's avatar
      Kevin_Davies_40
      Icon for Nacreous rankNacreous
      That is exactly how persist uie works. Only need to change the HTTP::header to HTTP::cookie
  • The F5 is designed to handle many thousands of connections. The iRule runs in each one.