topic Re: Setting up QOS for Voice Vlan in Switching

Setting up QOS for Voice Vlan

jacksonwoods4923 — Fri, 03 Nov 2023 19:48:17 GMT

We just installed some IP-Phones and we are hearing some calls cutting in and out. Talked to the provider and they said that enabling QOS could possibly help. Could I get some guidance with this, I have tried to look into Auto-QOS and tried to set it up, but I am not sure I am doing it correctly? We have 2960X and 2960XR switches.

On all my trunk ports I have

switchport mode trunk
switchport nonegotiate
srr-queue bandwidth share 1 30 35 5
priority-queue out
mls qos trust cos
auto qos trust

On my ports that have the phones

switchport access vlan 616
switchport mode access
switchport nonegotiate
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
switchport port-security
srr-queue bandwidth share 1 30 35 5
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
macro description ACCESS
auto qos voip cisco-phone
spanning-tree portfast edge
spanning-tree bpduguard enable
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY

Any help is appreciated!

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Fri, 03 Nov 2023 20:45:22 GMT

Are you using Cisco VoIP phones?

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Sat, 04 Nov 2023 01:22:44 GMT

They are called Clearly IP Phones. I guess now that you say that, they are not a cisco-phone.

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Sat, 04 Nov 2023 03:35:44 GMT

Okay, the two problems with using Brand X VoIP phones.

First problem: Cisco's AutoQoS might not treat them as VoIP phones (for QoS purposes); if not AutoQoS can be amended.

Second problem: You would need to determine what QoS tagging capabilities these VoIP phones have, and how to configure that UNLESS you only have those phones on specific ports. (In the latter, we can trust the port.)

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Sat, 04 Nov 2023 16:07:28 GMT

Im not sure if this would help the first problem case, I had assumed that the Cisco Phone would work because the Clearly phones show up as CDP neighbors. For the second issue, we have some of the phones on designated ports, and they are able to do passthrough as well, and we use the cisco voip vlan for tagging the voip traffic vs the data from the desktops. New here, Sorry if I do not make any sense. Thanks for the help!

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Sat, 04 Nov 2023 17:18:43 GMT

Cisco's AutoQoS is a "work in progress". It doesn't change often, but it has "evolved" over time and what it actually does also depends on the QoS features of the device. I.e. to see what AutoQoS considers a VoIP phone, you need to examine what configuration it generates.

It's possible a "Clearly" VoIP phone operates like a true Cisco VoIP phone, but I'm unfamiliar with them.

With AutoQoS, again, without examining what it generates, cannot say how it might be impacted by "Brand X" VoIP phone on ports configured with a voice VLAN, in addition to a data VLAN, vs. ports configured directly in the voice VLAN.

(NB: My experience in large Enterprises has been extensive both in QoS and using VoIP phones, but without using AutoQos and seldom using Cisco VoIP phones.)

In principle, you should be to provide preferential for your VoIP traffic. How it can be done, varies. AutoQoS, from the beginning, was designed to provide preferential treatment for VoIP traffic, although use Cisco VoIP phones. When use Brand X VoIP phones, you may need to amend AutoQoS; which is doable. Your next step if to find out how closely your Cleary VoIP phones mimic Cisco VoIP phones.

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Sat, 04 Nov 2023 22:45:04 GMT

Okay, well if I don’t use AutoQOS and tried to do it manually, how would I go about starting that? I would have to label the voice traffic right? And then trust ports upstream? What if someone else manages our WAN, would I have to let them know or would the tag stay with the traffic?

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Mon, 06 Nov 2023 15:55:56 GMT

Although, as mentioned, I don't use AutoQoS, for multiple reasons, not using AutoQoS requires a better/deeper understanding of QoS.

For just VoIP, unlikely you'll do much "better" than AutoQoS. (For other than VoIP, that's a different debate.)

For you, again concerning just VoIP, cannot say whether AutoQoS is better or not.

Actually, on 2960 switches, disabling QoS, altogether, might be a good option too.

Understand, network congestion can be adverse to network traffic, but do we know that's happening for you?

If you do have adverse network congestion, two mitigation approaches are providing more bandwidth and/or using QoS. (NB: practically any congestion issue can be solved adding bandwidth, but possible at silly expense which QoS might solve at trivial expense.)

So, perhaps we should try to determine if you have adverse congestion. Do any switch interfaces show drops?

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Mon, 06 Nov 2023 16:22:02 GMT

Int 1/0/47 is the uplink to WAN.

Int 1/0/48 is trunk to MDF stack with phones.

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Mon, 06 Nov 2023 16:45:05 GMT

Ah, some drops. That indicates congestion on those port, servere enough to overflow egress queue(s). NB: drops, alone, don't guarantee a problem, not lack of them guarantee no problem, but often start analysis on ports with drop.

Can you provide a topology diagram, and explain more about WAN? (WANs are often bottlenecks and need QoS.)

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Mon, 06 Nov 2023 21:03:15 GMT

We have another company manage our WAN and the WAN switches. All traffic from the locations flows towards the central office. Sorry if this is sub par drawing.

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Mon, 06 Nov 2023 21:05:38 GMT

The company that manages our WAN has taken a look, they mentioned that the Uplink to our ISP, 2 bonded 1-gig links, at the Central Office is peaking 99% utilization multiple times a day. This is most likely the issue?

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Tue, 07 Nov 2023 00:00:59 GMT

Does you VoIP traffic use the ISP path?

Where does your VoIP traffic flow?

If across your "WAN", that could be the trouble spots, again, as WANs tend to often had much less bandwidth.

BTW, even with 100% continuous bandwidth consumption, with QoS, such consumption can be a non-issue. For example, years ago, we had a couple of WAN links that ran at 100% all day long, during business hours. Ran all kinds of traffic across those links. QoS insured traffic like VoIP got the bandwidth it needed. (Incidentally, what caused the links to be so saturated, an application was installed to do constant backups of user PCs. Within QoS, that traffic only received left over or unused bandwidth, but that's what drove the links to 100%.)

Conversely, low average bandwidth consumption and/or no drops doesn't guarantee you don't have an issue because of the adverse impact of one traffic type to another during "microbursts". Usually you have sporadic issues with some "sensitive" traffic kinds (like VoIP), but often this is "invisible" to common network monitoring.

From decades of experience, if your VoIP traffic is crossing WAN links, I would analyze those first. Unfortunately, many network engineers (i.e. your WAN management provider) are not used to dealing with performance at the millisecond level, so often it's a uphill battle with them until you rub their nose in the problem. SLA tests can be useful to document the issue.

Often when a performance issue is recognized, the typical offered solution is, you need more bandwidth. Truthfully, you may, but many times QoS is a "better" solution. (Understand, if your bandwidth is such that no link can be oversubscribed, you're golden. But, that's very, very unusual. For example, if you have a switch with 48 ports, the uplink would need 48x the bandwidth of one of those ports to not be oversubscribed. Consider doing more of that at every level.)

Also, unfortunately, a WAN provider is often used to offering (selling) more bandwidth, not usually experienced in better management of your bandwidth.

One example I used to do, to demonstrate the "power" of QoS, I would setup a pair of routers, back-to-back, using a T1 serial, and ping and/or telnet between them. All fine.

I would then connect a host to one router, and blast 2 Mbps of traffic across the 1.5 Mbps T1. Pings, if they got across at all, had horrible response time, telnet became practically unusable.

Then, I activated FQ on serial interface, i.e. added just one interface command. Ping and telnet performance almost returned to the performance before I started the additional traffic stream, which was still running the link at 100% with a huge drop rate.

What I showed, was unlikely to happen real world, but the performance improvement that QoS provided, also works at the millisecond level, and all it took was one interface command. Of course, if I replaced the 1.5 Mbps with a link that could handle 3 Mbps or better (BTW, 2 Mbps or so, still very likely to see issues), should also restore ping/telnet performance. However, typically increasing WAN bandwidth is rather expensive compared to adding one additional interface configuration statement.

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Tue, 07 Nov 2023 18:38:11 GMT

I gotcha, where do I start with manually setting up QOS for VOIP traffic? I have read a little bit where I guess I would need to "classify" the traffic first, but what is the best way?

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Tue, 07 Nov 2023 21:10:10 GMT

First, you'll need to figure out how to "recognize" your VoIP traffic vs. other traffic. "Classification" as you mention. Often VoIP phones will tag their traffic, and might be configurable what tags you want them to use. Given a choice, chose L3 tagging vs. L2 tagging.

If the VoIP phone can tag their traffic, if they cannot tag as you desire, you may want to retag the traffic. Also, you want to determine whether you'll want to further verify VoIP tags (to preclude some other application using the tags that you don't want).

You'll want to then determine what your QoS policy will be. Usually, VoIP bearer traffic is given dequeuing priority all other traffic, but it might (optionally) be restricted that it cannot consume all bandwidth with such absolute priority.

You'll also want to determine treatment for VoIP control traffic. "By-the-book", generally you only need to insure the traffic isn't dropped, unlike the VoIP bearer traffic which has timing requirements too. However, since the control traffic is usually very light in its bandwidth needs, sometimes its just treated at VoIP bearer traffic (including using the same markings).

Once you know how to identify your traffic, and how to treat it, you just then need to configure your devices to do it.

The 2960 series has 4 egress queues, which, I recall, by default, direct different tags into different classes. Your QoS will only need two classes, VoIP and everything else.

The VoIP class would be directed to the first egress queue which supports absolute queuing using the "priority-queue out" interface command (appears to have been already configured by AutoQos).

I recall the 2960 series, by default, has QoS disabled, but here too, likely AutoQoS has enabled it.

From what you posted, you should remove the following interface statements:

mls qos trust cos auto qos trust mls qos trust device cisco-phone auto qos voip cisco-phone service-policy input xxx

You will need a trust or input service policy, but specifically what you need depends on how the edge VoIP traffic will be accepted.

Re: Setting up QOS for Voice Vlan

jacksonwoods4923 — Thu, 30 Nov 2023 13:47:45 GMT

I saw a video today, would this work? Since I know where the issue is, could I set an ACL with the subnet of the phones, use the ACL to Match-Any in a class-map, and then set a policy map to retain a certain bandwidth of the link. I sure appreciate your help.

Like :

ip access-list extended Phones

permit ip 10.60.1.0 0.0.0.255 any

permit ip any 10.60.1.0 0.0.0.255

class-map match-any Phone-Traffic

match access-group name Phones

policy-map Phone-Policy

class Phone-Traffic

bandwidth percent 3

int gig 0/1

service policy out Phone-Policy

Im sure this is not the best, but could this work? In your opinion, what would be the best way I could test QOS policies? Do i need to get some old hardware? Or are there online options that would allow me to see congestion?

Re: Setting up QOS for Voice Vlan

Joseph W. Doherty — Thu, 30 Nov 2023 16:38:00 GMT

I think (?) all the 2960 models still use MLS QoS, not MQF syntax QoS, like what you've posted.

What do you have in mind for "testing" QoS policies? Generally, QoS works as configured on Cisco platforms.

In "normal" network, "seeing" congestion can often be difficult, as it's sporadic and might only last part of a second. Sometimes variable ping times is a visible attribute of occasional sporadic congestion.