Table of Contents

QoS Analysis Tutorial

These topics help you understand how to use QPM monitoring to analyze the effect of your QoS policies on your network traffic. By graphing traffic based on how it matches the filters in your policies, QPM helps you see the types of traffic on your network as well as how the traffic is modified by the policies. This can help you adjust your policy definitions to obtain the desired impact on traffic.

• Understanding QPM Monitoring
  
  
• Lesson 4-1: Doing a Baseline Traffic Analysis
  
  
• Lesson 4-2: Monitoring QoS
  
  
• Lesson 4-3: Monitoring QoS in Real Time
  
  

Understanding QPM Monitoring

QPM monitors traffic based on the QoS policies that have been distributed to network interfaces using QPM. QPM cannot monitor traffic on interfaces that do not have QoS policies, or on interfaces where QoS policies have been defined by other means.

These topics help you understand QPM's monitoring capabilities.

• What is the Purpose of QoS Analysis?
  
  
• What Can You Monitor Using QPM?
  
  
• What Is the Difference Between Historical and Real-Time Monitoring?
  
  
• How Much Disk Space Is Required for Historical Monitoring?
  
  

What is the Purpose of QoS Analysis?

QoS Analysis serves these main purposes:

• Baseline Traffic Analysis—The analysis of your existing traffic patterns before they are affected by QoS policies. Creating a baseline traffic analysis helps you understand your existing traffic, based on DiffServ classes or applications, so that you can develop QoS policies that are meaningful for the actual traffic on your network. Lesson 4-1: Doing a Baseline Traffic Analysis describes how to do baseline traffic analysis.
  
  
• QoS Analysis—The analysis of how your QoS policies are affecting network traffic. By monitoring QoS policies, you can determine if they are affecting traffic in the desired way, or if the policies need to be adjusted. Lesson 4-2: Monitoring QoS describes how to do QoS analysis.
  
  
• QoS Troubleshooting—The real-time analysis of traffic on an interface, based on QoS policy, to help you determine if a problem you are having on an interface is related to the QoS policies that are active on the interface. Lesson 4-3: Monitoring QoS in Real Time describes how to do real-time monitoring.
  
  

What Can You Monitor Using QPM?

You can monitor the traffic on any interface on which you have distributed QoS policies using QPM. These policies do not have to be created using QPM. If you already have QoS policies defined on your interfaces, you can use QPM to import the policies, and then have QPM redistribute the policies to the interfaces. This action does not change the policies on the interface; it simply makes QPM aware of the policies. It also lets you thenceforth use QPM to modify and redistribute these policies.

If you do not already have QoS policies defined, you can use QPM to create a set of QoS policies that do not affect traffic to categorize traffic and help you establish a baseline for the traffic on your network, as described in Lesson 4-1: Doing a Baseline Traffic Analysis. Or, if you already know what you want to do with QoS, you can create QoS policies that do affect network traffic and monitor the results, as described in Lesson 4-2: Monitoring QoS.

What Is the Difference Between Historical and Real-Time Monitoring?

QPM has two types of monitoring: historical and real-time. Historical monitoring is best used when you want to collect a lot of data over several hours, days, or even months. Real-time monitoring is best used for immediate troubleshooting. Table 4-1 shows some differences between the types of monitoring.

How Much Disk Space Is Required for Historical Monitoring?

Historical monitoring tasks can create a large amount of data. For example, an historical monitoring task for two interfaces that each have three policies (each with two conditions in the filter and one action), with a polling interval of 10 minutes, would generate approximately 600KB if run for 32 hours. The same task would generate 3000KB if the polling interval was reduced to 2 minutes.

These would both be considered small tasks. An historical monitoring task for 12 interfaces that each have six policies (each with one condition in the filter and two actions), with a polling interval of 10 minutes, would generate 66MB if run for ten days.

These are the factors that increase disk space usage for each historical monitoring task:

• Number of interfaces monitored—The more interfaces, the more data is collected.
  
  
• Number of policies—The policies on each interface are considered unique policies. For example, if you deploy the same five policies to ten interfaces, the total number of policies is 50, not five.
  
  
• Number of filters—Separate statistics are collected for each filter condition in a policy.
  
  
• Number and type of actions—Separate statistics are collected for each action in a policy. The amount of data also differs based on the type of action; for example, complex actions like policing (three counters) or WRED (21 counters) generate more data than simple queuing (one counter).
  
  
• Polling interval and duration—QPM collects a complete set of data during each polling interval, so the more frequent the polling interval, and the longer the task is run, the more data is collected. Due to the amount of data that can be generated, QPM limits the duration of tasks based on the polling interval; QPM will tell you if you select a duration too long for the polling interval. See User Guide for CiscoWorks QoS Policy Manager 3.0 for the specific limitations.
  
  

The polling interval and duration can also affect how many concurrent tasks you can run. In general, you should run concurrent tasks on a representative sample of your WAN interfaces. If you choose a polling period of 1 minute, you should not collect data on more than 50 interfaces. If you select longer polling periods, you can analyze more interfaces.

When you install QPM, you specify how much free disk space should be maintained for database backups. If you leave insufficient space, monitoring tasks might use up your disk space. If this happens, all historical monitoring tasks stop and you must delete them. Thus, you should manage the disk space used by historical monitoring tasks by:

• Selecting realistic polling intervals and durations
  
  
• Periodically deleting old tasks when you are finished analyzing the data
  
  
• Exporting old tasks if you want to save the data
  
  

Lesson 4-1: Doing a Baseline Traffic Analysis

Before you develop QoS policies, you might want to analyze your existing network traffic to help you determine the types of policies from which your network might benefit. To monitor your existing network traffic using QPM, you must first deploy QoS policies to the interfaces you want to monitor. These policies should filter traffic into meaningful groups, but they should not affect the traffic.

These topics explain how to set up a baseline traffic analysis in more detail:

• Understanding How to Monitor Traffic for Baseline Analysis
  
  
• Step 1: Filtering Traffic for Analysis
  
  
• Step 2: Setting Up an Historical Monitoring Task
  
  
• Step 3: Reading the Historical Monitoring Graphs
  
  

Understanding How to Monitor Traffic for Baseline Analysis

QPM can only monitor traffic if the traffic meets the filter requirements of a QoS policy. Thus, to create graphs that show your existing network traffic, you must deploy QoS policies to each network interface where you want to take a baseline reading. These QoS policies should filter traffic without affecting the traffic.

You can use class-based policing policies to accomplish this type of filtering. Specifically, the policing policies should have these characteristics:

• QoS Property for the policy group—Select Class-Based QoS for the scheduling method for the policy group.
  
  
• Filters—Try to isolate types of traffic on your network that you will want to treat the same way. For example, you might create a filter for applications that require real-time performance (such as voice and video), another filter for important data-intensive applications (such as database, CRM, or other ERP traffic), and another filter for traffic that is not critical to your business (such as Gnutella traffic). Each network has its own definition of critical versus non-critical traffic, so use your knowledge of the network to filter traffic into meaningful groups.
  
  
• Actions—Set the Rate, Burst Size, and Exceed Burst policing rates to 8.0 Kbps. Set both the Conform and Exceed actions to Transmit. This ensures that all traffic is transmitted without the policies affecting the traffic.
  
  

Related Topics

• Step 1: Filtering Traffic for Analysis
  
  
• Understanding QPM Monitoring
  
  

Step 1: Filtering Traffic for Analysis

Before you can do a baseline analysis of the traffic on an interface, you must create a policy group with the interfaces and an appropriate set of policies. The policies filter traffic into analyzable groups.

Before You Begin

This step assumes you have already added devices and interfaces to QPM, and that you have created a deployment group. The lessons in Introduction and Data Network Tutorial describe how to define these items in QPM.

As you follow this procedure, you must substitute your own device names and constraints for the example names and constraints. Also, modify the policy filters to make them meaningful for your network; the examples shown might not provide you with meaningful baseline information for your network.

Procedure

Step 1   Select Configure > Policy Groups. The Policy Groups page appears.

Step 2   Select your deployment group from the Deployment Group list box.

The page refreshes to display the policy groups in the deployment group, if any.

Step 3   Create the policy group:

Step 4   Select Class-based QoS as the QoS property for the policy group:

Step 5   Assign network elements to the policy group:

Step 6   Create the policies to filter traffic into meaningful groups. In this example, we will create five policies. The policy characteristics are described in Table 4-2. This procedure will show you how to create the EF policy. Repeat the process to create the other policies.

Step 7   Select Deploy > Deployment and follow the wizard to deploy the policy group. See Lesson 2-6: Deploying the Data Network Tutorial Policies and Lesson 2-7: Monitoring the Deployment Process for more detailed information on deploying policies and monitoring the deployment.

Proceed with Step 2: Setting Up an Historical Monitoring Task.

Related Topics

• Understanding How to Monitor Traffic for Baseline Analysis
  
  

Step 2: Setting Up an Historical Monitoring Task

This step describes how to set up and run an historical monitoring task.

Before You Begin

You must use QPM to deploy policies to an interface before you can use QPM to monitor the interface. The policies you deploy do not have to affect the traffic, they just have to filter the traffic. Step 1: Filtering Traffic for Analysis, describes how to create QoS policies that do not affect traffic.

Procedure

Step 1   Select Reports > Analysis. The Historical Monitoring Tasks page appears. This page lists all the historical monitoring tasks that you have defined.

Step 2   Click Create. The Monitoring Task Wizard starts at Step 1, Task Definition.

Step 3   On the Monitoring Task Wizard - Task Definition page, fill in these fields to define the historical monitoring task:

• Name—A name you find meaningful.

For this example, the name is Baseline remote demo.

• Polling Interval—How often you want to collect data from the devices. The more frequent you poll the devices, the more effect the monitoring task might have on device performance. Also, the more frequent you poll the devices, the larger amount of data will be collected (thus filling up your disk space). See How Much Disk Space Is Required for Historical Monitoring? for a more detailed discussion of the implications of polling intervals.

For this example, the polling interval is 10 minutes.

• Start and End Time—The date and time you want the monitoring task to start and end. Click the calendar icon to choose dates from a calendar. The start time must use the 24-hour clock notation (that is, midnight is 00:00:00, noon is 12:00:00, 11 PM is 23:00:00, and so forth).

For this example, start time is 15 August 2002, 19:34:00 (7:34 PM), and end time is 15 September 2002, 19:34:00.

• Enabled—Check Enabled to identify that the task should be started at the selected start time. The task cannot run until you enable it.
• Description—Optionally, enter a description for the task.

When you are finished defining the task, click Next. The Monitoring Task Wizard - Select Devices page appears.

Step 4   On the Monitoring Task Wizard - Select Devices page, select each device you want to include in this monitoring task by checking the box next to the device. Keep in mind that each monitoring task can have a maximum of 12 interfaces, so do not select more devices than you can use in this task.

When you are finished selecting devices, click Next. The Monitoring Task Wizard - Select Interfaces page appears.

Step 5   On the Monitoring Task Wizard - Select Interfaces page, select the interfaces you want to include in the monitoring task. You can select a maximum of 12 interfaces.

When you are finished selecting interfaces, click Next. The Monitoring Task Wizard - Select Policies page appears.

Step 6   On the Monitoring Task Wizard - Select Policies page, select the policies you want to include in the monitoring task. To select all policies, you can check the box in the table heading.

When you are finished selecting policies, click Next. The Monitoring Task Wizard - Summary page appears.

Step 7   On the Monitoring Task Wizard - Summary page, review your task settings. If you want to make changes, click the links in the TOC to go to the page in the wizard that you want to change.

When you are satisfied with the task definition, click Finish. The task is saved and the Historical Monitoring Task page appears (Figure 4-1). Your task should be added to the list.

If the status of your task is "Processing," QPM is still analyzing your task. Select Reports > Analysis to refresh the page. When the status changes to "Running," the task is ready to run at the start date and time. A task with a status of "Running" will not contain data until the start date and time has passed.

Proceed with Step 3: Reading the Historical Monitoring Graphs.

Related Topics

• Understanding How to Monitor Traffic for Baseline Analysis
  
  

Step 3: Reading the Historical Monitoring Graphs

This step describes how to view an historical monitoring task, and how to read the graphs.

Before You Begin

You can view any historical monitoring task, but a task will not have any data to display until the start date and time has been reached, QPM has polled the device three times, and at least one hour has passed. If you view a task before it is finished running, you can see the data that has been collected up to the latest polling period.

Procedure

Step 1   Select Reports > Analysis. The Historical Monitoring Tasks page appears. This page lists all the historical monitoring tasks that you have defined.

Step 2   Select the task you want to view by checking the box next to the task. For this example, the task is Baseline remote demo.

Step 3   Click View Report. The Policies Graphs page appears (Figure 4-2).

Figure 4-3 shows the matching traffic per class prior to QoS actions graph from Figure 4-2.

From the information in Figure 4-3, you can see that traffic that matches the AF2 policy's filter consumes approximately 1050 Kbps of the interface's bandwidth. If you select Percentage from the Vertical Axis list box, you can see that this is approximately 52% of the interface's bandwidth (Figure 4-4). Policy AF3, on the other hand, accounts for almost no traffic.

If a policy has more than one filter condition, like policy AF2 in this example, you can further analyze the traffic by looking at the filter graphs. The filter graphs show how much traffic matched each filter in a policy. To see the filter graphs, click the Filters Graphs button at the bottom of the page. Figure 4-5 shows the filter graph for policy AF2. In this case, no traffic matched DSCP 22 (af23). DSCP 20 (af22) used approximately 22% of the bandwidth; DSCP 18 (af21) used approximately 30%.

The graphs also include ones that show the matching traffic after applying QoS, and the traffic that was dropped due to QoS action. However, because this is a baseline traffic analysis, the QoS policies do not affect traffic, so these graphs do not contain interesting information.

After you apply QoS policies that do affect traffic, you can monitor how the policies affect the traffic using the same techniques discussed in this section. Proceed with Lesson 4-2: Monitoring QoS for a detailed example of monitoring QoS.

Related Topics

• Understanding How to Monitor Traffic for Baseline Analysis
  
  

Lesson 4-2: Monitoring QoS

Monitoring QoS is similar to baseline monitoring, as described in Lesson 4-1: Doing a Baseline Traffic Analysis. The only difference is that the QoS policies you are monitoring are designed to affect the traffic on the interfaces. Thus, you should see some evidence of your policies reducing the bandwidth used by some applications, with subsequent packet dropping for those applications.

Before You Begin

This lesson assumes you have already created and deployed QoS policies to some devices using QPM. This lesson uses a specific interface and set of policies deployed on a Cisco test network. Replace the sample device and interface names with names from your network to create a monitoring task that can run on your network. These examples are meant to help you understand how to analyze the data QPM produces.

This example monitors 10.51.116.60 Serial 1/1, an HDLC 2048 Kbps interface on a Catalyst 3600, running IOS 12.2T. Table 4-3 shows the policies deployed to the interface for outbound traffic. The policy group uses Class-based QoS scheduling. The policies have these purposes:

• RealTime and VoiceControl—These policies are meant for voice over IP traffic. Their purpose is to ensure low packet loss and delay.
  
  
• Gold—This policy is for high-priority data traffic. Its purpose is to provide fast response time.
  
  
• Silver—This policy is for secondary-priority traffic. Its purpose is to provide a bandwidth guarantee to ensure that the traffic is not starved for bandwidth, yet not allow the traffic to overwhelm gold or voice traffic.
  
  
• BestEffort—This policy is the default policy that applies to all traffic not covered by other policies. Its purpose is to ensure that the traffic is treated fairly, but the traffic is dropped if needed to ensure the service levels required by voice, gold, or silver traffic.
  
  

Procedure

Step 1   Select Reports > Analysis, and click Create, to set up a new historical monitoring task. Step 2: Setting Up an Historical Monitoring Task explains in detail how to set up an historical monitoring task using this wizard.

For this example, the historical monitoring task has these characteristics. The task you create will differ based on the devices and policies in your network:

• Name—MonDemoTask.
• Polling Interval—1 minute.
• Start and End Time—14 August 2002 12:45:00 to 16 August 2002 12:45:00 (2 day duration).
• Device and Interface—10.51.116.60 Serial 1/1.
• Policies—All policies described in Table 4-3.

Step 2   After the task has run long enough to poll the device at least 3 times (and at minimum one hour has passed), you can view the task and start analyzing the graphs. From the Historical Monitoring Tasks page (Reports > Analysis), check the box next to the task and click View Report. The Policies Graphs page appears and shows the graphs of the data collected by the task.

Step 3: Reading the Historical Monitoring Graphs explains some of the basics of reading these graphs. This discussion assumes you have already read that information.

Because this monitoring task is monitoring QoS policies that are intended to affect the network traffic on the interface, you should see a difference between the "Matching Traffic Per Class Prior to QoS Actions" (Figure 4-6) and the "Matching Traffic Per Class After QoS Actions" (Figure 4-7) graphs.

In this example, notice that traffic matching the BestEffort policy (number 1 in the figures) is approximately 1200 Kbps before QoS actions (roughly 60% of the interface's bandwidth), but only 600 Kbps after QoS actions. If you open the "Matching Traffic Per Class Discarded by QoS Drop Actions" graph (Figure 4-8), you can see that roughly 600 Kbps of BestEffort traffic is being dropped. Also note that there is some Silver traffic dropping, but that no RealTime, VoiceControl, or Gold traffic is dropped. This is exactly the desired result for this set of policies.

Step 3   Because linear graphs display all collected data points, the lines can be difficult to read if you are trying to analyze a portion of the data. To get a clearer view, you can zoom in on a specific time period.

For example, in Figure 4-6, you can see some significant spikes approximately 25 hours into the task. To zoom in on the first spike, modify the From Time and To Time fields to approximate this period, and click Apply. In this case, change the From Time to 08/15/2002 13:20:00 and the To Time to 08/15/2002 13:50:00 (Figure 4-9).

The resulting graphs show the network activity much more clearly for this time period.

Step 4   To get a simplified view of the network traffic, you can select Bar for Graph Type to see bar graphs.

Unlike linear graphs, bar graphs do not show every data point collected. Instead, bar graphs show 10 data points, each one an average of the data collected over one tenth of the task's duration. The collection periods are shown in the lower right of the Policies Graphs page (Figure 4-13).

Bar graphs can hide variations in traffic patterns. For example, the bar graph for "Matching Traffic Per Class Prior to QoS Actions" (Figure 4-14) does not show the spikes and lolls in traffic that appear on the linear version of the graph (Figure 4-6). On the other hand, bar graphs clearly show each traffic class, because bars cannot overlap like lines. These types of graphs can help you see broader traffic patterns, and can be useful for presentations.

Related Topics

• Understanding QPM Monitoring
  
  

Lesson 4-3: Monitoring QoS in Real Time

This lesson describes how to set up and use a real-time monitoring task. Real-time monitoring is useful for troubleshooting an interface. If there seems to be a problem on an interface, you can monitor it to determine if there is a problem with the QoS policies. With real-time monitoring, you can only monitor one interface per task. However, you can start more than one task to view multiple interfaces.

Before You Begin

You must use QPM to create QoS policies on an interface before you can use QPM to monitor the interface. Because you can only monitor real devices, this lesson uses devices on a Cisco test network as an example of how to set up and view a real-time monitoring task. When following this lesson, use devices and interfaces that reside on your own network. Only devices and interfaces you have defined in QPM are available for selection when you create a monitoring task.

Procedure

Step 1   Select Reports > Analysis > Real-Time. The Real-Time Monitoring Tasks page appears.

Step 2   Click Create. The Real-Time Monitoring Wizard starts at the Device Selection page. Make these selections:

• Name—Enter a meaningful name for this task. For this example, the name is Cat3600 HDLC. The example will monitor the interface used in Lesson 4-2: Monitoring QoS.
• Polling Interval—Select how often you want QPM to collect information from the interface. The more often you poll the interface, the more effect monitoring can have on the interface's performance. For this example, the polling interval is 15 seconds.
• Device—Select the device that has the interface you want to monitor. For this example, the device is 10.51.116.60.
• Description—Optionally, enter a description for the task. You can rerun real-time monitoring tasks whenever you want, so a meaningful name and description can help you identify the task you want to rerun.

When finished, click Next. The Real-Time Monitoring Wizard - Interface Selection page appears.

Step 3   On the Real-Time Monitoring Wizard - Interface Selection page, select the interface you want to monitor. For this example, the interface is Serial 1/1, an HDLC interface.

Step 4   Click Finish to save your task definition. QPM opens a separate window and automatically starts the real-time monitoring task. You will not see any data until QPM has polled the interface three times. Then, data is posted to the real-time monitoring graphs as it is collected.

As data fills the graphs left to right, a vertical red line indicates which part of the data is the most recently gathered. When the graphical information reaches the right side of the graph, new data is overwritten on the graph left to right (Figure 4-15).

The following figures show examples of the real-time report for this interface. Because it is the same interface used in Lesson 4-2: Monitoring QoS, you can compare these figures with the equivalent figures in that lesson.

As you can see in Figure 4-18, the discard rate for Silver traffic is close to zero. To get a clearer view of the discard rate, open the Action folder and look at the Silver policy (Figure 4-19).

If you have a policy with multiple filter conditions, open the Filter folder and look at the graph for the policy. QPM shows you the matching traffic for each filter condition in this graph. In this example, the Gold policy has two conditions (Figure 4-20).

Step 5   Click Close Window to close the Real-Time Report window and end the task.

Tips

• You can rerun a real-time monitoring task by selecting Reports > Analysis > Real-Time, checking the box next to the desired task, and clicking Run.
  
  

Related Topics

• Understanding QPM Monitoring