QoS configuration - can someone check my work?

[Jesse_Ohlsson]

We're an Extreme shop, and I'm the new-ish engineer here. I'm tasked with configuring up a replacement X440 switch stack to replace some old Cisco 3560 switches. I was taking configuration queues from one of our existing Extreme user access
switch stacks. In so doing, I think our existing QoS configurations are incomplete.

Here is what I found in the existing stack from which I'm duplicating configurations:
The switch has two QoS profiles created by default: QP1 and QP7. On this switch, two additional QoS profiles were created:

create qosprofile "QP5"

create qosprofile "QP6"



Then, the QoS profiles QP1, QP5, and QP6 were applied to all ports:

configure qosprofile QP1 minbw 0 maxbw 20 ports 1:1-48,2:1-47,3:1-47,4:1-47

configure qosprofile QP5 minbw 0 maxbw 100 ports 1:1-48,2:1-47,3:1-47,4:1-47

configure qosprofile QP6 minbw 0 maxbw 100 ports 1:1-48,2:1-47,3:1-47,4:1-47

On this stack, ports 1:48, 2:48, 3:48, and 4:48 are a LAG for the switch uplinks.

That seems a curious configuration, since the default profile QP1 is now limited to using a maximum of 20% of an egress port available bandwidth. Also, by defining no minimums, it is possible for traffic in QP5 or QP6 to take all available port bandwidth.

Later, the switch uses LLDP to instruct the VoIP phones to tag voice traffic with VLAN 606, and mark it with DSCP 63, the highest possible value for DSCP. From what I've used elsewhere and what I've read about it, VoIP traffic, while it needs certain minimums, isn’t the highest priority of packets, and doesn’t need to be stamped with such a high DSCP value.

However, this is as far as the QoS in that production access switch setup goes. In this configuration, the QoS profiles are created and assigned to the ports. But, the switch never examines ingressing traffic to apply a QoS profile to it.

I confirmed this by observing the result of the show port 1:48,2:48,3:48,4:48 qosmonitor command to see into what queue traffic was being placed:



Slot-1 X440Stack.1 # show port 1:48,2:48,3:48,4:48 qosmonitor

Qos Monitor Req Summary Fri Sep 9 16:43:26 2016

Port QP1 QP2 QP3 QP4 QP5 QP6 QP7 QP8

Pkt Pkt Pkt Pkt Pkt Pkt Pkt Pkt

Xmts Xmts Xmts Xmts Xmts Xmts Xmts Xmts

===============================================================================

1:48 0 0 0 0 0 0 0 0

2:48 29000235 0 0 0 0 0 0 601287

3:48 29855741 0 0 0 0 0 0 59808

4:48 90251869 0 0 0 0 0 0 60342



There is some QP8 traffic, which confused me. But, I suspect that is switch management traffic. The default queue, QP1, seems to be reflecting all user port traffic. No packets are being put into QP5 or QP6.

On the new X440 stack I'm configuring, here’s what I’ve done with its QoS configs:

First, I created QoS Profile QP6:



create qosprofile "QP6"



Then, I enabled DSCP examination and disabled ToS examination on all user ports, (not the uplinks):



enable diffserv examination ports 1:1-47,2:1-47,3:1-47

disable dot1P examination ports 1:1-47,2:1-47,3:1-47



I applied QoS profile QP6 to all user ports:



configure qosprofile QP6 minbw 5 maxbw 10 ports 1:1-47,2:1-47,3:1-47



The goal here is to give VoIP traffic a minimum of 5% and a maximum of 10% of each port’s available bandwidth. VoIP traffic isn’t high bandwidth, but it does need a reserve, and it needs priority to reduce latency and jitter. Those minimum and maximums may be a bit high. I checked sFlow data I'm collecting from the production user access switch I'm using as an example, and I never see any traffic to/from the VoIP phones that exceeds 1% of the bandwidth reported by sFlow.

I then defined the DSCP mapping, which will place any ingressing packet marked with a DSCP value of 40 into QP6:



configure diffserv examination code-point 40 qosprofile QP6


Finally, I used LLDP to instruct the VoIP phones how to tag and mark voice packets:



configure lldp port 1:1-47,2:1-47,3:1-47 advertise vendor-specific med policy application voice vlan Voice603 dscp 40



I disabled LLDP on the uplink ports, we don’t need that protocol there.



Now, I think I got this right. Can I ask you guys to check my work?

Thanks,

Jess

[Jesse_Ohlsson]

Thanks, Stephane.

I thought maybe that strict priority QosScheduler might be problematic, too. I need to read more about the weighted round robin in comparison to weighted deficit round robin.