F5 UAG SharePoint 2010 (NO DIRECT ACCESS)

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.....

Lazar, I believe cookie insert persistence, being based off a simple hash, has a couple advantages.

 

1. Gets around the clumping that happens with the 'branch office' or proxy scenario that Joe might encounter.

 

2. No persistence table needs to be maintained on the BIG-IP, as in the case of source IP persistence.

 

3. No persistence table needs to mirrored to the failover BIG-IP. Since it is a hash, the failover BIG-IP can read and understand it immediately.

 

 

If you do go with source IP persistence (which is often the only option when you are persisting non-http traffic), the BIG-IP builds and maintains a persistence table that includes the source IP / VIP:Port / and selected pool member. You can also configure the BIG-IP to mirror this table to the peer BIG-IP in the case of a BIG-IP failover. In my experience, sometimes I recommend mirroring the persistence table, sometimes I don't. If the application you are load balancing uses a very large number of short lived TCP connections, constantly mirroring this table can start to eat resources on the BIG-IP (fortunately HTTP keep-alives has mitigated this behaviour for http to a large extent), and some protocols/apps are actually more resilient to failure than others. For instance, a lot of times, if an HTTP session is disrupted (as may be the case with a BIG-IP failover) the client will often just resend the request after a short timeout, which will hopefully result in a completed transaction.

Ryan,

 

 

Thanks. Will evaluate as the design is and moving forward. The challenge is being able to validate why we should do SSL re-encryption vs SSL passthrough to UAG. We are looking at load balancing two or more SharePoint 2013 VIPS and ADFS Vips

The biggest differences will be content inspection (or lack of), and the ability to persist user connections with anything other than client source addresses. With SSL passthrough you all lose iRules, protocol optimizations, and acceleration techniques native to LTM.

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.

 

Issues over here :-(

 

using this config:

 

UAG VIP (default "cookie" persistence profile) => 2 UAG Servers => VIP SPS (Default "Cookie" persistence profile) => 2 SPS servers.

 

 

SharePoint is using a Claims based authentication (AD + FBA) and we are using a custom UAg dev to log external users using the AD authentication provider. The Custom dev uses the UAG 401 authentication method and sends the credentials on behaf of the user to the sharepoint site.

 

The issue is: we are having a random error:

 

 

The request from user domain\\user at source IP address (internal BigIP IP address) to trunk xxx;

 

Secure=1 failed because the request was unable to reply to an HTTP 401 request from application XXX of type SharePoint14AAM.

 

 

 

If we take one of the UAG servers offline the error is less frequent.

 

I switched to "source_addr" persistence profile and we still see this error.

 

 

i will create a custom "cookie' profile as Ryan stated in one of his replies.

 

Any suggestions are welcome.

 

 

Solved the problem by enabling SNAT on both VIPS. UAG and SPS servers live in the same DMZ and are not forced to go through the F5 when communicating whith each other. We did have a similar issue which was solved by enabling SNAT on the UAG VIP but this was because we were trying to connect to the UAG portal (VIP) from a server which was in one of the the UAG internal routes.

 

In the second case the error was not random. We simply were unable to connect so I still don't understand the randomness of this error !!! Anyway it is solved now.

another issue here :-)

 

I have two web applications on the sharepoint vip.

 

We manage sso from one web app to the other via a custom dev.

 

I connect to http://webapp01 => I go to server UAG01 => OK

 

On the webbapp01 page I have a link to go to http://webapp02.

 

I click to https://webapp02 The F5 box sends me to UAG02 !!!!

 

How to maintain the connection on the same UAG server in this case. I'm sure there is an iRule for this :-)

 

thanks.

You said this is a single VIP, yes? http://webapp01 and http://webapp02 resolve to the same VIP, and UAG01 and UAG02 are nodes in a single pool?

 

 

Are you still using cookie persistence?

setup is like this:

 

 

Client => UAG VIP => UAG Pool UAG1/UAG2 => SharePoint VIP => Sharepoint Pool SPS1/SPS2

 

 

Two applications are published on on UAG (accessed on UAG VIP with UAG pool).

 

I go to http://webapp1 I see a bigip cookie going to server UAG1.

 

When I cliick on http://webapp2 UAG logs me off and in the fiddler trace i see a bigip cookie going to UAG2 (second pool memeber).

 

 

What I want is to stay on same pool member when accessing different urls on same vip.

 

 

I'm using SNAT and the default cookie persistence profile.