QoS Policy Manager (QPM)
QPM provides many of the features that you need when you get serious about deploying QoS across an enterprise. The following list summarizes some of the more important features:
Enables you to define a QoS policy based on business rules.
Automatically configures some or all network devices with QoS features, based on the QoS policy described to QPM. The features that QPM enables include marking, queuing, shaping, policing, and Link Fragmentation and Interleaving (LFI) tools.
Loads the correct configurations automatically.
Enables you to monitor the device configurations to make sure no one has made changes to them. If the configurations have been changed, you can use QPM to restore the original configuration.
To get a sense of how QPM eases QoS configuration, imagine that you want to create a policy to mark all VoIP traffic with DSCP EF as near to the edge of the network as possible. You simply point and click to tell QPM what fields to look for in the packet or frame header. QPM creates the CB Marking configuration and loads it into all the appropriate devices. So, to use QPM, you still need to know what the base QoS tools can do, but you do not have to know the configuration syntax of all the different QoS tools, and you do not have to repeat the configuration task on all the devices—QPM takes care of that for you.
QPM runs on Microsoft Windows 2000 Professional or Server with Service Packs
3 or 4, or with Microsoft Windows Advanced Server (without terminal services).
(See
http://www.cisco.com/en/US/partner/products/sw/cscowork/
ps2064/products_user_guide_chapter09186a0080080808.html#4048
for the hardware and software requirements of the latest release of QPM, version
3.2, as of press time.)
To configure a common QoS policy and push this policy to the network devices, QPM needs to be able to learn which devices are present in the network and communicate with those devices. QPM can use the CiscoWorks database to discover the location of the devices in the network.
Figure 3-2 outlines the overall location and functions between the QPM server and the rest of the network.
)
Figure
3-2 QPM Server and Communication with Other Devices
For QPM to create configurations, load the configurations, and monitor the configurations for changes, QPM must know which devices it should manage. The most convenient way to define the devices for QPM to manage is to use the device list from the CiscoWorks2000 database. Cisco requires that QPM be installed on a machine that also has CiscoWorks Common Services 2.2, with Service Pack 2, which allows QPM to automatically discover the network devices; however, you can statically define devices to QPM as well.
QPM is an important tool for networks that deploy QoS extensively. The following list outlines some of the more popular features:
Supports a wide variety of routers and switches
Allows network-wide QoS policy definition, followed by automatic deployment of appropriate configurations
Creates graphs of real-time performance
Creates graphs of historical performance
Allows end-user viewing of reports and configuration using a web browser
Manages only a single device from the browser
Manages the entire network from one browser window
Implements the actual probes and responses when necessary for measuring network performance
SNMP Support for QoS
QPM uses Telnet and the Simple Network Management Protocol (SNMP) to configure and monitor devices. Cisco IOS includes a couple of important proprietary SNMP Management Information Bases (MIBs) that provide a lot of good information about QoS performance in a router. When QPM displays performance data for MQC-based QoS tools in a router, the performance data comes mostly from these specialized QoS MIBs.
First, the Class-Based QoS MIB (CBQoSMIB) contains variables that describe the MQC configuration commands in a router. This MIB also includes statistical variables, which are essentially the same kinds of stats seen with the show policy-map interface command.
More interestingly, CBQoSMIB goes beyond those statistics, providing statistics for packets before a policy map has been processed, and afterward. In other words, you can see statistics about packets before the PHBs have been applied and after they are applied. QPM, of course, knows about this MIB, so it is ready to show graphs of packet statistics comparing the pre- and post-policy map.
Network Based Application Recognition (NBAR) can be used by MQC class-map commands to help classify traffic. NBAR can also be used to simply recognize and count traffic based on different protocol types. Of particular interest, NBAR can recognize hard-to-recognize protocols that do not use well-known ports, or that use dynamically allocated port numbers, by looking past the TCP and UDP headers into the application layer protocol. So, NBAR provides some interesting statistics about what protocols might be running through a network. (Chapter 4, "Classification and Marking," covers NBAR in much more detail.)
You can look at NBAR statistics for different protocols with the show nbar protocol-discovery command from a router; however, IOS includes the Cisco NBAR Protocol Discovery (CNPD) MIB, making the same statistics available from CiscoWorks and QPM. In particular, when planning a QoS implementation, NBAR can be a useful tool for figuring out what protocols are actually being sent through the network. The CNPD MIB can be used to easily graph and track the counters to decide how much bandwidth is needed for each particular type of application.
An engineer has a great set of tools for configuring and managing QoS with MQC at the command line, and QPM and these specialized MIBs from the management station. However, Cisco has one other significant tool that aids in QoS implementations, called AutoQoS, which will be covered in the last section of this chapter.