Forum Discussion

tmull60_92900's avatar
tmull60_92900
Icon for Nimbostratus rankNimbostratus
May 20, 2011

F5 LTM / Riverbed / Exchange 2010 Disconnect and Reconnect

Is anyone having an issue when using F5 LTM to load balance Exchange 2010 connections over a WAN when Riverbed is used to accelerate network traffic?

 

 

All of our remote users get disconnected and then reconnected when using that setup. If we take F5 out of the loop over the WAN, their connection is fine. However, if we take Riverbed out of the loop and go directly to the F5 their connection to Exchange 2010 is also fine.

 

 

F5 support is baffled and cannot find an anwser. Same with Riverbed.

16 Replies

  • We have the exact same issue. I'm unclear as to what the final config/fix was on both the F5 and Riverbed. Which of the following changes were made to resolve?

     

     

    F5

     

    - change the Exch2010 rpc VIP to FastL4 with a idle timeout of 7200 seconds

     

     

     

    Riverbed

     

    - change riverbed to allow Exch2010 traffic to pass through without modification

     

    - update riverbed code to version ?

     

     

     

    Also - were you able to fix the Directory disconnect issues or did this just take care of the Mail disconnects?

     

  • As I said, the work around that we implemented to fix the issue was to put a rule on the Riverbed to ignore traffic to/from the F5 Outlook RPC VIP. We have since worked with Riverbed on a proper solution:

     

     

    All Riverbeds have to be updated to version 6.5.1 or later.

     

    MAPI and encryption have to be enabled on the Riverbed.

     

    There are some other tuning options that I don't recall but will ask our network guys to list out so I can give a report.

     

     

    Here are the other tuning options that need to be done on the Riverbed:

    https://support.riverbed.com/kb/sol...yName=MAPI

     

     

    As for the directory disconnects, no I did not solve that yet. It appears to be isolated to Windows 7 clients, or at least Windows 7 clients appear to be more affected than Windows XP clients. Since we don't officially support Windows 7 in the office yet I haven't made it a priority to fix. I am certainly interested though if anyone else has solved that particular issue.

     

     

  • Yes the upgrade to RiOS fixed the Riverbed problem.

     

     

    The Windows 7 disconnect issue turned out to be the RPC connections timing out. I had to go into the profile for TCP for the RPC connection and put the timeout value up to 7200 seconds or so.

     

  • Hi JTrimble,

     

     

     

    It might be more than just TCP timeouts:

     

    You could have SNAT timeouts on another device (switching addresses transparently, but alas disconnecting your user's sessions).

     

    E.g. a device that has a few snat addresses to throw traffic at the Riverbed / F5's. Amongst other things, persistence records don't fare well by this.

     

     

     

    Kind regards,

     

     

    Thomas
  • As far as I know, there are only Avaya switches between the users and the F5 devices, so I don't see where additional SNAT's would be in the picture. Increasing the timeout for RPCs on the F5 resolved our problems though. I think it was defaulted for something like 5 minutes and I increased it to 2 hours.