A customer of ours is rolling out Microsoft Lync 2010 and asked me to setup their Cisco ACE load balancer for the task. I had barely heard of Lync (I know, I know, you’re right in thinking that I’m the last person to keep up with Microsoft’s offerings), so it was time to study up! Lync has a whole bunch of resources: Front End pools, Director pools, Edge Server pools and reverse proxy pools. Microsoft recommends load-balancing traffic for these pools with either DNS or a hardware load balancer (HLB). They state that for client-to-server HTTP/HTTPS traffic, you have to have a hardware load-balancer:
Decide which load balancing solution is appropriate for each pool in your deployment, keeping in mind the following restrictions: The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one interface and hardware load balancing on the other. Some types of traffic require a hardware load balancer. For example, HTTP traffic requires a hardware load balancer instead of DNS load balancing. DNS load balancing does not work with client-to-server web traffic. You must use a hardware load balancer to load balance reverse proxy traffic. DNS load balancing is not supported for reverse proxy traffic.
Now I see why the customer brought me in… Cisco doesn’t have a whitepaper, at present, on how to configure the class-maps and policies for Microsoft Lync, but we’re just load-balancing HTTP and HTTPS traffic and that I’ve done before. However, Microsoft threw in some more requirements (no surprise there):
- Use cookies for persistence. The cookies must be named “MS-WSMAN”, not expire and not be marked “httpOnly”.
- The ACE must decrypt SSL (otherwise he couldn’t read the cookie to stick the sessions to the appropriate real server) and then re-encrypt SSL to the real servers (because they are expecting HTTPS connections). This is called End-to-End SSL on the ACE and will be the first time I’ve set it up.
- Enable Persistence Rebalance. On the ACE, enabling Persistence Rebalance in a HTTP parameter map instructs the ACE to inspect each and every HTTP request within a TCP session for a cookie and loadbalance appropriately.
- TCP idle timeout of 1800 seconds.
- Load-balance ports TCP/80, TCP/443 and TCP/4443. My customer also needed us to load-balance TCP/8080.
Now that we have the requirements out of the way, it’s time to configure!
rserver host LFE01
ip address 10.250.140.71
inservice
rserver host LFE02
ip address 10.250.140.72
inservice
serverfarm host lync
description Microsoft Lync
predictor leastconns
probe tcp_http_probe
probe tcp_https_probe
rserver LFE01
inservice
rserver LFE02
inservice
parameter-map type connection TCP_IDLE_30min
set timeout inactivity 1800
parameter-map type http lync-http-map
case-insensitive
persistence-rebalance
set header-maxparse-length 65535 ! this is a workaround for bug csctx92484 in A5.1.2
set content-maxparse-length 65535 ! this is a workaround for bug csctx92484 in A5.1.2
length-exceed continue
parameter-map type ssl lync-ssl-map
authentication-failure ignore
sticky http-cookie MS-WSMAN lync-cookie-sticky
cookie insert
timeout 65535
replicate sticky
serverfarm lync
ssl-proxy service lync-ssl-client
ssl advanced-options lync-ssl-map
ssl-proxy service lync-ssl-termination
key lync.website.com.key
cert lync.website.com.crt
class-map match-any Lync-HTTP-Class
2 match virtual-address 10.250.90.71 tcp eq www
3 match virtual-address 10.250.90.71 tcp eq 8080
class-map match-any Lync-HTTPS-Class
2 match virtual-address 10.250.90.71 tcp eq https
3 match virtual-address 10.250.90.71 tcp eq 4443
policy-map type loadbalance first-match Lync-HTTP-Policy
class class-default
sticky-serverfarm lync-cookie-sticky
policy-map type loadbalance first-match Lync-HTTPS-Policy
class class-default
sticky-serverfarm lync-cookie-sticky
ssl-proxy client lync-ssl-client
policy-map multi-match int90
class Lync-HTTP-Class
loadbalance vip inservice
loadbalance policy Lync-HTTP-Policy
loadbalance vip icmp-reply active
appl-parameter http advanced-options lync-http-map
connection advanced-options TCP_IDLE_30min
class Lync-HTTPS-Class
loadbalance vip inservice
loadbalance policy Lync-HTTPS-Policy
loadbalance vip icmp-reply active
appl-parameter http advanced-options lync-http-map
ssl-proxy server lync-ssl-termination
connection advanced-options TCP_IDLE_30min
A lot of the configuration goes without saying, but I’d like to hit on the reasoning behind some of the configuration above:
- The TCP_IDLE_30min parameter-map exists because inactive TCP sessions shouldn’t be closed until after 30 minutes of inactivity.
- Persistence Rebalance is enabled on the lync-http-map because each and every HTTP request should be inspected within a TCP session.
- Authentication-Failure Ignore is enabled on the lync-ssl-map because I could not get the ACE to accept the certificate on the real servers. You probably won’t need this.
- The lync-cookie-sticky has an expiration of 65535 minutes (45 days) because that is the maximum I could specify on the ACE. Microsoft wanted no cookie expiration, but you take what you can get.
- The lync-ssl-client ssl-proxy configuration initiates the SSL connection to the real servers and the lync-ssl-termination serves up the SSL certificate and key to clients. We had to create both since the ACE performs end-to-end SSL (termination and initiation).
- The class-maps accept unencrypted connections on TCP/80 and TCP/8080 and encrypted connections on TCP/443 and TCP/4443. These came from Microsoft and the customer; I believe the TCP/8080 and TCP/4443 are necessary for external access to the servers.
With this configuration in staging for two weeks now, we’ve experienced no issues. The customer is still doing verification and testing, so this post may change as we realize potential issues with the configuration. I’m posting it as my interpretation of Microsoft’s requirements and may be wrong. I really would welcome any feedback in the comments below on your experience with ACE and MS Lync.
Thanks for reading!
- Andrew
