Table Of Contents
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?
Lesson 4-1: Doing a Baseline Traffic Analysis
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
Lesson 4-3: Monitoring QoS in Real Time
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.
•
Lesson 4-1: Doing a Baseline Traffic Analysis
•
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?
QoS Analysis serves these main purposes:
•
•
•
What Can You Monitor Using QPM?
You can monitor class-based QoS and CAR QoS policies on devices running specific Cisco IOS software versions, as long as you have distributed QoS policies using QPM. User Guide for CiscoWorks QoS Policy Manager has a detailed explanation of what can be monitored. For the purposes of these tutorial lessons, keep these basic rules in mind:
•
http://www.cisco.com/en/US/products/sw/cscowork/ps2064/products_device_support_tables_list.html
•
•
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.
Table 4-1 Differences Between Historical and Real-Time Monitoring
Maximum number of interfaces monitored per task
12
1
Disk space requirements
Substantial. See How Much Disk Space Is Required for Historical Monitoring?
No disk space used. Data is only presented on web page; it is not saved.
Polling interval for data collection
From 1 to 60 minutes.
From 10 to 30 seconds.
Length of task
Up to several months, depending on polling interval. QPM enforces a duration limit based on polling interval. See the User Guide for CiscoWorks QoS Policy Manager for the specific limits.
As long as you want, but you must be at the computer to see the data.
Reuse of monitoring task
Can only be run once, because you set a start and end time.
Can be rerun any time desired, because there is no set start or end time.
Reviewing results
Can review the results as many times as you want.
Results must be reviewed as they are collected.
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:
•
•
•
•
•
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:
•
•
•
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
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:
•
•
•
Related Topics
•
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.
Make sure the device and Cisco IOS Software version you use is supported for QPM monitoring. Find the device support information at this URL:
http://www.cisco.com/en/US/products/sw/cscowork/ps2064/products_device_support_tables_list.html
Procedure
Step 1
Step 2
The page refreshes to display the policy groups in the deployment group, if any.
Step 3
a.
b.
c.
d.
•
•
•
•
Click OK to save the device constraints. The Policy Group Definition Wizard - Constraints Definition page appears.
If you want to add other device constraints, click Define Manually and add them.
e.
The Policy Group Definition Wizard - Capabilities Report page appears, where you can view a summary of the QoS features that can be configured for the policy group, according to the device constraints.
f.
Step 4
a.
b.
c.
Step 5
a.
b.
c.
d.
Step 6
Follow these steps to create the policies:
a.
b.
c.
•
•
Click Next. The In Policy Wizard - Filter page appears.
d.
•
•
e.
•
•
•
In the In Policy Wizard - Filter page, click Next. The In Policy Wizard - Marking page appears.
f.
•
•
•
g.
h.
Step 7
Proceed with Step 2: Setting Up an Historical Monitoring Task.
Related Topics
•
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
Step 2
Step 3
•
For this example, the name is Baseline remote demo.
•
For this example, the polling interval is 10 minutes.
•
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.
•
•
When you are finished defining the task, click Next. The Monitoring Task Wizard - Select Devices page appears.
Step 4
When you are finished selecting devices, click Next. The Monitoring Task Wizard - Select Interfaces page appears.
Step 5
When you are finished selecting interfaces, click Next. The Monitoring Task Wizard - Select Policies page appears.
Step 6
When you are finished selecting policies, click Next. The Monitoring Task Wizard - Summary page appears.
Step 7
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.
Figure 4-1 Lesson 4-1, Step 2, Historical Monitoring Tasks Page After Defining Task
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
•
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.
Note
Procedure
Step 1
Step 2
Step 3
Figure 4-2 Baseline Demo—Policies Graphs Page, Initial View
Task details—The historical monitoring task details, including name, duration, and polling interval. Use this information to help you understand the displayed data.
Customization controls—Fields that let you change how the data is displayed:
•
•
•
•
•
Group folders—Folders that you can open or close to see the graphs related to that item.
•
•
Graphs—The collected data displayed according to your customization selections. You can open or close each graph by clicking the arrow to the left of the graph's name. The colors used on the graphs are the colors used in the graphed items list (number 5 below).
Graphed items—The items that can be displayed on the graphs (either policies or interfaces, depending on your selection in the Group customization control). In this example, the items graphed are policies. You can control which policies are graphed by checking or unchecking the associated box and clicking Show Graphs (not shown in this figure; the button is at the bottom of this group). If you have trouble seeing the data for an item (for example, because two lines occupy the same space), deselect the other items until you see the desired line. Switching between line and bar graphs can also help you identify overlapping data.
Figure 4-3 shows the matching traffic per class prior to QoS actions graph from Figure 4-2.
Figure 4-3 Baseline Demo—Matching Traffic Per Class Prior to QoS Actions Graph
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.
Figure 4-4 Baseline Demo—Matching Traffic Per Class Prior to QoS Actions Graph, Percentage Format
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%.
Figure 4-5 Baseline Demo—Filter Graph for Policy AF2
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
•
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 that can be monitored 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. See What Can You Monitor Using QPM? for information on the types of policies and devices that can be monitored.
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:
•
•
•
•
Procedure
Step 1
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:
•
•
•
•
•
Step 2
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.
Figure 4-6 MonDemoTask—Matching Traffic Per Class Prior to QoS Actions
BestEffort
Gold
Silver
RealTime. The line for RealTime is behind the line for Silver.
VoiceControl. This line is just above the zero line.
Figure 4-7 MonDemoTask—Matching Traffic Per Class After QoS Actions
Figure 4-8 MonDemoTask—Matching Traffic Per Class Discarded by QoS Drop Actions
BestEffort
Gold
Silver
RealTime
VoiceControl. Gold, VoiceControl, and RealTime overlap and are all 0 (no dropped traffic.)
Step 3
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).
Figure 4-9 Zooming In On Linear Graphs
The resulting graphs show the network activity much more clearly for this time period.
Figure 4-10 MonDemoTask—Matching Traffic Per Class Prior to QoS Actions (After Zoom)
BestEffort
Gold
Silver
RealTime. The line for RealTime is mostly below the line for Silver. The lines occasionally cross.
VoiceControl. This line is just above the zero line.
Figure 4-11 MonDemoTask—Matching Traffic Per Class After QoS Actions (After Zoom)
Figure 4-12 MonDemoTask—Matching Traffic Per Class Discarded by QoS Drop Actions (After Zoom)
BestEffort
Gold
Silver
RealTime
VoiceControl. Gold, VoiceControl, and RealTime overlap and are all 0 (no dropped traffic.)
Step 4
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).
Figure 4-13 Periods for Bar Graph Data Points
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.
Figure 4-14 Bar Graph for Matching Traffic Per Class Prior to QoS Actions
Related Topics
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. See What Can You Monitor Using QPM? for information on the types of policies and devices that can be monitored.
Procedure
Step 1
Step 2
•
•
•
•
When finished, click Next. The Real-Time Monitoring Wizard - Interface Selection page appears.
Step 3
Step 4
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).
Figure 4-15 Real-Time Demo—Real-Time Report Page, Initial View
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.
Figure 4-16 Cat3600 HDLC Real-Time—Matching Traffic Per Class Prior to QoS Actions
BestEffort
Gold
Silver
RealTime. The line for RealTime is mostly below the line for Silver. The lines occasionally cross.
VoiceControl. This line is just above the zero line.
Figure 4-17 Cat3600 HDLC Real-Time—Matching Traffic Per Class After QoS Actions
Figure 4-18 Cat3600 HDLC Real-Time—Matching Traffic Per Class Discarded by QoS Drop Actions
BestEffort
Gold
Silver
RealTime
VoiceControl. Gold, VoiceControl, and RealTime overlap and are all 0 (no dropped traffic.)
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).
Figure 4-19 Cat3600 HDLC Real-Time—Action Graph for Silver Policy
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).
Figure 4-20 Cat3600 HDLC Real-Time—Filter Graph for Gold Policy
Step 5
Tips
•
Related Topics
