Today’s complex enterprise IT networks carry a lot of different kinds of traffic. These typically include your ordinary local area network (LAN) traffic such as web browsing, file transfer, database query/response, and intranet traffic; application and service delivery traffic; wide area networking (WAN) traffic; voice over IT (VoIP) and other forms of media traffic; and Internet traffic associated with the hybrid cloud infrastructures that are so often typical for today’s enterprises. Having so many different forms of traffic all traveling together through your network backbone and infrastructure means a lot of jostling for bandwidth can occur. Some of these types of traffic are critical to the success of your business; others are not so critical. Wouldn’t it be nice if you had some form of “traffic cop” policing your network infrastructure to ensure that high-value network traffic always has priority over less important forms of traffic? You do: Microsoft Quality of Service (QoS) Policy.
QoS the network traffic manager
QoS Policy, a feature of Microsoft’s Windows Server platform, is designed to do just that. Just as traffic lights are designed to direct the flow of automobile traffic in a safe and efficient way across a road system, QoS Policy can direct the flow of TCP/IP packets across your network in an orderly and efficient manner. And just as road congestion is a familiar thing to those of us who have to drive to work each morning, in a similar fashion network, congestion is a constant concern of sysadmins in charge of providing the applications and services that users need to perform their jobs.
When two cars, a truck, and an ambulance converge on the same intersection simultaneously, the rules of the road dictate that other vehicles yield right of way to the ambulance because it is an essential service. Similarly, the servers, routers, and WAN links, and connections to the Internet can easily get bogged down and congested when different kinds of traffic workloads suddenly converge on them at the same time. In such situations, QoS acts as a kind of virtual traffic cop to ensure that the “rules of the road” are enforced on your TCP/IP network. And what’s more is that you get to define just what those rules of the road should be on your own network! For example, you can tag forms of traffic that are sensitive to network latency such as voice or video traffic so they receive priority over other forms of traffic like bulk data transfers that are not sensitive to latency issues.
How QoS Policy works
QoS isn’t something that’s specific only to the Windows Server platform. QoS is actually a set of industry standards starting out with RCP 791 where it was first defined and then later updated by other RFCs including 1349, 2474, 3644, 5777, and a number more. To get a good understanding of standards-based QoS see this article by Russ White on Packet Pushers. But our focus here is on the Windows Server platform, and in the latest versions of Windows Server you can manage QoS on your network by establishing policies. In Windows Server, this means creating and configuring Group Policy policies on your domain controllers. The place where you define new policies for QoS is twofold:
Computer Configuration | Policies | Windows Settings | Policy-based QoS
User Configuration | Policies | Windows Settings | Policy-based QoS
The image below shows the QoS Policy node for computers in the Group Policy Object (GPO) called the Default Domain Policy:
Once you’ve defined a new QoS policy in a GPO, the policy can be applied via Group Policy to all of the computers or users in the organizational unit (OU), domain, or site linked to that particular GPO. QoS policies configured in Active Directory on Windows Server 2016 apply to computers running earlier Windows Server versions down to Windows Server 2008. They also apply to computers running client versions of Windows including Windows 10, 8.1, 7 and Windows Vista. A good introductory walkthrough on how you can create a new QoS policy in Windows Server 2012 can be found in this article by our own Brien Posey right here on TechGenix. And if you want additional information about the various settings available for configuration using the Policy-based QoS Wizard then this article on Microsoft Docs may be helpful.
Windows Server vs. Cisco QoS
QoS is one of those areas where heads may begin to butt against one another inside your IT department, especially if your organization is a fairly large one that has been around for some years. That’s because controlling the flow of traffic across the network has traditionally been under the domain of those who manage the switching and routing infrastructure of an enterprise. For example, if your company has Cisco routers deployed at different sites then you may already be using the QoS functionality built into Cisco routers. By using the Cisco IOS Modular QoS command-line interface (CLI) you can configure and enable class-based QoS features by creating new traffic classes, by creating traffic policies and attaching them to an interface, and by performing various other tasks associated with controlling network traffic congestion. If such policies are already in place and administered by Cisco professionals on your network then you may experience pushback if you want to implement Windows Server-based QoS policies using Group Policy. One might ask: why complicate things by having two separate sets of policies implementing network QoS? Is it better just to rip out Cisco policies and replace them with Microsoft ones?
There are arguments both for and against the Windows Server and Cisco approaches. Implementing QoS in Windows Server definitely has some manageability advantages. For example, being configurable with Group Policy means the Active Directory already has familiarity with the management infrastructure and can quickly create and assign new policies which can be propagated to the user’s computers using Group Policy updating mechanisms. It also means that regardless of how the user’s computer is joined to the network it can still receive the required policy, so users that frequently disconnect or use WiFi can still have their network traffic managed by QoS Policy. On the other hand, if it’s mostly traffic congestion on your network backbone that you’re concerned about then configuring Cisco QoS on your core routers and 10 GbE switches is perhaps a simpler and more robust approach as it doesn’t depend upon the viability of your Active Directory infrastructure to keep working properly. Note however that this becomes a bit more complex to implement if you’re using IPsec to encrypt traffic across your network backbone.
Featured image: Pixabay