QoS Questions

Started by routerdork, March 12, 2015, 03:43:45 PM

Previous topic - Next topic

routerdork

So I've been deep diving into QoS lately. Our configurations are a mix of Auto-QoS and Configured QoS (presumably by a consultant or the installer). We've got a mix of Cisco 2960's, 3560's, 3750's, 3850's, 4900's, and a few 6500's. So what I'm trying to do is keep things as standard and as simple as possible. I have a 2960 and a 3560 sitting beside me that I'm going through the motions on. I've come across a few things that seem to overlap, don't make sense, or contradict each other.

I've found this to be a really helpful document but it also contradicts what I'm seeing.
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/91862-cat3750-qos-config.html

At one point it states that if a service policy is applied to an interface the mls qos trust cos command is automatically removed. But from what I see after setting Auto-QoS on the port it adds the command.
interface FastEthernet0/1
srr-queue bandwidth share 1 30 35 5
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY


I started putting together my template before I looked into Auto-QoS, below is what I got so far.
interface GigabitEthernet0/1
description EXAMPLE ACCESS PORT CONFIG
switchport access vlan XXXX
switchport mode dynamic desirable
switchport voice vlan XXXX
mls qos trust device cisco-phone
mls qos trust cos
switchport priority extend cos 0
spanning-tree portfast


So I'm curious what others have done or come across? I don't see why I couldn't use Auto-QoS on my access ports and be fine but I'm interested in what others do as well.
"The thing about quotes on the internet is that you cannot confirm their validity." -Abraham Lincoln

that1guy15

QoS for switches is very hardware dependent. Just wait till you start digging into the 6500s as this gets specific to the line card.

Honestly Im deploying Auto-QoS as we upgrade our closets to 3850s. Ive heard from multiple sources that Auto-QoS on newer gear is actually pretty solid and I have no issues to date. Ive also used it on a handful of remote sites on 3560s but they dont ever get much load so I cant talk for its performance.

Also we are an Avaya shop so I also add "trust dscp" and "trust cos" to the access interfaces.
That1guy15
@that1guy_15
blog.movingonesandzeros.net

AnthonyC

Quote from: that1guy15 on March 12, 2015, 03:54:02 PM
QoS for switches is very hardware dependent. Just wait till you start digging into the 6500s as this gets specific to the line card.

Same goes for the Nexus 7x00 series as well.  The only part of QoS that is fairly reusable across the platforms is the classification part (other than adjust the difference between IOS/NX-OS/non-Cisco OS etc).
"It can also be argued that DNA is nothing more than a program designed to preserve itself. Life has become more complex in the overwhelming sea of information. And life, when organized into species, relies upon genes to be its memory system."

wintermute000

jebus 7x00 qos is a nightmare. built in hardware queues, different types of class maps, world's worst documentation... I just tweak the input maps and throw FCOE traffic into queue 3 (lossless), the rest can go to hell. LOL

I've never had any issues with auto-QoS as long as you remember to put trust on all the trunks and no smartie pants decides to manually tune the queues and allocations somewhere in the LAN in a different/incompatible manner. I would just go with auto qos defaults for LAN except for in data centre.


This is pretty bad from a security and from a safety POV - use static access or trunk mode is best practice.
switchport mode dynamic desirable =

routerdork

Quote from: wintermute000 on March 13, 2015, 12:40:00 AM
This is pretty bad from a security and from a safety POV - use static access or trunk mode is best practice.
switchport mode dynamic desirable =
It hasn't been implemented yet. Currently we do set to access/trunk. We've been looking at different options to ease the pain when a local user decides they'll re-design the network for us.  :angry: We've got some sites overseas that believe moving connections around on the switches is acceptable without calling us first. So a simple issue for packet loss to a website can turn into WTF happened here the whole site is down. We're slowly getting them trained but some are really pushing back.
"The thing about quotes on the internet is that you cannot confirm their validity." -Abraham Lincoln

routerdork

Sounds like Auto-QoS is the way to go for all the end-sites. After I worked on what I thought I needed I found that in the Auto-QoS doc it does the same things plus some more.

I narrowed my list to the following as possible separate policies:

MPLS End-sites - Auto-QoS on the switches, match/adjust the router policy-maps to the carrier settings and/or adjust the carrier profile
VPN End-sites - Auto-QoS on the switches and luckily they are all CME/CUE sites, pray for MPLS  :not_worthy:
Corporate HQ - Shaping and Policing right now, Auto-QoS with extra additions for the server boys that think they need to sneak in replication servers outside of the DC's (this just happened hence the policing and shaping currently applied)
DC's - Shaping and Policing right now, Will be adding ACL's to match/mark/classify (site is 3rd party and we don't own the switches so even if QoS is setup I'm not sure I'll trust them :-\)
"The thing about quotes on the internet is that you cannot confirm their validity." -Abraham Lincoln