F5 UAG SharePoint 2010 (NO DIRECT ACCESS)

Posted By Ryan Korock on 03/22/2013 11:41 AM

 

Hey Joe... The BIG-IP uses several pieces of data to track (and separate) connections. The most basic is the information found in the TCP & IP headers (source port/source IP - destination port/destination IP). In your case, since everything is coming from the same proxy and destined for the same VIP:Port, 3 out of those 4 will be identical. However your proxy will (most likely) be sending the traffic to the BIG-IP using different TCP source ports for each user based connection. This is enough information for the BIG-IP to understand that these are separate connections and load balance them independantly of eachother.

 

 

This also means that you will need more IPs to act as the source IP on your proxy if you plan on having more than 65k connections eminating from it to the same VIP:Port. That's because you'll run out of source port values to use at this level.

 

 

Since Source IP persistence only looks at the source IP (and not port values) to associate connections, it will assume all these connections from your proxy are part of the same session and send them all to the same server. Cookie persistence operates differently, and independantly of IP adresses. After the BIG-IP load balances the traffic to a specific server, it will append its own cookie (that contains information about what server the connection was sent to) to the http packet when it sends the response traffic back to the client. When the client makes any more requests to the VIP (whether the client is generating a new TCP connection, or just reusing the old one), the client will resend the cookie with the request. The BIG-IP then sees the cookie, and can determine from the cookie value which server that the user was originally connected to and send the new request to it. Any new users attempting to connect to the VIP will not have a BIG-IP cookie in the HTTP packet, and so BIG-IP will assume its a new user and load balance it appropriately.

 

 

I hope this helps Joe.... I've intentionally generalized a bit, but I hope you get the point.....

 

 

Thanks for the explanation, Ryan. I see how it works now :-)

 

Will go for cookie persistence since we're loadbalancing http traffic.

 

Will also stick to decryption/encryption of the SSL traffic.