Wireless Access

Hi,

 

Couple of weeks ago I deployed an Aruba controller based WLAN, using 7220's, 325's with 6.4.4.5.

Since the start using this WLAN, lot of people are complaining about short silcences during S4B calls.

These 1 second silences do not really have a pattern but can occur with an interval of 10 seconds or more.

 

We are in the progress of implementing the SDN API to have S4B traffic prioritized, but due to some circumstances this is not going to take place within the next month.

For a short term solution, I configured the heuristic config as described in the following document:

 

http://www.arubanetworks.com/assets/tg/SG_MicrosoftLyncHeuristics.pdf

 

However, after configuring all required settings I don't see any session/call being marked or recognized as high prio VoIP call.

Assuming that the config is correct, do these settings take effect on S4B clients or only Lync? If so, what is the difference between the two because based on the documentation that I've red I don't see any differences regarding layer 4 port communcation or session encryption.

 

Can the short silences be caused by some scan or other enabled functionality? I'm trying to find a solution that does not cost me weeks or month by deselecting different options one-by-one.

Anyone able to point me in the right direction where to look for and how to solve this annoying issue?

I think someone needs to take a look at your configuration.  That someone is TAC, to ensure you have all of your ducks in a row.

Will do Colin!

Report back to us what you find.  One thing that not everyone does is configure the clients for QOS but they should:  https://technet.microsoft.com/en-us/library/jj205371(v=ocs.15).aspx

 

http://community.arubanetworks.com/t5/Wireless-Access/Configuring-QoS-for-Lync-2013/td-p/239592

 

Also make sure that "Voice Aware" is enabled in your ARM profile so that there is no scanning during VOIP calls.

voip- and video aware scan are both enabled on the ARM profile.

I asked the client team if QOS is enabled and they confirmed me it is being pushed in the polciy. I will have this doublechecked to be sure.

Once a have a solution to this issue I will share this.

When you type "show session table <IP address of client>" during a call, what flags do you see during a VoIP call?

Hi Colin,

 

I've just checked if QOS is send by the client for S4B data and I can confirm this is true.

VoIP gets 46 while video gets 34. Seems to work correctly on the client part.

 

I've also attached the show datapath output of the controller. I do see DPI is taking place but don't see the V(oIP) flag. I'm wondering if Aruba controller is able to determine S4B VoIP traffic using heuristic scanning. Will have a case opened at TAC today.

 

Thanks for looking into this.

What is your ACL to classify S4B traffic?

 

Here is a screenshot of what you should have in general:

 

HTTPS is what Lync uses remotely.  SIPS or TCP 5061 is what lync uses internally.  The ACL above signals to the firewall to inspect all of this traffic and then classify the traffic as voice if we see voice traffic.  Typically you would restrict that source and destination of the TCP 443 and TCP 5061 traffic so that the controller does not attempt to classify ALL TCP 443 traffic.

You should then start a call and the type "show datpath session table <ip address of client> | include V" to see if it is being classified as voice:

(Aruba7005-US) #show datapath session table 192.168.1.237 | include V
       C - client, M - mirror, V - VOIP
22.240.16.25    192.168.1.237   17   52679 50053  0/0     0    46  0   tunnel 14   1a0  273        102960     FHTV            
22.240.16.25    192.168.1.237   17   52186 50052  0/0     6    0   0   vlan 1      192  19647      1580474    FHPTIQV         
192.168.1.237   22.240.16.25    17   50053 52679  0/0     0    46  1   tunnel 14   1a0  618        406485     FHTCV           
192.168.1.237   22.240.16.25    17   50052 52186  0/0     6    0   0   vlan 1      192  11319      2372524    FHPTCIQV        

In the example, my off-premise Skype for Business Server is 22.240.16.25 and my Lync/S4B client is 192.168.1.237

Once the call is started, the call continues with high ports and using "Classify Media" in the ACL determines what ports those are and sets the "V" flag.

"show ucc client-info" would show my client that is recognized and more info.

(Aruba7640-US) #show ucc client-info 

Client Status:
--------------
Client IP      Client MAC         Client Name  ALG      Server(IP)  Registration State  Call Status  AP Name     Flags  Device Type
---------      ----------         -----------  ---      ----------  ------------------  -----------  -------     -----  -----------
192.168.1.237  b8:e8:56:38:9d:be  Client       Skype4B              REGISTERED          In-Call      Office-325         OS X


Flags: V - Visitor, A - Away, W - Wired, R - Remote, B - Blocked, E - External

Show ucc call-info cdrs will give you a record of all of your calls:

(Aruba7005-US) #show ucc call-info cdrs 

CDR:
----
CDR ID  UCC Call ID  Client IP      Client MAC         Client Name  ALG      Dir  Called to  Dur(sec)  Orig Time        Status  Reason      Call Type  Client Health  UCC Score  UCC-Band  MOS  MOS-Band
------  -----------  ---------      ----------         -----------  ---      ---  ---------  --------  ---------        ------  ------      ---------  -------------  ---------  --------  ---  --------
5       NA           192.168.1.237  b8:e8:56:38:9d:be  Client       Skype4B  NA   NA         622       May 23 07:10:11  ACTIVE  NA          Voice      86             68.44      Fair      NA   NA
4       NA           192.168.1.136  ac:cf:85:6b:c5:e6  NA           Jabber   NA   NA         31        May 18 17:38:52  SUCC    Terminated  Voice      73             NA         NA        NA   NA
3       NA           192.168.1.136  ac:cf:85:6b:c5:e6  NA           Jabber   NA   NA         16        May 18 17:38:36  SUCC    Terminated  Voice      0              NA         NA        NA   NA
2       NA           192.168.1.136  ac:cf:85:6b:c5:e6  NA           Jabber   NA   NA         6         May 18 17:38:30  SUCC    Terminated  Voice      0              NA         NA        NA   NA
1       NA           192.168.1.237  b8:e8:56:38:9d:be  Client       Skype4B  NA   NA         2712      May 16 09:26:13  SUCC    Terminated  Voice      74             82.59      Good      NA   NA

I hope all of that makes sense...

Hi Colin,

 

Makes absolutely sense.

Based on the Aruba doc, I did configure the following:

 

netdestination lync-servers
host 10.10.10.10

ip access-list session lync-control
any alias lync-servers svc-sips permit classify-media
any alias lync-servers udp 443 permit classify-media
exit
ip access-list session lync-rtp
any any udp 1024 65535 permit
exit

user-role lync-user
access-list session lync-control
access-list session lync-rtp
exit

ip access-list session lync-365-control
any any tcp 443 permit classify-media
exit

ip access-list session lync-rtp
any any udp 1024 65535 permit
exit

user-role lync-user
access-list session lync-365-control
access-list session lync-rtp

 

Like you mentioned I already had the destination IP's of the Lync front end servers configured to prevent non lync/S4B traffic to be prioritized.

 

These settings are documented for a Lync setup. Not sure if these settings are still fully compatible and required for S4B to function properly. Also I've to check if the user role ' lync user'  is being hit as this will be an issue for the ACL to be aplied if it is not.

For troubleshooting all you would need is the ACL that I showed you (and an "allow all" after that).  It will ONLY classify traffic that it detects is Lync traffic, so there is no problem writing it for all TCP 443 and TCP 5061 (SIPS) traffic.  Start with only that to see if your sessions have the "V" flag...

 

After configuring the setup you mentioned, I now see Skype traffic marked with 'V'. I've attached the output of the commands.

There are still 2 things that I don't quite get:

 

1- Before you mentioned that it is advisible to limit the marking of traffic using source/destinations instead of having all 443 traffic inspected, but in your latest reply described that only lync/S4B traffic will be inspected.

2- When looking at the output, I see the following 3 destinations: 'tunnel', 'local' and 'vlan1'. I would expect to ony see tunnel here. 

Sorry to steal this thread somewhat...

 

We as an organisation use Skype4B. Unfortunately as an organisation we only use GA code, so currently have no vsibility of Skype4B traffic over the wireless. We have successfully implemented a policy-based GPo to mark the client traffic correctly, but as we are running code that can't detect Skype4B, the ACL we applied for Lync 2013 in the user-role to classify the media is not classifying the traffic as voice. I would like to understand what the consequence of this as it is my understanding that the traffic is being placed in the voice WMM queue based on the DSCP marking applied through the GPo?

The GPO that pushes to the client marks the traffic from the client to the AP.  The S4B acl marks the traffic from the controller/AP to the client.  Both have to occur  for the best quality.  The traffic between the AP and the client is the the most likely link for any contention.

 

Thanks for the explanation Colin. After having the ACL configured, I know have full insight in call info, excellent! I see that VoIP and video dscp are coming into the AP from the client and vice versa.

 

Regarding my earlier questions can you clarify the below questions:

 

1- Before you mentioned that it is advisible to limit the marking of traffic using source/destinations instead of having all 443 traffic inspected, but in your latest reply described that only lync/S4B traffic will be inspected.

2- When looking at the output, I see the following 3 destinations: 'tunnel', 'local' and 'vlan1'. I would expect to ony see tunnel here. 

1.  I suggested all destinations as a troubleshooting method to make sure it can see the sessions, but in practice, you don't want the controllers engine attempting to classify ALL traffic.  When you have "Classify Media" checked in the ACL, the controller with watch the call control ports and sample the traffic to detect a Lync call.  You only want the controller to do that for traffic destinations/sources you suspect could be Lync/S4B traffic.

2.  The firewall uses the result of "show datapath route-cache" to determine how to deliver layer 2 traffic.

 

Apreciate your time and explanation on this.

 

So by enabling 'classify media', all traffic will be inspected by the controller, regardless of the layer 4 port defined in the same ACL? Then configuring the specifc layer4 port is used by the controller to mark the specific packets after inspecting the traffic. By defining source and/or destination IP's, this inspection will be limited to just those IP-range(s)?

If this is the case I don't think source/destination can be of much help as all clients in the network are potential S4B clients.

 

From my understanding DPI is done when 'classify media' is enabled and only with the specific layer4 port detected in the session (in this case 5061). In other words, sessions with a different layer 4 port won't be inspected by the controller.

 

Plese correct me if I'm wrong.

Enabling Classify media inspects the traffic defined by the ACL; source, destination and port.  The source, destination and port needs to match before "Classify Media" is triggered.  You do not want the DPI engine inspecting all traffic; you want it to be specific as possible.

thanks Colin, that makes sense and matches my thought on the ACL/DPI behaviour.

Much apreciated!

So far S4B seems to have improved a lot. Although still in some occasions a very short license can be heard, but the amount and duration is far less.

This indicates that QOS did improve the qualiy of VoIP, but could even be imrpoved based on the remaining short silences.

 

Looking at the call list in the UCC dashboard, I sometimes notice facetime marked traffic passing by. The client does not send and DSCP (0), but the ACL which is configured for S4B does mark this traffic with DSCP 46 (VoIP).

When I seetup a facetime connection is is being marked as a Skype4B session.

 

My questions:

 

- based on what values is facetime being detected by the Aruba WLAN?

- Why is my facetime connection to another person connected to the same AP recognized by Aruba WLAN as a Skype4B session?

- If facetime is being marked as 46, does this mean the video part is also marked as DSCP 46 or just the voice part?

- How to configure a separate Facetime ACL for DPI and QOS tagging?

With regards to the pauses, are all your clients on the 802.11a band or the 802.11g band sometimes?  Are you doing 20 or 40 mhz channels?

 

Facetime should typically only be classified starting with port TCP 5223 to a 17.x.x.x network (Apple).  Below is a facetime ALG:.  You really only need the ACL in bold for facetime:

 

(host) (config) #ip access-list session facetime
(host) (config-sess-facetime)#any any tcp 80 permit position 1 queue low
(host) (config-sess-facetime)#any any tcp 443 permit position 2 queue low
(host) (config-sess-facetime)#any network 17.0.0.0 255.0.0.0 tcp 5223 permit position 3 queue low classify-media
(host) (config-sess-facetime)#any any UDP 80 permit position 4 queue low
(host) (config-sess-facetime)#any network 17.0.0.0 255.0.0.0 UDP 16384 16387 permit position 5 queue low

http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-do-we-apply-QOS-for-Apple-Facetime-Traffic/ta-p/174854

 

 

I don't have the logs.tar for your network, so I cannot determine why your traffic is being misidentified. I know that Heuristics and identification improved with 6.4.4.x.  I am not sure what role facetime played with that.

 

To see if traffic is being tagged, type "show datapath session table <ip address of device>" to see if traffic is being tagged, etc.  If the client does not support DSCP tagging of traffic, the traffic will probably only tagged in a single direction (from the AP to client).

 

 

Got the specific Facetime ACL added to the config. Will do some Facetime tests tomorrow.

Regarding your questions, I'm using 6.4.4.5, got all clients (laptops, tablets, phones) on the 5Ghz band and using 20Mhz only. I've excluded all other options from the config.

Got the log.tar files created but concerned about sharing these on this 'open' forum. Any suggestions?

 

I've attached a printscreen of the facetime marked session that I noticed.

Just did a Facetime test but UCC shows Aruba defines this stream as a Skype4B session (attachement).

The classification might be misqualified due to the 17.0.0.0 network being configured in the ACL?

 

Although Facetime (iphone) does not add a DSCP value itself, the Aruba controler does and defines this session as a VoiP (in my case 46) which concerns me because now the video part is also being prioritized as VoIP potentially causing lower quality of real VoiP sessions taking place.

 

The questions that I have:

 

1- How to distinguish Facetime from Skype4B (based on todays tests, ACL with TCP 5225 and 17.0.0.0. network doesn't seem to work)

2- When testing S4B voice and video, voice session gets 46 and once video is started the session is being seen as video so prioritized as 34. Can the same be accomplished for Facetime but using Facetime specific ACL (question 1)?

 

What I also noticed during my tests is that once a S4B voice session is setup, it is correctly prioritized with 46. When a video call is setup in the same voice session, the session gets prioritized 34 within a short delay which is good and as expected. However, when terminating the video session leaving only the voice session active does not have this session prioritized back to 46 again. It stays at 34 and UCC remains defining this sesson as video even after 10 minutes.

I would expect to see this change back to a voice session once video has stopped. I might have to open a support case to address this observation and have this behaviour investigated.

Currently I'm working with Aruba engineering on a solution on this.

 

First, I had to create a specific ACL which indicated that all Facetime traffic with and its specific layer 4 communication is recognized as Facetime instead of S4B, by setting the specific internal network range of our company in the S4B rule. As Facetime always uses Apples public IP-addresses, it is now being recognized correctly as Facetime application.

 

Secondly, Facetime default behaviour is that it does setup a audio or a video session, but does no distinguish between the two. In other words, when you are having a video call with facetime, the audio part is also being marked as video. Also the DSCP value is not reverted back to the audio value when the video is terminated but the audio session still remains.

S4B does use separate streams for the audio and video part, enabling the Aruba controller to mark audio traffic with VoIP priority and video with video priority.

 

Lat but not least, the above was based on IOS 9.3.5 tests and Aruba 6.5.0.0. With IOS 10 Apple seems to have changed the way audio and video can be recognized by the Aruba Controller. Facetime audio or video session are no more being recognized by the Aruba controller., hence QOS priorities are no more being marked to these packets. so far I haven't tested other VoIP apps but hopefully this is limited to Facetime only.

This is currently under investigation by Aruba engineering.