Configure Voice Queue

[shrikantchi]

Dear All,

I have a question regarding voice configuration. We have C9200 cisco switch. I want to understand configuration see below configuration.

class-map match-any system-cpp-police-ewlc-control
description EWLC Control
class-map match-any AutoQos-4.0-Output-Multimedia-Conf-Queue
match dscp af41 af42 af43
match cos 4
class-map match-any system-cpp-police-topology-control
description Topology control
class-map match-any system-cpp-police-sw-forward
description Sw forwarding, L2 LVX data packets, LOGGING, Transit Traffic
class-map match-any AutoQos-4.0-Output-Bulk-Data-Queue
match dscp af11 af12 af13
match cos 1
class-map match-any system-cpp-default
description EWLC data, Inter FED Traffic
class-map match-any system-cpp-police-sys-data
description Openflow, Exception, EGR Exception, NFL Sampled Data, RPF Failed
class-map match-any AutoQos-4.0-Output-Priority-Queue
match dscp cs4 cs5 ef
match cos 5
class-map match-any system-cpp-police-punt-webauth
description Punt Webauth
class-map match-any AutoQos-4.0-Output-Multimedia-Strm-Queue
match dscp af31 af32 af33
class-map match-any system-cpp-police-l2lvx-control
description L2 LVX control packets
class-map match-any system-cpp-police-forus
description Forus Address resolution and Forus traffic
class-map match-any system-cpp-police-multicast-end-station
description MCAST END STATION
class-map match-any system-cpp-police-high-rate-app
description High Rate Applications
class-map match-any system-cpp-police-multicast
description MCAST Data
class-map match-any system-cpp-police-l2-control
description L2 control
class-map match-any system-cpp-police-dot1x-auth
description DOT1X Auth
class-map match-any system-cpp-police-data
description ICMP redirect, ICMP_GEN and BROADCAST
class-map match-any system-cpp-police-stackwise-virt-control
description Stackwise Virtual OOB
class-map match-any non-client-nrt-class
class-map match-any system-cpp-police-routing-control
description Routing control and Low Latency
class-map match-any system-cpp-police-protocol-snooping
description Protocol snooping
class-map match-any AutoQos-4.0-Output-Trans-Data-Queue
match dscp af21 af22 af23
match cos 2
class-map match-any system-cpp-police-dhcp-snooping
description DHCP snooping
class-map match-any system-cpp-police-ios-routing
description L2 control, Topology control, Routing control, Low Latency
class-map match-any system-cpp-police-system-critical
description System Critical and Gold Pkt
class-map match-any AutoQos-4.0-Output-Scavenger-Queue
match dscp cs1
class-map match-any system-cpp-police-ios-feature
description ICMPGEN,BROADCAST,ICMP,L2LVXCntrl,ProtoSnoop,PuntWebauth,MCASTData,Transit,DOT1XAuth,Swfwd,LOGGING,L2LVXData,ForusTraffic,ForusARP,McastEndStn,Openflow,Exception,EGRExcption,NflSampled,RpfFailed
class-map match-any AutoQos-4.0-Output-Control-Mgmt-Queue
match dscp cs2 cs3 cs6 cs7
match cos 3
!
policy-map AutoQos-4.0-Output-Policy
class AutoQos-4.0-Output-Priority-Queue
priority level 1 percent 30
class AutoQos-4.0-Output-Control-Mgmt-Queue
bandwidth remaining percent 10
queue-limit dscp cs2 percent 80
queue-limit dscp cs3 percent 90
queue-limit dscp cs6 percent 100
queue-limit dscp cs7 percent 100
queue-buffers ratio 10
class AutoQos-4.0-Output-Multimedia-Conf-Queue
bandwidth remaining percent 10
queue-buffers ratio 10
class AutoQos-4.0-Output-Trans-Data-Queue
bandwidth remaining percent 10
queue-buffers ratio 10
class AutoQos-4.0-Output-Bulk-Data-Queue
bandwidth remaining percent 4
queue-buffers ratio 10
class AutoQos-4.0-Output-Scavenger-Queue
bandwidth remaining percent 1
queue-buffers ratio 10
class AutoQos-4.0-Output-Multimedia-Strm-Queue
bandwidth remaining percent 10
queue-buffers ratio 10
class class-default
bandwidth remaining percent 25
queue-buffers ratio 25
policy-map AutoQos-4.0-Trust-Cos-Input-Policy
class class-default
set cos cos table AutoQos-4.0-Trust-Cos-Table
policy-map system-cpp-polic

And on interface level configuration is .

interface GigabitEthernet1/0/2
description Phones
switchport access vlan 20
switchport mode access
auto qos trust
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
service-policy input AutoQos-4.0-Trust-Cos-Input-Policy
service-policy output AutoQos-4.0-Output-Policy

Could you please explain? how it works. We have VOIP from Zoom and their phones. My voice VLAN is 20

Thanks for help in advance.

ShrikantCMi.

[M02@rt37]

Hello @shrikantchi,

Regarding your output, this configuration is to prioritize voice traffic from VoIP phones and allocate sufficient bandwidth to ensure voice quality. Different classes are defined to handle various types of traffic, such as voice, multimedia, control, bulk data, and others...

Class maps define how traffic is classified based on certain criteria. In your configuration, you have several class maps (e.g., AutoQos-4.0-Output-Multimedia-Conf-Queue, AutoQos-4.0-Output-Bulk-Data-Queue, etc.), each designed to match specific types of traffic based on either DSCP values or CoS values.

For example, AutoQos-4.0-Output-Multimedia-Conf-Queue matches traffic with DSCP values af41, af42, and af43.

Policy maps define how traffic is treated within certain classes. You have a policy map named "AutoQos-4.0-Output-Policy" that contains classes for various types of traffic. Each class is assigned a specific amount of bandwidth and queue settings. For example, the "AutoQos-4.0-Output-Priority-Queue" class is given a high priority with 30% of the bandwidth, while the "AutoQos-4.0-Output-Scavenger-Queue" is given a lower priority with only 1% of the bandwidth.

Service policies are applied to interfaces to control how traffic is treated on those interfaces. In your case, you're applying the "AutoQos-4.0-Trust-Cos-Input-Policy" as an input service policy and the "AutoQos-4.0-Output-Policy" as an output service policy on interface GigabitEthernet1/0/2. These policies effectively implement the QoS settings defined in your policy maps for incoming and outgoing traffic on this interface.

-- auto qos trust command is used to trust the incoming CoS and DSCP values on the interface. This is important for ensuring that traffic is correctly classified and prioritized based on its markings.

[shrikantchi]

Dear M02@rt37,

Thanks for the explanation. I was watching videos on YouTube. First, you create a class and then add a matching condition and then apply it to the policy and then you can apply it to the interface.

When you define a class, then you have to give it a name and under that class, you can create all your match conditions.

Here, how many classes are defined? How many policies are defined? Which one is specifically for Voice?

Thanks in advance and your help.

[Joseph W. Doherty]

Re:  How it works.

Ingress policies generally attempt to recognize kinds of traffic, e.g. voice.  While egress policies attempt to insure different kinds of traffic obtain the network resources needed by each kind of traffic, for example, for voice, the goals are to not delay or drop its packets.

Regarding Zoom, specifically, you would need to know how Zoom tags its packets by default and possibly by its configuration and what are the QoS configurations for all transient network devices.

In your OP you post one device's network policies and one interface config, so we might explain what QoS behavior on the one port BUT how is the Zoom traffic tagged by the app, and/or along the network path to the posted port?

[shrikantchi]

Dear Joseph,

We have Zoom Phone. Is there any specific value for Zoom Phone and if yes, then how do I find out?

In our company, we use Zoom desk phones and softphones. We do video chat and audio through Microsoft Teams.

Do you have any suggestions?

Thanks, in advance.

[Joseph W. Doherty]

Sorry, I'm unfamiliar with Zoom Phones and/or Microsoft Teams.

Both, though, should come with some form of admin guide which should have a section on QoS.  What such sections usually describe is recommended QoS treatment, defaults the device/app will use for CoS(L2)/ToS(L3) tagging, whether you can change tagging settings, etc.

Cisco's AutoQoS is a based on (current) Cisco's QoS model (which is a minor variation of the RFC QoS recommendations).  If the devices/apps are also using RFC recommends markings, good chance AutoQoS will (somewhat) treat your traffic as needed.  However, although recommended markings are likely to be used between Cisco AutoQoS and devices/apps, how much bandwidth to actually allocate is but a "guess" on Cisco's AutoQoS part, unless you run your Cisco's devices for a few days using AutoQoS discovery.

One other area you need to watch for, Cisco's AutoQoS (I recall?) sort of assumes Cisco VoIP phones are being used, which validate themselves via CDP.  I.e. Cisco's AutoQoS, without manual modification (which it supports) might not "accept" other than Cisco VoIP phones as being legitimate sources for VoIP traffic.

NB: As AutoQoS can be manually modified and has changed over the years and might vary between devices, I cannot predict what AutoQoS will do without seeing the current QoS settings on a device.

As an aside . . .

Personally, I've never used AutoQoS, for multiple reasons.

However, starting with the very first AutoQoS variant, if using Cisco VoIP phone, your VoIP traffic will usually obtain the QoS treatment it needs to work well.

[Giuseppe Larosa]

Hello @shrikantchi ,

>> My voice VLAN is 20

If we look at your interface configuration we see:

interface GigabitEthernet1/0/2
description Phones
>>>> switchport access vlan 20
switchport mode access

This configuration can be used if your phones have no PC port to connect a PC downstream of them. In addition with this configuration frames in Voice Vlan 20 are received untagged with no 802.1Q header and this means no CoS bits to trust .

The autoqos config in input attempts to trust or map the CoS bits to a CoS table but your frames are untagged without a CoS field in them so I am not sure they are correctly treated the switch port should trust the DSCP instead

As noted also @Joseph W. Doherty  AutoQoS is generally good when using Cisco IP phones so how it behaves with Zoom phones it is not clear.

Hope to help

Giuseppe

[Joseph W. Doherty]

"In addition with this configuration frames in Voice Vlan 20 are received untagged with no 802.1Q header and this means no CoS bits to trust."

What @Giuseppe Larosa wrote is 100% correct, but also understand CoS and/or ToS tagging isn't required for QoS to operate.  Conversely, CoS and/or ToS tagging, alone, does not guarantee QoS treatment.  Tagging is just an efficient (shortcut) for frame/packet identification for QoS purposes.

Also BTW, its possible to use VLAN CoS, on some Cisco devices, without an access port "voice" VLAN, if you use encapsulation priority-tagged.

I also personally recommend to always use L3 ToS, and avoid using L2 CoS, unless you cannot use L3 ToS.

". . . I am not sure they are correctly treated the switch port should trust the DSCP instead"

Although CoS and ToS can be used concurrently, and often are, they might not "agree" on QoS handling.  Which to chose, is one of the reasons I suggest not using CoS at all.

". . . AutoQoS is generally good when using Cisco IP phones so how it behaves with Zoom phones it is not clear."

Also, it's possible (excluding CDP considerations?) you might be able to configure Zoom phones to generate frames tagged like a Cisco VoIP phone would, but as noted above, QoS doesn't even need to use CoS/ToS tags and possibly Zoom frames/packets look very much unlike Cisco VoIP phone frames/packets, which may, or (hopefully) may not, be a problem.  Again, even AutoQoS configs can be manually tailored.  (Personally, if you need to start tailoring AutoQoS, why not just write your own QoS policy - which, in my experience, can be less complex, and even more effective; one of the reasons I don't use it.)