Cisco Catalyst 9300 QoS phone call choppy

[kevirami]

Hello all, 
The Phone calls work perfectly before applying the QoS but get choppy after applying. 
I am currently applying QoS on Cisco 9300 access switches but the phone calls are cutting in and out (Choppy). I am using Cisco phones. Below are the configurations for 2 access switchports and the trunk ports for each. 

Access Switchport Int Gig x/x/x **This configuration on both sides**
Switchport access vlan xx
switchport mode access
switchport block unicast
switchport voice vlan xx
trust device cisco-phone
storm-control broadcast level bps 20m
storm-control unicast level bps 62m
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source

Trunk ports:
switchport trunk native vlan xx
switchport trunk allow vlan xxxx
switchport mode trunk
switchport nonegotiate
ip arp inspection trust
udld port
ip dhcp snooping trust
service-policy output QoS_POLICY_SWITCHPORT

QoS Configuration:
Class-map match-all C2_VOICE
     match ip dscp 47
class-map match-all VOICE
     match ip dscp ef
class-map match-all VIDEO
     match ip dscp af41
class-map match-all PREFFERED_DATA
     match ip dscp af33

Policy-map QoS_POLICY_SWITCHPORT
class C2_VOICE
     priority level 1 10
class VOICE
     priority level 2 15
class VIDEO
     bandwidth percent 25
class PREFFERED_DATA
     bandwidth percent 25
class class-default
     bandwidth percent 25
exit

Thank you!

[Joseph W. Doherty]

Insufficient information.

I will say, some aspects of your QoS configuration are unusual, but cannot say they are actually detrimental.

[kevirami]

Joseph, 
As far as applying the QoS service-policy output, I only have that command on the trunk ports connecting to the distribution switch. I have no QoS anywhere on the distribution switch or towards the router. QoS is only enabled on the access switches. Should that be the case? 

[Joseph W. Doherty]

As @chrihussey notes "QoS should be end to end".

That's the "book" answer, and it's not bad advice.

Actually, though, QoS is only really needed where there's sufficient congestion that's adverse to the performance requirements of your traffic.  This also assumes, QoS can remediate such situations, which isn't always the case.

Of course, having QoS end-to-end, sort of insures, at least, every possible congestion point is ready to use QoS to remediate adverse congestion, if possible.

When I initially wrote there's insufficient information, such information would include what's happening at every interface, end-to-end. Such information would also include what your service goals are.  What are your markings for.  (For example, what's C2 Voice traffic with a unusual value of 47?)  The intent of unicast storm control, etc., etc.

I will mention, many low end Catalyst switches, default buffer settings for QoS, often drop traffic prematurely.  However, without more information, cannot whether that's a problem for you.

Basically, rather difficult to diagnose your issue, as it can be caused by so many things.

What I would suggest, is trying to find a local consulting network engineer with expertise in VoIP and/or QoS.

[chrihussey]

Hello - QoS should be end to end. From access port, across all trunk and network links to the final destination. 

[Leo Laohoo]

Post the complete output to the following command: 

sh run | include queue-softmax-multiplier

[kevirami]

**WORK AROUND**
Thank you all for the help/posts. I have identified the issue using Auto QoS. I enabled Auto QoS on the access/ports since they automatically configure class-maps and policy-maps. I was able to see packet matches with the command "show policy-map interface x/x/x". I believe the reason my original configuration using the MQC was not working is that I was not matching for COS 3 which the Auto QoS was matching. I'm not entirely sure but at the moment I cannot test it to validate.

Class-map: AutoQos-4.0-Voip-Signal-CiscoPhone-Class (match-any)
      5 packets
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs3
      police:
          cir 32000 bps, bc 8000 bytes

QoS is working fine with Auto QoS on the Access ports:  

auto qos voip cisco-phone

 And Auto QoS trust on the Trunk ports. 

auto qos trust

[Joseph W. Doherty]

Great to read!

I had thought to suggest AutoQoS, as the one thing it usually does well is VoIP.  However, again for lack of information, and seeing your existing, somewhat unusual, policy, I was concerned about all your other, non-VoIP, traffic.  AutoQoS might be adverse to that traffic.