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

[Chad5]

I do have the DOT1P settings as you described. I did a test. I did:

disable dot1P examination ports 2:21

enable diffserv examination ports 2:21

Then I qos monitor port 2:21 expecting that DSCP will kickin and put everything in QP1, as per the default diffserv examinination config, but as soon as I make a voip call on that port, I see QP6 numbers increase. So I still can’t explain it. I disabled dot1p examination, so can’t explain why QP6 is being hit.

Thanks,

[Jesse_Ohlsson]

Well, it doesn't work. And, I am very puzzled why not. My Cisco model 7941G phone is connected to port 4:5, Our uplinks are a LAG containing ports 1:48, 2:48, 3:48, and 4:48. Here are my relevant configs:

Slot-1 X440Stack.18 # show conf | grep 4:5

enable diffserv examination port 4:5
disable dot1p examination port 4:5
configure qosprofile QP6 minbw 5 maxbw 10 ports 4:5
configure lldp port 4:5 advertise port-description
configure lldp port 4:5 advertise system-name
configure lldp port 4:5 advertise system-capabilities
configure lldp port 4:5 advertise vendor-specific dot1 port-vlan-id
configure lldp port 4:5 advertise vendor-specific dot3 mac-phy
configure lldp port 4:5 advertise vendor-specific dot3 link-aggregation
configure lldp port 4:5 advertise vendor-specific med capabilities
configure lldp port 4:5 advertise vendor-specific med policy application voice vlan Voice606 dscp 40

Slot-1 X440Stack.19 # show qosprofile port 4:5

Port: 4:5
QP1 MinBw = 0% MaxBw = 100% MaxBuf = 100% Weight = 1
QP5 MinBw = 0% MaxBw = 100% MaxBuf = 100% Weight = 1
QP6 MinBw = 5% MaxBw = 10% MaxBuf = 100% Weight = 1
QP8 MinBw = 0% MaxBw = 100% MaxBuf = 100% Weight = 1

Slot-1 X440Stack.20 # show diffserv replacement

QOSProfile->CodePoint mapping:
QP1 -> 00
QP5 -> 32
QP6 -> 40
QP8 -> 56

Slot-1 X440Stack.21 # show diffserv examination

CodePoint->QOSProfile mapping:
00->QP1 01->QP1 02->QP1 03->QP1 04->QP1 05->QP1 06->QP1 07->QP1
08*>QP1 09*>QP1 10*>QP1 11*>QP1 12*>QP1 13*>QP1 14*>QP1 15*>QP1
16*>QP1 17*>QP1 18*>QP1 19*>QP1 20*>QP1 21*>QP1 22*>QP1 23*>QP1
24*>QP1 25*>QP1 26*>QP1 27*>QP1 28*>QP1 29*>QP1 30*>QP1 31*>QP1
32*>QP1 33*>QP1 34*>QP1 35*>QP1 36*>QP1 37*>QP1 38*>QP1 39*>QP1
40->QP6 41*>QP1 42*>QP1 43*>QP1 44*>QP1 45*>QP1 46*>QP1 47*>QP1
48*>QP1 49*>QP1 50*>QP1 51*>QP1 52*>QP1 53*>QP1 54*>QP1 55*>QP1
56->QP8 57->QP8 58->QP8 59->QP8 60->QP8 61->QP8 62->QP8 63->QP8

Slot-1 X440Stack.22 # show lldp port 4:5

LLDP transmit interval : 30 seconds
LLDP transmit hold multiplier : 4 (used TTL = 120 seconds)
LLDP transmit delay : 2 seconds
LLDP SNMP notification interval : 5 seconds
LLDP reinitialize delay : 2 seconds
LLDP-MED fast start repeat count : 3

LLDP Port Configuration:

Port Rx Tx SNMP --- Optional enabled transmit TLVs --
Mode Mode Notification LLDP 802.1 802.3 MED AvEx DCBX
===============================================================================
4:5 Enabled Enabled -- PNDC- P-- M-L- C-P- ---- --
===============================================================================
Notification: (L) lldpRemTablesChange, (M) lldpXMedTopologyChangeDetected
LLDP Flags : (P) Port Description, (N) System Name, (D) System Description
(C) System Capabilities, (M) Mgmt Address
802.1 Flags : (P) Port VLAN ID, (p) Port & Protocol VLAN ID, (N) VLAN Name
802.3 Flags : (M) MAC/PHY Configuration/Status, (P) Power via MDI
(+) Power via MDI with DLL Classification for PoE+,
(L) Link Aggregation, (F) Frame Size
MED Flags : (C) MED Capabilities, (P) Network Policy,
(L) Location Identification, (p) Extended Power-via-MDI
AvEx Flags : (P) PoE Conservation Request, (C) Call Server, (F) File Server
(Q) 802.1Q Framing
DCBX Flags : (I) IEEE 802.1Qaz DCBX, (B) Baseline v1.01 DCBX

Slot-1 CysHqdDX440Stack.24 # show port 4:5,1:48,2:48,3:48,4:48 qosmonitor
Qos Monitor Req Summary Wed Sep 14 17:23:44 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 42088955 0 0 0 0 0 0 944243
3:48 41867147 0 0 0 0 0 0 89269
4:5 6481193 0 0 0 0 0 0 66984
4:48 14003447 0 0 0 0 0 0 90065

===============================================================================
> indicates Port Display Name truncated past 8 characters
Spacebar->Toggle screen 0->Clear counters U->Pageup D->Pagedown ESC->exit

Based on all that, I'd expect to see traffic in QP6 when I make a call on my phone. But, I don't. I think my switch configs are correct. About what I'm unsure now is the behavior of my VoIP phone.

These Cisco phones have a web interface in which I can view its configs. Here are the relevant bits of my phone's configs:

LLDP-MED: SW Port Yes

DSCP For Call Control CS3
DSCP For Configuration CS3
DSCP For Services Default

As near as I can tell, this phone is configured to listen to the LLDP TLVs I'm sending it above. But, as far as the DSCP marking, I'm not sure. That last entry, "DSCP for Services" is set to default. I asked our CUCM administrator to show that setting to me. This setting is in the CUCM Administration > System > Enterprise Parameters menu, and it is set there to "default DSCP (000000).

I think this phone is doing what it's told, and I think the CUCM is telling it to mark voice traffic with a DSCP value of zero. Even though my switch is configured to tell it to mark voice traffic with DSCP 40.

Does anyone here know why the VoIP phones are ignoring the DSCP value set using LLDP? The phones do learn the proper voice VLAN, as they get a correct IP address, and they do function.

Stupid VoIP and QoS. It looks like this should be easy, but it is resisting attempts to make it work.

[Scott_Singer1]

Jesse,

Yes, you have everything correct. Here's some more detail

DSCP's 56-63 are generally reserved for network control traffic like STP BPDU's, OSPF advertisements, etc.. That's probably what you're seeing hitting QP8. The DSCP's 0-55 are assigned to QP1 and the top eight, 56-63, are assigned to QP8 by default. As you've probably noticed, QP2-QP7 are not pre-configured. You'll have to add the queues you want to use, so creating QP5 and QP6 was the place to start. Keep in mind that QP7 will be used by the stacking code when stacking is enabled and will not be available on switches configured as such. I generally exclude it from my configs for that reason.

Then you need to map the interesting DSCP's to the proper queues. Your example of mapping DSCP 40 to QP6 is correct. This traffic is probably the VoIP bearer traffic. I've also seen vendors use 46, which is also in the Expedited Forwarding Class. It's not uncommon to also map the VoIP control traffic as well to an Assured Forwarding class like DSCP 24 or 34.

Without setting minimum and maximum bandwidth values, the switch will operate the queues in a strict priority fashion, which is usually as far as you need to go in most environments. This means that the higher queues will be serviced fully as long as there is traffic in them. If congestion on your uplinks is common, you may end up "starving" the lower queues. You can set a minimum bandwidth on them to reserve some headroom, but this will be at the expense of the higher queues. This not generally done when your primary purpose in implementing QoS is guaranteeing the delivery of time, delay, and/or latency sensitive traffic like voice and video. If a congested situation is common, you're probably looking at adding more bandwidth or redirecting some traffic along another path.

LLDP is a standards-based way of sending configuration information to devices as well getting configuration information about the device. Because of this, it's not a bad idea to include it on the uplinks, especially in multi-vendor environments. On the other hand, EDP will be already enabled on most Extreme Network devices, which serves the same purpose. Also, confirm your LLDP settings with your VoIP vendor if you haven't already. Some vendors, like Avaya, have proprietary extensions that provide more features.

I have used maximum bandwidth (peak rate) to protect uplinks from lower priority traffic overrunning them. I have also used minimum bandwidth (committed information rate) to help guarantee bandwidth in a simplified Service Provider situation.

Regards, Scott

[Ryan_Mathews]

Sweet! The Hub just got a lot stronger with Mr. Singer in the mix.
Great to see you on the Hub Scott!

[Stephane_Grosj1]

Hi,

your reasoning seems good to me. You are right to disable dot1p examination and enable diffserv examination if you want dscp to be used. In the precedence order, dot1p is preferred over dscp.

Do a show diffserv examination to check your settings. Note that a show dot1p replacement will also tell you what dot1p will be marked on tagged packet egressing the switch (there's an automatic dot1p replacement with diffserv examination).

You are defaulting to a Strict Priority scheduler, btw.