The writing masses in addition to professional media generate tons of articles each week. What’s the best way to keep up? My strategy is multi-pronged.TL;DR.
If you’ve made it this far into the series, I have one simple point about QoS policy effectiveness that I want to bring home in this post before going through a couple of packet walks. The point is this. If an interface isn’t congested, your QoS policy dealing with congestion isn’t impacting traffic. Of course, rate limiters & marking policies will be effective whether your interface is congested or not, as the point of them is to throttle a traffic class to a specific transmission rate or mark traffic with a specific value.
When dealing with the WAN, a common problem is that the actual available bandwidth of a circuit might different from the bandwidth of the physical circuit handoff. For example, a carrier might provide an enterprise with a gigabit Ethernet handoff, when in fact the connection is being throttled to 100Mbps downstream. A similar sort of problem appears when head-end bandwidth differs from remote site bandwidth. For example, a headquarters site might have a full DS3 connection,
As traffic flows across an enterprise’s network, there often comes a point where some part of the infrastructure is not owned by the enterprise. For example, enterprises with offices spread across several different cities usually rely on a telecommunications provider to connect the offices together. The telecom provider will layer the enterprise’s traffic on top of their own infrastructure, commonly in the form of an L3VPN. To the enterprise, the connection handed off to them by the provider is a private one providing access to their remote offices.
Many large enterprises across the world use Cisco switching gear. As mentioned in previous parts of this series, implementing QoS across disparate devices, even within the Cisco ecosystem, can be frustrating as the syntax varies widely. In an attempt to reduce network operator frustration (as well as human error), Cisco introduced AutoQoS as a means to deploy a templated QoS policy on certain of their devices. I believe exploring the code that Cisco AutoQoS generates on a Catalyst 3750X switch provides a good baseline of QoS implementation specifics for Cisco products.
A significant part of the challenge of delivering a QoS strategy to a network is in the execution. How, exactly, does one write a QoS policy that will accomplish business goals consistently across a diverse network infrastructure? There is no obvious answer to this question (and large books have been written on the topic), as the types of QoS tools to apply differ by network location and by the types of problems that can be experienced at each of those locations.
Like any IT discipline, QoS is awash in terminology & acronyms. I’m going to tackle the most common QoS terms here, and try to provide some context in my definitions. Ideally, you’ll know not just a definition of the term, but also how the term fits into the larger QoS ecosystem.
ToS – ToS stands for “type of service.” The ToS value is stored in a byte of the IP header of a packet.
When designing a QoS scheme to apply to an enterprise network, a common misconception is that delivery of all packets is the most important thing. The logic goes that an application is best served if all of the packets of a transaction are delivered, no matter what it takes to make that happen. Network engineers often go down the road of enlarging buffers as much as they can, in the hopes of lessening packet drops.
With an introduction to QoS behind us, let’s start talking through some of the design concerns that drive QoS policy creation.
What QoS problems do enterprises typically have?
Network convergence is a trend that has stayed steady in enterprise (and service provider) networks for well over a decade now. The challenge with collaboration applications – voice & video especially – is that the network traffic they generate needs special treatment so that the service level is guaranteed for the organization using them.
What is QoS?
Quality of service is a group of tools that form a traffic delivery policy. This policy ensures some traffic arrives on time, allows some traffic to arrive late, and some to not arrive at all, depending on how the traffic is classified and what importance is given to it. The idea is that traffic is split up into classes, and each class is treated in a particular way as it travels through interfaces across your network infrastructure.
Network engineers the world over have a loathing for quality of service (QoS). Next to IP multicast, QoS ranks near the top of the list of frustrating network technologies. But not for me. I thoroughly enjoy QoS. Why? QoS addresses real world problems of traffic not being delivered on time or at all. When correctly applied, QoS strategies affect real, positive changes for applications riding across a busy network. Done right, QoS helps ensure that traffic is delivered every time,