Aruba Networks Lync Solution
Deployment Guide
Lync Deployment Guide
Warning and Disclaimer
This guide is designed to provide information about wireless networking, which includes Aruba
Network products. Though Aruba uses commercially reasonable efforts to ensure the accuracy of the
specifications contained in this document, this guide and the information in it is provided on an “as is”
basis. Aruba assumes no liability or responsibility for any errors or omissions.
ARUBA DISCLAIMS ANY AND ALL OTHER REPRESENTATIONS AND WARRANTIES, WHETHER
EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE, NONINFRINGEMENT, ACCURACY, AND
QUIET ENJOYMENT. IN NO EVENT SHALL THE AGGREGATE LIABILITY OF ARUBA EXCEED
THE AMOUNTS ACTUALLY PAID TO ARUBA UNDER ANY APPLICABLE WRITTEN AGREEMENT
OR FOR ARUBA PRODUCTS OR SERVICES PURCHASED DIRECTLY FROM ARUBA,
WHICHEVER IS LESS.
Aruba Networks reserves the right to change, modify, transfer, or otherwise revise this publication
and the product specifications without notice.
Aruba Networks, Inc.
2
Lync Deployment Guide
Table of Contents
Warning and Disclaimer
2
Introduction
6
Lync Overview
6
Lync Security
6
Lync Over WLAN
7
Lync Architecture
Lync Topology
7
7
Lync Client Characteristics
9
Network Characteristics
9
Upstream QOS
10
Client Roam time
10
Aruba WLAN & Lync
11
Aruba Controller based WLAN & Lync
11
Aruba Instant based WLAN & Lync
13
Aruba Infrastructure Configuration Guidelines
13
AP selection and placement recommendations
13
Capacity based RF design
13
AP Placement Recommendations
14
AP Selection Recommendations
16
RF Considerations
16
Controller settings
17
Aruba Instant AP Configuration Recommendations
18
Remote AP Configuration Recommendations
18
Authentication and Encryption Guidelines
19
High availability
19
Network Topology Considerations
19
Campus Deployment Considerations
20
Distributed Enterprise Deployment Considerations
21
Multi-site Lync Architecture
24
Guest and BYOD Access Topology
25
Firewall vs. VLAN for separation
26
Forwarding Mode considerations
26
Configuring Lync on Aruba
27
Heuristics based Configuration
27
SDN API based Configuration
27
Heuristics vs. SDN API
27
QOS
28
WMM & QOS
29
Aruba Networks, Inc.
3
Lync Deployment Guide
QoS Segments
30
QOS Considerations
31
QoS Flow
32
DSCP Considerations
35
Scalability Considerations
37
Call Scalability Per AP per Radio
37
SDN API Scalability
37
Troubleshooting
37
SDN Integration Troubleshooting
37
Controller Troubleshooting
38
AP Troubleshooting
39
RF Troubleshooting
40
Wired Network Troubleshooting
40
Controller CLI commands For Troubleshooting
41
Appendix
Aruba Networks, Inc.
44
4
Lync Deployment Guide
Aruba Networks, Inc.
5
Lync Deployment Guide
Introduction
The adoption of unified communication (UC) applications such as Lync in the enterprises is growing
quickly. The combination of mobile UC clients and a UC enabled WiFi solution have enabled
companies to improve collaboration, communication and mobility in the enterprise. Mobile devices
running UC applications also create an excellent opportunity to rightsize networks and forgo
investments in expensive switching infrastructure, backup power refresh and desk phones.
One of the biggest obstacles for mobile UC over WiFi has been improperly designed WiFi networks
as well as the lack of visibility into the UC traffic for monitoring and management. With the
introduction of Aruba’s integration into Microsoft Lync, we can now meet these quality and visibility
requirements.
This document will cover all aspects of network design for an enterprise Lync deployment including
AP placement, RF design, Network topology considerations, WLAN configuration, QOS, Lync
detection, Lync visibility and Troubleshooting.
As Lync deployments come in all shapes and sizes, this document will cover controller, instant, and
RAP deployments as well as the design considerations for each deployment.
The design considerations cover the use of Lync for voice, HD video, conferencing, and off WLAN
communications.
This document assumes the existence of a tested Microsoft Lync installation as well as an advanced
understanding of network topology and WLAN deployments. Prior to configuration of the WLAN
solution please confirm the function of all Lync components.
Lync Overview
Lync Security
Every communication channel Microsoft Lync Server uses is encrypted. All server-to-server
communications are encrypted and authenticated is done using Mutual Transport Layer Security
(MTLS). Each server is issued a server certificate by a trusted Certificate Authority (CA), which is
then used for authentication and to exchange a symmetric key used to encrypt the network session.
Lync uses Session Initiation Protocol (SIP) as the signaling protocol, which is encrypted using
Transport Layer Security (TLS).
Since Lync leverages the secured SIP channel, Lync Instant Messaging traffic also benefits from the
same encryption provided by TLS.
Application Sharing uses the Remote Desktop Protocol (RDP). This TCP traffic uses TLS as the
underlying transport. Authentication is established over the secured SIP channel.
Web conferencing traffic uses Persistent Shared Object Model (PSOM). PSOM also uses TLS as the
underlying transport, and authentication is also established over the secured SIP channel.
Aruba Networks, Inc.
6
Lync Deployment Guide
Audio and video (A/V) traffic traveling to and from Lync Server is protected with Secure Real Time
Protocol (SRTP) to prevent any eavesdropping or packet injection. SRTP uses 128-bit Advanced
Encryption Standard (AES) stream encryption. Lync Server establishes a media path that can
traverse firewalls and network address translations (NATs) before allowing A/V traffic to flow between
two endpoints.
In Summary, all Lync Signaling and media traffic are encrypted.
Lync Over WLAN
The three core design components of a Lync ready WLAN include Air, QOS, and Visibility.
Fundamentally, Lync is an application that is very latency sensitive meaning that any delay or
disruption to the flow of the Lync traffic can cause quality issues. By addressing each of the
categories in a systematic approach we can limit the amount of latency a client will experience.
It is also critical to address the integration of voice and data along the same data path. Since Lync is
an application on a general-purpose device it is unfeasible to treat the entire device in a dedicated
fashion. The coexistence of UC and other applications must be seamless and balanced to ensure
neither suffers from the other’s needs. The result is a natural invisible integration to the end user.
The measured goal between all Lync components including peer-to-peer (local and remote), peer to
gateway (SBC), peer to Conference Bridge is as follows:
 Round trip delay of less than 100ms
 Jitter of less than 10ms
 Packet loss <5%
This should be measured under load with typical background traffic no less than 100Mbps.
Lync Architecture
Lync Topology
Lync clients are assigned to a cluster of Front End servers, called a Lync Front End pool. Large Lync
deployments will typically have many front end pools deployed to serve a wide geographic area. In a
global deployment Lync clients will still register with their home Front End servers despite their
proximity to a closer front-end server. This fact should be well understood during any troubleshooting
exercise to minimize confusion and mis-diagnosis of Lync issues.
Lync is designed to traverse the public Internet without any additional components, such as a VPN or
specialized ports. The Lync client detects it is outside of the corporate network via a DNS query.
When outside, Lync can traverse the corporate border through the Lync Edge server.
The following diagram shows different components of Lync network.
Aruba Networks, Inc.
7
Lync Deployment Guide
Figure-1: Lync Network Components
Lync Front End Pool
The Front End (FE) Server pool performs call processing in Lync. The FE server can be pooled
together with other FE servers to create a fault tolerant Front End Pool. Front End servers can also
perform bridging or conferencing functions in the absence of a dedicated bridge. Clients connect
directly to a Lync font-end server in order to make or set-up calls and communicate with other users.
The Front-End server is also the component that talks to the Aruba infrastructure via Lync SDN API
Dialog Listener and Lync SDN Manager (LSM).
Lync SDN Manager
The Lync SDN Manager is a component of the SDN API architecture and acts as a collect and
forward agent for SDN API messages. The LSM receives Lync SDN messages from multiple Lync FE
servers and sends those to Aruba Mobility Controllers. The LSM can be installed on Lync Server itself
for small-scale deployment (Under 1000 subscribers). For deployments in greater than 1000 Lync
users, the LSM needs to be installed on a separate Windows 2008/2012 server.
Active Directory (AD)
Lync is tightly integrated with Microsoft Active Directory. Not only is AD the repository for Lync user
credentials it also stores the Lync topology in the directory schema. Lync users are created in AD and
then enabled in the Lync server manager control panel.
Lync Edge Server
This enables external users such as authenticated and anonymous remote users, federated partners,
mobile clients and users of public instant messaging (IM) services to communicate with other users
inside the Lync domain. The Lync Edge server uses port 443 for its communications to the FE Pool.
Reverse Proxy
Aruba Networks, Inc.
8
Lync Deployment Guide
This is used for external discovery of a Lync FE pool assignment. Reverse proxy is required for
external clients to access the Lync Server web services for example, which are on the internal
network.
QoE Server
This system component includes a Microsoft SQL Server database. This is an optional component in
Lync infrastructure. The QoE server provides information about the End-to-End call quality metrics for
Lync calls.
Though QoE server is an optional component during the Lync install process, but is required as part
of the Lync SDN API integration for Aruba to get visibility to end-to-end call quality metrics. Lync
clients collect data during a call and send this data to the Front-End server where it is forwarded to
the QoE server. The QoE server is responsible for calculating Call quality metrics such as MOS
(Mean Opinion Score), Packet loss, Jitter, delay etc. for a call. MOS represents the end-to-end call
quality for Lync Voice call. MOS ranges from 0 to 5, 0 being the worst to 5 being the best call quality.
QoE Server generated call quality metrics helps with troubleshooting. Lync call classification and
prioritization will work without QoE Server.
NOTE: The SDN API plugin on the Lync Front End server will not send a MOS score without an
installed QoE server.
Lync Client Characteristics
Lync is a single unified communications application that runs on nearly every platform available today
including:
 Desktop OS - Windows (XP, Vista, 7, 8), OSX
 Mobile – iOS, Android, Windows Mobile, Windows 8RT
 Lync room systems
 Dedicated Lync endpoints (Polycom, Snom etc.)
 Embedded application systems using the Lync API
Network Characteristics
Lync follows a typical SIP registration and call control ladder model. The Lync client uses a DNS
service discovery model to determine how it will sign into Lync. When the client signs into Lync it
registers with a Lync Front End Server or if external to the network an Edge server. When a call is
made, the Lync client will communicate to the Front End or Edge server to set up the call over TCP.
Once the call is set up RTP data traffic flows between the clients or media gateways directly via UDP.
The following ports are used for Lync communications.
 TCP 53 – Lync DNS query
 TCP 5061 – Lync clients inside a corporate network
 TCP 5063 - Used for incoming SIP requests for Audio/Video conferencing.
 TCP 443 – Used by Lync clients outside a corporate network – or all Lync Online clients
Aruba Networks, Inc.
9
Lync Deployment Guide
 UDP 3478 – This port is used for STUN (Session Traversal Utilities for NAT) messages. Lync
clients initiate STUN connectivity check prior to media transmission. Once STUN connectivity
check is succeeded, media transmission happens.
 UDP 50000 – 65000 – typical port range used for RTP – can be set to a specific port range on
the Lync server
Upstream QOS
Not all Lync clients are capable of tagging Lync traffic with QOS markings. Today only Windows
clients (Vista/Win7/8) are capable of performing upstream tagging of Lync RTP packets. To enable
upstream tagging you must configure a group policy. For detailed instructions please see Group Edit
Policy Configuration. Enabling upstream tagging can have a significant improvement on Lync quality.
Upstream tagging should be enabled whenever possible.
NOTE: Refer to the client QOS section for some caveats on upstream tagging.
Client Roam time
The Lync wireless clients are sensitive to disconnection from the network during roam event to
from one Access point to another one. Any roam interval over 150ms will cause Lync voice quality
issues. A longer roam interval can cause the Lync client to disconnect and re-register with the FE
server. Refer to configuration best practices in order to minimize the roaming interval.
Aruba Networks, Inc.
10
Lync Deployment Guide
Aruba WLAN & Lync
As discussed in earlier section, Lync signaling and media traffic are encrypted. It is not trivial to detect
and classify different traffic types such as Voice, video, desktop sharing and file transfer etc.
Both Aruba Controller and IAP (Instant AP) based architecture has built in Application Layer
Gateways (ALG) that can detect and classify different types of Lync applications. Both infrastructures
can dynamically prioritize high priority Lync Traffic such as Voice, Video over other Lync data traffic.
The following diagram gives an overview of the Aruba’s Lync solution architecture in Controller and
Instant based deployment.
In controller-based architecture, both Campus APs and Remote APs are supported.
Figure-2: Aruba Lync Solution Architecture
Aruba Controller based WLAN & Lync
Aruba Controller uses two different methods of detecting and classifying Lync applications.
1. Heuristics method
2. Lync SDN API method
Aruba Networks, Inc.
11
Lync Deployment Guide
Heuristics based Lync detection
With Heuristics method, Aruba controller does deep packet inspection on the Lync traffic to determine
Lync Voice and Video traffic. There are no changes required on Lync server for this classification
method.
The Lync client and server send call control signals through the Mobility Controller via TCP port 5061
or TCP 443, which initiates a Lync call. This information is used to identify clients in the call and
further classify and prioritize Lync media packets.
The following gives a detail walk through on Heuristics based classification method 1. An Access Control List (ACL) is defined on the controller to listen on port TCP 5061. Classify
media is enabled in this ACL. This ACL is mapped to a user role.
2. When Lync voice/video calls are established, Lync ACL is hit and Lync clients are marked as
Media capable clients
3. Any subsequent UDP data flow with source/destination port > 1023 from/to Media capable
users goes through Deep Packet Inspection (DPI)
4. If the session is found to be an RTP session based on DPI, then payload type in RTP header
is looked into to determine if the session is voice or video
5. TOS is set in the session, which is equal to the egress Wi-Fi tunnel DSCP mapping configured
in SSID profile
Refer to the Heuristics Configuration guide for more details on Lync heuristics based configuration on
the controller.
SDN API based Lync detection
The Lync SDN API is a software component developed by Microsoft. It can be installed on a Lync
2010 or Lync 2013 server. Lync SDN API provides an interface to the Aruba controller to access
Lync network diagnostic information about Voice & Video calls, Desktop Sharing and File Transfer.
The Aruba controller uses this diagnostics data to prioritize the Lync traffic and provide visibility into
usage of Lync applications on the network. Lync server communicates with the controller via XML
messages over HTTP or HTTPS.
Lync SDN API 2.0 has two components –
1. Lync Dialog Listener (LDL) which is installed on Lync FE Server
2. Lync SDN Manager (LSM) which can be installed on a Windows 2008/2012 server
Lync Server SDN API should be obtained directly from Microsoft: http://www.microsoft.com/enus/download/details.aspx?id=39714. See the installation guide for detail requirements of LDL and
LSM installation.
Aruba Networks, Inc.
12
Lync Deployment Guide
The following diagram shows a Lync call flow with the Lync SDN API and Aruba Controller.
Figure-3: Lync Call Flow with SDN API
Refer to the SDN API Configuration guide for more details on Lync SDN API based configuration on
the controller.
Aruba Instant based WLAN & Lync
Instant supports Heuristics based Lync classification only. It can classify Lync Voice and Video traffic
types and dynamically apply QOS for these traffic types. Steps of classifying Lync traffic using
heuristics on Instant are the same as the controller.
Refer to the Lync Configuration guide for Instant for more details on Heuristics based configuration on
the Instant AP.
Aruba Infrastructure Configuration Guidelines
Pervasive RF coverage, optimum RF signal level, end-to-end QoS are the key requirements of a Lync
ready network. Sub-optimal WLAN design will degrade network performance and hence degrade the
quality of Lync calls. Correct WLAN design along with the configuration best practices guarantees the
Lync clients are communicating with the best APs at all times, QoS is in place for both RF and wired
network. This section discusses in detail about RF considerations including AP selection and
placement and QoS considerations that is required for a Lync deployment.
AP selection and placement recommendations
Capacity based RF design
There are primarily two ways to design a WLAN Network in terms of AP density 1. Coverage based
Aruba Networks, Inc.
13
Lync Deployment Guide
2. Capacity based
Coverage based network would have fewer APs spaced significantly apart from each other, operating
at higher TX power and therefore having larger coverage areas. In contrast, a capacity-based
network would have a higher number of deployed APs operating at lower TX power such as to keep
cell size smaller. This allows devices within these cells to associate at higher PHY rates and therefore
experience better performance.
The following example gives a comparison between Coverage based and capacity based design in a
802.11n WLAN deployment. In a coverage based design, clients get 7.2Mbps data rate at the cell
edge and whereas in capacity based design, clients get 216.7 Mbps data rate.
For Lync network, Capacity based network design is recommended to achieve optimal network
performance. Since wireless is a shared medium, higher client data rate results in low latency helping
Lync call quality.
Figure-4: Coverage Vs. Capacity based WLAN design
AP Placement Recommendations
This section discusses AP placement recommendations for various deployment environments. AP
placement is important to make sure there is 100% pervasive coverage and special care to be taken
in High Density deployments.
Carpeted office space
Distance from the center of one AP to the center of neighboring AP is recommended as 50 feet. A
honeycomb pattern is recommended. The following is an example of honeycomb pattern with 36APs.
This pattern ensures that distance is normalized along all directions to have the best coverage.
Aruba Networks, Inc.
14
Lync Deployment Guide
Figure-5: AP Deployment – Honeycomb Pattern
High Ceiling and Long Corridor Spaces
If the ceiling height is 40Ft or below, ceiling mount is recommended. In case if the ceiling height is
more than 40 Ft, then use wall mount or under the floor installation.
Manufacturing Facility
It depends on size of the facility and ceiling height. If the facility has ceiling height that is more than
40Ft. high, then Ceiling mount is recommended.
Warehouse
Recommendations for AP placement and Ceiling height are the same as that for manufacturing
facility. However, the deployments can be complex with brick walls, metal equipments etc. To learn
more about AP placements for these of complex deployments, refer to Indoor Site survey and
planning VRD.
Aruba Networks, Inc.
15
Lync Deployment Guide
Retail Stores
Retail stores environments can be complex. Both 2.4 GHz and 5 GHz frequencies can have difficulty
penetrating walls, shelving, freezers, containers, and other typical obstructions in a retail setting. For
floor to ceiling shelving type environments, Aruba recommends ceiling mount APs. To learn more
about AP placements for retail store deployments, refer to Indoor Site survey and planning VRD.
Conference rooms and large auditoriums
These are high-density environments. The AP placement requirements for these deployments vary
depending on the ceiling height, client density etc. To learn more about AP placement guidelines for
large auditoriums and conference rooms, refer to High Density Wireless Network Design VRD.
AP Selection Recommendations
11ac AP Considerations
802.11n has become the standard interface for PCs, tablets and smartphones. The number of
applications and High Definition multimedia streaming used by these devices has continued to evolve.
11ac addresses these high bandwidth requirements by providing data rates in excess of 1Gbps.
Aruba recommends the use of 11ac APs to achieve high network performance.
a) For Indoor deployment, deploy AP-224 and AP-225
b) For Outdoor deployment, deploy AP-274 and AP275
c) For RAP deployment, deploy AP-109 and AP-155
RF Considerations
The following recommendations should be followed to ensure proper device operation for a high
density Lync deployment.
 Power Settings
o Min and Max AP power difference no greater than 2 steps
o AP power setting low to moderate power. For example, in a high density AP deployment
set min/max power to 12 -18dbm for 5GHz and set min/max power to 6 -12dbm for
2.4GHz.
 Disable lower transmit data rates
o If there are no 11b clients in the network, disable lower rates 1 - 11Mbps
 Set supported beacon rate to higher rate such as 12 Mbps
o Beacons are transmitted at lowest basic rate. Beacons if transmitted at lower rates such
as 1 Mbps can consume considerable amount of air time
 Minimum RF signal (RSSI) levels of -65 dBm
 Minimum Signal-to-noise ratio (SNR) of 25 dB
o Higher signal level and high SNR are the indicators of superior RF environment, it will
help clients transmit at better rates
 Local Probe Request threshold to 18
Aruba Networks, Inc.
16
Lync Deployment Guide
o This prevents APs from responding to a client’s probe request if their SNR value is
below 18 dB, thereby encouraging the client roaming to closer APs who are responding
client's probe request.
 Cell size reduction to 15dB for dense deployment with AP225s, and 10dB for dense
deployments with AP135s
o Cell size reduction reduces Receive sensitivity of Access Points. In other words, it
reduces range of a client by reducing the Rx sensitivity. For example, if Cell size
reduction is 15 and Noise Floor is 90, AP will not receive packets with signal strength
less than -75 dbm which is “Noise Floor – Cell size Reduction value”
 Mitigation of interference sources (Microwave Oven, DAS equipment, game consoles etc)
 Use of both 2.4 and 5Ghz bands
 20Mhz channel bandwidth on 2.4Ghz
 40Mhz or less channel bandwidth on 5Ghz
o For High-density deployments, it is recommended to use 40MHz or less channel
bandwidth to reduce Adjacent and Co-Channel Channel Interference. Using 80MHz
channel bandwidth in high density AP deployment may result in Adjacent or Co-channel
interference.
 Disable 802.11b where possible
Controller settings
 Broadcast Filter ARP – enabled on the virtual AP profile
o All broadcast ARP requests are converted to unicast and sent directly to the client
instead flooding the network with broadcast ARP packets. Also Unicast packets get
transmitted at better data rates than the broadcast packets.
 Enable fair-access station shaping policy in the traffic management profile
o This makes sure all clients get equal access to the wireless medium. For example, you
may not want the slower clients starve for airtime, thereby affecting their performance
 On the SSID profile
o Set max-retries to 8
 Try to retransmit packets 8 times. The client might be in a state where it is not
responding to the packets sent by AP due to some reason.
o Configure QoS Settings (DSCP-WMM mapping) to be the same as the wired network
and as per the tagging in the client devices if configured
 This ensures End-to-end traffic prioritization for Lync Voice/Video traffic.
 In the ARM profile
o Enable voice/video aware scan
 This ensures AP does not do off channel scanning during a Lync Voice or Video
call
o Client Match - enabled
 ClientMatch provides dynamic spectrum load balancing and dynamic band
steering. It constantly optimizes the client association by continuously scanning
the wireless environment and sharing information about the clients and the APs.
Based on this dynamic data about the clients and APs, the clients are steered to
Aruba Networks, Inc.
17
Lync Deployment Guide
the best AP. This also solves the sticky client problem where the client is
associated to a far away AP affecting the overall network performance.
 In case of 802.1X authentication in the dot1x profile
o Enable Opportunistic Key Caching (OKC)
 OKC involves only one-fourth the number of frames during authentication. It is
much less susceptible to frame errors and retries, or to interference from other
Wi-Fi and non-Wi-Fi devices. Whereas these effects stretched some full reauthentication events over several seconds, OKC handovers invariably
completed promptly.
o Enable Validate-pmkid
 This configuration is very useful if you have devices that do not support OKC
such as MACOS or iOS devices. By enabling validate-pmkid, the controller looks
for PMKID in association/re-association requests from the client indicating the
client supports OKC or PMK-Caching. Without this option, full 802.1X
authentication will take place. MACOS/iOS devices support PMK caching.
o Enable EAPOL rate optimization
 This ensures that APs send EAPOL frames at lowest possible rates, thereby
avoiding authentication delays because of retransmitted packets.
NOTE: OKC is only supported on Windows devices and few Android devices. For MACOS/iOS
devices where OKC is not supported, use PMK Caching.
Aruba Instant AP Configuration Recommendations
The following are the RF best practices for Instant. Please see the detail explanation for these
parameters in the controller RF considerations section.
 100% coverage in all areas of Lync use
 Capacity Based RF Network design
 Minimum RF signal (RSSI) levels of -65 dBm
 Minimum Signal-to-noise ratio (SNR) of 25 dB
 In the ARM Configuration
o Client Match - enabled
 Broadcast Filter ARP enabled
 Set local probe threshold to 18
 Traffic shaping configuration – Configure the following to protect Lync Voice and Video traffic in
presence of high volume of background traffic. This feature will ensure that Voice and Video
packets are processed and only background and best effort traffic gets shaped to preserve
Lync quality. These settings are in WLAN settings  Advanced options. Adjust the Voice
and Video % based on expected Voice/Video traffic in your environment.
Remote AP Configuration Recommendations
Remote AP (RAP) is primarily used for Home Office or Micro Branch office type of environments.
RAP terminates on a controller. Controller RF recommendations are applicable to RAP as well.
Aruba Networks, Inc.
18
Lync Deployment Guide
Lync Heuristics based Lync classification is supported in Tunnel and D-Tunnel modes only. Lync
SDN API based Lync classification is supported in Split Tunnel mode as well along with Tunnel and
D-Tunnel forwarding modes. Depending on which Lync classification method is used, appropriate
forwarding mode needs to be configured.
Authentication and Encryption Guidelines
Latency and jitter are some of the key parameters that can impact Lync call quality. Care to be taken
to minimize latency and jitter intervals during authentication/re-authentication process.
802.1x with AES is the preferred Authentication/Encryption method than WPA2-PSK in most
enterprises because of the stronger security. For 802.1X based, make sure OKC or PMK Caching is
enabled for faster authentication.
EAP-TLS certificate based authentication is preferred over PEAP because it eliminates password
authentication with Active Directory. In a network where Certificate Authority is separate from Active
Directory such as Aruba Clearpass Policy Manager (CPPM), then in EAP-TLS authentication request
is contained with CPPM, but PEAP, CPPM sends password authentication request to Active Directory
server further causing the delay in the authentication process.
High availability
In multi controller based architecture, make sure AP fast failover is enabled to have hitless failover in
case of a controller failure. Note that AP fast failover is not client session aware. With AP fast failover,
Access Points will not go down, however Lync clients will be de-authenticated and re-associated. For
example, if there are 2 controllers in the network and the Lync clients are associated to an AP on
controller-1 and Controller-1 goes down. Lync clients will be re-authenticated on Controller-2 and
Lync calls need to be re-initiated and new Lync session entries will be created on the based on call
re-initiation.
In instant virtual controller based architecture, there is no single point of failure.
Network Performance

End-to-End QoS: Make sure the same QoS Tagging configured and matched across all the
wired switches/routers and in wireless infrastructure end-to-end. Ensure that APs are included
in QOS trust to enable upstream markings.

Round trip delay of less than 100ms between clients

Jitter of less than 10ms

Packet loss <5%

Configure QOS trust on all voice ports to honor the QOS markings
Network Topology Considerations
In this section, we discuss different Lync deployment design considerations. The design
considerations include Controller based campus deployments, Branch office deployments, Multi-site
Aruba Networks, Inc.
19
Lync Deployment Guide
Lync deployments etc. These design considerations give an insight how Lync network should be
designed for a specific deployment scenario as discussed below.
Campus Deployment Considerations
In a campus deployment, controllers can deployed in the following modes –
1) Master-Master: APs are terminated on the master controller. This deployment is best suited
for small-to-medium enterprise Campus environment.
Figure-6: All Master Controller deployment
2) Master-Local: APs are terminated in Local controllers only. This is a common scenario for
large enterprises where the configuration is pushed from the Master controller to the local
controllers.
Aruba Networks, Inc.
20
Lync Deployment Guide
Figure-7: Master - Local Controller deployment
Distributed Enterprise Deployment Considerations
The advent of secure communication protocols over the Internet has allowed most organizations to
adopt the distributed enterprise model. A distributed enterprise is an organization with multiple
offices/locations spread across a specific geographic region or the entire globe. Examples of
distributed enterprise include:

Retail Chains

Health care offices

Public service organizations such as Police departments, post services and DMVs

Restaurant and hotel chains

Technology companies with home offices and call centers
Different organizations may have different distributed enterprise solution needs. For example, a
restaurant or retail chain may require a distributed network that supports everyday business
operations, guest services and trend analysis. Whereas, a financial institution might just require
remote employee access. In general, an ideal distributed enterprise network must be cost effective
and satisfy all the business uses cases without compromising security, scalability, ease to
deployment and management. However, this is not achievable and the network administrators end
up compromising one over the other. The Aruba distributed enterprise solution is purpose built to
achieve the goal of an ideal distributed enterprise network. The Aruba distributed enterprise solution
allows the network administrators deploy a distributed enterprise network that meets all the business
requirements while being secure, cost-effective, easy to deploy, monitor and manage.
Aruba Networks, Inc.
21
Lync Deployment Guide
Aruba provides the following types of distributed enterprise deployments –
1) Branch controller based deployment at remote sites
2) Instant AP based branch deployment
3) Remote AP based branch deployment
Controller based solution at remote sites
Controllers are deployed at the remote branches. Lync Servers are deployed in Data center. This
is ideal for large distributed enterprise deployments.
Both Lync SDN API and Heuristics based classification are supported in this deployment.
Figure-8: Branch Controller deployment
Instant AP based remote deployment
Instant provides controller-less WLAN solution to deliver comprehensive enterprise-grade security,
resiliency and scale to distributed networks. Lync server pool can be deployed in the data center
and IAPs are deployed in the remote branch sites. This is ideal for a large or medium size
distributed enterprise types of deployments.
Only Lync Heuristics based classification is supported in this deployment.
Aruba Networks, Inc.
22
Lync Deployment Guide
Figure-9: IAP based branch deployment
RAP based deployment
This is a micro branch site deployment. This includes home office or tele-commuter type of
deployments. Lync server pool is deployed in the data center.
Both Lync SDN API and Heuristics based classification are supported in this deployment.
Lync SDN API based Lync classification is supported in Tunnel, D-tunnel and Split-tunnel mode.
Heuristics based classification is supported in Tunnel and D-tunnel mode only.
Aruba Networks, Inc.
23
Lync Deployment Guide
Figure-10: RAP based branch deployment
Multi-site Lync Architecture
Multi-site Lync architecture is quite common across large enterprises with multiple office locations
around the world. It is important to understand the design guidelines for a multi-site Lync architecture.
In the following diagram, the lync topology is divided into 3 sites. In each site, one Lync SDN
Manager (LSM) is assigned to the Lync FE Server pool in that region. This SDN manager is
configured to communicate with all the controllers in that region. See the guidelines for multi-site
architecture.
Aruba Networks, Inc.
24
Lync Deployment Guide
Figure-11: Multi-site Lync Architecture
1)
2)
3)
4)
5)
6)
One Lync FE Server pool per region say Americas.
One Lync SDN Manager (LSM) per region
LSM is configured to communicate with all Aruba controllers in that region
All the lync clients in a region will be served by the FE Servers in that region
Lync calls across multiple regions will be managed by local FE Server in that region
Check with Aruba Lync expert on the scalability of number of Aruba Controllers and Lync
clients to be managed LSM and FE Server Pool.
Guest and BYOD Access Topology
There is an ongoing shift to Mobile enterprise. There is a shift from Office centric model to Mobility
centric model. An employee carries multiple devices such as Tablets, laptops and smart phones,
some are Corporate issued and some are BYOD. People wants to be “Anywhere, Anytime and
always mobile” and still need complete access to their email, social media applications and more. The
security boundary has moved from perimeter security in office centric model to Application, Data and
Network security.
L1/L2 network separation no longer exists, one common services network is shared between all
users, devices and applications. The focus has shifted to Context – User role, Device, Mode
(Personal/Enterprise), Application and Location. Security Assurance, QoS Assurance and Traffic
engineering has taken a new paradigm to address this.
The following are the guidelines to design your BYOD network from Lync perspective 1) Configure the user roles and network access rules for Employee, Guest and BYOD profiles
2) Apply Lync ACL to a specific user role such as Guest, Employee etc where Lync traffic needs
to be classified and prioritized, else Lync traffic will be treated as best effort traffic.
Aruba Networks, Inc.
25
Lync Deployment Guide
3) Design your network to keep Lync traffic local instead of dragging to DMZ, else numerous
active Lync flows in your network will be hitting the DMZ and Edge Server.
Firewall vs. VLAN for separation
VLAN based access control limits to a single VLAN and is not recommended. With mobility centric
model, the focus has shifted to context. One common services network is shared between all users,
devices and applications. With built-in firewall, each traffic flow is inspected for context - user, device,
location and application. Based on these flow results, appropriate firewall policy is enforced.
Aruba recommends Role and context based Access control than VLAN based access control.
Forwarding Mode considerations
Access Points can be deployed in different forwarding modes. See below the details about the
forwarding modes and the appropriate Lync classification method to be used in that forwarding mode.
a) Tunnel mode
In Tunnel forwarding mode, both Lync Heuristics and SDN API based classification is supported. In
this mode, the Lync traffic is forwarded to the controller and the controller classifies and prioritizes
Lync traffic.
b) D-Tunnel mode
In D-tunnel mode, AP can decrypt the packet, but AP cannot do any further analysis to determine
Lync Traffic type. Lync ALG resides on the controller. Lync traffic analysis and classification is done
on the controller.
QoS flow remains the same as Tunnel mode as described in the above use cases.
c) Split Tunnel mode
In Split-tunnel forwarding mode, SDN API based Lync classification is supported for Remote APs only.
Heuristics mode of Lync classification is not supported in Split tunnel mode.
d) Bridge mode
In Bridge forwarding mode, neither SDN API nor Heuristics based Lync classification are supported.
The following table summarizes Forwarding modes vs. Lync classification methods support matrix.
Tunnel
D-Tunnel
Split-tunnel
Bridge
Lync Heuristics
Yes
Yes
No
No
Lync SDN API
Yes
Yes
Yes (RAPs only) No
Table 1 – Forwarding Mode vs.Lync Classification
Aruba Networks, Inc.
26
Lync Deployment Guide
Configuring Lync on Aruba
Heuristics based Configuration
Refer to Lync Heuristics Solution Guide for details on the configuration on the Aruba Controller.
SDN API based Configuration
Refer to SDN API Solution Guide for details on the integration and configuration on the Lync Server,
Lync SDN Manager and Aruba Controller.
Heuristics vs. SDN API
The following table compares Heuristics vs. SDN API with respect to feature support and deployment
scenarios perspective.
Lync Feature Support Matrix
Feature
Heuristics
Tagging and Re-tagging of WMM/DSCP values
Classification and Prioritization of Lync Voice and Video Traffic
Classification and Prioritization of Lync Desktop Sharing and File
Transfer Traffic
End-to-End call quality metrics such as MOS for Diagnostics and
Troubleshooting
Real time call quality analysis using UCC score
Co-relation between UCC score and Wi-Fi RF health metrics
UCC dashboard for complete Network wide visibility and
Troubleshooting
Advanced troubleshooting with detailed Call Statistics and reports
100% accurate identification of all Lync Traffic
UCC Dashboard and Diagnostics Capabilities using Airwave
Prioritization of Office 365/Lync Online
Support for Aruba Instant Products
Scalable beyond 100 Controllers
Lack of dependency on Lync Infrastructure
X
X
SDN API
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Table 2 – Lync Heuristics vs. SDN API
Aruba Networks, Inc.
27
Lync Deployment Guide
QOS
Aruba Policy Enforcement Firewall (PEF) is a stateful firewall that allows policies to be applied to user
traffic sessions. In addition to the functions that are typically associated with firewalls, the Aruba PEF
can also reclassify traffic. Firewall policies and application layer gateways are used to dynamically
reclassify traffic to not only prevent abuse, but also to properly prioritize traffic that has not been
marked with the correct priority. Here are few use cases that discusses the traffic classification by
Aruba controller.
Classifying Unmarked Traffic
When traffic reaches the mobility controller with no DSCP or 802.1p marks, the traffic is compared to
the policy that is assigned to the user role. If the traffic falls within a class of traffic that normally would
be classified at a different level, such as for a voice session, the mobility controller remarks the traffic
and then forwards it. If the traffic is untagged and that is the correct state, the mobility controller
forwards the traffic unchanged. Refer to the following figures for more details –
Incoming Traffic Is Marked
When traffic arrives and it is already marked, those marks are compared to the system policy. If the
marks are correct for the policy and traffic type, the traffic is forwarded unchanged.
Aruba Networks, Inc.
28
Lync Deployment Guide
Remarking Traffic to a Different Class
The third case occurs when traffic arrives but it is marked for an incorrect class. It can happen in the
following cases 
Client is configured for a DSCP tag for VO. Client sends voice packets with the correct DSCP
tag, but when it reaches the controller, it has a different DSCP Tag. Here is an example: DSCP
46 is configured on the client as VO, when client sends voice packet on Air, it gets classified
WMM-AC priority as VI. AP assigns DSCP tag corresponds to VI defined in DSCP-WMM
configuration in the controller, which is different than VO DSCP tag set by client.

Switches and routers in the wired network need to be configured to honor the DSCP tag set by
Client or in the controller. In the upstream direction, if the client is setting the DSCP tag for VO
as 56 and AP is sending VO packet with DSCP 56 when it sends the packet to the controller.
But if intermediate wired switch is misconfigured, then it may change original DSCP Tag.
Controller can be configured to reclassify this traffic as required by the network administrator.
WMM & QOS
WMM is based on 802.11e standard. It defines the basic QoS features for 802.11 networks. WMM
uses the 802.1P classification scheme developed by the IEEE. This classification scheme has eight
priorities, which WMM maps to four access categories: AC_BK, AC_BE, AC_VI, and AC_VO. These
access categories map to the four queues required by a WMM device as defined in the following table.
Aruba Networks, Inc.
29
Lync Deployment Guide
Priority
802.1P Priority
802.1P Designation
Access Category (AC)
WMM Designation
Lowest
1
BK
AC_BK
Background
2
BK
0
BE
AC_BE
Best Effort
3
EE
4
CL
AC_VI
Video
5
VI
6
VO
AC_VO
Voice
7
NC
Highest
Table 3 – WMM-AC and 802.1P priority
QoS Segments
The following diagram shows different legs of the network from QoS perspective. On wired side,
traffic is prioritized with DSCP tags or 802.1p priority. On the wireless side, it is prioritized with WMMAC tags.
Figure-12: QoS Segments
Aruba Networks, Inc.
30
Lync Deployment Guide
QOS Considerations
QOS ensures that the Lync real time traffic is prioritized both in the air and on the wire. On a wired
network QOS is applied via a DSCP (or DiffServ) marking for layer 3 and COS (class of service) for
layer 2 routing. On a wireless network QOS is applied through WMM (wireless multi media) also
known as 802.11e markings. These QOS markings can be applied either at the client layer if the
client and application support this or in the switching or AP layer.
a) Client Side QOS
 Some Windows clients are capable Tagging the traffic. Tagging can be configured on the client
or it can be set through Group Edit Policy through the Lync Server. See Appendix for more
details.
 If DSCP tag for VO is configured as 46 on the client, it is sent as WMM-AC-VI on the Air. Any
value with DSCP 48 and above translates to WMM-AC-VO. Aruba recommends DSCP 48 and
above for VO.
b) Controller QOS Configuration
DSCP-WMM mapping can be done on the controller. DSCP value can be set for different application
categories such as VO/VI/BE/BK.
NOTE: With Lync SDN API, Lync Desktop-Sharing will be tagged as the same as Video DSCP and
Lync File Transfer traffic will be tagged with Best Effort DSCP tagging.
Aruba Networks, Inc.
31
Lync Deployment Guide
c) AP QOS Considerations
In a controller environment, DSCP-WMM configuration done on the controller is sent to the APs. APs
translate WMM  DSCP values as per this mapping when sending the traffic upstream (Wireless
client to Controller) and downstream (Controller to wireless Client) direction.
When AP sends the packet to the controller, DSCP tag is placed outside the GRE header.
d) Instant AP (IAP) QOS Configuration
Starting Instant AP v6.4.0.2-4.1, IAP supports customization of Wi-Fi Multimedia to DSCP mapping
configuration for upstream (client to IAP) and downstream (IAP to client) traffic. The following table
gives the DSCP to WMM mappings for different traffic types. For example, if incoming traffic type is
marked with DSCP 48 or 56, it will be put to WMM Voice queue.
DSCP Decimal Value
8
16
0
24
32
40
48
56
WMM Access Category
Background
Best Effort
Video
Voice
Table 3 – Lync Heuristics vs. SDN API
You can also create customized mappings between WMM AC and DSCP tag to prioritize various
traffic types and apply these changes to a WMM-enabled SSID profile. When WMM AC mappings
values are configured, all packets received are matched against the entries in the mapping table and
prioritized accordingly.
Refer to “Aruba Instant 6.4.0.2-4.1 CLI Reference Guide.pdf” for DSCP-WMM configuration.
Prior to Instant 6.4.0.2-4.1, customized DSCP-WMM configuration was not supported. DSCP 48 was
mapped to Voice traffic and DSCP 40 was mapped to Video traffic.
QoS Flow
The following use cases demonstrate how the QoS gets translated for different call scenarios such as
Wireless to wireless call, Wireless to wired calls and vice versa. The use cases are demonstrated for
WMM only mode (Without any Lync Voice classification and prioritization), Lync Heuristics and SDN
API modes. These use cases are described in the Tunnel forwarding mode of operation.
1) WMM Only mode
In the following use case, client-A has initiated a Lync voice call to client-B. Client-A is not tagging the
Lync Voice traffic.
Aruba Networks, Inc.
32
Lync Deployment Guide
a) In upstream direction (Client to Controller), AP looks at L2 Priority (WMM-AC as BE) and puts
the DSCP 24 as per DSCP-WMM mapping in controller.
b) Controller decrypts the packet and uses L2 priority to assign DSCP 24 in downstream direction
(Controller to Client)
c) AP assigns WMM-AC as BE corresponding to DSCP-WMM mapping on the controller
NOTE: Lync Best effort traffic is sent with Best Effort Priority in entire network.
2) Heuristics mode
Client-A has initiated a Lync voice call to client-B. Client-A is not tagging the Lync Voice traffic.
Controller is configured to detect Lync VO traffic through Heuristics method.
a) In upstream direction (Client to Controller), AP looks at L2 Priority (WMM-AC as BE) and puts
the DSCP 24 as per DSCM-WMM mapping in controller.
Aruba Networks, Inc.
33
Lync Deployment Guide
b) Controller finds out Lync VO traffic type using Heuristics method and corrects DSCP tag to 46
in downstream direction (Controller to Client).
c) AP assigns WMM-AC as VO as per DSCP-WMM mapping in the controller.
NOTE: Lync Voice Traffic goes with Best effort priority in upstream direction, but gets corrected to
VO priority in downstream direction.
3) SDN API mode
QoS flow with Lync SDN API is identical to QoS flow in Heuristics mode. Lync SDN API module on
Lync Server sends Lync VO traffic type information to Aruba controller when Client-A initiates a Voice
call to Client-B.
4) Wired  Wireless
This use case applies to Lync VO call from a Wired client to a Wireless client either with Lync
heuristics or Lync SDN API based Lync classification.
a) In upstream direction (Wired client to Wireless client), controller finds out Lync VO traffic in
datapath and assigns DSCP 46 as per DSCP-WMM mapping. AP assigns WMM VO as per
the DSCP-WMM mapping.
b) In downstream direction (Wireless client to wired client), AP looks at L2 Priority (WMM-AC as
BE) and puts the DSCP 24 as per DSCM-WMM mapping in controller.
c) Controller finds out this is a Lync VO packet and corrects DSCP tag to 46 for VO when
sending the packet to the wired Lync client.
5) Wireless  Wired
This use case applies to Lync VO call from a Wireless client to a Wired client either with Lync
heuristics or Lync SDN API based Lync classification.
Aruba Networks, Inc.
34
Lync Deployment Guide
a) In upstream direction (Wireless client to Wired client), AP looks at L2 Priority (WMM-AC as BE)
and puts the DSCP 24 as per DSCM-WMM mapping in controller.
b) Controller finds out this is a Lync VO packet and corrects DSCP tag to 46 for VO when
sending the packet to the wired Lync client.
c) In downstream direction, Controller finds out this is a Lync VO packet from the wired client and
corrects DSCP tag to 46 for VO
d) AP assigns WMM-AC as VO as per DSCM-WMM mapping in controller
DSCP Considerations
It is recommended that a wireless controller DSCP setting for VO/VI/BE/BK have to match the
configuration of the wired network and that of client devices (if the client devices are tagging the
traffic). However, there are some caveats the way WMM converts DSCP to WMM mapping. See the
following example -
a) Client-A is configured to tag VO traffic with DSCP 46
b) Controller is configured to DSCP-WMM mapping VO/VI/BE to 46/34/24 respectively. AP is
forwarding mode is Tunnel mode.
c) Client-A makes a Lync Voice call to Client-B. Wireless driver on Client-A converts DSCP to
WMM-AC as Video and sends it over Air
Aruba Networks, Inc.
35
Lync Deployment Guide
d) AP sees this WMM-AC as VI and it put DSCP tag as 34 (as per DSCP-WMM mapping in the
controller)
VO traffic is sent with VI priority in upstream direction. The issue is the way wireless driver interprets
DSCP and converts to WMM-AC. Here is the table how WMM interprets DSCP values DSCP Range
48 - 63
32 - 47
22 - 31
0 - 21
WMM-AC
VO
VI
BE
BK
Table 4 – DSCP range vs. WMM-AC
It is recommended that the client to apply DSCP tag as above to achieve the correct WMM-AC
priority.
If your wired network is configured with DSCP 46 for VO and is not trivial to reconfigure to DSCP 56
and above, then use the following workaround a) Program your Wireless clients with DSCP 56 and above using Group Edit Policy configuration
from the Lync Server.
b) Client sends VO packets with WMM-AC as VO on air and AP is able to apply the correct
DSCP Tag for VO (DSCP 46) when it sends the packets to the controller
See the following QOS flow diagram -
NOTE: Configuring clients with Group Edit Policy apply to Windows 7/8 clients only.
Aruba Networks, Inc.
36
Lync Deployment Guide
Scalability Considerations
Call Scalability Per AP per Radio
The following table describes the recommended number of simultaneous Lync VO/VI calls.
AP Type
Band Tested
AP135
5G
AP225
IAP135
5G
5G
Number of Lync VO/VI Calls
tested
Background
Traffic
140Mbps UDP
Downstream
30 None
20 None
20
Release
AOS v6.2
AOS v6.4
3.4.0.0
Table 5 –Lync Call Scalability per AP radio
SDN API Scalability
The following recommendation is for per LSM controller supportability. For large deployment, it is
recommended to have one LSM per one FE Server pool. It is recommend that one FE Server pool
should contain minimum of 3 Lync FE servers and a maximum of 8 Lync FE Servers.
Number of LSM
Number of Controllers
1
120
Table 6 –LSM vs. Controller Scabaility
Troubleshooting
SDN Integration Troubleshooting
1) Check Lync traffic classification by controller
See the steps below to see if the Lync traffic is reaching and getting classified by the controller.
In “show datapath session”, include the wireless client IP address and see if the controller tags the
traffic correctly. In the following example, there is a Lync Video call, the controller is able to classify
the Video traffic with VoIP flag - “V” and apply the correct DSCP tag which is “40”.
Note that Lync Video call has both Lync Voice and Video sessions. Voice and Video are tagged with
their respective DSCP Tags. In the following command output, only VI DSCP tagging is displayed.
Aruba Networks, Inc.
37
Lync Deployment Guide
2) Voice debugging
If Lync VO/VI traffic is not reaching the controller, first thing to check is whether actual Lync voice or
video traffic is flowing or not. There could be issues with call connectivity itself. Voice debug logs give
information about the Lync SDN API messages and prioritization. These logs provide granular
visibility into the messages exchanged between Lync SDN Manager and the controller.
Voice debug logging can be enabled as follows. Sample debug logs are shown as part of the
following screen capture. This shows the controller is able to receive XML messages from the Lync
server.
NOTE: If we are receiving SDN messages and still Lync traffic not getting prioritized, check whether
the Lync SDN manager is sending start dialogue for calls and not an error message. If Error message
received, controller does not prioritize traffic and issue could be due to some misconfiguration on the
Lync server.
Controller Troubleshooting
1) Empty UCC Dashboard
After SDN API is installed and configured, if UCC dashboard does not pop up, then make sure “voice
real-time-config” is enabled as below.
Aruba Networks, Inc.
38
Lync Deployment Guide
2) DSCP-WMM mapping
DSCP to WMM mapping for VO/VI/BE/BK traffic types are defined in SSID profile in the controller as
follows –
Controller prioritizes different Lync traffic types are as per the above configuration.
To verify if the controller is able to prioritize Lync traffic and is applying the correct QOS, see the “show
datapath session” output as discussed in “SDN Integration Troubleshooting” section.
AP Troubleshooting
Once we verify Controller is applying the QOS correctly and still the users are having a bad Lync
experience, you need to troubleshoot AP side as follows.
1) AP QOS Troubleshooting
RF packet captures gives visibility to 802.11 headers to find out if Lync traffic is sent from the AP to
the client with the correct WMM-AC priority.
2) Radio statistics
From the controller, we can monitor detail radio statistics information. That will give the details about
the number of packets are getting transmitted/dropped on WMM VO/VI queues. Number of dropped
packets for Lync VO/VI traffic is expected to be less, since this traffic gets prioritized over BE/BK
traffic. If VO/VI dropped packet count is high, then QOS is not taking effect at AP.
First, reset AP debug counter as follows. Make new Lync voice/video calls on that AP and verify
voice/video Tx WMM packet drop counters.
Aruba Networks, Inc.
39
Lync Deployment Guide
If you need to get the above statistics on per a client basis, use “show ap debug client-stats
<client-MAC>”.
RF Troubleshooting
1) Prioritization over RF
RF packet captures gives visibility to 802.11 headers to find out if Lync traffic is sent with the correct
WMM-AC priority. If the wireless client is tagging the traffic, make sure the WMM-AC priority of
upstream traffic from the client matches with DSCP tag configured on the client.
In the downstream direction (From AP to the client), make sure Lync Traffic type marked with the
correct WMM-AC priority.
2) RF Packet Capture
RF packet captures gives visibility into the number of useful information such as packet
retries/failures, data rates, beacon rates etc. These RF environment attributes can be helpful to
troubleshoot Lync related issues.
Wired Network Troubleshooting
1) Wired QOS
End-to-end QOS is recommend to achieve the best Lync performance. We need to make sure the
switches/routers in the wired network honor the QOS settings. There is a known issue with some of
the wired switches (Cisco 3750 for example) can reset DSCP tag to 0 for all egress traffic if QOS is
not enabled on that switch. Packet capture on the wired network will show DSCP tagging details.
2) Wired Bandwidth
We need to make sure the wired network has adequate bandwidth to handle the volume of Lync
traffic the customer wants to run. Lync bandwidth usage is variable, but predictable. For network
bandwidth requirements for various Codecs, refer to http://technet.microsoft.com/enus/library/jj688118.aspx.
Aruba Networks, Inc.
40
Lync Deployment Guide
Controller CLI commands For Troubleshooting
The following troubleshooting commands are used to gather more data about communication
between Controller and Lync Server, Lync call status, Call detail records etc.
show ucc trace-buffer lync
This command is used to record activities of Lync clients. Max of 256 entries will be recorded in a
circular buffer to save memory. Events such as establishing Voice, Video, Desktop Sharing and File
Transfer will be recorded. Each entry of CLI will display IP, MAC, client name, Timestamp, WMM,
DSCP, called-party, media-type & AP name. The intent of this CLI to keep track of individual
sessions with respect to their handling on the Aruba wireless network.
Show ucc client-info
This command provides details about clients that are actively using Lync. An entry is created for
clients that have actively participated in voice, video, desktop-sharing or file-sharing sessions.
If filter with station MAC is applied on this command, it provides a detail report specific to that client
for example number of active calls, call history, call type, client health, ucc score, MOS etc.
Aruba Networks, Inc.
41
Lync Deployment Guide
Show ucc call-info cdrs
This command provides the call detail records for Lync voice, video, Desktop Sharing and File
transfer call. It also displays call quality metrics such as MOS that is received from Lync Server.
CDRs detail give additional visibility on a per call leg basis to DSCP/WMM-AC QOS tagging details,
Codec information, RF statistics such as SNR, Tx/Rx packet retries, packet drops, data rates etc.
Aruba Networks, Inc.
42
Lync Deployment Guide
Aruba Networks, Inc.
43
Lync Deployment Guide
Appendix
1) Aruba Controller Lync Heuristics Configuration guide http://www.arubanetworks.com/pdf/solutions/SG_MicrosoftLyncHeuristics.pdf
2) Aruba Controller Lync SDN API Configuration guide http://www.arubanetworks.com/pdf/solutions/SG_DeployMicrosoftLync.pdf
3) Aruba Instant Lync Heuristics Configuration guide http://www.arubanetworks.com/pdf/technology/whitepapers/WP_LyncDeployment.pdf
4) Steps to create QoS policy on a Windows 7 or Windows 8 client –
a) Create QoS policy:
gpedit.msc -> Local Computer Policy -> Computer Configuration -> Windows Settings ->
Policy-based QoS
Create QoS policies by specifying the name of the application executable and the
source/destination ports to apply QoS to.
b) Ensure that the computer is domain-joined, and if not, make changes in the registry settings
to circumvent the limitation for Win7 to be domain-joined:
[HKEY_LOCAL_MACHINE]
"Do not use NLA"="1"
i.e., create a REG_SZ value binary value with name "Do not use NLA" and value "1"
c) Restart your computer
d) Run the application and verify DSCP markings using a packet capture tool.
5) Managing Quality of Service (QoS) from Lync Server through Group Edit Policy http://technet.microsoft.com/en-us/library/gg405409.aspx
6) Network Bandwidth requirements for different Codecs - http://technet.microsoft.com/enus/library/jj688118.aspx
Aruba Networks, Inc.
44