QOS for the Integrator and Administrator

By David Iseminger

Chapter 10 from Windows 2000 Quality of Service, published by New Riders Publishing

Somewhere along the road to a QOS-enabled network, there must be the actual implementation of QOS capabilities on the network. That's where integrators and administrators come into the QOS picture. If your client has considered deploying QOS in one of its environments, and the consideration ended with a nod of approval and the award (to you) of an implementation contract, welcome—you're the integrator. If you are responsible for ensuring that the ongoing operation of your QOS-enabled network (or its QOS-enabled parts) continues smoothly, welcome—you're the QOS administrator. If you fall somewhere between those two, or if you just want to find out what's involved in getting Windows 2000 QOS running in a network environment, this chapter is where you'll find much of the Windows 2000-specific information you need.

For integrators or administrators, getting QOS running on a network means getting the infrastructure configured and ready to service QOS requests. As explained in the previous chapter, the first steps for such a deployment are almost certainly to get the QOS Packet Scheduler installed on the Windows 2000 clients participating in QOS and to get QOS ACS installed on each IP subnet on which QOS clients reside. Finishing that, however, doesn't complete the integrator or administrator's job—you must now make policies, enforce group policies, or even set enterprise-wide standards. In a word, you must configure.

On This Page

Planning for QOS on the Network
Configuring QOS ACS on the Windows 2000 Server
QOS for Non-Windows 2000 Clients

Planning for QOS on the Network

Because QOS requires the cooperation of network devices across the entire network, there are some items you should ensure are in place…or at least considered…during the course of planning for your QOS implementation. This part of the planning for QOS in the network is simply the logical application of the way QOS works in a network. For example, QOS provisioning requires routers that are either RSVP- or DSCP-enabled; so to provide end-to-end QOS provisioning, the routers in the path between QOS-enabled end nodes should be RSVP- or DSCP-enabled. Or, you can ensure that your routers are over-provisioned to a point at which data transmission delays won't occur.

Note: You can always over-provision network devices in the path where QOS-enabling is desired, and thereby circumvent the need for QOS on those devices. This is simply an application of the definition of QOS—loosely, data transmission quality through network devices that equates to unloaded network conditions. If you over-provision network devices (routers, WAN connections, and switches), they are essentially unloaded. This isn't a better use of network resources (as QOS provides), it's simply a partial or reduced use of network resources.

As we know from reading through much of this book, there is a diverse collection of network devices that contribute to the creation of an end-to-end QOS-enabled connection. Windows 2000 computers on either end of that connection certainly get the connection going (or respond to requests), but the gamut of network devices that may interact with RSVP messages that move across the network can be from any network vendor out there. Thus, their specific implementations can't be covered here. What can be covered in this chapter, however, are the steps you need to take (or to ensure that are taken) in your network to provide end-to-end network connectivity, and the Windows 2000-specific configuring that can get you most of the way to "QOS-enabled-dom." Most of that configuration is done with the QOS ACS and its associated policies.

Despite the seemingly sizeable undertaking that QOS-enabling a network can appear to be, part of any QOS implementation plan should be to keep in perspective the implementation plan and the QOS capability of the overall network. The perspective I'm suggesting is simply that you don't have to have every single network device QOS-capable before going ahead with QOS implementations. This can be a relief for budget-conscious or workload-conscious integrators and administrators.

QOS Implementation Checklist

Any implementation needs a plan. Even something as simple as installing a printer needs a plan—lest you end up with a printer that's fifty feet away from the servicing computer, requiring holes in walls to run an extremely long cable between printer and computer, and a printer that's right under the coffee pot (and not more perky with its morning cup of coffee). Whether simple or complex, you need a plan, and a plan should have some sort of checklist from which you can work.

The following sections provide lists of items you need to consider when planning for a QOS implementation in your network environment. When reviewing these lists, keep in mind that you can implement QOS capabilities in stages (perhaps based on a budget or on available IT personnel resources). In order to create a complete set of lists, however, you'll find a comprehensive set of must-do items in the following sections. When reading these must-do items, just remember that many of them can be tempered or reduced, based on mitigating circumstances (such as budgets).

Note: Some list items are required, even to get basic QOS capabilities. Such list items are suffixed with the term required. Make sure that these items are completed, even in staged QOS implementations.

On Clients

Clients include both the sender and receiver of QOS-enabled connections (often, a given QOS client is both sender and receiver).

  1. Install QOS Packet Scheduler on participating Windows 2000 clients—required.

  2. Implement QOS-enabled applications—required.

  3. Install 802.1p-capable NICs in QOS-enabled clients (Windows 2000 or other).

In the Network

The network is generally where you find the diversity of network devices, and many of the following list items require that you consult the installation guide for your given network device (such as a Cisco router) for proper configuration and, if appropriate, additional software packages to enable QOS.

  1. Install 802.1p-capable switches on LAN segments hosting QOS-enabled clients, and coordinate their installation with 802.1p-capable NICs on clients.

  2. Configure 802.1p-capable switches, and coordinate their configuration with QOS ACS/SBM configuration settings.

  3. Install QOS ACS/SBM on Windows 2000 Server computers on each subnet that hosts QOS-enabled clients, and ensure that the server is a member of the same domain as the subnet it intends to manage.

  4. Install QOS ACS/RRAS on Windows 2000 Server computers and on RRAS Servers hosting WAN connections.

  5. On each QOS ACS Server, create a user account called AcsService and add the account to the local Administrators group. (You can also create the account on a domain-wide basis.) In its Log On property sheet, set the Admission Control (RSVP) Service to log on with the AcsService account. Restart the service to put the change into effect—required.

  6. Install and configure RSVP or DSCP capabilities on routers.

  7. Ensure that boundary routers (those connected to external networks, which include any such WAN connections) are configured to properly tag (or re-tag) QOS-provisioned packets, according to the SLAs (Service Level Agreements) negotiated with external network service providers.

Service Level Agreements (SLAs) are agreements that your organization secures with networks to which your organization is attached (often an ISP). They specify how your QOS-enabled packets are treated as they cross that (ISP's) network. Generally, such SLAs require that packets coming from your network are tagged (such as with a specific DSCP value) according to the agreement, with charges associated with the transmission of better-than-best-effort traffic. The IETF has recommendations for SLAs, but the specifics of such agreements are, of course, based on the service provider to which your network is attached.

SLAs will be familiar to integrators who know ATM or Frame Relay provisioning (at least, the idea of such service-level guarantees), and associated service-level charges will be familiar. For more information on SLAs, check out the DiffServ working group's page on the IETF Website: https://www.ietf.org/html.charters/wg-dir.html.

Another item you should consider with network devices is the initiative to make network devices capable of interacting with Active Directory. As an LDAP-compliant directory service, Active Directory has the capability to centrally store configuration information for all sorts of software or devices. If network devices are capable of retrieving such information, your configuration effort might be considerably easier in a "store once, apply many" environment, such as an Active Directory-stored configuration profile. Cisco, for example, is working on efforts to enable interoperation with Active Directory. Before you spend too much time configuring your non-Windows network devices one-by-one, check your network device vendor's Web site to see whether it's Active Directory-ready.

Policies

Creating and applying policies are at the heart of the Windows 2000 QOS deployment, and they are often the most difficult tasks for an organization to complete. Despite the fact that the Policies list is short, policies are central to ensuring that your QOS deployment behaves the way you intend it to behave.

  1. Create enterprise-based QOS ACS policies, and augment them with subnet-specific or user-specific policies only as necessary—required.

More information on policy creation for QOS ACS, as well as a detailed step-by-step explanation of how to create policies, are provided in the "Creating Policies" section, later in this chapter.

Gauging Network Usage

Throughout the previous section on staging the implementation of QOS in your organization, there has been an underlying assumption—that you, the integrator or administrator, have knowledge about network usage in your organization. You must apply your knowledge of the use of your network infrastructure to the QOS staging that you do. For instance, if you have a FDDI or ATM backbone that's at 30% capacity and LAN segments that are nearing maximum capacity, you are better off replacing your LAN switches with 802.1p-capable switches and upgrading those segments' clients' NICs, rather than spending money on the backbone. Why? Because your backbone isn't at capacity, but your LAN segments are; you'd get more bang for your budgetary buck by upgrading the LAN segments first. Because the backbone can handle a lot more traffic, it's likely to behave somewhat similar to an "unloaded device." Thus, it isn't in as dire a need for QOS provisioning as your LAN segments are. (You can also apply this logic to WAN connections, individual router connections, and LAN segments.)

In fact, making decisions about which staging approach to take (or whether you need to stage the QOS implementation at all) requires that you have knowledge of network usage and capacity in your network. If you don't, your planning will be filled with gut-level guesses, and that's no way to implement a network. Educated guesses are much better, and educated guesses that are based on gathered data are better yet.

Part of your planning and implementation process must be to get a handle on network usage and capacity. But how do you get information about network usage? How are you supposed to have an education about network usage when those packets are too fast and slippery for you to get your hands on? There are a number of ways to do this, and some are more expensive and involved than others are. But there's one approach that can get you at least 90% of the way without spending an additional dime for expensive network-monitoring equipment: System Performance Monitor (formerly called Performance Monitor).

Note: System Performance Monitor enables you to monitor the activity—including the network activity—of any Windows NT or Windows 2000 computer. However, it won't help you monitor or gather data about the network activity of non-Windows (NT or 2000) network devices such as (non-Windows) routers or switches, or WAN interfaces. Therefore, you may need to get creative in the way you use System Performance Monitor to gather your performance data. For example, you may choose to monitor one particular Windows 2000 Server that houses an SQL server that is a candidate for QOS-enabled connections (in addition to the routers between that server and its clients). Other mechanisms are available for non-Windows devices, such as SNMP-based utilities and hardware-based monitors. System Performance Monitor will get you part of the way—a large part of the way, if you're creative—but there are limitations to its capabilities and to the network devices it can assess.

Using System Performance Monitor

System Performance Monitor, a tool that's included in Windows 2000 Server and Professional, enables administrators or integrators to track (in real-time, also known as current activity) the performance of almost every Windows 2000 node, component, feature, or capability that you can imagine (and some that you can't). System Performance Monitor has the capability to monitor everything on your Windows 2000 computer (or other Windows NT or Windows 2000 computers) that you might want to chart, monitor, track, log, report, or be alerted about. Included in that list of interrogating capabilities is extensive network monitoring information—the likes of which you can use to create a well-rounded vision of your network environment…provided that you use it wisely.

System Performance Monitor gets its data by gathering information from counters, all of which belong to associated objects. Counters are simply tick marks that monitor the activity of different software and hardware components, such as the percentage of time a CPU spends in privileged (kernel) mode or a given network interface's bytes/received per second. Objects gather counters into logical groups. For example, the counters titled % User Time and % Privileged Time (among others) are part of the Processor object. Counters are processed logically by Windows 2000, and their information is then displayed or gathered through System Performance Monitor's collection of data-gathering formats, which consist of the following System Performance Monitor views:

  1. Chart view

  2. Histogram view

  3. Report view

From any of those views, you can view either of the following types of data:

  1. Current Activity

  2. Log File Data

For gathering data that you can use to determine the best QOS deployment approach for your network, you'll be most interested in gathering data in the form of performance log files. After you save network usage data in the form of a log file, you can view that log file data in any of the three formats listed earlier (Chart, Histogram, or Report view).

Gathering Network Usage Data

Performance measurement is the process of gathering and analyzing data to find out where bottlenecks are located. In the case of gathering data about your network infrastructure, you need to choose a Windows NT or Windows 2000 computer of particular interest (or, more likely, choose a collection of them to get a more complete view of network usage for a particular part of your network). You then choose the appropriate counters from the list of available counters and begin to gather data.

With System Performance Monitor, you can gather data centrally from computers that are scattered about the network, as long as you have proper permissions to do so. To direct System Performance Monitor to gather data from a computer other than the computer you're using, simply tell it to do so in the Add Counters window, as shown in Figure 10.1.

Bb742476.image001(en-us,TechNet.10).gif

Figure 10.1: Adding counters from a remote computer.

The process for gathering data for log files used to be slightly different from viewing current activity. In Windows NT 4 (and earlier), you could choose individual counters and view their activity in any of the three view formats listed previously. With log files, however, you had to choose objects to include in the saved log file, and all counters associated with that object were saved during the course of saving the log file data. With System Performance Monitor, all that has changed. You now can choose individual counters to include in the logs, thereby reducing the size of the overall file. This avoids the previous requirement of having to choose all counters for a given object, even if you were only interested in one of its counters.

To create a log file, take the following steps:

  1. In the System Performance Monitor snap-in, select the Counter Logs node, found beneath the Performance Logs and Alerts parent node. Figure 10.2 shows where this can be found.

    Bb742476.image002(en-us,TechNet.10).gif

    Figure 10.2: The Counter Logs node in the System Performance Monitor snap-in.

  2. In the right pane, right-click somewhere in the pane, but not on an existing log file. You get a fly-out menu similar to the menu shown in Figure 10.3. Choose New, and then select Create New Log Settings from the menu.

  3. You are presented with a window that prompts you to name the file. After you provide an appropriate name, you are presented with a tabbed window, in which you can customize the log file to a detailed extent.

    Bb742476.image003(en-us,TechNet.10).gif

    Figure 10.3: Creating a new log file from the Counter Logs node of the System Performance Monitor snap-in.

By creating a set of log files (or one log file that gets executed on different computers), you can gather network utilization data that can help you figure out network usage in different areas throughout your network. However, there are some considerations to be given to the data you gather—because making sweeping decisions (or making judgments) based on a snapshot of data can get you in trouble. The next section explains how to take an appropriate approach to sorting through and making sense out of the network utilization data that you gather with System Performance Monitor.

Making Sense of Network Usage Data

A little bit of information can be a dangerous thing. This section is aimed at helping you make the safest use possible of the information you gather from System Performance Monitor. Perhaps most importantly, when analyzing the network data on which you plan to base your QOS implementation, you must take some steps to ensure that the data is as accurate and pertinent as possible.

  1. Be smart about your measurement period. If you're attempting to measure the network utilization of an RRAS Server during peak times, don't get a ten-second measurement at 12:00 pm and decide that the server has plenty of resources to service the link…and deem that it can be second-seat in your staged QOS implementation. Along those lines, don't get a ten-second measurement at 10:00 am (perhaps its peak time) and believe that it's indicative of the work in general. Short measurement periods can skew the results and make analysis work inconsequential. A better approach might be to monitor the RRAS Server over a couple of days during two hours of its peak period. Such a sample would be more indicative of actual usage and provide better insights to the actual network utilization that it's experiencing.

  2. Get a baseline. If you have nothing against which you can measure, how will you know whether network utilization is increasing, decreasing, or staying steady? This is also a good idea for ongoing usage because, as you'll notice when you start using System Performance Monitor, QOS has a number of counters associated with QOS ACS as well as other QOS components.

  3. Be wary of averages. In the earlier example, in which you're taking samples over a couple of hours, be careful not to simply take an average over the two hours and decide that network utilization is low or high. Although there may be some useful information in the generalities that you can derive from such averages, making the average your deciding factor for QOS implementation would be tantamount to ignoring important details. Look closely; there may be times of low activity (such as a break time that you weren't aware of) that are skewing a highly utilized or oversubscribed interface.

  4. Gather representative data. You need to make sure that the data you're gathering in the System Performance Monitor logs are representative of the conditions in the network area that you're interested in. If you're determining whether subnet A should be QOS-enabled, make sure that you aren't gathering data from a computer on subnet A that's unused most of the time. If you do, your data probably won't be representative of the actual network usage on subnet A. This goes for servers as well (for example, ensure that you aren't gathering data for a database server that houses only legacy data that's hardly used anymore).

With the data you can gather with System Performance Monitor (and other utilities, such as router logs or similar resources, if available), you can get a view of the network that is better than guesswork. Although it's difficult to get all-encompassing measurements of network activity, you can use available tools to at least make your guesses educated and thus more accurate.

If you're proactive and want to get QOS capabilities into your organization, you can gather this analysis data and present it to the decision-makers in your organization. Thus (if the data supports it), you provide a compelling set of real, hard data to back up your allegation that the network could really benefit from the implementation of QOS—and maybe you could even make some staging suggestions, as well.

Staging QOS Implementations

You don't have to implement QOS in every corner of your network to begin reaping the benefits of QOS. In fact, depending on your QOS requirements and as your resources allow, you can get significant QOS capabilities by staging the implementation of QOS in certain areas of your network. Then, as resources become available, you can implement additional QOS capabilities in your network until you have as much QOS functionality as your network deployment requires.

Note: If you need to achieve delay-sensitive data transmissions, such as those associated with Guaranteed Service, you need an end-to-end QOS-enabled connection (and you, therefore, probably need more than incremental QOS deployments in your organization). Such traffic is often called real-time traffic. Compare it to traffic that adapts easily to delays, such as best-effort traffic, which is sometimes also called elastic traffic. However, one approach to staging QOS implementations—point-to-point staging—can even help you get around the need for real-time traffic transmissions.

There are a number of different approaches that you could take in staging QOS in your network, but the most telling point that should be considered is this: Where can you get the most out of QOS? Different networks suffer from congestion in different areas: some in certain subnets, some in the backbone, and others have problems only in the path between two (or more) highly used resources. The following sections provide some guidance on how to partially implement QOS and reap significant benefit from its partial implementation (and perhaps extend QOS to the rest of the network later on). Regardless of whether you stage in subnets, in the backbone, or between a few points on the network, it's important to realize that even partial QOS capability in your network can get results.

LAN Segment Staging

One of the most overt abusers of network efficiency is the IP protocol suite itself. By its very nature, UDP (and TCP, to a certain extent) sends out data as fast as it can, clogging network interfaces and capacities with bursts. It would be better for the network if they would smooth themselves out a bit. The remedy is traffic control, which includes the smoothing of bursts and the shaping of traffic over time (among other things). Even if you only get traffic control going in heavily used subnets, you can immediately reap the benefits of QOS. Perhaps the simplest and quickest ways to gain the benefit of traffic control, as well as other QOS benefits in the subnet, is to start the implementation of QOS by staging its first deployment in the LAN segment.

To take the first step in LAN segment QOS staging, you need only to do the following:

  1. Install QOS Packet Scheduler on participating Windows 2000 clients.

  2. Install QOS ACS/SBM on Windows 2000 Server computers on each subnet that hosts QOS-enabled clients, and ensure that the server is a member of the same domain as the subnet it intends to manage.

  3. On each QOS ACS Server, create a user account called AcsService and add the account to the local Administrators group (you can also create the account on a domain-wide basis). In its Log On property sheet, set the Admission Control (RSVP) Service to log on with the AcsService account. Restart the service to put the change into effect.

  4. Create enterprise-based QOS ACS policies, and augment them with subnet-specific or user-specific policies only as necessary.

  5. Implement QOS-enabled applications.

This is a reasonably inexpensive, cost-effective approach to getting significant QOS capabilities into your network environment. Your only costs are those of the QOS ACS Servers, and they can be doing double- or triple-duty (or more). That is, you can have them act as a departmental file server and QOS ACS Server, thereby avoiding the need to deploy a dedicated Windows 2000 Server to QOS ACS. As with any Windows server, you should ensure that the server in question has enough resource capacity to service all of its required duties. You don't want to pick a file server that has its %CPU Time at 95% for your QOS ACS Server.

If you have more available resources for your LAN segment QOS staging or if want to increase the effectiveness of a LAN segment's staged implementation, you can also implement the following:

  1. Install 802.1p-capable NICs in QOS-enabled clients (Windows 2000 or other).

  2. Install 802.1p-capable switches on the LAN segment.

  3. Configure 802.1p-capable switches and coordinate their configuration with QOS ACS/SBM configuration settings.

Implementing these 802.1p capabilities is particularly effective for applications with small amounts of delay-sensitive traffic on LAN segments with large amounts of traffic. Remember that you must also use QOS-enabled applications to take advantage of QOS. So, if you're part of the department or IT management structure that determines which applications are used on the corporate desktop or if you have some input as to design guides for such implementations, ensure that QOS-enabling is part of the design requirements for your important (or QOS-needing) applications. Programmers can also impose traffic control (only) on a given application programmatically, without the need for RSVP signaling. See the QOS section on the Platform SDK at MSDN Online (msdn.microsoft.com) for specifics on how to do so.

Note: Remember from earlier chapters that if you have applications that are not QOS-enabled, their data will get treated by 802.1p as default data. Only applications that are QOS-enabled can potentially transmit data across a LAN segment at better-than-best-effort.

Network Infrastructure Staging

Some networks have sufficient bandwidth availability in their LAN segments. When it gets to the backbone, however, the traffic backs up, and (because the backbone is like the freeway system of the network) if you have to transmit data across the backbone and you're clogged up in the backbone, it doesn't matter that your LAN segments are below capacity. The data transmission will be slow. In such circumstances, you can take the following steps to help make better use of the clogged area in your network infrastructure:

  1. Install QOS Packet Scheduler on participating Windows 2000 clients.

  2. Install QOS ACS/SBM on Windows 2000 Server computers on each congested network segment, and ensure that the server is a member of the same domain as the subnet it intends to manage.

  3. On each QOS ACS Server, create a user account called AcsService and add the account to the local Administrators group (you can also create the account on a domain-wide basis). In its Log On property sheet, set the Admission Control (RSVP) Service to log on with the AcsService account. Restart the service to put the change into effect.

  4. Create enterprise-based QOS ACS policies, and augment them with subnet-specific or user-specific policies only as necessary.

  5. Install and configure RSVP or DSCP capabilities on affected routers.

  6. Implement QOS-enabled applications.

Note: Make sure that you read that second point correctly because it's different from its earlier versions. The need to install and configure QOS ACS on the subnets is due to its "gatekeeper" nature. However, the LAN segment on which you install the QOS ACS can be your congested network backbone, rather than client subnets. In doing so, you regulate QOS-enabled traffic on that segment, and enable the application of QOS policies for traffic crossing that particular subnet.

Point-to-Point Staging

There are other QOS-enabling circumstances that can easily be imagined, among those the need to have QOS provisioning between specific end nodes or specific LAN segments on the network. In such a situation, you can stage QOS implementation so that all network devices and subnets in the path between certain sets of end nodes (such as those on segment A and segment K) are QOS-enabled. The rest of the network comes online with QOS capabilities as budgetary or workload constraints allow.

For a quick point-to-point example, suppose that you have a training department that is connected to a certain part of the network, with video servers that reside in another (centrally located) building. Three routers sit between the training department and the video servers. With point-to-point staging, you can QOS-enable the point-to-point connection (the affected network devices and subnets) between the two locations and get the QOS you need for the training department.

For point-to-point staging, you need to take the following steps:

  1. Install QOS Packet Scheduler on participating Windows 2000 clients.

  2. Install 802.1p-capable NICs in QOS-enabled clients (Windows 2000 or other) that require point-to-point QOS capabilities.

  3. Install 802.1p-capable switches on LAN segments hosting QOS-enabled clients that require point-to-point.

  4. Configure 802.1p-capable switches and coordinate their configuration with QOS ACS/SBM configuration settings.

  5. Install QOS ACS/SBM on Windows 2000 Servers on each subnet with clients requiring point-to-point QOS capabilities, and on each subnet over which data will need to be transmitted between end points. Ensure that the QOS ACS Server is a member of the same domain as the subnet it intends to manage.

  6. On each QOS ACS Server, create a user account called AcsService and add the account to the local Administrators group (you can also create the account on a domain-wide basis). In its Log On property sheet, set the Admission Control (RSVP) Service to log on with the AcsService account. Restart the service to put the change into effect.

  7. Create enterprise-based QOS ACS policies, and augment them with subnet-specific or user-specific policies only as necessary.

  8. Install and configure RSVP or DSCP capabilities on routers in the point-to-point path.

  9. Install QOS ACS/RRAS on Windows 2000 Server computers on RRAS Servers hosting WAN connections.

  10. Implement QOS-enabled applications.

After you have a point-to-point QOS stage implemented, bringing other point-to-point stages online can become less resource-intensive because some of your subnets or backbones may already be QOS-enabled. To extend the previous example, if the sales department needs to use the video servers, you can QOS-enable the sales department's point-to-point connection by QOS-enabling the sales subnets and any routers between their subnet(s). You can also QOS-enable the video servers that weren't already QOS-enabled in the first point-to-point stage, and they will be QOS-enabled. Because the video servers and their subnets were already QOS-enabled, a portion of the work necessary to QOS-enable the sales department subnet was already complete.

Other Must-Read Staging Considerations

Which of the QOS staging techniques is best? The answer depends on your network's needs, your resources, and your general disposition about QOS-enabling your network. By approaching QOS in stages, you can minimize the resource impact of QOS deployments while still reaping the benefits of partial QOS provisioning. Each of these staging ideas is flexible and should be molded to your own needs.

These approaches to staging QOS deployments were derived by applying the QOS mechanism logic to the ways you can go about staging QOS implementations. There are other approaches to staging, and some of them might be much better than any of the suggestions that are provided here. You might, in fact, come up with an approach that's better than any of them; if so, use it! While you're at it, share it with others, so they can benefit as well. These suggestions aren't meant to be hard-and-fast rules; they're meant to help get QOS running on your network without having to flip your entire network (or your budget) upside down. The suggestions also illustrate that you can get imaginative with QOS deployment and get some use out of the technology without buying 20 new $200,000 routers.

The must-read part of this section is twofold: These staging ideas should be tailored to your network needs and they are simply applications of QOS implementation logic. If you come up with a different approach to getting QOS incrementally deployed in your network that fits your network needs more closely than any of these staging approaches, you have probably found the best staging approach for your network.

Also, remember that you don't have to stage QOS implementations. You can go ahead with a plan that converts the entire network to QOS in one large undertaking, but that's probably less common than planning incremental stages. With this section, you've been provided with a handful of ideas to get that QOS implementation plan moving ahead.

Configuring QOS ACS on the Windows 2000 Server

When we consider discussions from earlier in the book—discussions that explain the logical path that RSVP messages take in their journey between end nodes—we remember that the first step in a Windows 2000 client's request process (and the last step in the granting process) is QOS ACS. QOS ACS acts as a sort of gatekeeper, through which QOS-enabled clients on its LAN segment must pass before any QOS provisioning can occur. This provides it with the unique opportunity to be gatekeeper and keymaster (in loose, "ghostbusterish" terms). It can be the point at which QOS requests from cooperative Windows 2000 clients can be rejected or approved.

As a result of QOS ACS's pivotal role in QOS provisioning, almost all the configuration-associated Windows 2000 QOS is achieved through configuring the QOS ACS with policies that reflect the configuration that your organization wants to implement for a given enterprise, with additional policies created for individual users or groups.

Creating Policies

The approach to creating policies for QOS ACS is simple: Create wide-reaching enterprise-level policies and augment those policies on an as-needed basis by creating specific policies for user, groups, or particular subnets. This approach enables administrators to get the most results from the least amount of work; rather than requiring all users or groups to have their own policy configurations, administrators can cover everyone (in a blanket policy) and deal with the exceptions.

The creation of policies fall into the following categories:

  1. Enterprise-wide policies

  2. Subnet-specific policies

Within each category, two default policies are always available, and should be specified on an enterprise-wide basis:

  1. Any Authenticated User

  2. Un-Authenticated User

There are a couple of definitions that need to be explained regarding the two default policies. You need to pay special attention to these explanations because there can be some provision-limiting effects of misinterpreting these default policies.

  1. Any Authenticated User: This policy applies to any user who has been authenticated in a trusted domain and who is requesting QOS provisioning from a Windows 2000 client.

  2. Un-Authenticated User: This policy applies to any user who doesn't fall under the previous policy. This includes users who are authenticated to a trusted domain, but who are not running on a Windows 2000 computer. The policy also applies to clients on Windows 2000 computers who are not authenticated to a trusted domain (they could be authenticated to a Windows 2000 domain, but to an untrusted domain).

Because there is a collection of different policies that could apply to a given user (or group), QOS ACS has a progression by which it authenticates users or groups, and to which the policy or policies that their QOS provisioning request applies. The following list describes the steps through which QOS ACS applies policies:

  1. User-specific policies in the given subnet

  2. Group-specific policies in the given subnet

  3. Any Authenticated User policies in the given subnet

  4. User-specific policies defined for the enterprise

  5. Group-specific policies defined for the enterprise

  6. Any Authenticated User policies defined for the enterprise

To paraphrase this hierarchical list of policy implementation, it goes from the most specific for a given locale (subnet), to the least specific for the entire enterprise. The application of this hierarchy and its implications for the creation of subnet-specific policies are discussed further in the next few sections.

Creating Enterprise-Wide Policies

The best approach to creating policies for QOS ACS is to start with a general all-encompassing policy and to add exceptions to that policy as needed. With QOS ACS, that means starting with enterprise-wide policies.

In order to create enterprise-wide policies, you need to have properly installed QOS ACS as a member of the same domain that you intend it to manage. You must have created the AcsService user account, added it to the local Administrators group, and then configured the Admission Control (RSVP) Service to log on with that AcsService account. As long and drawn-out as that process is, it's necessary to get QOS running on the Windows 2000 Server (and it's a security issue as well, so it could be considered a benefit). Once those requisite steps have been taken, you can create enterprise-wide policies by taking the following steps:

  1. Launch the QOS Admission Control snap-in. This is generally found by clicking the Start button, and choosing Programs, Administrative Tools, QOS Admission Control. As always, there is more than one way to do just about everything in Windows, so you can launch the QOS Admission control snap-in from a number of different locations (including the Control Panel). The window that appears looks similar to Figure 10.4.

    Bb742476.image004(en-us,TechNet.10).gif

    Figure 10.4: The QOS Admission Control snap-in.

  2. Select the Enterprise Settings node (folder) to display its contents. Included are the two default policies: Any authenticated user and Un-authenticated user. Choose the first policy you want to define; and either double-click on it, or right-click on it and choose Properties from the fly-out menu that appears.

  3. You are presented with a window that has multiple property sheets, as seen in Figures 10.5, 10.6, and 10.7. By defining the settings on these property sheets, you set the enterprise-wide policy for the users that fit that policy's description.

    Bb742476.image005(en-us,TechNet.10).gif

    Figure 10.5: The General property sheet, associated with setting enterprise-wide policies.

    Bb742476.image006(en-us,TechNet.10).gif

    Figure 10.6: The Flow limits property sheet, associated with setting enterprise-wide policies.

    Bb742476.image007(en-us,TechNet.10).gif

    Figure 10.7: The Aggregate limits sheet, associated with setting enterprise-wide policies.

  4. After these policies are filled in, you have officially created an enterprise-wide policy. Remember to configure both of the default enterprise-wide policies.

Note: It's important to remember that some Windows 2000 domain-authenticated users can fall into the Un-Authenticated Users policy. This policy applies not only to unauthenticated users (users who are not members of a trusted domain), but also to users who may be members of a downlevel domain. It can also include non-Windows 2000 clients that are actually authenticated in a trusted domain.

Creating Subnet-Specific Policies

If specific needs within a subnet differ from policies made on the enterprise level, such exceptions can be specified for specific subnets. To define specific policies within a given subnet, take the following steps:

  1. Launch the QOS Admission Control snap-in. This is generally found by clicking the Start button and selecting Programs, Administrative Tools, QOS Admission Control.

  2. Select the subnet for which you want to create the specific setting (creating subnets is explained later in this chapter). Similar to the Enterprise Settings folder, the specific subnet includes two default policies: Any Authenticated User and Un-Authenticated User. Choose the policy you want to define, and either double-click it, or right-click it and choose Properties from the fly-out menu that appears. The window that appears looks similar to Figure 10.8.

    Bb742476.image008(en-us,TechNet.10).gif

    Figure 10.8: The QOS Admission Control snap-in, with the subnet-based Any Authenticated User fly-out menu displayed.

  3. You are presented with the same policy configuration window that was displayed when you created enterprise-wide policies, along with its accompanying property sheets. By defining the particular setting that you want to modify on the appropriate property sheet and leaving the remaining settings as Use Default Policy Setting, you implement the subnet-particular setting without having to redefine the policy settings that apply to the entire enterprise (thus saving your work).

That's all there is to making subnet-specific changes to the two default policies found in each subnet: the Any Authenticated User policy and the Un-Authenticated Users policy.

If there is one piece of information that you should remember about creating specific policies (instead of using default enterprise-wide policies), it should be this: You need only to define specific variations from the enterprise-wide policies—you don't have to define all aspects of the policy. In other words, if you only need to increase the peak data rate for a given subnet, then you can define that particular field in the subnet-specific policy (such as the Any Authenticated User policy in a specific subnet). You can let the rest of the fields remain set to Use Default Policy Settings.

Creating User-Specific or Group-Specific Policies

The guidelines for creating user- or group-specific policies are similar to the guidelines for creating subnet-specific policies. Only create them if you need to, and only change the particular settings that deviate from the enterprise-based or subnet-based policies, as appropriate. For example, if you only need to modify a particular user's data rate for guaranteed service on a given subnet, then make only those changes and leave the rest of the parameters in the policy configuration sheets set to Use Default Policy Settings.

There are a couple of points, really clarifications, to keep in mind when you create user- or group-specific policies:

  1. User- or group-specific policies that are created as enterprise-wide policies apply throughout the entire network (the enterprise). That's pretty straightforward.

  2. If you create user- or group-specific policies in a subnet node, those policies apply only to that specific subnet and only to traffic traversing that subnet.

  3. If possible, limit these user- and group-specific variations to each subnet.

If the guidelines are similar to creating subnet-specific policies (and they are), then the steps you need to take are essentially identical, with one exception: you create a new policy, rather than modifying the properties of an existing (provided-by-default) policy. The steps to doing so are as follows:

  1. Launch the QOS Admission Control snap-in. This is generally found by clicking the Start button, and selecting Programs, Administrative Tools, QOS Admission Control.

  2. Select the scope in which you want your specific setting to apply (enterprise-wide or subnet-specific), and right-click on its node (the Enterprise Settings folder or the particular subnet in which you want the policy to be created). A fly-out menu appears, at the top of which is the Add Policy menu item, as seen in Figure 10.9. Choose the Add Policy menu item.

  3. You are presented with the same policy configuration window that was displayed when you created other policies, along with its accompanying property sheets. By defining the particular setting that you want to modify on the appropriate property sheet and leaving the remaining settings as Use Default Policy Setting, you implement the user- or group-specific settings that you want. You don't have to redefine the policy settings that apply to the subnet or the entire enterprise (again, saving you work).

    Bb742476.image009(en-us,TechNet.10).gif

    Figure 10.9: The Add Policy menu item in a particular subnet's folder.

Managing Subnets

With policies defined or created, the piece of the configuration puzzle that remains is associating the QOS ACS Server with its managed subnet. Specifying the subnet that a given QOS ACS Server is going to manage is fairly straightforward, but it requires a little explanation to clarify the bounds within which it must operate.

As mentioned previously in this chapter, the QOS ACS must be a member of the same domain as the subnet it intends to manage. This requirement is due to the interaction of QOS (and everything else in Windows 2000) with Active Directory (as the "Deleting Managed Subnets" section, later in this chapter, evinces).

There are two primary activities associated with QOS ACS management of subnets:

  1. Creation of a managed subnet

  2. Assignment of servers eligible to manage the subnet

For those of you who occasionally make a mistake during the course of preliminary configurations (who doesn't?), there is a third activity that is a little less than intuitive. To save you the grief of trying to find out how to do this by trial-and-error, I'll include it in this chapter as well:

  1. Deletion of a (created) subnet

Creating Managed Subnets

In order to manage a given subnet, the subnet must be created. One way of doing this is through the QOS Admission Control snap-in. Take the following steps to create a subnet for QOS ACS management:

  1. Launch the QOS Admission Control snap-in. This is generally found by clicking the Start button, and selecting Programs, Administrative Tools, QOS Admission Control.

  2. Right-click the Subnetwork Settings node. A fly-out menu appears, at the top of which is the Add subnetwork menu item, as seen in Figure 10.10. Choose the Add subnetwork menu item.

    Bb742476.image010(en-us,TechNet.10).gif

    Figure 10.10: The Add subnetwork menu item from the Subnetwork Settings node.

  3. When you select the Add subnetwork menu item, you are prompted to enter the IP address of the subnet you want to add. Then, unless you've done it a number of times, you are confronted with the dialog box seen in Figure 10.11. Once you get it right, the subnet is added to the Subnetwork Settings node, and you can set management options on it.

    Bb742476.image011(en-us,TechNet.10).gif

    Figure 10.11: You put in the IP address of the subnet incorrectly. So does everyone else.

Reading Binary Rather than doing a hit-and-miss with the input of the subnet name, take a few steps to help you get it right as quickly as possible:

  1. Ensure that the slash (/) is going the right way.

    Translate the subnet address into binary, translate the mask into binary, and derive the appropriate input for the IP address window from that combination.

    Here's an example taken right from the dialog box. If you have a subnet with an IP address (when masked) of 255.14.252.0, then the subnet has the following binary IP address:

11111110.00001110.11111100.00000000

The confusing sin of omission that is being committed here is that the IP address of your subnet should be discussed in conjunction with your subnet mask. In this example (and in the dialog box), the foregone conclusion is that you have the following network mask:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

11111111.11111111.11111100.00000000

That means, in more common (decimal) terms, you have a network mask of 255.255.252.0.

For a quick translation from decimal into binary, the binary version is derived from adding the following values for each bit position (based on whether the bit is set to 1) for each octet (an octet is the period-delimited set of eight bits):

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

0 0 0 0 0 0 0 0 [128] [64] [32] [16] [8] [4] [2] [1]

In our example, the first octet is the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

11111110

So, we add the values for the bit positions as follows:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

128 + 64 + 32 + 16 + 8 + 4 + 2

The last value is decimal 1, which happens to be the decimal addition value as well as the binary value to which the bit is set (in this case, we're looking at its decimal addition value). It isn't added because the bit in that position of the octet is set to zero. When we add all those together, we get 255, which is the value of the first octet in the 255.14.252.0 address. Other numbers can be generated similarly; in fact (or of course, depending on your level of experience with reading binary) any value between zero and 255 can be generated by a combination of eight bits. Add one more bit, and you double the numbers that can be generated by the combination of bits (nine bits have 512 different combinations, 10 bits have 1024, and so on).

Therefore, if your subnet mask is 255.255.252.0, your mask (of ones) is the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

11111111.11111111.11111100.00000000

Because the 252 equates to the setting of the first six bits in its octet to one (or in decimal terms, equates to 128+64+32+16+8+4).

How does this apply to the WWW.XXX.YYY.ZZZ/MM format that QOS ACS is looking for? Simple: You have to count the number of bits set to 1 in your subnet mask (starting from the front, or, more intuitively, from the LEFT of the series of octets). That number is the MM that QOS ACS wants after the / (that's a forward slash, remember, not a backslash). In our example's case, that means 8 (the first octet is all 1s), plus 8 (so is the second), plus 6 (in the third octet, 6 bits are set to 1)—for a grand total of 22.

Clear as mud, right?

Assigning Servers to a Subnet

Once you have created a subnet, you can assign one or more servers to manage it. The designation of QOS ACS Servers permitted to manage a given subnet is done from within the subnet's Servers property sheet. Take the following steps to bring up a given subnet's Servers property sheet:

  1. Launch the QOS Admission Control snap-in. This is found by clicking the Start button; then selecting Programs, Administrative Tools, QOS Admission Control.

  2. Right-click on the Subnetwork Settings node. A fly-out menu appears and the Properties menu item appears in bold. Choose the Properties menu item.

  3. When you select the Properties menu item, a window with five property sheets appears, as seen in Figure 10.12. Choose the Servers property sheet, choose Add, and select the Windows 2000 QOS ACS Servers you want enabled to manage the subnet.

    Bb742476.image012(en-us,TechNet.10).gif

    Figure 10.12: The Servers property sheet from a subnet Properties window.

It's a good idea to provide redundancy for QOS ACS within a given subnet, which can be done by enabling more than one QOS ACS Server to manage any given subnet. You can then install (and have running) a second QOS ACS Server; if the primary QOS ACS Server fails, the backup QOS ACS Server can automatically take its place until the failed server is brought back online. Because subnet policies are stored centrally in Active Directory, the secondary QOS ACS Server can simply retrieve any subnet-specific policies (as well as enterprise policies) and provide seamless QOS ACS service to the subnet.

Each QOS ACS Server manages each subnet for which it has a local IP address. If a QOS ACS Server has a single NIC with two IP addresses (each logically connected to different IP subnets residing on the same physical wire), the QOS ACS Server will manage each of those IP subnets. If the QOS ACS Server has multiple NICs connected to different physical wires (a multi-homed computer), the same rule applies. The QOS ACS Server will manage each IP subnet for which it has an IP address. The rule, then, is as follows: QOS ACS Server manages each IP subnet to which it is logically connected.

Deleting Managed Subnets

Because you could sprain a finger trying relentlessly to delete a subnet that you created in the QOS Admission Control snap-in, without success, a quick explanation here is aimed at preventing weeks of finger-casts. You can't delete a subnet from the QOS Admission Control snap-in. Because the creation of the subnet is something that Active Directory apparently holds dear, you must go into the Active Directory Sites and Services snap-in to do so, as the following steps explain:

  1. Launch the Active Directory Sites and Services snap-in. This is found by clicking the Start button; then choosing Programs, Administrative Tools, QOS Admission Control.

  2. Expand the Sites node, expand its Subnets node, and choose the subnet you want to delete.

  3. From the keyboard, toolbar, or Action menu, choose delete. You will be prompted that your action is going to delete all the items in its container (including any subnet-specific policies you created). If you're sure, click okay to delete the subnet.

QOS for Non-Windows 2000 Clients

Much of Windows 2000 is based on open standards, and QOS ACS is no exception. QOS ACS is an implementation of the IETF SBM recommendation. Because it is standards-compliant, non-Windows clients that adhere to the SBM standard can also take advantage of QOS ACS capabilities. Note that these non-Windows clients will be seen as Un-Authenticated Users to QOS ACS, as will Windows clients that are not Windows 2000 clients.

About the Author

David Iseminger is an individual consultant at Microsoft, and has worked on Windows NT and Windows 2000 (since Windows NT 3.5) as a networking and router performance analyst, telecommunications specialist, and performance tool developer. He works with Microsoft's Developer Documentation Group as a programming writer, creating and maintaining many of the Platform SDK's established and emerging networking technologies, including Quality of Service. Currently, David writes a handful of books a year, including both nonfiction computer books and novels.

Copyright © 1999 by New Riders Publishing, Pearson PTR

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Link
Click to order