In this blog, we will take a look at Cisco switch queuing architectures and configuration. Ethernet based switches have a lot of bandwidth, but congestion is a possibility on any platform. Local area network designs typically involve some form of oversubscription on uplinks to other switches. Large Cisco switch deployments consist of the following three layers:
• Access
• Distribution
• Core
Access layer switches aggregate Fast Ethernet or Gigabit Ethernet access ports and uplink the switches to the distribution layer. The Cisco campus network design guide recommends an oversubscription ratio of 20:1. A 24 port Gigabit Ethernet switch uplinked over 1 Gigabit Ethernet port would result in a 24:1 oversubscription ratio. Many Cisco switches have 10 Gigabit Ethernet uplink ports to limit the oversubscription at the access layer, but there is a certain amount of oversubscription in most switch network. Oversubscription will most certainly result in congestion during periods of heavy network utilization. When there congestion, there is the possibility of dropping high priority traffic so queuing is highly encouraged at the access layer.
Distribution layer switches aggregate access layer switches and provide connectivity between the access layer switches and the core switches. Some switch based deployments are not large enough to warrant a core layer and utilize a collapsed core model. Distribution layer uplinks to core switches usually employ a 4:1 oversubscription factor which can result in packet loss.
Core switches are usually designed to be non-blocking architectures. Due to the complexity level of the internal switch architecture, it is recommended to utilize QoS queuing even when a switch is non-blocking in nature (no oversubscription).
The “Catalyst® QoS: Quality of Service in Campus Networks” Cisco Press book does a good job explaining the “VERY” limited QoS capabilities of the Cisco Catalyst 2900XL, 3500XL, 4000, 5000, 2948G, and 2980G platforms. Most of these switches are at or near the end of support date in Cisco’s “End-of-Sale and End-of-Life Products” (link below). We will not be covering these switches in this blog series.
The first queuing algorithm used on QoS capable switches was weighted round robin (WRR). Since weighted round robin is based on round robin scheduling, let’s take a look at round robin scheduling first. A T1 interface consists of 24 individual DS-0 channels in which each of the 24 channels are multiplexed together in a round robin manner. A sample is taken from each DS-0 channel (1-24) every time the T1 framing process occurs. WRR is very similar to round robin, but WRR will apply a weight to each queue, therefore allowing some queues to receive more bandwidth than other queues. The 2950 and 3550 switch platforms have a default WRR bandwidth allocation as follows:
Queue# Bandwidth CoS mapping
1 25 0,1
2 25 2,3
3 25 4,5
4 25 6,7
The quantity of 25 is a configurable parameter through the wrr-queue bandwidth command. Each queue can be configured with a value of 1 – 255, but it is best practice to have the sum of all queues equal to 100. Each queue will receive their bandwidth divided by the total configured bandwidth value during periods of congestion. As long as the total bandwidth is configured to equal 100, we can think of the configured bandwidth as a percentage of interface bandwidth.
In the next blog, we will begin discussing various switch configurations for queueing. We will also investigate the queuing operation performed in the Cisco switches when auto qos is used.
REFERENCES
Switches - End-of-Sale and End-of-Life Products
http://www.cisco.com/en/US/products/hw/switches/prod_category_end_of_lif...
Campus Network for High Availability Design Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG...
Implementing Cisco Quality of Service
http://www.globalknowledge.com/training/course.asp?pageid=9&courseid=757...
Advanced Cisco Quality of Service
http://www.globalknowledge.com/training/course.asp?pageid=9&courseid=936...
Enterprise QoS Solution Reference Network Design Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRN...
Dennis Hartmann, CCIE No. 15651, is a consultant with www.highpoint.com and author of Implementing Cisco Unified Communications Manager, Part 1. Dennis is also a lead instructor at Global Knowledge. Dennis has various certifications, including the Cisco CCVP, CCSI, CCNP, CCIP, and the Microsoft MCSE. Dennis has various specializations including unified communications, data center, routing & switching, service provider (MPLS and optical). Dennis has worked for various Fortune 500 companies, including AT&T, Sprint, Merrill Lynch, KPMG, and Cabletron Systems. He lives with his wife and children in Hopewell Junction, New York.
The Leader in Network Knowledge
lets talk about something new
How about you write something people will comment on, rather than just trying to stay on the front page of Cisco Subnet with these poor short blogs you copy and paste.
I would rather see something that 50 people comment on than you on the front page of Cisco Subnet everyday with these bad blogs. It is not a contest to see who stays on the front page the most. Seems like thats the only time you write a new blog, to get back on the front page. But I am done reading your blogs, boring.
re: lets talk about something new
I agree - your a smart guy with alot to say, but you just touch on the subject - give some examples that we can relate to for real life ideas.
Examples
There are great examples in the QoS SRND. I began the blog with examples, but it became clear that I was just re-creating Tim Szigeti's great work. Check out the switching chapter in the SRND and the examples should start to make sense after reading this blog series. There is a lot to talk about here and I will not be able to do it in one blog. Thanks for taking the time to post a comment.
qos
"Due to the complexity level of the internal switch architecture, it is recommended to utilize QoS queuing even when a switch is non-blocking in nature (no oversubscription)."
Why? and by whom?
This is a good start to the series but it might have been worth just keeping it as an overview of the whole series before leaping into the WRR queuing mechanism.
There are a couple of other useful articles on CCO.
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.pdf
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html
There is always the Cisco QoS technology page:
http://www.cisco.com/en/US/products/ps6558/products_ios_technology_home.html
Good to see you managed to squeeze in a couple of links for Global Knowledge training courses while you were at it.
Back plane speeds, buffer allocation, memory, ASICs, etc.
Auto QoS commands on the switches usually tune memory buffer allocations on the ports which are confusing. There is also bus arbiter process in which fixed size cells are transported across the backplane of switches. The backplane of the switch can be congested or there may be no available memory for the process to function. A 6500 with a SUP720 and an older line card may only have a Medusa ASIC which will only allow it to connect to the switch fabric module (SFM) at 20Gbps. The 20Gbps connection is a congestion point that would not be known unless there was an in depth understanding of the architecture.
I have not studied the switch architectures in some time because I have been very focused on Unified Communications, but I'm aware of the complexity.
Each switch platform has its own QoS Configuration Guide. I highly recommend taking a look at the configuration guide for the switch in which you will be deploying QoS.
I always try to squeeze in a couple of www.globalknowledge.com links. :-)
switch backplane architecture
I understand why you'd focus more on UC: there are few people who bother to learn the different hardware capabilities for each platform/module. I'm not one of them. I tried, but I think the articles were written by the sales people at Tylenol: reading through them certainly gave me a headache.
A quick question then (one of the things I don't/can't remember): is the SFM limited to the lowest common speed? If you have an older line card with a 20G connection, does that affect other line cards? If not, then how does the AutoQoS tune the system to account for the different access speeds?
Also, is there a publicly-available version of the QoS SRND?
I've been through GK training courses in the UK a few times - when I was at Cisco UK, they were the preferred training partner for courses they didn't run internally - and always found them to be pretty good, well equipped and well presented. Just made me smile to see the GK links buried in with the rest of the QoS ones. :)
Backplane / SRND
The QoS 3.3 SRND is publicly available at http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
All SRNDs are available at www.cisco.com/go/srnd, but they are organized into different design zones. The QoS SRND is not under the Design Zone for Unified Communications. This SRND can be found under the Design Zone for WAN/MAN. Check out the QoS sections in the CUCM and Telepresence SRND as well. They provide additional QoS information.
Unfortunately, I do not have the answer to your MEDUSA ASIC question, but the 20Gbps ASICs are the newer MEDUSA ASICs that can tie into the SFM2 on the SUP720. Two Medusa ASICs on one line card can generate 40Gbps of traffic onto the SFM. The SFM2 allows each line card on the 6509 to connect to the matrix at 40Gbps. 40Gbps X 9 slots = 360Gbps. The 720Gbps (SUP720) number is based on full duplex operation (transmit and receive at 360Gbps - 360 X 2 = 720Gbps).
I will ask a couple of the Catalyst 6500 instructors at Global Knowledge to chime in on this blog. They know the 6500 architecture very well. In the meantime, if you would like to learn more check out the following two links I have found by Googling the term "catalyst 6500 backplane architecture":
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html
http://www.cisl.ucar.edu/nets/devices/eswitches/6500-backplane.html
Post new comment