F5 LTM / Riverbed / Exchange 2010 Disconnect and Reconnect

Did you try to make RPC virtual a FastL4 type?

I have this exact same setup and problem. I've temporarily modified HOSTS file on one client to verify that the F5 is the issue. I have not tried the FastL4 type for RPC since I have no idea what that means... Can anyone elaborate?

 

@JTrimble - do you also use Riverbed in your environment?

 

 

F5 has two core modes of operation - full proxy(also known as Standard), which operates on sessions, and Fastl4, which is a traditional packet-based load-balancing mechanism that doesn't terminate actual TCP connections on F5 but rather performs delayed binding before making load-balancing decision. A full detailed description of each virtual server type with illustrations and their differences can be found in this F5 Solution article:

 

 

https://support.f5.com/kb/en-us/solutions/public/8000/000/sol8082.html?sr=15727922l4

 

Yes, we have Riverbed deployed at all of our remote sites to keep the bandwidth used down as much as possible. However it appears to not like the F5's as we tried a test yesterday which set the Riverbed to pass through traffic to the F5 without touching it and so far Outlook clients are performing much better. Prior to the change Outlook would disconnect every 5-15 minutes, after the change there was only 2 disconnects in 12 hours.

 

 

I'm using the standard WAN/LAN TCP profiles that the F5 sets up when you use the wizard to set up Exchange 2010 for load balancing.

 

 

 

Sounds like I was right - except you should re-enable Riverbed optimizations and change RPC VIP on the LTM to be Performance(L4) type instead of standard - and you should be all set. That's the official F5 recommendation for you. :)

Thanks, I've made this change in our lab and it appears to work fine but I don't have Riverbed in the lab. I'll have to go through our change process to update this in our production environment and test it.

 

 

I'll post back when I have the results.

 

The change on the F5 appears to have fixed things for one site, but not the other. Both have identical riverbeds. We discovered though that the Riverbeds are not configured to optimize Exchange 2007 traffic so we are enabling that tonight to check if it works.

 

 

One other note, when we are looking at the Outlook connection status dialog we see disconnects for the Directory. This only started once F5 was put into production. The problem this has is that if someone opens the Address book, or anything that would look something up, occasionally it will error out saying it is not connected to Exchange. If you try again immediately it works.

 

 

We'll see if the changes to the Riverbed tonight help with that.

 

You may have to increase the "idle timeout" value in your tcp profiles. It's a funny situation because the environment works without the riverbed (just the f5) and without the f5 (just the riverbed) so a combination of the two seems to cause issues.

We had a similiar setup, and from the reading on the web, we are thinking that port jumping caused by F5 (switching to different Exchange severs) pushes riverbed to tear down the existing connection and open up another new ones. Setting up static RPC ports could resolve this issue. any comments?

No changes that we have made have made a difference. THe perceived fix to one site didn't turn out as expected. After researching it Riverbed actually has some fixes to F5 connectivity in recent firmware updates (6.1.5) however we are on an older version which requires some extensive updates to our Riverbed infrastructure. The other issue found was that Riverbed wasn't handling the encrypted RPC traffic properly. Exchange 2003 didn't have encryption on by default but 2010 does so Riverbed does something with the packets to cause a reset of the TCP connection. We have yet to schedule enabling encryption so don't know if that will fix it or the firmware update.

 

 

For now to solve our issue we've put a rule on the Riverbed to ignore traffic to/from the F5 VIP for Outlook.