LAN QoS - Best Practice?

Say you have a small site running CME: 28xx series router, 30-60 phones, no more than 2 switches (mostly 3560s). I typically use auto qos (cisco-phone) on the switch ports only, then on the dot1q trunk ports I trust DSCP markings, but don't setup congestion management. Router is setup to appropriately prioritize voip traffic across the provider network/WAN. Everything works fine - no QoS problems whatsoever BUT the trunk links bother me - What's the rule of thumb for QoS on the trunk links in this scenario?

Find more posts tagged with

Comments

networker050184

In anything that small I've set up I've never even used QoS on the LAN. Never had any issues. My best practice is to only use features where you truly need them, nothing fancy.

pitviper

Maybe someday I'll need to add 1000 phones (but only 48 in SRST mode) - it's more scalable if I think ahead

. Nah, I know it's overkill - I was more so curious since the QoS course barely touched on LAN and didn't mention trunks at all.

hoogen82

I do think if you are taking care of trusting the values it is a good deal.. Some people do forget to trust on the trunks and the values are lost. Congestion or the idea of QOS is mostly if you don't have enough bandwidth.. And qos is only going to be in effect if you have a congestion problem.. LAN usually doesn't have those problems..

GT-Rob

Im pretty sure you want to trust COS on the trunks, not DSCP. Since the trunks are layer 2, and DSCP markings are layer 3.

We run QoS on our LAN as well but Im pretty sure its never actually had to queue packets. All of our servers are gigE right through the core except for a few legacy things on 100, and although some users are on gigE switches, our phones are only 100mb cutting them down. We are 'enterprise', but I don't consider us huge, maybe 400 people with phones/computers.

In any case auto-qos voip cisco-phone is simple enough that you might as well through it on if you are running cisco voip.

Turgon

networker050184 wrote: »

In anything that small I've set up I've never even used QoS on the LAN. Never had any issues. My best practice is to only use features where you truly need them, nothing fancy.

Agree, and it really needs to be tested thoroughly on a reference model first. A lot of people try this 'n' that with QoS with intangible or detremental results.

GT-Rob

Turgon wrote: »

Agree, and it really needs to be tested thoroughly on a reference model first. A lot of people try this 'n' that with QoS with intangible or detremental results.

Like your provider putting QoS on your links and missing a zero on one of the statements, effectively rate limiting all our WAN traffic to 300k?

Yes, I have since learned QoS CAN cripple your network! haha

Turgon

GT-Rob wrote: »

Like your provider putting QoS on your links and missing a zero on one of the statements, effectively rate limiting all our WAN traffic to 300k?

Yes, I have since learned QoS CAN cripple your network! haha

Yes and the dreaded default of map-class coming in at 64K

I would venture that QoS is possibly the worst understood of all technologies in terms of application, with multicast a close second, MPLS third, Switching fourth.

pitviper

GT-Rob wrote: »

Im pretty sure you want to trust COS on the trunks, not DSCP. Since the trunks are layer 2, and DSCP markings are layer 3.

DSCP only works fine on the trunks - I'm using all L3 switches. Packets come into the router tagged accordingly.

pitviper

Turgon wrote: »

Agree, and it really needs to be tested thoroughly on a reference model first. A lot of people try this 'n' that with QoS with intangible or detremental results.

Used the same setup for the last six or so sites with no problems – Tested in the lab prior. Overkill probably (though I do want to at least tag on the switches anyways) but good to practice for exam time none the less

Turgon

pitviper wrote: »

Used the same setup for the last six or so sites with no problems – Tested in the lab prior. Overkill probably (though I do want to at least tag on the switches anyways) but good to practice for exam time none the less

If only everyone was so thorough. I shall have to pick your brains about QoS in the weeks ahead.

Forsaken_GA

GT-Rob wrote: »

Like your provider putting QoS on your links and missing a zero on one of the statements, effectively rate limiting all our WAN traffic to 300k?

Oh, you must have uplinks with Telia as well...

dtlokee

If you're really bored and want to read the SRND for QoS it will tell you how to do it. Trust DSCP on uplinks between switches, not COS. Also make sure you fix your COS-DSCP maps on your switches to match the required values (by default most switches map COS 5 to DSCP 40 - this will mess you all up). Be careful with AutoQoS as it's very version dependant, sometimes it enables a priority queue, sometimes not. You should have a priority queue on uplinks along with configuring your shaped and shared (or WRR weights on older switches) accordingly.

In something that small it's unlikely that QoS will make anything better but it's very likely that misconfiguring QoS will make things much much worse.

pitviper

dtlokee wrote: »

If you're really bored and want to read the SRND for QoS it will tell you how to do it. Trust DSCP on uplinks between switches, not COS. Also make sure you fix your COS-DSCP maps on your switches to match the required values (by default most switches map COS 5 to DSCP 40 - this will mess you all up). Be careful with AutoQoS as it's very version dependant, sometimes it enables a priority queue, sometimes not. You should have a priority queue on uplinks along with configuring your shaped and shared (or WRR weights on older switches) accordingly.

In something that small it's unlikely that QoS will make anything better but it's very likely that misconfiguring QoS will make things much much worse.

Excellent - Thanks for the pointers!

COS-DSCP map is good – It's the first thing I check since I ran into problems with the default settings on my lab 3550s. Looks like its been fixed on the newer switches and or IOS. Here is the default from the 3560 in question:

mls qos map cos-dscp 0 8 16 24 32 46 48 56

Still trying to wrap my head around the differences between the WRR queues on my 3550s/from the QoS course and the newer SRR queues. I have the SRND printed out for prolonged bathroom reading but it's a pretty brutal read.

I’m going to play around with the queues a little more before I mess with the trunk links.

pitviper

partial 3560 config w/auto-qos that I've been playing around with:

mls qos map policed-dscp 24 26 46 to 0
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
mls qos
!
!
!
!
!
spanning-tree mode pvst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
ip ssh version 2
!
class-map match-all AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
match ip dscp cs3 af31
!
!
policy-map AutoQoS-Police-CiscoPhone
class AutoQoS-VoIP-RTP-Trust
set dscp ef
police 320000 8000 exceed-action policed-dscp-transmit
class AutoQoS-VoIP-Control-Trust
set dscp cs3
police 32000 8000 exceed-action policed-dscp-transmit
!
!
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport voice vlan 20
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
.....//.....
interface FastEthernet0/48
description <<<<<<<< AIR-AP1131AG >>>>>>>>
switchport access vlan 10
switchport mode access
switchport voice vlan 20
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
!
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
mls qos trust dscp

dtlokee

Yes the whole SRR = shared round robin or shaped round robin (depending on the configuration) is a bit confusing. Basically if you only set the "shared" queue weights then it's shared, if you also configure "shaped" queue weights then it works as shaped to that maximum rate. You may ask "why would I shape traffic?" if you activate the priority queue then it will consume all of the available bandwidth if you don't assign it a shaped weight. so something like this is pretty common:

srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth 3 0 0 0
priority-queue out

Now where it gets fun is mapping all of your applications to the queues. In this case we are using queue 1 as priority so that should only get voice. Queue 2 has a large portion of the bandwidth and will carry most of our traffic (now we could get into a lengthy discussion on drop thresholds and all - more fodder) but in reality we want our mission critical apps and call signaling in here. Q3 is our default queue - that is all traffic taht was marked with DSCP 0. Q4 is going to be our less than best effort scavenger queue. The value of 3 in the "shaped" command restricts the priority queue to 33% of the bandwidth.

Calculating the amount of bandwidth each queue gets is interesting, the priority queue gets 33% the remaining 3 queues get the other 67% broken up according to their weights (70/(70+25+5) (20/(70+25+5) and (5/(70+25+5)).

GT-Rob

Im confused here. Why DSCP on L2 trunks?

from Cisco:

Configure QoS on the Layer 2 Uplink

If the voice traffic is going to cross the switch via the trunk links, you need to configure the QoS parameters on the trunk ports. In this case, you need to issue the auto qos voip trust command instead of the auto qos voip cisco-phone command.

Configure Auto-QoS on the Trunk Links of the Catalyst Switches that run IOS

Switch#configure terminal

Switch(config)#interface gigabitethernet 1/1

Switch(config-if)#auto qos voip trust

!--- Configures the port to trust the CoS labels
!--- in the incoming packets and configures the
!--- traffic-shaping parameters.

Configure IOS Catalyst Switches to Connect Cisco IP Phones Configuration Example - Cisco Systems

*****************

And only mentions DSCP on L3 interfaces. I was under the impression that CoS on L2 interfaces.

pitviper

dtlokee wrote: »

Yes the whole SRR = shared round robin or shaped round robin (depending on the configuration) is a bit confusing. Basically if you only set the "shared" queue weights then it's shared, if you also configure "shaped" queue weights then it works as shaped to that maximum rate. You may ask "why would I shape traffic?" if you activate the priority queue then it will consume all of the available bandwidth if you don't assign it a shaped weight. so something like this is pretty common:

srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth 3 0 0 0
priority-queue out

Now where it gets fun is mapping all of your applications to the queues. In this case we are using queue 1 as priority so that should only get voice. Queue 2 has a large portion of the bandwidth and will carry most of our traffic (now we could get into a lengthy discussion on drop thresholds and all - more fodder) but in reality we want our mission critical apps and call signaling in here. Q3 is our default queue - that is all traffic taht was marked with DSCP 0. Q4 is going to be our less than best effort scavenger queue. The value of 3 in the "shaped" command restricts the priority queue to 33% of the bandwidth.

Calculating the amount of bandwidth each queue gets is interesting, the priority queue gets 33% the remaining 3 queues get the other 67% broken up according to their weights (70/(70+25+5) (20/(70+25+5) and (5/(70+25+5)).

awesome - I can't thank you enough for your time!!!

pitviper

GT-Rob wrote: »

Im confused here. Why DSCP on L2 trunks?

Not sure - I picked it up from an engineer who helped us out with a VoIP project a few years ago. All I know is that when the traffic hits the router through the trunk the DSCP markings are intact.

dtlokee

DSCP on uplinks because we went to so much trouble to mark our traffic using a bunch of traffic classes, if you trust COS you are going back to 8 classes and losing the granular aspect of AFx1 - AFx2 - AFx3 policing and markdown for your different drop thresholds within WRED and switchport dropt thresholds.

in short, it's more granular to keep our DSCP markings.

On a side note - be careful with AutoQoS - it doesn't always follow the best practices and it only considers voice, I generally don't use it.

GT-Rob

Ok, you made it sound like you don't trust COS because it wouldn't work. Only having 8 queues is a problem on your LAN?

Pitviper: If its going to a routed interface (IE to a router), with an IP, then always do DSCP. But layer2 switch to a layer 2 switch (IE, LAN QoS), can easily be done with COS.

Yes you lose the flexibility that DSCP has, but more people are not using that anyway. Most LAN QoS is "I want my phones to work, everything else can be the way it was". In which case, you really are only using 2 queues anyway.

dtlokee

So why not trust DSCP on an L2 uplink between switches? You already have DSCP markings on the packets, what is the advantage to trusting COS over DSCP?

To be clear I conditionally trust the COS on the access link to a IP phone using either CDP or LLDP-MED depending on the phone.

I don't typically use more than 8 queues but I do define more than 8 traffic classes in most cases with different drop thresholds. Networks are always evolving and I don't want to go back and change thousands of uplinks because we decided to add a new traffic class and ran out of COS values.

DSCP default - best effort
cs8 - less than best effort scavenger class
af11, af12, af13 - bulk data
af21, af22, af23 - interactive data
cs3 - call signaling
af31, af32, af33 - mission critical data
af41 interactive video
ef - voice
cs 6 - network control
cs 7 - internetwork control

I don't use them all of them all the time but they are predefined on my devices for future expansion. It's all based on the SRND best practices from Cisco. Once you build them, it becomes part of your config template, and I have not had any issues with it. Now you need to keep in mind the capabilities of the device, if you have a switch with 1p3q2t or a switch with 1p3q8t it will change how you map your DSCP values to queues. If you have a WAN link less than 1.5 MB/s you most likely don't want to define more than 5 outbound queues or the individual reservations get too small. In the environments I work in I can't just protect voice and call signaling and forget all other flows.

That's my $0.02.

AbdullahCCIE

Hi,

I've a customer want to implement QoS best practice and MPLS QoS on PE , Cisco QoS classes recommendation
1- Voice, 2- Call Signalling, 3- Critical Data , 4- Best Effort, 5- Scavenger.

Example:

class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF
class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking
bandwidth percent 1 ! Current Call-Signaling marking
class-map match-any Critical Data
match ip dscp cs6 ! Routers mark Routing traffic to CS6
match ip dscp af21 af22 ! Recommended markings for Transactional-Data
match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Scavenger
match ip dscp cs1 ! Scavenger marking
!
policy-map WAN-EDGE
class Voice
priority percent 33 ! Voice gets 33% of LLQ
class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling
class Critical Data
bandwidth percent 36 ! Critical Data class gets 36% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class
class Scavenger
bandwidth percent 1 ! Scavenger class is throttled
class class-default
bandwidth percent 25 ! Default class gets a 25% BW guarantee
random-detect ! Enables WRED for class-default

Sachindon

Voice : Ipecs --> VOIP phone
Video : ALCAD -->Streaming
IP Camera

> remote vewing
Data---->Admin
WIFI---->Admin/Guest

Core Switch-3850
Access Switch- 2960

Connectivity ,all devices will be connected on separate port

If someone can help and give a template for QOS to apply on the switches Global mode and on each interface .

please treat as urgent because I hardly need this configuration.

thanks
best regards ,