Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Zoom call woes

Jump to Best Answer
This thread has been viewed 73 times
  • 1.  Zoom call woes

    Posted Oct 12, 2020 10:33 AM

    Hello,

     

    AOS 8.6.0.5

    Cluster (10 MDs)

    6,500 APs

     

    We are getting reports of users having issues with videoconferencing, this seems to be particularly bad for Zoom users. It's the start of term so there's a lot of 'noise' and it's hard to know what are real issues and what are the usual kinds of end user problems. But it has prompted us to look at what we can do to mitigate this kind of thing.

     

    I'm new to the classification side of things, I know UCC is designed to help with this. Is there anything we can/should do a) specifically for Zoom? b) in general for video calls and the like (eg is there a VRD for this? I couldn't see one).

     

    Thank you,

     

    Guy



  • 2.  RE: Zoom call woes

    Posted Oct 12, 2020 11:47 AM

    There are some improved classifications for Zoom in 8.7, but it only identifies it, it does not provide QOS that I am aware of.

     

    If you wanted to do this the quick and dirty way, I would define a netdestination of *.zoom.us and prioritize traffic to and from that destination.

     



  • 3.  RE: Zoom call woes

    Posted Oct 12, 2020 06:55 PM

    Thanks Colin, that's very useful. We might try that as it looks like this is a problem at the moment.

     

    So would we set the queue to high for that destination in an ACL (I'm just looking at an existing facetime-acl on the system)?



  • 4.  RE: Zoom call woes
    Best Answer

    Posted Oct 12, 2020 07:11 PM

    This is a sample of what I have:

     

     

    config t
    netdestination zoom
        description "Zoom"
        name *.zoom.us
    ip access-list session zoom
        any alias zoom any permit disable-scanning queue high tos 46 dot1p-priority 7 
     alias zoom any any permit disable-scanning queue high tos 46 dot1p-priority 7 
    user-role Production
        access-list session global-sacl
        access-list session zoom
        access-list session allowall
    

     

     

    This would only mark the QOS from the AP to the client.  If you have other problems going on with your wireless, this is not a silver bullet.

     

    You can type "show firewall dns-names" on the MD to see if it is indeed learning all of the zoom URLs ip addresses  to mark the traffic properly.

     

    You could also choose a client and type "show datapath session table <ip address of client>" on the MD to see if any traffic is being marked with the dscp markings above.



  • 5.  RE: Zoom call woes

    Posted Oct 13, 2020 04:11 AM

    This is great, thanks for the details Colin, we'll try that out.

     

    Just one more quick question - as the SSID is tunnelled does that mean QoS on the switchport (of the switch the AP is connected to) is irrelevant?



  • 6.  RE: Zoom call woes

    Posted Oct 13, 2020 04:17 AM

    The outer header of the GRE frame will have the QOS marking when it is on the wired network.  If your wired network is configured to grandfather and prioritize packets marked with QOS, that traffic will also be prioritized on your wired network.  The configuration I posted will provide QOS on the wireless medium which is the primary point of contention.  You would also have to configure your wired network, as stated, to provide proper end-to-end QOS.



  • 7.  RE: Zoom call woes

    Posted Oct 13, 2020 04:23 AM

    Ok, that's great, unfortunately we're in a federated environment, so only in control of some LANs, so I guess there's a limit to what we can do in those cases. We'll try your config as a starter. I think there is some QoS config on the switches we manage, so we may be good there.

     

    Thanks again



  • 8.  RE: Zoom call woes

    Posted Nov 19, 2020 12:10 PM
    This configuration can be applied in 6.x controller?

    ------------------------------
    Yogendran Parthasarathy
    ------------------------------



  • 9.  RE: Zoom call woes

    Posted Nov 19, 2020 12:18 PM
    The configuration is the same, but if you have poor RF, this will add only a cosmetic benefit.  You need to ensure that clients in class are not dropping more than 2/10 pings to their default gateway to be conservative.  If that is happening, the RF of your environment needs to be fixed first.  The configuration above is to further prioritize traffic, not solve RF problems.

    ------------------------------
    Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
    ------------------------------



  • 10.  RE: Zoom call woes

    Posted Feb 18, 2021 10:53 AM
    I suggest you to have a look at this link for Zoom QoS marking. This might be a good starting point. Maybe you need to adjust your ACL with those value.
    Zoom QoS DSCP Marking

    Also you can look at enabling AirSlice if you have the newer ax APs (5xx series) and planning to upgrade to 8.7. AirSlice support Zoom by default.
    AirSlice-TechNote

    Here's also a good article from acmxguy on how to configure and troubleshoot AirSlice
    Aruba AirSlice - IAP Configuration and Troubleshooting

    ------------------------------
    Mathieu Champagne
    ------------------------------



  • 11.  RE: Zoom call woes

    Posted 21 days ago
    Hi Colin,

    Can you explain the difference between your config and mine, specifically what the "disable-scanning" means?

    Building Configuration...
    netdestination zoom
    name *zoom.us
    ip access-list session zoom-tos
    any alias zoom any permit queue high tos 46 dot1p-priority 7

    ------------------------------
    Brian Simpson
    ------------------------------



  • 12.  RE: Zoom call woes

    Posted 21 days ago
    https://community.arubanetworks.com/blogs/shyam-moolayilkalarikkal1/2014/07/07/how-do-i-disable-arm-scanning-for-a-particular-service

    ------------------------------
    Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
    ------------------------------