Jump to content
Welcome to our new Citrix community!

Persistence issues with Exchange 2010 - Load on backend servers


Murilo Rocha

Recommended Posts

Hi All,

I have the netscaler being used to load balance CAS Exchange 2010. The  problem I am facing is that now with the corona virus users are working from home and with the current network setup traffic is hitting the netscaler with a single ip address.

 

This is the topology

Internet -> Firewall-> DMZ Netscaler (Content switching - sends traffic to internal netscaler) -> Firewall -> Internal Netscaler (round robin and srcip persistence) -> Exchange

 

The problem is that when traffic hits the internal netscaler it uses the SNIP of the external netscaler  so traffic is not being load balanced correctly which is creating load on the backend. I am still doing some investigation and also have a ticket logged with Citrix but apparently Exchange 2010 must have persistence configured. 

 

Using source ip mode is not an option cause return traffic will be dropped on the firewall.

 

Did some research about rule persistence, nat but it seems that what I can achieve with that is limited and won't solve my problem.

 

At this stage I think I only have two options:

 

1)Disable persistence on the internal which will first need confirmation from MS that persistence on 2010 is not required or a workaround on the server end can be put in place

2)Move ALL the exchange related configuration from the external netscaler to the internal

 

Has anyone faced an issue like this before? Any ideas?

 

Thanks

Link to comment
Share on other sites

Have you tried using Cookie persistence?   I assume you are terminating the SSL connection on the dmz NetScaler keeping it end to end from there.  I'm thinking that would keep the cookie value all the way to the backend Exchange.   Personally I wouldn't move all to the Internal, rather allow your DMZ NS SNIP to connect from the dmz to your Exchange servers.  It opens a few ports but keep the rule specific.  That way the public connections still stay in your dmz.

Link to comment
Share on other sites

The netscaler setup for exchange was done a long time ago and it seems out of date but on the external netscaler it is all SSL.

The service configured for it points to the internal netscaler IP on port 443

add service internal.netscaler.443 wlgcasarray 

 

But on the internal netscaler is all ports

lbvserver_kdc_exch_rpcUPUP10.243.140.20*

 

So it seems that that VIP is being used for rpc as well.

I am not sure what would be the impact of creating a new VIP with the same ip address but on port 443 and using cookie consistency

Link to comment
Share on other sites

You can configure another lb vserver with same IP but different protocol so for instance a second vserver same IP, SSL(or ssl_bridge) port 443.  Then add a listen policy to the original vserver like CLIENT.TCP.DSTPORT.NE(443) to exclude port 443.  I haven't tried using a Not Equal listen policy before, but I think it would work.  If your internal NetScaler VIP is also used by internal Outlook clients then I would try testing this out on a test vserver or seperate test VPX so not to interrupt client connections.

 

  • Like 1
Link to comment
Share on other sites

Thank you for your help. That's great.

After you told me about using cookie consistency I also discussed the issue with the server team and they mentioned that the load is being caused by active sync so another option I am thinking is to try to identify that traffic using the content switching policies like HTTP.REQ.URL.CONTAINS("/Microsoft-Server-Activesync/") and then create a dedicated VIP on the internal but if your suggestions works it will achieve a better result. I will let you know if I proceed with it and the results.

Link to comment
Share on other sites

Thanks mborrel308.

Doing what you  suggested took the load off the exchange backend servers. We are still having mail performance issue but at least it's being load balanced more equally now and the server guys have reported CPU and memory now normal.

 

Thanks a lot.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...