QoS for "Fuze" voip and conferencing

[Adrian4]

Hello,

I am trying to add DSCP tagging on our MR36's for our VOIP and video conferencing software called "Fuze" (aka 8x8).

I have this from their documentation - 

Would adding a rule of "all voip and video conferencing" (there isn't a specific definition for Fuze) with "46 EF" do the job do you think?


Thanks!

[PhilipDAth]

If your wireless devices support WMM, you shouldn't need to do anything.

Otherwise, yes.  Related articles:

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/... 

https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Wireless_QoS_and_Fast_Lane 

[GIdenJoe]

For downstream traffic it is important that the AP can classify the downstream traffic.

If fuze is not explicitly recognized then it will not apply the correct tags and in effect not place the traffic int he correct WMM queue.

However you do see UDP and TCP ports nicely shown in your table there so if NBAR can't recognize it you can add those ports to your EF rule and CS3 signaling rule.

I do not agree with the table in regards of used DSCP tagging.  CS7 is explicitly used for LAN operational protocols.
Usually voice is EF, conferencing video is AF41, signaling is CS3.

For your wireless devices however I defer to @PhilipDAth 's reply.  Your end devices need to already tag upstream traffic with the correct DSCP values to actually use the WMM queues too.

[Adrian4]

thanks for the reply.

We have MX units at the gateway. Do these automatically tag all application traffic? (we seem to just have the default rules enabled).

How can I tell if NBAR is recognizing/tagging it correctly? Do I have to capture and inspect the packets with wireshark or is there an easier way in the dashboard?

If I have to add custom definitions based on ports - how do I specify a source or destination one? destport /srcport     ? Presumably Id specify destination on downstream at the MX and source on upstream at the AP?

Thanks!

[GIdenJoe]

Hey, there is no debug feature that can show you what the MX or MR is doing with packets internally and the flow logging on the MX also won't show matching or tagging data.  So for this you would have to do some pcaps on for example the LAN port of the MX or the LAN port of the MR with the best filters to see how your traffic is being tagged upstream and downstream.  These filters won't be hard to create since you have a nice table with ports to look for.

About the matching on port.  That's a difficult one.  I'm not 100% sure if you match on port if it matches both source or destination.  And the localnet feature only supports IP addresses, not ports.  So experimentation is key here.

If the traffic comes in untagged at the MX and you choose to tag it at the MR then for downstream traffic you will only be able to identify it using OTA (over the air) captures.  To avoid any decrypting issues it is best to temporarily make an unsecured WLAN so you can actually see what's in the packets.  You can actually decrypte pre-shared key packets if you captured the 4way handshake of that client however your capturing device must then capture the full packets which does not work on for example Ekahau capture what I use.  I however tend to recognize the packets if you only use the one application on the endpoint while testing.

Since both MX and MR now can use NBAR I have to guess the application recognition would be identical so tagging the traffic on the MX is definitely a valid option.

[cmr]

@Adrian4 are you actually having issues, or just planning?  We use a lot of voice and video providers on our Meraki / Cisco networks and generally just set everything to trust DSCP.  Unless you overload links you don't usually need to do more.

[GIdenJoe]

Hey @cmr I have to respectfully disagree here.

If your VoIP provider comes in on a regular internet connection, chances are very high you won't have any layer 3 marking on your packets.  Even conferencing app's don't always get those tags.

I have to applaud @Adrian4 to do the due diligence to try to find out how the application is actually behaving.

You also have 2 points where you can have reduction of quality and that is the WAN link but also the air between the AP and the client if the client is wireless. Also upstream is the biggest issue when the network clients are not tagging the packets themselves before sending those in the air.

The whole point of making sure the markings are marked when they're not and treated correctly is to avoid support tickets due to quality and have a great experience.

[cmr]

@GIdenJoe no worries, I wasn't saying that you shouldn't do it, just sharing our experience.  I'd love for us to be in the position to get everything tagged properly, but so far we've been lucky!

[Adrian4]

Hello again.

We are indeed having issues, one way audio, crackling, delay, audio speeding up and slowing down, audio cutting out - all of it is intermittent, people can go a while without any issues at all.

Fuze support have said the application definitely tags the traffic it sends as per the table, so upstream packets arriving at the MR should be tagged. I need to add rules to make sure that traffic is prioritised.

Since Fuze is unknown to Meraki I will have to do it based on source port but I dont know how to make the custom expression.

On the MX units I will put the same rules on based on destination port to tag the downstream.

One other thing that worries me is that Fuze are adamant that their table is correct (proven) but their CS values dont seem to match merakis - for example Fuze say signalling is CS5 and meraki say CS5 is broadcast video.

When I make the rules do you think I should stick to Fuzes's version? presumably if that's how they are tagging stuff then it doesnt matter if its wrong so long as my rules match?

[GIdenJoe]

So yes there is a difference between Cisco and other vendors where they tag signaling traffic CS3 instead of CS5.  So the tables will be different.  However that is signaling traffic which means when you pick up your phone, when you dial.  The realtime traffic however should be DSCP46 = EF.
So to verify if the application tags it's own traffic from the server downstream if that server is on your Meraki LAN you could verify by capturing packets on the port entering.  Else if it's not anything could happen over the internet.  So then you'll have to capture at the LAN port of your MX to see if the traffic is tagged and then check again at the switchport leading up to the AP and on the wired port of the AP itself if the tag is still there.

If the tagging is already correct then the AP will match a corresponding WMM tag to your traffic and use the appropriate timings.  You could still check by doing an OTA to see if that is the case.  However if the tagging is gone or incorrect then you will have to add the tagging yourself using the tools you have.  Btw you cannot capture downstream wireless traffic on the same Meraki AP where the traffic is flowing through.  Only upstream traffic is captured.  However you could use a second AP on the same channel close to your testclient to do the full capture.

For upstream traffic you will have to check because if the clients are windows OS devices then chances are your app may tag the traffic but windows just strips them again before sending it up to the NIC.  Then you'll have to play around with windows GPO's to fix that.

[Adrian4]

It's not just CS5....

Cisco tagging 

Fuze Tagging

also - I just found this;
https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Wireless_QoS_and_Fast_Lane

"

Default Upstream QoS

Meraki Access Points honor all upstream QoS sent by the client. Clients have defaults for WMM AC and the DiffServ value for different traffic classes. Please refer to vendor documentation for more details on QoS specifics for traffic sent by the client. The DiffServ field within Ethernet traffic sent from the client will be maintained when the AP forwards it onto the Ethernet network. 

If the AP receives traffic with no QoS markings from the client, it will apply DSCP markings according to configured traffic shaping rules before forwarding the traffic onto the Ethernet network. "



Does this mean, that assuming Fuze is tagging according to their table, that there is nothing I need to do for the upstream? I assuming that traffic being tagged isnt enough, I at least need a rule to tell Cisco to prioritise the tag right?

So would making a rule "all voip and video conferencing" with a PCP of 7 do the job?

[GIdenJoe]

Well for upstream their tagging is a bit wrong.  So CS7 is network control (stuff like spanning-tree and all that)  They should tag video with AF41 and voice with EF.  However you can't control what they send in the air.

So if they send upstream voice using CS7 that means it will be mapped to a WMM queue AC_VO and have the shortest timing.  However if you don't configure it the tag will remain at CS7 throughout your network which in fact should be changed to AF41 or EF depending on the type.  You can verify by capturing on the wired port on the AP or the switchport connecting it.  The PCP tag should be set to 6 for video and 5 for video so downstream voice goes into AC_VO and downstream video goes into AC_VI.  The reason for this distinction is that video is heavier and gets more TxOP time than audio does.  But audio has the lowest wait times so it should be statistically more responsive.

So in effect:  Please do configure port matching for voice and video in two separate rules if the application uses different ports for that.  For the voice use marking EF and PCP6, for the video use marking AF41 and PCP5.  You can also match on signaling and put that on CS3 and PCP3.

Once that is succesful and tested you will have to do multiple tests and if you can reproduce the problem you'll have to determine if it's at the WiFi AP or at the internet circuit where the congestion is happening.

[Adrian4]

Thank you for the reply but I am getting a bit lost. I tried asking Meraki support but they have not been ,much help - how exactly do you port match in the traffic shaping rules?

When choosing a custom expression the only term I have been able to find is "localhost" to specify a IP.

Also - out of interest why do we not use PCP 7 which has the highest priority?

Thanks!

[GIdenJoe · Accepted solution]

Entering custom ports:

To match you just need to enter the port numbers in a custom expression.  The GUI will add port in front of it.  You can use both individual ports and portranges with a dash.

Understanding wireless WMM queues:
In QoS for wireless you have 4 queues or access categories as they are officially named.  Background (AC_BK)
Best effort (AC_BE)
Video (AC_VI)
Voice (AC_VO)
Packets tagged with PCP 1 or 2 go into AC_BK.
Packets tagged with PCP 0 or 3 go into AC_BE
Packets tagged with PCP 4 or 5 go into AC_VI
Packets tagged with PCP 6 or 7 go into AC_VO
There is no real operational difference between both values but normally you use 6 for voice and 7 for network control.  It's just a nitpicky thing 😉  But further in the wired part of the network you need to use the correct DSCP tags for your traffic because alot depends on the operation of your network itself.  You don't want your network to lose spanning-tree, OSPF or UDLD packets which are necessary to keep your network running to voice packets which is why these should be the highest prio.

Traffic shaping rules strategy:
Use one rule for each tagging and bandwith shaping result and put all your matches in those.  They are always OR, never AND.  So I mean one rule for all voice traffic that needs AC_VO and DSCP 46 (ignore bandwith limit if any).  One rule for video conferencing which gets AC_VI and AF46 also ignore bandwith limit if any).  Then go down to your useful business but latency insensitive traffic, then your unwanted low prio traffic (with limitation) and at the end the rest which you can't match.

Please have a good read here: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

[Adrian4]

Sorry, one last question - how do you specify if its a source or destination port?

EDIT - nevermind, I see its destination only 😄

[Adrian4]

thanks!