While researching the Catalyst QoS chapter of the latest IPexpert book The Operation and Troubleshooting of QoS, I discovered that there are many incorrect blog posts out there regarding the configuration of traffic policing on a switched virtual interface (SVI). The purpose of this post is to provide the correct configuration and some supporting commentary. Big thanks to upcoming IPexpert instructor Kevin Wallace for this clear and direct video on the topic during our CCIE Lab Fundamentals course where he was one of our prized Guest Speakers.

As you know, policing sets a “speed limit” for traffic that is entering or exiting the Catalyst switch. Traffic that is not exceeding the speed limit is termed the conforming traffic. Traffic that is exceeding the speed limit is termed the exceeding traffic.

Read Full Entry »

For all that have purchased IPexpert’s latest text, QoS Operation and Troubleshooting, there is an update being pushed to member’s sites on Monday, May 14th by 5 PM EST USA.

This update will fix some cosmetic issues, correct some grammar problems that slipped by our editors, and will also add some content in spots to help improve clarity of the text.

Thanks so much for all of the amazing feedback regarding this book series at IPexpert.com. We will keep writing as long as you keep reading! :-)

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

The following is an excerpt from the IPexpert book - IPv4/IPv6 QoS Operation and Troubleshooting

The Modular Quality of Service Command Line Interface (MQC)

The MQC approach consists of three important steps:

1. The classification of traffic into class maps – Chapter 4: Classification explores this topic in detail. This chapter will completely explore the class map itself. We create class maps with the class-map command.
2. The QoS treatment of the traffic classifications – policy maps are used to configure the actual QoS mechanisms on the traffic that has been classified. The policy-map command creates a policy map. These policy maps reference the class maps created in step 1.
3. The application of the policy map to an interface – applying the policy map is accomplished with a service policy. You create a service policy using the service-policy command.

Note: In this chapter, our emphasis is on the MQC itself. Please understand that configuration examples will be shown, but those specific QoS configurations are taught in other chapters of this text. Please try and focus on the MQC itself here and do not be distracted by the additional commands.
Read Full Entry »

The following is an excerpt from the upcoming IPexpert book - IPv4/IPv6 QoS Operation and Troubleshooting

In the previous section, we discussed how WFQ gives certain types of traffic preferential treatment when congestion occurs on a slow-speed link. In that section, we reviewed how WFQ does this by automatically detecting flows and preventing any one conversation from starving out others on a link. Additionally, WFQ suffered from limitations in scalability and granularity. These issues result when the WFQ algorithm has to manage very aggressive individual flows, or a very high number of flows. Class-based weighted fair queuing (CBWFQ) overcomes these limitations. CBWFQ enhanced the fair queuing algorithm such that it now supports statically defined classes. This fact affords CBWFQ control over how traffic will be queued and how bandwidth will be assigned to particular flows.

The advantages of CBWFQ come in the form of scalability, granularity, and ease of configuration. Not to mention that it combines all the capabilities of legacy congestion management protocols into one mechanism. CBWFQ also incorporates support for weighted random early detection (WRED). We will review how CBWFQ works with WRED in Chapter 7: Congestion Avoidance. All these factors make CBWFQ possibly one of the most advanced and powerful congestion management mechanisms offered by Cisco IOS.
Read Full Entry »

The following is an excerpt from the upcoming IPexpert book – IPv4/IPv6 QoS Operation and Troubleshooting

One of the points that many Cisco QoS texts fail to make clear is that a typical Cisco network device interface possess a software queue and a hardware queue for outbound traffic transmissions. When we read that a particular QoS tool will engage and work in times of congestion only, this is a reference to packets overflowing the hardware queue into the software queue. The software queue is where the magic of Quality of Service happens. In fact, one of the QoS mechanisms called Link Fragmentation and Interleaving (LFI) directly addresses the split between these two queues. LFI ensures that large packets (Jumbograms) do not clog the hardware queue. These large packets are chopped up (fragmented) so that higher priority, smaller packets (like voice) can be interwoven between the fragments in the hardware queue. Chapter 11: Link Fragmentation and Interleaving (LFI) details this process for you.
Read Full Entry »