Wireless Access

last person joined: 2 hours ago 

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
  • 1.  Zoom call woes

    Posted Oct 12, 2020 10:33 AM




    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,



  • 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 12 days ago
    This configuration can be applied in 6.x controller?

    Yogendran Parthasarathy

  • 9.  RE: Zoom call woes

    Posted 12 days ago
    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.