Table of Contents

Contents

Overview

Getting Started

Monitoring and Analyzing Traffic

Capturing and Decoding Packets

Performing User and System Administration

Understanding Cisco Security Packet Analyzer Deployment

Customizing Cisco Security Packet Analyzer

Understanding Prime Cisco Security Packet Analyzer Traffic Sources

Configuring Cisco Security Packet Analyzer Security

Understanding Cisco Security Packet Analyzer Behavior Reference

GUI Field Descriptions

Troubleshooting Network and Cisco Security Packet Analyzer Issues

Title page

Contents

Overview

This chapter contains information about the Cisco Security Packet Analyzer software and describes task overviews.

This chapter contains the following sections:

- Introducing Cisco Packet Analyzer

- Overview of the Packet Analyzer Platforms

- How to Use Packet Analyzer to Analyze Your Traffic

- Before You Begin

Introducing Cisco Packet Analyzer

The Cisco Security Packet Analyzer (Packet Analyzer) software is a network monitoring and analysis tool that combines flow-based and packet-based analysis into a single tool set. Packet Analyzer software provides network operations and engineering with user, command line, and application programming interfaces that you use for traffic analysis of applications, hosts, and conversations, performance-based measurements on application, server, and network latency, quality of experience metrics. as well as ways to see deeper into your network. The robust graphical user interface makes traffic monitoring and troubleshooting simple and cost-effective.

for details on high-level function areas and how they map to the user interface.

Table 1-1 Packet Analyzer Task Areas

Task Area

Menu Mapping

Function Description

Used By

Plan and Prepare

Setup menu

Create a list of your network performance goals. Set expected goals and limits for response time, expected ranges for MOS values, bandwidth usage per application, and utilization on critical WAN links. Determine on which performance issues you want to concentrate.

Network Engineers, Designers, and Architects

Monitor and Analyze

Home, Capture, Analyze and Monitor menus

View dashboards which give you a quick view of traffic performance information, and various incidents. Use interactive reports filter data when monitoring specific network traffic and troubleshooting problems.

Monitor your network and perform other day-to-day operations related to proactive and reactive traffic analysis and troubleshooting.

Analyze QoS policy traffic using alarms, syslogs, traps, and e-mail alerts.

See Monitoring and Analyzing Traffic and Capturing and Decoding Packets.

Network Engineers, NOC Operators, and Service Operators

Administer

Administer menu

Change default system display, notification, and user settings, as well as manage database access control and view system diagnostics.

See Performing User and System Administration.

Network Engineers

Deploy

Setup and Admin menus

Configure devices to share data with Packet Analyzer. Configure managed devices and data sources.

Perform customized setup of Packet Analyzer including sites, alarms and thresholds, scheduled exports, and so on.

Monitor an extended level of your managed device’s data (health and interface information).

Determine which locations are ingress or egress points of a logical network boundary (aggregation layer, core, campus edge, and so on) that can offer valuable insights into the network activity within that partition.

Create a baseline of current metrics including applications, bandwidth per application, top conversations and hosts, QoS values used in the network, unrecognized protocols, and current server and end-to-end response time measurements.

See Customizing Cisco Packet Analyzer.

Network Engineers, Designers, and Architects

Troubleshoot

Capture, Analyze and Monitor menus

Resolve common Packet Analyzer issues including login problems and unresponsiveness, understand error messages, and troubleshoot network issues using Packet Analyzer.

See Troubleshooting Network and Packet Analyzer Issues.

Network Engineers, NOC Operators, and Service Operators

Overview of the Packet Analyzer Platforms

Packet Analyzer is supported on a variety of platforms. This guide does not discuss platforms, but focuses on functions and capabilities.

.

It is important to note that the portfolio of Packet Analyzer models differ in memory, performance, disk size, and other capabilities. Therefore, some allow for more features and capabilities (for example, the amount of memory allocated for capture).

Throughout this guide, there may be notes explaining that some features apply only to specific platforms. If there is no note, then that feature or aspect applies to all Packet Analyzer platforms.

How to Use Packet Analyzer to Analyze Your Traffic

The Cisco Packet Analyzer software helps you to address the following major areas:

- Network Layer Traffic Analysis. Packet Analyzer provides comprehensive traffic analysis to identify what applications are running over the network, how much network resources are consumed, and who is using these applications. Packet Analyzer software offers a rich set of reports with which to view traffic by Hosts, Application, or Conversations. See the discussions about Dashboards, starting with Using Traffic Summary.

- Application Response Time. Packet Analyzer can provide passive measurement of TCP-based applications for any given server or client, supplying a wide variety of statistics like response time, network flight time, and transaction time. See Using Response Time Summary.

- Voice Quality Analysis. Packet Analyzer provides application performance for real time applications like Voice and video. Packet Analyzer can compute MOS for voice and MDI for video, as well as provide RTP analysis for the media stream. See Analyzing Media.

- Advanced Troubleshooting. Packet Analyzer provides robust capture and decode capabilities for packet traces that can be triggered or terminated based on user-defined thresholds. See Application Performance Monitoring Using Capture and Decode.

- WAN Optimization insight. Packet Analyzer provides insight into WAN Optimization offerings that compress and optimize WAN Traffic for pre- and post-deployment scenarios. This is applicable for Optimized and Passthru traffic. See

- Open instrumentation. Packet Analyzer is a mediation and instrumentation product offering, and provides a robust API that can be used by partner products as well as work with customer-created applications. Contact your account representative for a copy of the Cisco Security Packet Analyzer API Programmer’s Guide .

.

Table 1-2 Data Source Monitoring Capabilities

Data Sources

Monitoring Capabilities

Capture

Traffic

ART

RTP/Voice

URL

SPAN/VACL/ERSPAN

Yes

Yes

Yes

Yes

Yes

WAAS

No

Yes

Yes

No

No

NetFlow

No

Yes

No

No

No

For information on which data sources Packet Analyzer uses to deliver this functionality, see Understanding Packet Analyzer Traffic Sources.

Before You Begin

Depending on your Packet Analyzer, ensure the following list of requirements are complete before you use Packet Analyzer. For detailed instructions, see your platform installation guide, except where noted:

- Reset your Packet Analyzer root password

- Set up a data source to send traffic to the Packet Analyzer

- Configure access to the Packet Analyzer user interface or CLI

- Synchronize your Packet Analyzer to the standard time source outside the Packet Analyzer in addition to the router or switch (depending on your platform). For detailed instructions, see Synchronizing Your System Time.

For optional advanced customizations, such as adding sites or configuring alarms and thresholds, see Advanced Configuration Overview.

Getting Started

This chapter contains getting started information for both users that want to use the Packet Analyzer quickly without customizing the product or that want to customize the Packet Analyzer. It includes some simple workflows that illustrate how to use Packet Analyzer quickly to help troubleshoot performance and optimization issues.

There are many additional workflows for which Packet Analyzer can be used. These tasks are documented in the following chapters. Cisco Security Packet Analyzer

This chapter contains the following sections:

- Before You Begin

- Quick Start

- Where to Go to Learn How to Customize Your Packet Analyzer

Before You Begin

This section contains tasks that must be performed prior to using Packet Analyzer.

2. Ensure that the Packet Analyzer system time is configured correctly. If the system time is incorrect, Packet Analyzer data presentation may be inaccurate due to time ranges, hence providing incorrect interpretations of Packet Analyzer data. Although some platforms are synchronized automatically, you must also synchronize the standard time source outside the Packet Analyzer in addition to the Packet Analyzer and the router or switch in order for the data to be accurate. For details, see Synchronizing Your System Time.

Quick Start

Use the following workflows to get started using your product. These tasks do not require additional configuration or setup. You can see other workflows and tasks within this user guide in the task-specific chapters.

- Troubleshooting Application Slowness

- Using Traffic Summary

- Using Response Time Summary

- Using Site Summary

- Using Alarm Summary

- Filtering Data Using Global Search

- Filtering Traffic for Viewing on the Dashboards

- Filtering Data Using Global Search

Where to Go to Learn How to Customize Your Packet Analyzer

There are many capabilities beyond the tasks you can perform out-of-the box. These tasks require some level of customization before you can access some of the additional functionality within Packet Analyzer.

To review the customization you may need to perform, see Advanced Configuration Overview.

Monitoring and Analyzing Traffic

Cisco Security Packet Analyzer provides several dashboards and tools to help you monitor and analyze your network traffic data. Cisco Security Packet Analyzer Software starts collecting data once it is up running and network data packets are sent to its data port(s). You can view the monitor dashboard, analyze traffic using various views, troubleshoot suspicious traffic using the capture tool, and decode capture sessions without any additional configuration on your part.

This chapter provides information about monitoring your network traffic and analyzing the information presented.

This chapter contains the following sections:

- How To Make Dashboards Work for You

- Troubleshooting Application Slowness

- Using Traffic Summary

- Using Response Time Summary

- Using Site Summary

- Using Alarm Summary

- Analyzing Traffic

- Optimizing WAN

- Measuring Response Time

- Analyzing Device Interface and Health Data

- Analyzing Media

- Using the Packet Analyzer Application Programming Interface

If you want to customize Packet Analyzer to use more advanced configurations such as sites and filtering, see Customizing Cisco Packet Analyzer.

How To Make Dashboards Work for You

menu).

The Monitor dashboards allow you to view graphic depictions of network traffic, application performance, site performance, and alarms at a glance. From there, you can isolate one area, for example an application with response time issues, and then drill down to the Analyze dashboard for further investigation.

The following are some of the configuration tasks that enhance Packet Analyzer ability to provide more traffic details on dashboards:

- Turn on deep application classification to identify applications regardless of the ports on which the applications may be running. To enable deep packet inspection, see Adding More Detail into Dashboard and Application Reports. For example on how to troubleshoot using deep packet inspection, see Troubleshooting Application Slowness.

- To understand how to use filters to easily find information and significantly change what you view in the dashboards, see Filtering Traffic for Viewing on the Dashboards and Filtering Data Using Global Search.

- To make your custom application traffic more visible on the dashboards and reports, add HTTP URL or Server IP/Port definitions. See Creating Deeper Visibility Into Application Traffic

For more details about when or why to use specific dashboards, see How Do I Solve My Problem?.

How Do I Solve My Problem?

This section includes a table that provides various problems you can solve with specific dashboards, as well as what details you might want to know and what dashboards are associated with that data.

What Problem Needs Solving

Why Do I Need to Know This

Where to Go

My application is slow

Dashboards provide multiple entry points into data.

Troubleshooting Application Slowness

My phone quality is poor.

Packet Analyzer detects and computes Mean Opinion Scores (MOSs) for VoIP calls transported through Real Time Protocol (RTP) streams.

Using Site Summary see Top N Sites by Average MOS and RTP Streams

Has my server reached capacity?

You can filter by data source and analyze host details.

Filtering Traffic for Viewing on the Dashboards and Filtering Data Using Global Search

I want more or specific details in my captures

Use various filters to select what gets added in your captures.

Configuring Hardware Filters

Is my interface overloaded?

to see list of all interfaces and errors or discards on each interface.

Analyzing Device Interface and Health Data

I’m seeing a lot of unexpected or excessive applications traffic

This may be tied to the occurrence of multiple Unknown applications (for example, video traffic).

Configuring Application Classification

I want to identify my homegrown applications

Your traffic visibility into your application can be improved by adding your custom application details so it can be classified.

Creating Deeper Visibility Into Application Traffic

How do get notified before a problem occurs?

Set up alarms and thresholds to notify you via email.

Setting Up Alarms and Alarm Thresholds

Troubleshooting Application Slowness

This section contains a sample workflow that describes one way to use Packet Analyzer to help troubleshoot common network slowness.

This example concentrates on how to troubleshoot application performance issues that stem from using common server applications (such as HTTP or Sharepoint).

Tip This case applies to any instance where an application latency is caused by a network delay.

Before You Begin

, see Synchronizing Your System Time.

To determine what may be causing network slowness for the remote desktop users:

and ensure that the Deep Packet Inspection check box is selected. For more information, see Adding More Detail into Dashboard and Application Reports.

in order to find the network devices that use a specific protocol or application.

a. In the Interactive Report Filter select the name of your application (for example, Sharepoint) as the Application option in order to collect network traffic details for that application only. If you do not see your application, you may need to download the latest protocol pack.

b. You can also customize the time range to ensure that your data collection provides enough data or focuses on specific points of time that have heavy traffic.

If you do not see any data, select a different time range in the filter and submit the search again in order to locate the surge traffic.

Step 3 Use the zoom/pan chart slider at the bottom of the Application Traffic chart in order to focus in on those details that are most important to you.

Focus on the traffic surges in the chart in order to identify the participating servers and the remote clients.

Step 4 Use the Top Hosts Traffic In and Out charts in order to drill down for more bandwidth details.

a. Select the server with the most traffic and review the maximum and average bandwidth used by your application in order to pinpoint the source of the issue.

For the select server, assess the amount of traffic in order to view:

– A breakdown by each site

– Conversations by individual users

Step 5 Assess if there is enough capacity on the link connecting the site to the data center in order to determine if this might be part of the problem. Since this is out of this product’s scope, we recommend you use other applications to perform this task.

Step 6 If your network capacity is limited, for example, a 256 Kbps link shared across multiple applications and there is a requirement to support multiple clients, consider the following options:

- Apply a control mechanism, for example Quality of Service policies

- Upgrade the link so that it can handle a higher bandwidth

Using Traffic Summary

.

.

When you log into Packet Analyzer for the first time, the default view will be the Traffic Summary dashboard, and the top data source is selected by default.

provides an at-a-glance summary of the Traffic Summary dashboard. For each chart described below, you can left-click on any colored bar to get to a context menu, with which you can get more detailed information about that item. You can also place your cursor over the colored bar to see the number of bits per second collected or the total bits over the last time interval. To toggle your view from chart to table, select the icon under the table.

Table 3-1 Traffic Summary At-a-Glance

Basics

Chart

Description

View top application traffic rate or traffic volume, based on the Interactive Report filter selection (data rate or cumulative, respectively)

This chart reports application-level (L7 payload) bits.

from the context menu, you can start a capture on this data (see Capturing and Decoding Packets for more information). You can also select other options to view various application traffic details. See Analyzing Application Traffic.

View traffic rate or volume for top application groups

, where rate is the bits per second, and cumulative is the total number of bits.

View host activity

To get more specific details about the host activity, left-click on the colored bar and make a selection. If you left-click on a colored bar, you can select additional options for host activity data. See Analyzing Host Traffic.

View IP protocol traffic

Shows the percentages of bits being distributed to IP protocols (for example, IPv4 TCP).

View statistics for top DSCP aggregation groups

For more detail, hover over the colored bar or left-click to select Details option. See DSCP

View encapsulation traffic

In the Interactive Report, you can select a VLAN and filter specific encapsulation protocols from within this chart (including OTV, VxLAN, LISP, and others). You can also narrow your data by filtering on certain time ranges. The default time range is 15 minutes. See Encapsulation.

Tip To change from bits to bytes, choose Administration > System > Preferences and change the Data displayed in selection.

To see a chart in table format, use the Show Chart/Show Table toggle buttons on the bottom left corner of the chart.

. On that page, you can also configure the number of Top N entries you would like to display.

Using Response Time Summary

).

After the Packet Analyzer is started, these metrics will begin to populate automatically. When you first navigate to Response Time Summary dashboard, the top data source is selected by default. This dashboard shows you performance statistics for site, data source, encapsulation, and a specific amount of time.

Use the Interactive Report window on the left side of the window to change the parameters for the information displayed. To see a chart in table format, use the Show Chart / Show Table toggle button on the bottom right corner of the chart.

The dashboard charts will show you the following information:

- Top N Applications by Transaction Time

would show you the average response time of HTTP servers seen in the traffic category you have selected in the Interactive Report window. The data displays in microseconds (μ), milliseconds, or seconds depending on your preference settings.

- Top N Site-to-Site Network Time

This chart displays the top network time between the client site and the server site in the category you selected. The data displays in microseconds (μ), milliseconds, or seconds depending on your preference settings.

- TOP N Server-Applications by Server Response Time

This chart allows you to see how well servers perform, by showing you the server that has the longest response time (the item appearing at the top). The data displays in microseconds.

- TOP N Servers by Traffic Rate (In + Out)

).

- TOP N Client-Applications by Transaction Time

This chart displays the transaction time per client. The client with the highest response time appears on top. The data displays in microseconds (μ), milliseconds, or seconds depending on your preference settings.

- Top N Clients by Traffic Rate (In + Out)

This chart displays the total bits or rate of traffic for the top clients.

Using Site Summary

) shows you information about the sites in your network. You can use the Interactive Report on the left side of the window to change the information displayed. For more information about sites, see Configuring Sites.

The charts displayed on the Site Summary dashboard are:

- Top N Sites by Average Transaction Time

This chart shows the average transaction time by site.

- TOP N Application Traffic by Site to Site

This chart shows top site to site traffic.

- TOP N Worst Site to Site by Average MOS

This chart shows sites that have the highest average Mean Opinion Score (MOS).

MOS normally ranges from 1-5, denoting the perceived quality of the transmission, where 1 is the lowest perceived quality, and 5 is the highest perceived quality measurement. The MOS is weighted depending on the duration.

- Top N Sites by Traffic

This chart shows the sites that have the most traffic (which are the most active). It is a total of all the traffic sent or received for hosts that belong to the particular site, which means that this traffic includes intra-site traffic as well.

To see any of the charts in table format, use the Show Chart / Show Table toggle button on the bottom right corner of the chart.

Using Alarm Summary

) will show you the top alarms occurring in the network.

). You can also choose the desired amount of time from the Time Range drop-down menu, or you can customize the time range.

On any chart on the Alarm Summary Dashboard, you can click on a colored bar to see the Context menu, with which you can get more information.

If you do not set any alarms or thresholds, the Alarm Summary Dashboard will not display any data. For information on setting up alarms and thresholds, see Setting Up Alarms and Alarm Thresholds.

You could see a count of two alarms for the same occurrence if:

- both the source and the destination are in the same site in the Top N Site - Host Pair chart.

- both the source and the destination are in the same site in the Top N Site chart.

- both the source and the destination are in the same site using the same application in the Top N Site - Application Pair chart.

Note You will not have any data in Top N Site - Application and Top N Application if there is no threshold configured that involves an application (for example: Response Time threshold or Application threshold).

NetFlow Interface alarms are not related to any site; therefore, they will not appear on the four colored site alarm charts on the Alarm Summary dashboard. Instead, the New Alarms Raised and Last 50 Alarms tables at the bottom of this window will contain NetFlow Interface alarms raised.

The five charts displayed on the Alarm Summary dashboard are:

- Top N Sites by Alarm Count

This chart lists the top sites that have the most alarm triggers during the selected time range. The number of sites displays based on the maximum number you set in preferences. If no thresholds are configured, this chart contains no data.The number on the bottom of the chart is the alarm count.

.

- Top N Hosts by Site and Alarm Count

This chart shows the number of alarm messages during the selected time range that are triggered for Hosts across all sites, by the Site - Host Pair.

- Top N Applications by Alarm Count

This chart shows the number of alarms during the selected time range for Applications across all sites.

- Top N Applications by Site and Alarm Count

This chart shows the most alarm triggers during the selected time range by the application and site pair.

- New Alarms Raised

The New Alarms Raised table shows you all alarms that occurred during the interval selected in the Interactive Report window. Some alarms may have been triggered outside of the time period, but may still be occurring.

- Last 50 Alarms

.

to display a separate window, which shows all the alarms from that particular time interval.

You can also use the Filter button, both in this window and the All Alarms window, to display only alarms that meet the criteria you enter.

Utilizing Sites to Create a Geographically- or Organizationally-Familiar Deployment

In Packet Analyzer you can define a site, which enables you to aggregate and organize performance statistics. If you want to limit the view of your network analysis data to a specific city, a specific building, or even a specific floor of a building, you can use the sites function.

Figure 3-1 shows a centralized Packet Analyzer deployment analyzing multiple data sources from different locations in the network.

Figure 3-1 Site Level Aggregation

For this deployment, multiple sites can be created such as SanJose-Campus, SanJose-Datacenter, NewYork-NetFlow-Bldg1, and NewYork-WAAS-Bldg2. The data that does not match the site configuration will be displayed in the Default site called Unassigned site. This helps to isolate the view and information for monitoring and troubleshooting so you can drill down to the specific area of interest.

You can also include multiple types of data sources in the site definition, and you can then get an aggregated view of all network traffic.

makes it easy to bring up a Packet Analyzer without having to configure user-defined sites. Hosts that do not belong to any user-defined site will automatically belong to the Unassigned Site.

. Unassigned sites cannot be changed.

The interactive dashboard can be used to drill down into either San Jose or New York sites to see Top applications, hosts, Encapsulations, DSCP, and application response time.

From each of the charts in the dashboard, you can access the context menu to further drill down to analyze data such as detailed application, host, and conversation traffic.

Analyzing Traffic

Packet Analyzer offers many ways to analyze your network traffic data using graphs, charts, and detailed views.

Use the links below to locate information about:

- Analyzing Site Traffic

- Analyzing Application Traffic

- Analyzing Host Traffic

- NetFlow Interface Traffic Analysis

- DSCP

- Encapsulation

- URL Hits

- Detailed Traffic Analysis Views

- About Analyze Traffic Charts

Analyzing Site Traffic

To show you the traffic level for a given site over a selected period of time:

.

Step 2 To change the data to see the top application traffic coming into a specific site, out of a specific site, or all traffic within, coming in and moving out of that site, use the traffic selector buttons.

Step 3 To see site conversations about the conversation between sites to pinpoint specific applications or sites, select the Site Conversations button and choose filters from the Interactive Report to further pinpoint an application, data source, or time frame in question.

Step 4 To view top applications transmitting and receiving traffic for the selected time period and drill down to collect more data utilizing capture data, real-time graphs, and application group detail), left click the Top N Application dashboard.

Step 5 To see the criteria by which the Packet Analyzer classifies the amount of application traffic on this site over this period of time, use the view Application Distribution graph. Hover over graph parts to view detailed information on speed and percentages or left-click a graph element for other menu options.

Analyzing Application Traffic

To show you the traffic level for a given application over a selected period of time:

.

on the Interactive Report, and expand the time range to allow more data to be viewed.

Step 3 To focus in on a spike or area of interest, use the slider under the Application Traffic graph. Hover over the data points to see specific traffic details.

and choose filters from the Interactive Report to further pinpoint a data source, encapsulation method, or time frame in question.

Step 5 To view top hosts transmitting and receiving traffic for the selected time period and drill down to collect more data utilizing capture data, real-time graphs, and application group detail), left-click a Top N Hosts graph element and select a specific task.

describes the fields in this window.

to configure specific applications in your network. For detailed instructions, see Creating Deeper Visibility Into Application Traffic.

Analyzing Host Traffic

. It will show you:

- Input and output traffic for the host

- Top N application activity of the host over the selected interval

- Total application usage distribution for the host

- Host Conversations—Shows detailed lists of all the conversations for a particular host.

Applications Detail

describes the fields in the Applications Detail window.

NetFlow Interface Traffic Analysis

To view data collected for individual interfaces on a switch or router that is exporting NetFlow packets to the Packet Analyzer, use the NetFlow Interface Analysis page. The displayed information represents the total data collected since the collection was created, or since the Packet Analyzer was restarted.

Before You Begin

1. Ensure Auto-create is enabled for the NetFlow Data Export (NDE) data source. Once NDE data is sent to the Packet Analyzer, an NDE data source is created.

For more information, see Creating NetFlow Data Sources Using the Web GUI or html#33517" CLASS="cXRef_Color">Creating NetFlow Data Sources Using the CLI

) to ensure all information is populated.

To view NetFlow Interface Analysis:

. The default view is Interface View.

Step 2 Select an interface from the Interface Selector to see traffic in the charts. Click the arrow icon to the left of the NetFlow data source name to display all interfaces, and then select an interface to see data for that interface.

, and the charts on the right will sum up the metrics and display them for each group.

Note If the charts show no data, and you see a message “Interface needs to be selected,” you have not yet chosen an interface.

NetFlow flow record must include source/destination addresses, source destination ports, protocol, input and output SNMP interface if-indices, octet count, and packet count. Packet Analyzer discards flow records that do not meet this requirement.

NetFlow only takes into account of IP and its payload. Anything that is before the IP layer will not be counted toward the packet and octet count.

Once you have chosen the interface, you will see the following charts populated:

- Interface Traffic (Ingress % Utilization and Egress % Utilization)

- Top N Applications - Ingress

- Top N Applications - Egress

- Top N Hosts - Ingress

- Top N Hosts - Egress

- Top N DSCP Aggr - Ingress

- Top N DSCP Aggr - Egress

The interface speed can be entered manually through the Interface capacity table, or it can be auto configured if the SNMP settings for the NetFlow device are entered in data source table.

DSCP Detail

button on the right.

describes the fields in the All DSCP window.

DSCP

Differentiated services monitoring (DiffServ) is designed to monitor the network traffic usage of differentiated services code point (DSCP) values.

To monitor DSCP groups, you must configure at least one aggregation profile and one or more aggregation groups associated with each profile. For more information on configuring an aggregation profile, see Configuring DSCP Groups.

. The data provided to you includes:

- Traffic volume over time for DSCP group

- Top N applications and application groups using that DSCP group

- Top N hosts transmitting and receiving traffic on that DSCP group

Encapsulation

You can analyze the encapsulation traffic collected by Packet Analyzer (for setup, see Filtering Encapsulations). This section contains the following use cases:

- Viewing Collected Encapsulation Data—see Viewing Collected URLs

- Filtering Various Encapsulations—see Filtering a URL Collection List

URL Hits

You can analyze the URLs collected by the Packet Analyzer (for setup, see Configuring URL Collections).

The URL hits helps you to determine the URLs that are used in the network and then see what applications are affiliated with those URLs.

This section contains the following topics:

- Viewing Collected URLs

- Filtering a URL Collection List

Viewing Collected URLs

To view collected URLs and optionally create URL-based custom applications,follow these steps:

The URL Hits Window displays the collected URLs.

Note Only one URL collection can be active at one time. The data source is for information only.

.

Filtering a URL Collection List

To filter a URL collection list:

, choose which part of the URL to filter:

- URL —You can filter on any part of the URL

- Host —This filter applies only to the host part of collected URLs.

- Path— This filter applies only to the path part of the collected URLs

- Arguments— This filter applies only to the argument part of the collected URLs.

Step 2 Enter filter string.

to apply the filter.

Note To remove any display filter and show all URLs collected, click Clear.

Detailed Traffic Analysis Views

Packet Analyzer offers several detailed traffic analysis views which allow you to analyze the following data:

- Sites Detailed Views

- Site Conversations Detailed Views

- Applications Detailed Views

- Application Groups Detailed Views

- Application Traffic By Hosts Detailed Views

- Top Application Traffic Detailed Views

- Hosts Detailed Views

- Host Conversations Detailed Views

- Encapsulations Detailed Views

- DCSPs Detailed Views

Sites Detailed Views

Displays data for each site (including all unassigned sites) and see packet per second and bits per second details. Use the Interactive report filter to pinpoint specific attributes. There are no filter time limits for this data.

Site Conversations Detailed Views

Displays site traffic for all or selected sites. To pinpoint site traffic data between two devices, select the Interactive Report Filter.

Applications Detailed Views

To view the All Applications window and the detailed information about all application and filter on specific applications or other filter attributes, use the Interactive Report filter.

Application Groups Detailed Views

describes the fields in the All Applications window.

Application Traffic By Hosts Detailed Views

Shows the traffic for a given application broken out by individual hosts using the application. You may specify the time period to view, as well as the application, site (optional), data source (optional), and VLAN (optional).

The Packet Analyzer only supports a maximum Time Range of one hour filter for the Host Conversations, RTP Streams, Voice Calls Statistics, Calls Table, and RTP Conversations.

Top Application Traffic Detailed Views

Shows the top applications by traffic rate over a selected time and for the specified site and/or data source.

Top Application Traffic Detailed Views shows you all of the applications that have been running for the time period interval. The color-coded legend shows you what the applications are running.

data in addition to the data for the N number of applications.

If you place your cursor over any of the data points, you will get more details about the exact values for each of the applications that are running.

Hosts Detailed Views

button in the Interactive Report (left side of the window) to change the parameters of the information displayed.

Host Conversations Detailed Views

Shows detailed lists of all the conversations for a particular host.

You can view the following data:

- A table of hosts that sends and receives packets to the selected host, along with application, encapsulation, and traffic rate information.

- A breakout of application usage for the selected host. You can view the application usage table, when you select the required host from the filter only.

- A Top N Application Traffic Stacked Chart for the selected hosts. The application usage table is replaced with this chart, when you select both the required and optional hosts from the filter.

button in the Interactive Report (left side of the window) to change the parameters of the information displayed.

The Packet Analyzer only supports a maximum time range of one hour filter for the Host Conversations, RTP Streams, Voice Calls Statistics, Calls Table, and RTP Conversations.

Encapsulations Detailed Views

.

button in the Interactive Report to change the information displayed and target data.

DCSPs Detailed Views

.

button in the Interactive Report to change the information displayed and target data.

For details about setting your TOS key and the implications of doing so, see Customizing System Preferences.

About Analyze Traffic Charts

menu show statistics that occur over time. You can use the Zoom/Pan feature, with which you can drag the beginning or end to change the time interval or distribution.

The time interval change on the zoom/pan chart will affect the data presented in the charts in the bottom of the window. The zoom/pan time interval also affects the drill down navigations; if the zoom/pan interval is modified, the context menu drill downs from that dashboard will use the zoom/pan time interval.

Note In a bar chart which you can zoom/pan, each block represents data collected during the previous interval (the time stamp displayed at the bottom of each block is the end of the time range). Therefore, you may have to drag the zoom/pan one block further than expected to get the desired data to populate in the charts in the bottom of the window.

Optimizing WAN

Packet Analyzer can provide insight into WAN Optimization offerings that compress and optimize WAN traffic for pre- and post-deployment scenarios. This is applicable for optimized and passthru traffic.

WAN Optimization tasks include:

- Ensuring WAN Optimization

- Analyzing Traffic for Optimization Using the Top Talkers Detail

- Analyzing Application Performance after WAAS Optimization

- Monitoring WAAS Traffic Across Multi-Segments

- Monitoring WAAS Single-Segment Traffic

Note To monitor the WAAS data, you must select the correct WAAS data source.

Ensuring WAN Optimization

In order to ensure that your applications are performing optimally and your WAN is optimized:

.

If you do not have sites identified, you can use the Unknown site category or to learn about how to create sites, see Configuring Sites.

Step 2 Look for sites with the highest average transaction time and highest traffic rate.

Step 3 To quantify the application performance:

.

b. Set up a filter that targets key areas such as a specific location and different time ranges (one day and one week). This allows you to focus in on exactly the data you want to analyze.

c. Right-click the application with the highest server response time and choose Analyze Application Response Time.

d. Specify a filter time range using the Interactive Filter. We recommend viewing data over a one day range to allow for possible peak times.

e. Identify applications with poor performance and quantify the response time by network time, server response time, and data transfer time.

Step 4 To validate the impact of WAN optimization:

.

b. Minimize WAN Opt Impact analysis filter (on the left pane).

c. View the effect of optimizing one of your applications (for example, to determine if your HTTP browser has lower transaction times and thus better end-client experience, lower compression ratios for better utilization of the WAN, and fewer average concurrent connections for better utilization of server through connection reuse).

Step 5 To perform ongoing monitoring of WAN optimization and troubleshoot WAN optimized traffic:

.

b. View a detailed breakdown of latency and bandwidth measures for the server, WAN, and client network segments.

Analyzing Traffic for Optimization Using the Top Talkers Detail

While you are in the process of deploying WAAS devices, you can get data to assist in the WAAS planning and configuration.

This window allows you to display response time and concurrent connections for the top Application, Network Links, Clients, and Servers from WAN data sources before WAAS optimization.

To analyze traffic for optimization using the Top Talkers Detail:

Step 1 Choose Analyze > WAN Optimization > Top Talkers Detail and filter data using the Interactive Report window to select the traffic you want to analyze for optimization.

If the data source is from SPAN or WAAS, it does not include the packet header; if the data source is NetFlow, it will include the packet header.

Note You can choose to display Packet Analyzer data in either Bits or Bytes in Administration > System > Preferences.

Based on the results, you can then configure the WAAS products to optimize your network.

Analyzing Application Performance after WAAS Optimization

.

The tasks associated with this analysis include:

- Comparing Transaction Time (Client Experience)

- Comparing Traffic Volume and Compression Ratio

- Planning Capacity Using Average Concurrent Connections (Optimized vs. Passthru)

- Optimizing Usage Using Multi-Segment Network Time (Client LAN - WAN - Server LAN)

Comparing Transaction Time (Client Experience)

using this chart. It displays the average client transaction time. One line represents pass-through traffic (in which optimization is turned off), and the second represents optimized traffic. After setting up optimization for a certain period, you can compare the two lines and see where the vertical drop in the chart occurs. Depending on your Response Time Display unit preference setting, the data may display in microseconds, milliseconds, or seconds.

Comparing Traffic Volume and Compression Ratio

You can compare the bandwidth reduction ratio between the number of bits before compression and the number of bits after compression using this chart.

Planning Capacity Using Average Concurrent Connections (Optimized vs. Passthru)

You can use the number of concurrent connections during a specified time to assist with peak and off-period identification. This information can be used for capacity planning.

Optimizing Usage Using Multi-Segment Network Time (Client LAN - WAN - Server LAN)

You can use the network time between the multiple segments to identify lagging performance issues. The data is shown in microseconds.

Monitoring WAAS Traffic Across Multi-Segments

.

The window shows network time, server response time, and other metrics of the selected server or client-server pair from applicable segments. The relevant metrics from all segments are combined into one row per client-server conversation.

Monitoring WAAS Single-Segment Traffic

.

The window shows network time, server response time, and other metrics of the selected server or client-server pair (one row per segment).

Measuring Response Time

The Packet Analyzer monitors TCP packet flow between client and server, and measures response time data to provide more visibility into application response times (ART) and network latency. Packet Analyzer response time monitoring provides end-to-end response times to help you locate possible network and application delays.

Note Cisco Security Packet Analyzer software supports IPV4 and IPv6 for response time monitoring.

Packet Analyzer application response time requires both way TCP connections. In general, it is best to SPAN the physical interface with BOTH direction. If VLAN is desired, use either RX or TX. See the SPAN source product documents for SPAN limitations.

You can set up the Packet Analyzer to measure network time, client response time, server response time, and the total transaction time to improve application performance. Figure 3-2 shows the various points in network packet flow where the Packet Analyzer gathers data and the trip times you can monitor. This is one example that represents only a subset of measurements.

Figure 3-2 Packet Analyzer Application Response Time Measurements

Figure 3-3 shows a representation of total transaction time as opposed to application response time.

Figure 3-3 Transaction Time versus Response Time Measurements

lists and describes the ART metrics measured by Cisco Security Packet Analyzer.

), which allows you to see a summary view of the data.

To analyze Response Time data over time, use the following selections that fall under the Response Time window:

- Application Response Time

- Network Response Time

- Server Response Time

- Client Response Time

- Client-Server Response Time

. This section covers the following topics:

- Application Response Time Distribution

- Network Response Time Distribution

- Server Response Time Distribution

- Client Response Time Distribution

- Client-Server Response Time Distribution

- Server Application Responses

- Server Application Transactions

- Server Network Responses

- Client-Server Application Responses

- Client-Server Application Transactions

- Client-Server Network Responses

Application Response Time

The Application Analysis window allows you to view the performance of a particular application over time. The ART can be accessed by choosing Analyze > Response Time > Application.

The Transaction Time chart shows you the average total transaction time for the application you have selected and contains the following three components:

- Network Time

- Server Response Time

- Data Time

The Other Metrics chart allows you to see information over time after you have selected the desired metrics from the Metric Group 1 and Metric Group 2 drop-down.

Next are the Top Clients and Top Servers charts. These show you the clients and servers with the most bits of traffic for the chosen application.

Note You can choose to display Packet Analyzer data in either Bits or Bytes in Administration > System > Preferences.

Application Response Time Distribution bar chart shows the response of the chosen application for various time distribution range. To drill down for further response time distribution analysis, click Application Response Time Distribution from the context menu of the bar chart. The average total transaction time, top clients and servers for the selected distribution range is displayed.

Network Response Time

After you have selected a client site and a server site, the Network Response Time chart shows you the transaction time of the network link between the client site and server site. You can access the Network Response Time by choosing Analyze > Response Time > Network.

Note If you do not specify any application, the chart shows the network time instead of transaction time.

The Other Metrics chart allows you to see information about the network link between sites, after you have selected the desired metrics from the Metric Group 1 and Metric Group 2 drop-down.

The Top Clients and Top Servers charts show you the top clients and servers that are communicating through the network link (in bits or bytes).

The Network Response Time Distribution bar chart shows the response of the network link between the chosen client and server sites, for various time distribution range. To drill down for further response time distribution analysis, click Network Response Time Distribution from the context menu of the bar chart. The average total transaction time, top clients and servers for the selected distribution range is displayed.

Server Response Time

You can choose the Client Site and Server Site from the Interactive Report, and enter the IP address for the server that you want to analyze. The Total Transaction Time Composition chart displays the network time, server response time, data time, and the transaction time.

The Other Metrics chart allows you to see information about the server performance after you have selected the desired metrics from the Metric Group 1 and Metric Group 2 drop-down.

Top Client shows you top client talking to the server you have selected; Server Top Clients Sites shows the top client sites (traffic bits).

Note You can choose to display Packet Analyzer data in either Bits or Bytes in Administration > System > Preferences.

The Server Response Time Distribution bar chart shows the response of the chosen server for various time distribution range. To drill down for further response time distribution analysis, click Server Response Time Distribution from the context menu of the bar chart. The average total transaction time, server’s top clients and server’s top client sites for the selected distribution range is displayed.

Client Response Time

You can analyze the transaction time of that client in the Total Transaction Time Composition chart, after entering the client IP address and application in the Interactive Report Filter.

The Other Metrics chart allows you to see client performance over time after you have selected the desired metrics from the Metric Group 1 and Metric Group 2 drop-down.

The Clients Top Applications chart show you the applications being used the most by the client selected, and the Top Servers chart show you the servers being used most by the client.

The Client Response Time Distribution bar chart shows the response of the chosen client for various time distribution range. To drill down for further response time distribution analysis, click Client Response Time Distribution from the context menu of the bar chart. The average total transaction time, client’s top applications and client’s top servers for the selected distribution range is displayed.

Client-Server Response Time

You can analyze the transaction times between the client and server you have selected in the chart, after entering the client IP address and application in the Interactive Report Filter.

The Other Metrics chart allows you to see Client-Server transaction information after you have selected the desired metrics from the Metric Group 1 and Metric Group 2 drop-down.

The Client-Server Response Time Distribution bar chart shows the response of the chosen client and server for various time distribution range. To drill down for further response time distribution analysis, click Client-Server Response Time Distribution from the context menu of the bar chart. The average total transaction time for the selected distribution range is displayed.

Application Response Time Distribution

From the Interactive Report filter, select the application and the distribution range. The average total transaction time, top clients and servers for the selected distribution range is displayed.

Network Response Time Distribution

.

From the Interactive Report filter, select the client site, server site and the distribution range. The average total transaction time, top clients and servers for the selected distribution range is displayed. This distribution helps you to identify the problematic transactions and the associated client and server.

Server Response Time Distribution

In the Interactive Report filter, enter the IP address for the server that you want to analyze, and select the distribution range. The average total transaction time, server’s top clients and server’s top client sites for the selected distribution range is displayed.

Client Response Time Distribution

In the Interactive Report filter, enter the IP address for the client that you want to analyze, and select the distribution range. The average total transaction time, client’s top applications and client’s top servers for the selected distribution range is displayed.

Client-Server Response Time Distribution

In the Interactive Report filter, enter the IP address of the client and server that you want to analyze, and select the distribution range. The average total transaction time for the selected distribution range is displayed.

Server Application Responses

to display the Server Application Responses window.

to see more information.

provides definitions of each field of the Server Application Responses window.

Server Application Transactions

to display the Server Application Transaction window.

The Server Application Transactions window provides a summary of the server application transaction response times (ART) per server application displaying the server IP address, application used, and minimum, average, and maximum response times for the following:

- Application Response Time

- Data Transfer Time

- Retransmit Time

- Round Trip Time

Note Packet Analyzer uses the TCP three-way handshake to calculate network delay. If there are no new TCP connections during the polling interval, the Packet Analyzer GUI displays a dash (-) for the delay value indicating there is no delay data for that interval.

provides definitions of each field of the Server Application Transactions window.

Server Network Responses

Server Network Responses window. The Server Network Responses window shows the network connectivity and responsiveness between the server and the switch.

Note Packet Analyzer uses the TCP three-way handshake to calculate network delay. If there are no new TCP connections during the polling interval, the Packet Analyzer GUI displays a dash (-) for the delay value indicating there is no delay data for that interval.

provides definitions of each field of the Server Network Response Times window.

Client-Server Application Responses

.

provides definitions of each field of the Client-Server Application Responses window.

Note Packet Analyzer uses the TCP three-way handshake to calculate network delay. If there are no new TCP connections during the polling interval, the Packet Analyzer GUI displays a dash (-) for the delay value indicating there is no delay data for that interval.

Client-Server Application Transactions

The Client-Server Application Transactions window provides a summary of the server application transaction response times (ART) per server application displaying the server IP address, application used, and minimum, average, and maximum response times for the following:

- Application Response Time

- Data Transfer Time

- Retransmit Time

- Round Trip Time

Note Packet Analyzer uses the TCP three-way handshake to calculate network delay. If there are no new TCP connections during the polling interval, the Packet Analyzer GUI displays a dash (-) for the delay value indicating there is no delay data for that interval.

. You can also view the TopN Chart to view the most active network.

provides definitions of each field of the Client-Server Application Transactions window.

Client-Server Network Responses

The Client-Server Network Responses window shows information about network connectivity (also known as network flight time) between servers and clients.

.

Packet Analyzer uses the TCP three-way handshake to calculate network delay. If there are no new TCP connections during the polling interval, the Packet Analyzer GUI displays a dash (-) for the delay value indicating there is no delay data for that interval.

describes the fields of the Server-Client Network Response Time window.

Analyzing Device Interface and Health Data

window. The menu selections for analyzing Managed Devices are:

- Viewing Interface Information

- Viewing Health Data

Viewing Interface Information

You can view the following interface information:

- Interfaces Stats Table

- Interface Statistics Over Time

Interfaces Stats Table

. The Interfaces Stats table displays and shows the total packet distribution on all interfaces. Depending on the interface chosen, the chart below the Interfaces Stats table refreshes with that information.

Use the Interactive Report and the Filter button on the left to change the time range displayed.

The Discards and Errors are measured in packets per second. When you select a VDC below the Interactive Report, the main interface screen will be updated with interfaces that belong to the VDC. When Packet Analyzer is not in RISE environment, the VDC selector will not be displayed.

Interface Statistics Over Time

When you select an interface in the Interface Statistics Table, the statistics for that interface updates in the graph below the Interface Statistics Table.

You can check the check boxes for the information you would like to display in the graph:

- Bits: In Bits, Out Bits

- Packets: In Packets (inUcastPkts + inNUcastPkts), Out Packets (outUcastPkts + outNUcastPkts)

- Discards: In Discards, Out Discards

- Errors: In Errors, Out Errors

Note You can choose to display Packet Analyzer data in either Bits or Bytes in Administration > System > Preferences.

Viewing Health Data

from the menu.

For more details on the options available in each windows, see:

- Switch Health Options

- Router Health Options

Switch Health Options

For a switch, the Health window is displayed with a drop-down menu that provides the following options:

- Chassis Health

- Chassis Information

- Crossbar Switching Fabric

- Ternary Content Addressable Memory Information

Chassis Health

The Chassis Health window displays two real-time graphs:

- CPU usage

- Backplane Utilization

CPU usage

CPU type

- Usage for last 1 minute (%)

- Usage for last 5 minutes (%)

Backplane Utilization

- Peak %

- Peak Time (For example: Mon October 1 2007, 15:26:55)

The Health window also displays a matrix with the following information:

- Minor Alarm (on, off)

- Major Alarm (on, off)

- Temperature Alarm (on, off)

- Fan Status (other, ok, minorFault, majorFault, unknown)

Table 3-2 Chassis Memory Information

Column

Description

Memory Type

Type of memory including DRAM, FLASH, NVRAM, MBUF, CLUSTER, MALLOC.

Used

Number of used MB for a particular memory type.

Free

Number of free MB for a particular memory type.

Largest Free

Number of largest contiguous free MB for a particular memory type.

Chassis Information

describes the Chassis Information window.

Table 3-3 Chassis Information

Field

Description

Name

Name an administrator assigned to this managed node, this is the node's fully-qualified domain name.

Hardware

A textual description which should contain the manufacturer's name for the physical entity and be set to a distinct value for each version or model of the physical entity.

Backplane

The chassis backplane type.

Supervisor Software Version

The full name and version identification of the system’s software operating-system and networking software.

UpTime

The time (in hundredths of a second) since the network management portion of the system was last re-initialized.

Location

The physical location of this node.

Contact

The textual identification of the contact person for this managed node and information on how to contact this person.

Modem

Indicates whether the RS-232 port modem control lines are enabled.

Baud rate

The baud rate in bits per second of the RS-232 port.

Power Supply

Description of the power supply being instrumented.

Power Supply Type

The power supply source:

- unknown

- ac

- dc

- externalPowerSupply

- internalRedundant

Power Supply Status

The current state of the power supply being instrumented.

6: notFunctioning

Power Redundancy Mode

Power Redundancy Mode:

3: combined

Power Total

Total current available for FRU usage.

When Redundancy Mode is redundant, the total current available will be the capability of a power supply with the lesser power capability of the two power supplies.

When Redundancy Mode is combined, the total current available will be the sum of the capacities of all operating power supplies.

Power Drawn

Total Current Drawn by powered-on FRUs.

Crossbar Switching Fabric

describes the Crossbar Switching Fabric information.

Table 3-4 Crossbar Switching Fabric Information

Field

Description

Crossbar Switching Fabric

Physical and configuration information about the module:

—Indicates the slot number of the active switching fabric module. A value of NONE indicates that the active switching fabric module is either powered down or not present in the chassis.

—Indicates the slot number of the backup switching fabric module. A value of NONE indicates that the backup switching fabric module is either powered down or not present in the chassis.

—Determines the value of each module. If set to True, each and every module is allowed to run in bus-only mode. If set to False, none of the modules are allowed to run in bus-only mode. (All the non-fabric capable modules will be powered off.) Absence of fabric module results in all the fabric capable modules being powered off.

—Indicates whether truncated mode is administratively enabled on the device or not.

Module Switching Mode

Indicates switching mode of the module:

—Module does not use fabric. Backplane is used for both lookup and data forwarding.

—Module uses the backplane for forwarding decision and fabric for data forwarding.

—Module uses fabric for data forwarding and local forwarding is enabled.

Module-Channel

Module slot number

Module-Status

Status of the fabric channel at the module

Fabric Status

Status of the fabric channel at the slot

Speed (MB)

Speed (MB/second) of the module

Module-Channel

Channel for the module

In Errors

The total number of error packets received since this entry was last initialized.

Our Errors

The total number of error packets transmitted since this entry was last initialized.

Dropped

The total number of dropped packets transmitted since this entry was last initialized.

In Utilization (%)

Input utilization of the channel for the module.

Out Utilization (%)

Output utilization of the channel for the module.

Ternary Content Addressable Memory Information

lists and describes the TCAM information.

Table 3-5 Ternary Content Addressable Memory Information

Field

Description

Security Acl Mask

Indicates that TCAM space is allocated to store ACL masks.

Security Acl Value

Indicates that TCAM space is allocated to store ACL value.

Dynamic Security Acl Mask

Indicates that TCAM space is allocated to dynamically store ACL masks.

Dynamic Security Acl Value

Indicates that TCAM space is allocated to dynamically store ACL values.

Qos Acl Mask

Indicates that TCAM space is allocated to store QoS masks.

Qos Acl Value

Indicates that TCAM space is allocated to store QoS value.

Dynamic Qos Acl Mask

Indicates that TCAM space is allocated to dynamically store QoS masks.

Dynamic Qos Acl Value

Indicates that TCAM space is allocated to dynamically store ACL values.

Layer 4 Port Operator

Indicates that TCAM space is allocated for layer 4 port operators purpose.

Interface Mapping Module

Indicates that TCAM space is allocated for interface mapping purpose.

Router Health Options

If your device is a router, the Router Health window displays with a drop-down box that provides the following options:

- Router Health

- Router Information

Router Health

describes the contents of the Router Health window.

Table 3-6 Router Health Information

Field

Description

CPU Usage (graph)

Overall CPU busy percentage in the last 5 minute period

CPU Type

Describes type of CPU being monitored

Last 1 minute

Overall CPU busy percentage in the last 1 minute period.

Last 5 minutes

Overall CPU busy percentage in the last 5 minute period.

Temperature Description

Description of the test point being measured

Temperature Status

The current state of the test point being instrumented; one of the following are the states:

- Normal

- Warning

- Critical

- Shutdown

- Not Present

- Not Functioning

- Unknown

Failures

The failing component of the power supply being measured:

- None—No failure

- inputVoltage—Input power lost in one of the power supplies

- dcOutputVoltage—DC output voltage lost in one of the power supplies

- Thermal—Power supply thermal failure.

- Multiple—Multiple failures.

- Fan—Fan failure

- Overvoltage—Over voltage.

Memory Type

Type of memory including processor and I/O.

Used

Number of used MB for a particular memory type.

Free

Number of free MB for a particular memory type.

Largest Free

Number of largest contiguous free MB for a particular memory type.

Router Information

lists and describes the fields of the Router Information window.

Table 3-7 Router Information

Field

Description

Name

Name an administrator assigned to this managed node, this is the node's fully-qualified domain name.

Hardware

A textual description which should contain the manufacturer's name for the physical entity and be set to a distinct value for each version or model of the physical entity.

Supervisor Software Version

The full name and version identification of the system's software operating-system and networking software.

Up Time

The time (in hundredths of a second) since the network management portion of the system was last re-initialized.

Location

The physical location of this node.

Contact

The textual identification of the contact person for this managed node and information on how to contact this person.

Modem

Indicates whether the RS-232 port modem control lines are enabled.

Baud

The baud rate in bits per second of the RS-232 port.

Power Supply

Description of the power supply being instrumented.

Power Supply Type

The power supply source:

- unknown

- ac

- dc

- externalPowerSupply

- internalRedundant

Power Supply Status

The current state of the power supply being instrumented.

6: notFunctioning

Analyzing Media

The Analyzing Media contains the following sections:

- RTP Streams

- Voice Call Statistics

- Video Streams

- Video Channels Statistics

- Calls Table

- RTP Conversation

- Site MOS

- Video Channels Table

- Video Stream Conversations

RTP Streams

- Understanding the RTP Stream Data

- Monitoring RTP Streams

Understanding the RTP Stream Data

To view RTP stream information, summary statistics on the stream, and per-interval statistics, use the RTP Streams.

This window shows you three pieces of information:

RTP Stream Information

- Source IP Address and Port: IP address and UDP port of the originator of the RTP stream.

- Destination IP Address and Port: IP address and UDP port of the receiver of the RTP stream.

- SSRC: Synchronization source number as it appeared in the RTP header of the RTP stream.

- codec: encoding decoding format of the RTP stream.

RTP Stream Stats Summary

The summary includes the information about the RTP stream for the entire duration of RTP stream.

- Duration: duration of the RTP stream. This may not be the entire duration of the stream. It depends on the viewing time interval of the window which launched this RTP stream detail window.

- Worst / Duration Weighted / Max MOS: the lowest score among per-interval reports, the score of all per-interval reports that takes duration into account, and the highest score among per-interval reports of the stream.

Note Duration-weighted is calculated with the following formula:

SUM (per-minute-mos * duration) / SUM (duration)

- Worst / Duration Weighted / Min Jitter: the largest jitter among per-interval reports, the jitter that takes into account of the duration of all per-interval reports, and the smallest jitter values among per-interval reports of the stream.

Note Duration-weighted are used with the following formula:

SUM (per-interval-jitter * duration) / SUM (duration)

- Worst / Overall / Min Actual Packet Loss: Loss percent of RTP packets that are not seen by Packet Analyzer and RTP packets that arrived beyond the buffer capability of the receiving endpoint. This includes the highest percentile among per-interval reports, the sum of packets loss against total packets of all per-interval reports, and the lowest percentile loss among per-interval reports.

- Worst / Overall / Min Actual Packet Loss: Similar to above, but the percent loss only includes RTP packets that were not seen by the Packet Analyzer.

- Worst / Total / Min Concealment Seconds: Number of seconds in which Packet Analyzer detected packet loss during the duration of the stream. This includes lowest concealment seconds among per-interval reports, total concealment seconds of the entire duration of the stream, and highest concealment seconds among per-minute stream reports.

- Severe Concealment Seconds: Similar to above; severe condition is met when the seconds have more than 5 percent loss.

RTP Stream Stats Details

This table shows the per-interval stats calculated by Packet Analyzer at each interval. The columns of the tables are:

- Report Time: time when the stats were calculated. This is the end time of the interval.

- Report Duration: the stream duration during the report interval.

- Worst MOS: the lowest score of the stream among 3-second MOS score. Packet Analyzer internally evaluates the MOS value of the stream every 3 seconds. This is the lowest score among them.

- Average MOS: average score of the 3-second score values during the duration of the stream in the interval. This value is used in deriving the Duration Weighted MOS value in Packet Analyzer.

- Jitter: variation of packet arrival time compare to the expected time.

- Actual Packet Loss percentile: percentile of packets that are not seen by Packet Analyzer.

- Adjusted Packet Loss percentile: percentile of packets that include the actual packets lost an packets that had arrived too late to get into buffer prior to paying back at the endpoint.

- Concealment Seconds: number of seconds in which the Packet Analyzer sees packet loss.

- Severe Concealment Seconds: number of seconds in which the Packet Analyzer detected more 5 percent of packet loss.

- Packets: total packets Packet Analyzer have seen for the interval.

Monitoring RTP Streams

Use Packet Analyzer to monitor the network to ensure that call quality is good. If quality issues appear, isolate and troubleshoot the problem rapidly.

. You can access this from the RTP Conversation table by clicking on a specific stream or from the Call Detail window by clicking on the stream that is associated with the call.

This chart indicates current voice quality of all RTP streams being monitored. MOS values range from 1 to 5, where 1 is poor and 5 is excellent (see the legend for a breakdown into categories-Poor, Fair, Good and Excellent). Use the Top N RTP Streams source and destination endpoints to view whether there are calls that are in the poor range.

Step 2 To isolate calls that have had a poor MOS, scroll down to Top N RTP Streams and click on the chart to drill down into the RTP Stream Details. Note that MOS values for calls below 3.0 might be considered low. You can also look at the other metrics provided in the same row (for example, row one. note the jitter and packet loss rate scores to see if they also result in a low MOS value. This information can help you determine if jitter is the root cause of the poor calls; or if it is instead packet loss somewhere in the network.

Step 3 With the endpoints’ IP addresses, you can look at the network topology to identify where in the network your subnet is located.

. This page lists all interfaces and errors or discards on each interface. Look up the link that leaves the site in question. That interface is likely the source of the packet loss. Check the interface for faults and fix as needed.

Understanding RTP Streams

. You can also arrive at this page by:

- From the RTP Conversation table, clicking on a specific stream

- From the Call Detail window, clicking on the stream that is associated with the call

In this window, at least one of the following is required: Site or data source.

The five charts available in this window are:

- RTP Streams : Number of streams that fall in the quality bands of excellent, good, fair, and poor during the selected interval.

- Top N Source Endpoints : Endpoints that generated the lowest duration weighted MOS during the selected interval.

- Top N Destination Endpoints : Endpoints that experienced the lowest duration weighted MOS during the selected interval.

- Top N RTP streams : RTP streams that have the lowest duration weighted MOS during the selected interval.

- Top N RTP streams by Adjusted Packet Loss : RTP streams that have the highest overall adjusted packet loss percent during the selected interval.

Voice Call Statistics

. The charts will provide an overview of voice quality.

The charts available are:

- Voice Call Statistics : Number of calls per signaling protocol (SCCP, SIP, MGCP, and H.323) at each interval during the selected interval.

- Top N End Points by Jitter (ms) : Endpoints that have the largest average of endpoint reported jitter during the selected interval.

- Top N End Points by Packet Loss (%) : Endpoints that have the largest average of endpoint reported packet loss during the selected interval.

- Top N Calls by Jitter (ms) : Calls that have the longest endpoint-reported jitter during the selected interval.

- Top N Calls by Packet Loss (%) : Calls that have the most endpoint reported packet loss percent during the selected interval.

Video Streams

- Understanding the Video Stream Data

- Monitoring Video Stream Data

Understanding the Video Stream Data

The Video Streams window allows you to view video stream information, summary statistics on the stream, and per-interval statistics. Currently, Packet Analyzer monitors Video streams over RTP only.

The Video Streams window shows the following information depending on whether it is MPEG-TS stream:

- Video Stream Information

- Media Delivery Index Details of Current Stream’s Carrier RTP

- Video Stream of Codec Stats Summary

- Video Stream of Codec Stats Details

Video Stream Information

describes the Video Stream Information.

Table 3-8 Video Stream Information

Field

Description

Source IP Address and Port

IP address and UDP port of the originator of RTP stream.

Destination IP Address and Port

IP address and UDP port of the RTP stream.

SSRC

Synchronization source number that appears in the RTP header of the RTP stream.

Codec

Encoding decoding format of the video stream.

Note Currently, Packet Analyzer supports only MPEG-2 and H.264.

Program ID

For the MPEG-TS stream.

Protocol

Transport protocol for the video stream.

Possible options are:

- RTP

- RTP/MPEG-TS

Media Delivery Index Details of Current Stream’s Carrier RTP

describes the MDI details.

Table 3-9 MDI Details

Field

Description

Report Time

Time when the statistics were calculated. This is the end time of the interval.

Report Durations

Durations (in seconds) of valid MDI metrics in this interval.

Min/Max/Average Media Rate

The minimum/maximum/average media rate in this interval. The media rate is the media payload traffic rate for RTP packet and only counts the RTP payload octets.

Min/Max/Average Delay Factor

Delay factor is defined by RFC-4445 and is valid only when the traffic is CBR and is calculated on a per second basis.

Media Loss Rate

Media Loss Rate is defined by RFC-4445 and is the average MLR over the period.

Video Stream of Codec Stats Summary

describes the codec stats summary of the video stream for the entire duration of the video stream.

Table 3-10 Codec Stats Summary

Field

Description

Intervals monitored

Count of intervals that has been monitored.

Received Count / Impaired Count / Lost Count I Frame

Received/Impaired/Lost count of I frames in this period.

Received Count / Impaired Count / Lost Count All (I&B&P) Frame

Received/Impaired/Lost count of I/B/P frames in this period.

Worst / Min / Average I Frame Loss Rate

Worst/Minimum/Average Loss percent of I frames that are not seen by Packet Analyzer and is calculated with the formula:

SUM (I Frame Loss Count) / SUM (I Frame Received Count + I Frame Loss Count)

Worst / Min / Average All Frame Loss Rate

Worst/Minimum/Average Loss percent of all frames that are not seen by Packet Analyzer and is calculated with the formula:

SUM (I Frame Loss Count + B Frame Loss Count + P Frame Loss Count) / SUM (I Frame Received Count + B Frame Received Count + P Frame Received Count + I Frame Loss Count + B Frame Loss Count + P Frame Loss Count)

Video Stream of Codec Stats Details

The Video Stream of Codec Stats Details show the per-interval stats calculated by Packet Analyzer at each interval.

describes the Codec Stats Details.

Table 3-11 Codec Stats Details

Field

Description

Report Time

Time when the statistics were calculated. This is the end time of the interval.

Codec

Encoding decoding format of the video stream. Currently, it supports only MPEG-2 and H.264.

Frame Rate

Frame rate of the video stream.

I / B / P Frames Received

Received I/B/P frame count in the interval.

I / B / P Frames Impaired

Impaired I/B/P frame count in the interval.

I / B / P Frame Lost

Lost I/B/P frames that are not seen by Packet Analyzer in the interval (For H.264, it shows only I/None-I Lost).

Video Resolution

Width multiplied by height resolution of the video.

I / All Frame Loss Quality

Quality level of the interval and is calculated depending on the set Video Quality Ranges.

Monitoring Video Stream Data

.

The following charts get displayed:

- Video Frames—Number of Video Streams that fall in the quality bands of excellent, good, fair and poor during the selected interval.

- Delay Factor (MDI)—Number of MDI streams whose DF falls in the corresponding quality bands during the selected interval.

- Media Loss Rate (MDI)—Number of MDI streams whose MLR falls in the corresponding quality bands during the selected interval.

- Top N Source End Points—Endpoints that generated the largest frame loss rate during the selected interval.

- Top N Destination End Points—Endpoints that experienced the largest frame loss rate during the selected interval.

- Top N MDI Streams by Delay Factor—MDI streams that have the largest delay factor during the selected interval.

- Top N MDI Streams by Media Loss Rate—MDI streams that have the largest MLR during the selected interval.

Video Channels Statistics

The Video Channels Statistics charts provide an overview of video channels set up by media control signaling protocols.

The Video Channel Statistics chart shows the number of video streams per signaling protocol (SCCP, SIP, MGCP, H.323, RTSP and IGMP) at each selected intervals. The chart also shows the number of streams setup per protocol per state (Active, Paused, New and Terminated).

Calls Table

The Calls Table shows you calls that the Packet Analyzer detected by inspecting voice signaling protocols payload. For this table to have data, the Packet Analyzer must see:

- SCCP protocol—Call Information message of the call.

- SIP protocol—SIP INVITE message of the call. Note that SIP protocol will be detected as per call leg.

- H.323 protocol—Call SETUP of the call.

- MGCP protocol—Create connection message of the call. Note that MGCP will be detected per call leg.

Note SIP and MGCP will be detected per call leg. Each call could be two or more parties. Each party has its own call leg from the call party to control entity; for example, Cisco Unified Communications Manager or MGCP gateway. Any information that is not detected by Packet Analyzer will be displayed as “-” or blank.

. The Calls Table and RTP Streams for the Selected Call Table display. These tables show a list of all currently active calls.

Note Some values in the Calls table are not available until the end of the call, and Cisco Unified Communications Manager must be configured to have the IP phones send out the call status and quality information.

Note All calculated metrics in Table D-51, Calls Table, are based on a one minute interval.

provides descriptions of the Calls Table fields.

If you click on a call row in the table, in the RTP Streams for the Selected Call display at the bottom of the page you will see all streams that are associated with the call. It will display the RTP streams that:

- have source address and port matched the call’s calling host address and calling port or called host address and called port

- have destination address and port that matched the call’s calling host address and calling port or called address and called port

Note There is a delay of two minutes of RTP streams statistics. As the result, there may not be any RTP stream information of the call.

.

button. A pop up window will show more detailed information of the stream displayed.

RTP Conversation

. This table shows you the overview of RTP streams analyzed by Packet Analyzer during the selected interval. You can drill down to each stream to get stream statistics, which are analyzed by the Packet Analyzer at each interval. To get more detailed information, you can:

- Click on the RTP stream for which you want to see more information.

- Click on the “RTP Stream Details” context menu. A pop up window will show you the detailed information of the stream.

.

Site MOS

You can use the Mean Opinion Score (MOS) to quantify the perceived level of quality you are receiving in your network voice traffic. This allows you to assess the work of codecs, or algorithms, which compress audio traffic to save on bandwidth utilization but may result in a drop in quality.

You must first set up the software to monitor voice data, then you can view the collected voice data using Analyze > Media > Detailed Views > Site MOS.

contains details on Site MOS scores.

Video Channels Table

The Video Channels Table shows you video channels that are detected by inspecting media control signaling protocols payload. For this table to have data, the Packet Analyzer must use the below protocols:

- SCCP protocol—Video channels setup by this protocol for a VoIP call with video channel.

- SIP protocol—Video channels setup by this protocol for a VoIP call with video channel.

- H.323 protocol—Video channels setup by this protocol for a VoIP call with video channel.

- MGCP protocol—Video channels setup by this protocol for a VoIP call with video channel.

- RTSP protocol—Video channels setup by RTSP session.

- IGMP protocol—Video channels joined by IGMP/MLD protocol join message.

.

. You can view the Video Signaling Channel List, Video Stream Conversations, Media Signaling Sessions and RTP Streams for the selected Media Signaling Session. These tables show a list of all currently active videos on the related network.

Note All calculated metrics including stream state in Video Channels Table are based on one minute interval.

If you click on a video channel row in the Video Signaling Channel List table, you will see the following tables:

- Video Stream Conversation Table—Displays the video streams that have destination address and destination port matching with the video channel’s destination address and destination port, along with video channel start and end time.

- Media Signaling Session Table—Displays the media controlling session to setup related video channel. Signaling protocol to setup this video channel should be supported on Packet Analyzer.

- RTP Streams Table—Displays the RTP streams that have source address and port matching with the media control session’s calling/client host address and calling/client port or called/server host address and called/server port. Also, displays the destination address and port matching with the media control session’s calling/client host address and calling/client port or called/server address and called/server port.

Note There will be a delay of two minutes to display the RTP streams statistics. As a result, there will not be any RTP stream information for the video call.

.

button.

Note Video channels setup by supported media controlling protocol will have codec which are not supported by Packet Analyzer. Such video channels will not have any video conversation to display on Packet Analyzer.

See section Video Stream Conversations for more details on video conversation.

Video Stream Conversations

.

The following charts get displayed:

- Video Frames—Number of Video Streams that fall in the quality bands of excellent, good, fair and poor during the selected interval.

- Delay Factor (MDI)—Number of MDI streams whose DF falls in the corresponding quality bands during the selected interval.

- Media Loss Rate (MDI)—Number of MDI streams whose MLR falls in the corresponding quality bands during the selected interval.

- Top N Source End Points—Endpoints that generated the largest frame loss rate during the selected interval.

- Top N Destination End Points—Endpoints that experienced the largest frame loss rate during the selected interval.

- Top N MDI Streams by Delay Factor—MDI streams that have the largest delay factor during the selected interval.

- Top N MDI Streams by Media Loss Rate—MDI streams that have the largest MLR during the selected interval.

.

Using the Packet Analyzer Application Programming Interface

Packet Analyzer provides an Application Programming Interface (API) that allows you to configure and retrieve data from the Packet Analyzer. The API follows the commonly used Representational State Transfer (REST) style of providing services over HTTP or HTTPS. The Packet Analyzer REST API is also referred to as the Northbound Interface (NBI).

.

Capturing and Decoding Packets

You can use Packet Analyzer to capture packets to disk or memory buffers. Capture filters is used to select which packets to keep and which to drop. Packet Analyzer also supports built-in packet decoder which can decode captured packets from .pcap files on the disk or directly from a capture memory buffer. Decode filters shows only the interested packets and these interested packets are be written to a new .pcap file. You can then manage the data in local or remote storage and display the contents of the packets to collect troubleshooting information.

This chapter contains the following sections:

- How Do I Solve My Problem?

- Manually Starting a Capture

- Using Alarm-Triggered Captures

- Scheduling Captures

- Troubleshooting Application Slowness Using Alarms

- Application Performance Monitoring Using Capture and Decode

- Creating and Managing Capture Sessions

- Working with Capture Files

- Utilizing Capture Data Storage

- Working with Capture Query

- Inspecting Packet Decode Information for Suspicious Traffic

How Do I Solve My Problem?

This section provides an overview of how to collect and analyze packet data to ensure your network is running well or pinpoint network issues.

for details on how to get a quick capture.

provides an at-a-glance summary of capture tasks you can perform to ensure your network is optimized and trouble-free.

Table 4-1 Data Collection and Analysis At-a-Glance

Basics

Operation

Description

Capture the traffic quickly from any Packet Analyzer dashboard when anomalies are present

Quick Capture

Targets data collection based on the dashboard graph you select and provides a capture session and decode window to analyze the traffic immediately. See Manually Starting a Capture.

to configure and start your capture.

Proactively capture packet data to learn the cause of a network issue

Continuous capture or schedule capture

Allows you to set up data collection to:

- Collect data prior to a network problem

- Set up data collection based on an anomaly that reoccurs

See Using Alarm-Triggered Captures or Scheduling Captures.

Create hardware and software filters to focus on specific long-term packet data

On supported Packet Analyzer hardware, helps to limit the amount of packet data processing. See Configuring Hardware Filters and Configuring Software Filters.

Storing packet data for problem identification

Continuous capture

Allows you to save data to external storage targets, potentially for larger disk capacity and higher capture throughput or to offload capture files. Continuous capture overwrites itself in memory when the buffer is full.

See About Capturing to Data Storage.

Create targeted monitoring for problem isolation

Stop Capture and Save to File

.

See Configuring Alarm Actions and Using Alarm-Triggered Captures.

Set up storage for data collection

Allows you to save data for extended periods either to memory or storage. See About Capturing to Data Storage.

Analyze data for potential issues

Decode

See Inspecting Packet Decode Information for Suspicious Traffic.

Manually Starting a Capture

. Figure 4-1 shows an example of a context menu for Top N Applications dashboard.

For details on how to use the decode window to analyze your data, see Inspecting Packet Decode Information for Suspicious Traffic.

Figure 4-1 Quick Capture

Using Alarm-Triggered Captures

You can configure multiple alarm-triggered captures that start and stop automatically by alarm events you define.

To set up an alarm-triggered capture:

and create a capture session. For detailed instructions, see Configuring Capture Sessions.

to make a new trigger capture action which uses the session from Step 1.

Configure an alarm event for the type of event for which you want to capture data. For detailed instructions, see Configuring Alarm Actions.

window.

To configure the threshold of parameters of interest in the associated Alarm Event, see Defining Thresholds.

Scheduling Captures

You can configure multiple time-based triggered captures that start and stop automatically based on a certain time or period of time that you define. This is also referred to as continuous capture. Continuous capture overwrites itself in memory when the buffer is full. The following is an example of setting a 60 minute window to schedule capture packet data.

To set up a schedule capture:

window.

check box.

.

.

Step 5 Select appropriate software filters.

.

.

Troubleshooting Application Slowness Using Alarms

This section describes how to use Packet Analyzer to use triggered alarms and capture files to help you determine the source of some network problems.

Before You Begin

You must already create an alarm that notifies you when there is a surge in application traffic. If you need to create an alarm, thresholds, and set up email notification, see Setting Up Alarms and Alarm Thresholds.

To use existing alarms to help you to create and analyze captured packet files:

to view the Top N Applications by Alarm Count dashboard.

, you could view the top sites by alarm count dashboard in order to see the alarm details and determine what threshold variable is causing the alarm to trigger.

in order to analyze the response time during the time interval of the alarm trigger. If you application is not listed in the graph, you can select the table icon to choose your application from the list of all the applications and drill down from there to analyze the response time.

Step 3 Adjust the Interactive filter to view specific time ranges and severity levels in order to view where the spike in response time occur. This helps to determine if the occurrence is limited to a one-time event, if it occurs more than once in a short period of time, or is an event related to a specific time of the day. For example, by changing the time range filter from 1 hour to 4 hours to 1 day, you can see the latest data trends that help you to determine what to do next. See Filtering Traffic for Viewing on the Dashboards.

Step 4 In the graph that displays, focus in on the time frame when the event occurs by using the slider to pinpoint the event. Look for peak or valleys; these may be critical changes that require investigation. Using the legend you can determine whether the event was caused by the network or server. See Changing the Time Interval Using Zoom/Pan Charts.

Step 5 Select any of the metrics provided below the application average response time graph.

a. To view if there are specific clients that have significant transaction time differences, see the Top Clients By Average Transaction Time graph in order to identify data such as Client-Server Application Transactions using an application-specific filter.

- To view a table of response time metrics and add new metrics for additional data (such as average server response time) and use the drop down menu to select which other metric data you want to appear in the graph.

Application Performance Monitoring Using Capture and Decode

This task explains how to proactively monitor your application performance, then use it to help isolate and troubleshoot application latency issues experienced by your end user.

Before You Begin

, see Synchronizing Your System Time.

and select the Deep Packet Inspection check box.

For detailed instructions, see Adding More Detail into Dashboard and Application Reports.

.

For detailed instructions, see Setting Up Alarms and Alarm Thresholds.

and use the Top N Applications by Transaction Time dashboard to identify which application may be impacted.

You can select the table view to see more than the top default applications. You can also use the other dashboards to view server or client transaction times. See Using Response Time Summary.

Step 4 Analyze the application performance behavior over time using the Interactive Report filter. Determine if the behavior is transient, persistent, recurring, and so on. For details on using the Interactive Report filters, see Filtering Traffic for Viewing on the Dashboards.

Step 5 Zoom in to view specific spikes in the performance, and drill down to isolate whether the cause of the degradation stems from your network, server or application. See Changing the Time Interval Using Zoom/Pan Charts.

Step 6 Analyze the server response time and network performance metric in order to eliminate one of them as the cause. See Server Response Time and Network Response Time.

Step 7 Analyze server activity based on the traffic the server is placing on the network and assess the cause of increase in the server response time. See Analyzing Host Traffic.

Step 8 Perform packet captures in order to identify the root-cause. For details on quick captures or trigger captures, see Capturing and Decoding Packets.

Step 9 Perform additional actions to isolate and troubleshoot the problem including: QoS analysis and interface analysis.

Creating and Managing Capture Sessions

You can use capture sessions to capture, filter, and decode packet data, manage the data in a local or remote storage, and display the contents of the packets. The captured packets can be decoded and analyzed using Packet Analyzer for more efficient problem isolation.

This section contains the following topics:

- Configuring Capture Sessions

- Configuring Software Filters

- Configuring Hardware Filters

- Understanding Hardware and Software Capture Sessions Filters

- Viewing Capture Sessions

Configuring Capture Sessions

It is important for you to collect data over time and have various locations for which you want to analyze data, we support multiple sessions per capture location/target. You can collect data using multiple sessions per target, but only one session runs per hard disk target. Concurrent capture sessions can run if capture to buffers or different hard disk based targets. This limitation is mainly to avoid disk fragmentation and better performance. Capture decode filters can be used to view or separate different subset of packets to different files. Packet Analyzer now supports up to 25 capture sessions. If you have external storage you can save to local disk and some number of LUNs. As part of configuring a capture session, you can also create software filters, if desired (see Creating a Software Capture Filter for a Capture Session).

To configure a new capture session:

.

to set up a new capture. The Packet Analyzer displays the Configure Capture Session window.

) as appropriate.

, and so on.

to finish configuration for this session, or configure Software Filters for this session .

Configuring Software Filters

You can create and save specialized filters that will disregard all capture data except the information in which you are interested (see Figure 4-5). You can configure multiple software filters for each session (up to six). This allows you to narrow in on the traffic that you are interested in, and it also saves resources (either memory or disk space).

Use the following topics for help on filtering network traffic using software filters:

- Creating a Software Capture Filter for a Capture Session

- Editing a Software Capture Filter

- Understanding Software Capture Filter Options

Creating a Software Capture Filter for a Capture Session

You can create software capture filter for many variables. This workflow examines how to create a capture session with a software filter.

To create a software capture filter:

.

to create a new capture session.

If you already have a capture session to which you want to add a software filter, see Editing a Software Capture Filter for detailed instructions.

section.

for descriptions of the fields.

to close the dialog box without creating a software filter.

Editing a Software Capture Filter

To edit software capture filters:

.

.

.

.

Step 4 Enter information in each of the fields as appropriate.

Step 5 Do one of the following:

- To apply the changes, click Submit .

- To cancel the changes, click Cancel .

Important Notes about Software Capture Filters

This section contains important software capture filters details that may be helpful to know.

- Multiple software filters use the “OR” logic; in other words, if a packet passes any software filter, it is captured.

- If you create a session and then start it, you cannot edit the session or analyze it without stopping it. If you edit a session containing already captured data, you get a warning stating that the session will be cleared and the data removed. If clearing the session and removing the data is acceptable, ignore the warning dialog message, then add a filter to the session and click Submit to enable the new filter settings.

- The application filter can be used to filter on the highest layer of the protocol parsing; that is usually a layer 4 protocol (based on port). If you want to filter on the transport protocol (for example, UDP or TCP), you will need to use the IP Protocol selector. Selecting, for example, TCP in the “IP Protocol” selector will filter on all packets using TCP.

Tip Be careful when setting capture software filtering for encapsulation. If you set a software capture filter with encapsulation for the top three network traffic layers only, data displays only if the top three layers match the specified encapsulation type.

Understanding Software Capture Filter Options

You can define a software filter to filter based on any of the following options:

- Source host address

- Destination host address

- Network encapsulation

- VLAN or VLAN range

- TCP Flag bits

- Application

- Source port or port range

- Destination port or port range

- IP Protocol

Note Software capture filtering is not supported on URL-based applications.

contains descriptions of the Software Filter dialog box fields.

Note The parameters described in the table above are independently evaluated by the Packet Analyzer. Therefore, the Packet Analyzer will allow you to enter parameters that are contradictory, but you will not be able to get meaningful results if they do not match.

For example, the parameters Network Encapsulation and Source/Destination Address are independently evaluated. If a filter is specified with contradicting parameters such as “Network Encapsulation=IP4” and “Source Address=an IPv6 address”, it will never match any traffic, and the result will be 0 packets captured.

Configuring Hardware Filters

You can use hardware filtering to help limit the amount of traffic allowed into the Packet Analyzer for processing. The Packet Analyzer hardware platforms that support hardware filtering include:

- Specific Packet Analyzer 2000 Series Appliance—2400

Depending on your Packet Analyzer, the hardware filter support varies.

Creating Packet Analyzer Appliance Hardware Filters

This section describes how to create Packet Analyzer appliance hardware filters.

The Hardware filters allow you to improve capture performance by eliminating extraneous traffic, since packets filtered out are excluded from capture processing.

Note The hardware filter applies to the Packet Analyzer 2400 appliance. .

Software filters add flexibility to your filtering, but a capture session is most efficient when you use hardware filters only. The less traffic requiring software filtering, the more efficient the filtering.

For the Packet Analyzer appliances that support hardware filtering, you can set up to five hardware filters per appliance. When multiple hardware filters are created on the appliance, the logic among them are OR logic.

Hardware filters and global packet slicing affect all capture sessions, except for ERSPAN capture sessions.

All fields within a single filter are combined with AND logic. The filters are then combined with OR logic. See Figure 4-2 for examples of filter logic you can use.

Figure 4-2 Hardware Filter Logic (AND/OR)

See Configuring Supported Packet Analyzer Appliance Hardware Filters for detailed steps.

Configuring Supported Packet Analyzer Appliance Hardware Filters

window. To configure a hardware filter:

.

.

Step 3 Enter a name in the Name field.

Step 4 Choose any or all of the following types of filters:

- VLAN

- VLAN and IP

- IP

- IP and TCP/UDP

- IP and Payload Data

- Payload Data

Note When you use the IP address fields in the hardware filters, tunneled packets will be filtered based on the outer IP address. The Packet Analyzer will further inspect matching packets to analyze the contents within the tunnel. The Packet Analyzer will always display the inner IP address in the packet list. See Understanding the Packet Analyzer Packet Decoder for details.

Step 5 Data fields will then appear that correspond with the type of hardware filter you select. Fill in the desired fields.

to complete the configuration of the capture session.

IP and Payload Data

To configure an IP and Payload Data hardware filter:

Step 1 Enter a Filter Name and select your options.

Step 2 Enter a Source Address / Mask (optional).

Step 3 Enter a Destination Address / Mask (optional).

Step 4 Choose a Layer 4 Protocol, either TCP or UDP.

Step 5 Enter the values for Pattern Match:

- Enter a Value of up to four bytes (eight hex characters).

- Enter a Mask of up to four bytes (eight hex characters).

- Enter an Offset from 1-1023. The offset is relative to the beginning of the payload (Layer 5).

Note Only one payload segment (one row) is required and provided. This is to guard against overlapping payload segments. If overlapping segments have different values the filter will never match anything due to the inherent AND logic.

.

Payload Data

To configure a Payload Data hardware filter:

Step 1 Enter a Filter Name.

Step 2 Choose a Layer 4 Protocol, either TCP or UDP.

Step 3 Enter the values for Payload Data:

- Enter a Value of up to four bytes (eight hex characters).

- Enter a Mask of up to four bytes (eight hex characters).

- Enter an Offset from 1-1023. The offset is relative to the beginning of the payload (Layer 5).

Note Only one payload segment (one row) is required and provided. This is to guard against overlapping payload segments. If overlapping segments have different values the filter will never match anything due to the inherent AND logic.

.

Configuration Example

Figure 4-3 and Figure 4-4 shows configuration examples on how to calculate the offsite value and how to set mask to use the payload feature.

Figure 4-3 Configuration Example

Figure 4-4 Configuration Example (Continued)

Understanding Hardware and Software Capture Sessions Filters

You can filter specific traffic data and manage that information in local or remote storage. This increases your visibility into network issues and allows you to filter out unnecessary information. You can use either hardware or software filters to target specific packet data to receive.

As shown in Figure 4-5, if network packets coming into the Packet Analyzer pass through the hardware filters you have configured, the packets go on to the next step. If no hardware filters are configured, all packets pass through.

Note Hardware filters are supported on specific Packet Analyzer platforms. See Configuring Hardware Filters for details.

Packets must then pass at least one software filter in that particular session to be saved by that session. If no software filters are configured for a session, then all packets are captured. For more information about software filters, see Configuring Software Filters.

For better performance for the supported Packet Analyzer platforms, hardware filters are recommended over software filters, and fewer sessions are recommended over more sessions.

You do not have to configure the items in Figure 4-5 in any particular order. For example, you can set Global Capture Settings first, and then configure Capture Sessions, and then create filters; or, you can create Hardware and Software filters first, and then configure Capture Sessions, and finally apply Global Capture Settings. We recommend that you “Start” the session last; otherwise, you will start capturing before you have configured any filters and before doing any packet slicing.

Global Capture Settings and Hardware Filters can be changed at any time, even when the session is running; they will affect running capture sessions immediately. We recommend that you first stop your capture session to edit it since you may capture some unexpected packets during the filter change.

Figure 4-5 Packet Analyzer Capture Sessions Example

Viewing Capture Sessions

.

describes the Capture Sessions fields and operations that you can perform from the Capture Sessions window.

Working with Capture Files

To decode, download, rename, convert/merge, delete, analyze, or error-scan saved packet capture files use the Files option.

This section covers the following topics:

- Analyzing Capture Files

- Downloading Capture Files

- Deleting a Capture File

- Deleting Multiple Capture Files

- Understanding Capture Sessions

Analyzing Capture Files

) enables you to obtain various statistics including traffic rate (bytes/second) over a capture period and lists of hosts and protocols associated with network traffic.

button.

Note After clicking the Drill-Down button, the Host Statistics results table will display both source and destination hosts, if either the source or destination host of the traffic belongs to the Host/Subnet that you had specified.

graph displays the amount of traffic for the amount of time set in the Granularity of the capture file.

address.

describes the different areas of the Capture Analysis window.

Drilling Down into Packet Error Details

You can further investigate, or drill down, into packet error details by viewing the decode packet data available on Packet Analyzer.

The Capture Errors and Warnings Information window shows warnings and errors, and packet irregularities. From here, you can launch the Packet Decode Window, where you can drill down to packet details.

button.

Downloading Capture Files

You can only download one capture file at a time. To download a capture file to your computer:

.

Step 2 Choose a capture file from the list of captures.

.

.

dialog box opens and provides a way for you to rename and save the file at a location of your choice.

Deleting a Capture File

To delete a capture file:

.

Step 2 Check the check box to select a capture file from the list of captures, or select more than one if desired.

” and displays the file name.

to allow the file(s) to remain.

Deleting Multiple Capture Files

To delete all capture files at once:

.

Step 2 Check at least one check box to select a capture.

to delete all captures.

”

to allow them to remain.

Understanding Capture Sessions

To understand how Packet Analyzer creates capture files with saved packet data, it is important to learn about how Packet Analyzer handles capture session triggers.

This section contains the following topics:

- Types of Capture Triggers

- Resolving Session Conflicts

- Manipulating Capture Files

Types of Capture Triggers

Packet capture sessions can be triggered on the Packet Analyzer in several ways:

- Manually, by starting a capture using the Capture menu option or clicking the Start capture button.

- Scheduled, by specifying a start date/time and maximum duration when you create or edit a capture session.

- Alarmed, by creating an alarm with an associated trigger capture action that starts a particular capture session.

Resolving Session Conflicts

Packet Analyzer supports multiple capture sessions associated with the same capture storage location, but only one of these sessions can be running at any given time. Since there are several ways for such capture session to be started, it is possible for conflicts to arise among such capture sessions.

For example, suppose one capture session is started manually, but another capture session is scheduled to begin capturing while the first is still running. If these two sessions capture to the same storage location, there is a conflict. In this case, Packet Analyzer resolves the conflict by automatically stopping the manual session and allowing the scheduled session to begin.

In general, Packet Analyzer resolves capture session conflicts by prioritizing them in the following (descending) order:

1. High-severity alarm triggered capture

2. Low-severity alarm triggered capture

3. Scheduled capture

4. Manual capture

If a manually started capture session is saving data to the local disk and a scheduled capture is set to begin capturing to the same local disk, Packet Analyzer does not stop the manual session if the “uninterruptible” flag is set to true.

If there are existing capture sessions already running on the same storage target, this means there is a conflicting alarm trigger. An alarm trigger is created when you configure an alarm threshold to start collecting packet data. Each alarm has a severity option.

Once a capture session is completed, you can manipulate the file. See

Manipulating Capture Files

.

For information about how to save capture sessions to files, see Creating and Managing Capture Sessions.

Caution If you have capture files with a state of Full and the Packet Analyzer is rebooted, the capture is triggered again and these files may be overwritten by the new capture. If you want to retain the file, save the file before you reboot.

Table 4-2 Actions You Can Complete with Capture Files

Action

Description

Decode

Display the packets in a file.

Download

file format.

Note Do not add a file suffix when you provide the filename. The suffix .pcap is added automatically.

Rename

Give the file a new name. A dialog box displays and asks you to enter the new name for the selected capture file.

Merge

Merges capture files that were captured simultaneously in chronological order.

Note Merged files cannot exceed 2,000 MB. This limit is set purposely since many tools can not handle the large size capture files.

Delete

Delete selected capture files.

Analyze

View statistical analysis of the selected capture. See Analyzing Capture Files.

Errors Scan

View more information about the file (Packed ID, Protocol, Severity, Group, and Description). From here you can also decode the packet. For more information see Drilling Down into Packet Error Details.

Utilizing Capture Data Storage

Cisco Security Packet Analyzer platforms offer external storage connectivity for extended capture durations and higher capture bandwidths. All platforms support iSCSI data storage. Some platforms may support other forms of data storage, but this document covers only iSCSI data storage.

This section covers the following topics:

- About Capturing to Data Storage

- Installing and Configuring Local and External Storage

- Recovering Data Storage

Figure 4-6 External Storage Setup

About Capturing to Data Storage

page.

.

This release supports 32 external data storage targets, or Logical Unit Numbers (LUNs).

You can create multiple capture sessions per target. Only one capture per storage target (file location) is allowed at a time. Additionally you can have multiple sessions to memory.

Installing and Configuring Local and External Storage

You can use local or external storage as a repository for long term data for performance comparisons.

This topic covers:

- Configuring the iSCSI and SAS Array

- Locating the Packet Analyzer IQN and SAS Address

- Preparing LUNs for File Storage in iSCSI and SAS

- Connecting to the iSCSI Array

- Using LUNs to Store Packets in iSCSI and SAS from a Capture Session

- Logging In and Out of External Storage LUNs

- Connecting and Disconnecting iSCSI and SAS

- Configuring External SAS port

Configuring the iSCSI and SAS Array

You may decide that in addition to or instead of local storage that you want to set up an external storage drive using iSCSI and SAS. This section contains the required settings for Packet Analyzer.

Use your vendor's user documentation to ensure you have properly configured the iSCSI and SAS array. The Cisco Packet Analyzer is independent of most array settings, but some are important for accessibility and performance.

Step 1 To configure the disk volumes on the array there is often a Segment Size setting. Larger segment sizes can improve write speeds. Configure the Segment Size setting to use the largest possible segment size (up to 512 KB).

Multiple volumes can be configured on a single array.

Step 2 Assign a Logical Unit Number (LUN) to the disk volume. This number is used for volume identification by the host.

. Each IQN and SAS unique identifier represent a different list of LUNs which hosts (such as the Packet Analyzer) can access.

Packet Analyzer supports up to 32 LUNs between all protocols and multiple LUNs mapped to one IQN and SAS address.

Step 4 Packet Analyzer also has an IQN, which represents the host side of an iSCSI session and a SAS address which resentment the SAS session. You must give the Packet Analyzer’s IQN SAS address access to the iSCSI and SAS array’s LUNs. The arrays call this Host Access. Be sure to give the Packet Analyzer’s IQN and SAS address read-write access. Most arrays require this for security reasons to ensure that only certain hosts can access the LUNs.

Each Packet Analyzer has a unique IQN and SAS address, so perform this required step for each Packet Analyzer that requires access and for each target LUN that you want to access. For more details about which CLI command to use, see Locating the Packet Analyzer IQN and SAS Address.

Caution Only one Packet Analyzer should connect to a LUN because only one host can have write access at a time. If multiple Packet Analyzer connect to the same LUN simultaneously, there will be access conflicts and capture operations may not work properly.

Step 5 Ensure the Packet Analyzer management port has IP connectivity to the iSCSI or SAS array. For details on how to complete this required task, see Connecting to the iSCSI Array.

Locating the Packet Analyzer IQN and SAS Address

To find the Packet Analyzer IQN, use the remote-storage iscsi local-iqn CLI and for SAS address, use the remote-storage sas local-address command:

root@secpaxx# remote-storage iscsi local-iqn

Local iSCSI Qualified Name: iqn.1987-05.com.cisco:WS-SVC-NAM3-6G-K9.00:19:55:07:15:9A

For details on how to complete the storage array configuration, see Connecting to the iSCSI Array.

Connecting to the iSCSI Array

After you configure the iSCSI storage arrays, ensure that the array has an IP path to the Packet Analyzer management port. The array can be connected while the Packet Analyzer is running.

Some arrays come with multiple storage controller modules. As a security feature, module ownership must often be mapped to each LUN or IQN.

The Packet Analyzer logs into the storage to start an iSCSI session using the IP address and IQN(s) of the storage array.

To connect the storage array using the user interface:

.

Step 2 Click iSCSI Login and enter the iSCSI array IP address. Then click Search IQN Targets.

A list of IQNs available to the Packet Analyzer host IQN appear.

Step 3 Depending on the outcome, perform one of the following steps:

a. If the IQNs do not appear, check remote-storage iscsi list to verify the iSCSI session was properly started.

The follow example shows how to verify the iSCSI session.

helps you identify one LUN from others mapped to the same IQN. This number is unique to each IQN, meaning two LUNs from different IQNs can have the same number.

b. If the iSCSI session was properly started, check the storage array configuration to verify that:

- The LUNs are mapped to the target IQN, and

- The Packet Analyzer IQN has been given Read/Write access to the LUNs.

. All LUNs mapped to that target IQN will be disconnected from the Packet Analyzer.

Preparing LUNs for File Storage in iSCSI and SAS

Some arrays come with multiple storage controller modules, and the module ownership must often be mapped to each LUN (Logical Unit Numbers). This is a common security feature.

To see if the Packet Analyzer can access the storage array LUNs and prepare them to store files:

.

.

a. Skip to Step 3 if your LUNs are formatted.

b. If no LUNs appear, see Installing and Configuring Local and External Storage and Configuring the iSCSI and SAS Array for detailed instructions on how to set up your storage array.

.

.

The Label dialog appears with information about the current label and the last time the LUN was formatted.

You are now ready to use the external storage for capture files.

Using LUNs to Store Packets in iSCSI and SAS from a Capture Session

To use a LUN to store packets from a capture session:

.

.

option.

state.

to create the session.

. At that point, no other session can use that LUN until the session is deleted. This prevents contention, corrupted data, and write bandwidth degradation.

Logging In and Out of External Storage LUNs

You can use iSCSI to facilitate data transfers over intranets and to manage your remote capture data storage.

Packet Analyzer provides a more streamlined workflow to log in and out of your data storage targets. You must log into iSCSI in order to save capture sessions to remote storage. If you do not log in, capture sessions are saved to either local disk or memory locations.

To log in or out of your available remote data storage LUNs:

Step 1 Ensure you have configured your target iSCSI system with read/write permission to your Packet Analyzer for at least one LUN in the storage array. For details, see About Capturing to Data Storage.

.

.

All available IQNs for that location display in the table.

. The list of IQNs to which you are currently logged into displays in a table.

Step 5 To view the LUNs which the system will log you out, select one of the IQNs and a popup displays the associated LUNs to select.

.

Connecting and Disconnecting iSCSI and SAS

in the status column, and it is safe to remove the external storage device. External storage is automatically unmounted in this manner when the Packet Analyzer is powered down.

Caution If this step is skipped, it is possible to corrupt the storage data upon physical disconnect.

button. It will restore the storage target’s previous state. This makes it unnecessary to physically disconnect and reconnect the storage, which can be particularly useful if the storage is located far away from you.

Configuring External SAS port

All the Cisco SEC-PA-2400-K9 appliances have two SFF8644 mini-SAS HD connectors on UCSC-SAS9300-8E card (See Figure 4-7) at the rear of the chassis, which supports iSCSI managed storage arrays using x8 wide SAS ports. Use SFF-8644 (12G SAS) port to reach the SAS storage.

page to see the External SAS storage devices.

Figure 4-7 UCSC-SAS9300-8E Card

Recovering Data Storage

.

The following shows a iSCSI recovery example:

root@secpa.cisco.com# remote-storage iscsi list

Storage ID: 16

Label:

Status: Unformatted

Protocol: ISCSI

Target IP: 172.20.10.81

Target IQN: iqn.2011-09:celeros.target11

Model: IET VIRTUAL-DISK

LUN: 4

Capacity: 24.98GB

Available: 24.98GB

Storage ID: 15

Label: target 16

Status: In Use

Protocol: ISCSI

Target IP: 172.20.10.81

Target IQN: iqn.2011-09:celeros.target16

Model: IET VIRTUAL-DISK

LUN: 5

Capacity: 24.98GB

Available: 16.47GB

Active iSCSI Sessions:

tcp: [8] 172.20.10.81:3260,1 iqn.2011-09:celeros.target11

tcp: [7] 172.20.10.81:3260,1 iqn.2011-09:celeros.target16

root@secpa.cisco.com# remote-storage iscsi fsck 16

FS check completed successfully.

root@secpa.cisco.com# remote-storage iscsi list

Storage ID: 16

Label:

Status: Ready

Protocol: ISCSI

Target IP: 172.20.10.81

Target IQN: iqn.2011-09:celeros.target11

Model: IET VIRTUAL-DISK

LUN: 4

Capacity: 24.98GB

Available: 9.87GB

Storage ID: 15

Label: target 16

Status: In Use

Protocol: ISCSI

Target IP: 172.20.10.81

Target IQN: iqn.2011-09:celeros.target16

Model: IET VIRTUAL-DISK

LUN: 5

Capacity: 24.98GB

Available: 16.47GB

Active iSCSI Sessions:

tcp: [8] 172.20.10.81:3260,1 iqn.2011-09:celeros.target11

tcp: [7] 172.20.10.81:3260,1 iqn.2011-09:celeros.target16

Working with Capture Query

Capture sessions will have files associated with them. This feature will query all the files associated with a particular capture session for packets matching some search criteria.

When you run the query, it will generate pcap files that contain packets matching the search criteria. These query files will be archived within a gzipped tar file (.tgz) so the files can be easily downloaded for offline processing.

Note The Security Packet Analyzer has a built-in decoder for inspecting the results.

- This feature is available in Packet Analyzer 2400 modelsYou can only query the capture session with File as Storage Type (also known as capture to disk's session).

- Capture query will not be applicable to the captured files which have been modified. For example, in Capture > Packet Capture/Decode > Files page, if you change the captured file name by renaming or merging, then that capture session associated capture files can no longer be used for query.

- For a captured session in running state, there will be a captured file. The query job will skip this captured file and will not perform any search/match operation. You have to do the query only after the file writing process is complete or after the capture session is stopped manually.

- Capture > Packet Capture/Decode > Query page can show only the last 100 queries in the History table.

Related Topics

- Creating a New Query

- Decoding a Query

- Downloading Query Files

- Deleting a Query

- Duplicating a Query

Creating a New Query

To create a new query:

.

to create a new query.

for descriptions of the fields.

to close the dialog box without creating a query.

Only one query job will run at a time. If multiple query jobs are submitted, the queries will be queued and will run only after the previous job is completed or canceled manually. The job in the queue will run based on the queue order.

Canceling a Query

To cancel a query:

.

Step 2 Select a query from the Queue table.

to cancel the query.

The canceled query will move to the history table with a status indicating that they are canceled. The canceled query will have some files associated with it which can be decoded but it will not have a .tgz archive for download.

Decoding a Query

To decode a query:

.

Step 2 Select a query from the History table.

.

.

For detailed steps, see Analyzing Packets in the Packet Decoder.

For certain queries, Decode button will be disabled. This is because the query result file (.pcap and .tgz) will not be available.

Downloading Query Files

You can download all of the query files for a particular query with one click. To download the query files to your computer:

.

Step 2 Select a query from the History table.

.

dialog box opens and provides a way for you to rename and save the file at a location of your choice. The files will be grouped within a gzipped tar file (.tgz).

For certain queries, Download button will be disabled. This is because the query result file (.pcap and .tgz) will not be available.

Deleting a Query

To delete a query and it’s associated files:

.

Step 2 Select a query from the History table.

.

to allow the query to remain.

Duplicating a Query

You may want to create a new query that is similar to one of your previous queries. The duplicate feature makes it easy to reuse and alter the parameters from a query in the History table.

To duplicate a query:

.

Step 2 Select a query from the History table.

.

.

Step 4 Modify the required query parameters.

to close the dialog box without duplicating a query.

Inspecting Packet Decode Information for Suspicious Traffic

After you have captured some traffic data packets, you can use the Packet Analyzer packet decoder to view the packet contents and inspect for suspicious traffic.

This section includes the following sections:

- Analyzing Packets in the Packet Decoder

- Filtering Packets Displayed in the Packet Analyzer Packet Decoder

- Viewing Detailed Protocol Decode Information

- Understanding the Packet Analyzer Packet Decoder

Analyzing Packets in the Packet Decoder

Figure 4-8 Packet Decoder Window

Note To use these decode features, you must be capturing to memory with the no rotate option selected. Otherwise, captures must be paused or stopped. For detailed descriptions about the features in this window, see Understanding the Packet Analyzer Packet Decoder.

To inspect packet decode information for suspicious traffic:

.

.

Step 3 To quickly filter on a key word or phrase, for example rtp to focus on voice quality, enter the word in the Filter text box (see Figure 4-8). The window refreshes displaying only data that includes the filtered information.

. This action displays only the distribution of the packets that match your filter. For detailed steps, see Filtering Packets Displayed in the Packet Analyzer Packet Decoder.

on the Display Filter window. You can also edit or remove existing filters as needed.

Step 6 To view the packet capture flow and focus in on a specific time interval or area of interest click on the slider in the Packet Histogram and move the left or right cursors to zoom in (see Figure 4-8). To pan this filtered data, click and hold the slider while moving it inside the histogram. This provides a visual of packet capture flow and enables you to navigate through the packet list.

Step 7 To toggle

- between a one and two-column layout view, choose Tools > Toggle Layout .

- between the Packet Histogram and the packet paging controls, choose Tools > Show ...

.

.

. Only visible when filters are in use. Saves to memory or to the capture file based on the options in your Capture Sessions window. See Configuring Capture Sessions.

.

Step 12 Use the Tools menu to perform validation tasks—options have limited support. Options include:

– TCP Checksum Validation check box—filter on TCP in the decode window and use the TCP pane to verify that the checksum has been validated.

– UDP Checksum Validations check box—filter on UDP in the decode window and use the UDP pane to verify that the checksum has been validated.

– IP Host Name Resolution—perform global host name resolution for Packet Analyzer. Synchronizes with the Administration preferences.

Step 13 Use Decode As option to temporarily force specific tcp and /or udp ports to be decoded as the specific protocols as specified by the user. This is useful for custom protocols that use user defined ports or the same ports may be used by more than one protocols

Step 14 To view packet details including packet range displayed, data port, and number of filtered packets, see the heading in the upper right corner of the Packet Analyzer window.

Filtering Packets Displayed in the Packet Analyzer Packet Decoder

To filter packets based on multiple options for display in the Packet Analyzer Packet Decoder:

. The Packet Analyzer - Display Filter Window displays.

Step 2 Do the following:

- Choose a Filter Mode :

displays packets that match the condition(s.)

displays packets that do not match the condition(s).

- Choose an Address Filter :

address filters on IP address.

address filters on MAC address.

allows you to specify the source address, or leave it blank if not applicable.

allows you to specify the destination address, or leave it blank if not applicable.

allows you to match of packets traveling in both directions.

- Define a Protocol Filter :

to display packets that match any of the protocols or fields.

or

to display packets that match all of the protocols or fields.

list.

Note You can enter the first few letters of the protocol name to go directly to the protocol. If you make a typo, press ESC or SPACE to reset.

– Choose a protocol field from the Fields list, then specify the field value if applicable.

sign.

sign.

to apply the filter and keep the window open.

Viewing Detailed Protocol Decode Information

To view detailed protocol information:

Step 1 Highlight the packet number about which you want more information.

Detailed information about that packet is displayed in the Protocol Decode and hexadecimal dump panes at the bottom of the window.

Note If you highlight the details in the Protocol Decode pane, the corresponding bytes are highlighted in the hexadecimal dump pane below it.

Step 2 To review the information, use the scrolling bar in the lower panes.

Note When you decode SCCP traffic, Packet Analyzer lists the protocol as skinny, not SCCP.

Tip • Protocols are color coded both in the Packet Browser and the Protocol Decode pane.

Tip • Protocols are color coded both in the Packet Browser and the Protocol Decode pane.

- Choose the protocol name in the Protocol Decode pane to collapse and expand protocol information.

- To adjust the size of any of the panes, click and drag the pane frame up or down.

Understanding the Packet Analyzer Packet Decoder

The Packet Analyzer, also known as the packet decoder, uses two levels of packet analysis: basic and full. Because preparing a large capture file for full analysis can take a long time, Packet Analyzer automatically chooses which level to use based on your filtering complexity. This allows you to browse your captured packet data more quickly without having to wait for analysis.

When you select a capture file to analyze for the first time, Packet Analyzer limits some of the more complex display filters you can use. For example, you can filter using protocol identifiers such as TCP, UDP, SDP, and SIP which allow the packet decode to display more quickly than an advanced filtering selection.

If you enter more advanced filters (such as those with and/or logic operators on the protocol field), Packet Analyzer automatically begins the full analysis of the capture file and then applies your complex filter to display the results. For example, if you filter using ‘ip.src==192.168.1.1 && tcp.dstport==80’, the Packet Analyzer starts the full analysis and displays it only after the results have been filtered.

Understanding the Packet Analyzer Packet Decoder Window and Browser Pane

The Packet Analyzer Packet Decoder window shows three views of a packet:

- a summary line briefly describes the packet type

- the protocol field of interest can be shown and analyzed in the portion of the window directly below the summary line

- a hexadecimal dump shows exactly what the packet looks like when it goes across the wire.

There are many unique features in the Packet Analyzer Packet Decoder decode window; for example, it can assemble all the packets in a TCP conversation and highlight the ASCII data in that conversation. You can use the expanded display filter functionality to allow you to view more focused data.

Figure 4-8 is an example of the Packet Analyzer Packet Decoder window.

You can perform the following tasks in the Packet Analyzer window:

- Show Packet histogram display the number of packets over a specific time range. This provides a feel of the packet flow for the capture. You can use the histogram selector control to navigate through the packet list as well. You can apply a display filter to make the histogram show the distribution of the packets that match the applied filter. Can set time range and move across histogram. Firefox is faster than IE performance with this feature.

- Toggle to Show Packet Paging Controls displays the buffer divided into pages.

- Toggle layout changes how the three content panes in the decoder are arranged.

- Display Hex data font size by hovering over two buttons in the top right corner of the hex data content pane of the decoder. You can increase or decrease the font size of the contents.

- Display the current range of packets in the packet list by selecting the Packet range button. You can also enter the range of packets to view.

- Use the Display Filter button yo display Saved Display Filters and Manage Display Filters windows.

- Alter Protocol coloring. You can map custom colors to specific protocols in this release. Default colors

- Use the Tools menu—options have limited support. Options include:

– TCP Checksum Validation check box—filter on TCP in the decode window and use the TCP pane to verify that the checksum has been validated.

– UDP Checksum Validations check box—filter on UDP in the decode window and use the UDP pane to verify that the checksum has been validated.

– IP Host Name Resolution—perform global host name resolution for Packet Analyzer. Synchronizes with the Administration preferences.

- Use Decode As option to temporarily force specific tcp and /or udp ports to be decoded as the specific protocols as specified by the user.

- Display Filter input field to manually enter display filters.

Customizing Display Filters

Use custom display filters to create and save customized filters to use in the Packet Analyzer decode window to limit which packets are displayed.

Packet Analyzer supports most software display filters with the following exceptions:

- Filters using Perl Regular Expressions. For example:

http.request.uri matches "gl=se$"

- Filters on a protocol payload (a protocol section in a packet). For example:

udp[8:3]==81:60:03

See these topics for help setting up and managing custom display filters:

- Creating Custom Display Filters

- Editing or Deleting Custom Display Filters

Creating Custom Display Filters

To create custom display filters:

.

The Hardware Filters box is displayed at the bottom of the page.

.

Step 3 Enter information in each of the fields as appropriate.

Step 4 Do one of the following:

- To create the filter, click Submit .

- To cancel filter creation, click Cancel .

Tips for Creating Custom Decode Filter Expressions

.

Table 4-3 Logical and Comparison Operators

Operator

Meaning

and

Logical AND

or

Logical OR

xor

Logical XOR

not

Logical NOT

==

Equal

!=

Not equal

>

Greater than

to help you add filter expressions.

Examples of Custom Decode Filter Expressions

provides some examples of basic Packet Analyzer display filters you can use to filter on application types.

Table 4-4 Basic Packet Analyzer Display Filters (Limited to Application Types)

Filter

Meaning

tcp

Find all TCP-based applications

udp

Find all UDP-based applications

! eth

Find all packets other than Ethernet

tcp and not vlan

Find all TCP traffic NOT running over vlan

http

Find all src/dst HTTP application packets (may be not standard port 80 if different application 'decode as' port specified; e.g. 'tcp.port==8080,http')

ftp || http

Find either ftp or http packets

not tcp

Exclude all TCP packets

! tcp

Exclude all TCP packets

! (ftp || http)

Exclude all FTP and HTTP packets

provides some examples of complex Packet Analyzer display filters.

Table 4-5 Compound Packet Analyzer Display Filters

Filter

Meaning

tcp.port eq 80

Find all src/dst HTTP packets on standard HTTP port 80

ip.addr == 192.168.1.0/24

Find all packets in Class C network (subnet)

tcp.flags.reset == 1

Find all TCP resets

tcp.window_size == 0 && tcp.flags.reset != 1

Src is instructing dst to stop sending data (TCP buffer full)

Ipv6.addr == ::1

Correct statement with IPv6 label and IPv6 address.

provides some examples of protocol field hexbyte filters.

Table 4-6 Protocol Field Hexbyte Filters

Filter

Meaning

eth.src==00:3c:06:0a:02:68

Find source MAC

eth.dst==00:3c:06:0a:02:68

Find destination MAC

eth.addr==00:3c:06:0a:02:68

Find source or dest MAC

! (eth.addr==00:3c:06:0a:02:68)

Find all MAC except specific address

eth.addr contains 00:3c

Find bytes in any protocol field subrange

provides some examples of protocol field hexbyte subrange filters.

Table 4-7 Protocol Field Hexbyte Subrange Filters

Filter

Meaning

eth.addr[0:2]==00:3c

Find specific subrange in MAC

eth.addr[1:3]==3c:06:0a

Find specific subrange in MAC

provides some examples of hexbyte data representations syntax.

Table 4-8 Hexbyte Data Representations (Syntax)

Filter

Meaning

eth.dst == ff:ff:ff:ff:ff:ff

Hexbyte separators can be colons

eth.dst == ff-ff-ff-ff-ff-ff

Hexbyte separators can be dashes

eth.dst == ffff.ffff.ffff

Hexbyte separators can be dots (one or two bytes

Note You can use a filter expression with other fields in the Custom Decode Filter dialog box. In this case, the filter expression is ANDed with other conditions. Invalid or conflicting filter expressions result in no packet match.

Editing or Deleting Custom Display Filters

To edit custom display filters:

.

.

Step 3 Change the information in each of the fields as appropriate.

.

Performing User and System Administration

This chapter provides information about what user and system administration tasks are required or optional, how to generate diagnostic information when requesting technical assistance, and provide user access.

This chapter contains the following topics:

- Performing System Administration

- Troubleshooting Using Diagnostics Tools

- Controlling User Access

- Managing System Data

Performing System Administration

You can perform the following system administration tasks:

- Monitoring Packet Analyzer Health and Traffic Statistics

- Setting Network Parameters

- Setting the SNMP Agent

- Synchronizing Your System Time

- Sharing Packet Analyzer Data by Enabling Web Data Publication

- Setting Remote Servers to Receive Syslog Messages

- Configuring Hosts to Receive SNMP Traps from Packet Analyzer

- Customizing System Preferences

- Importing/Exporting Configuration Details

.

Table 5-1 System Administration At-A-Glance

Task

Choose...

View system health and traffic details

Use IP hostname resolution/DNS lookup

Add extra security and allow additional host details to be displayed in Packet Analyzer traffic information

Ensure that the Packet Analyzer system time is configured correctly (required)

Provide e-mail notification of alarms and reports

Allow general web users and websites to access selected Packet Analyzer monitor and report windows without a login session

Specify whether syslog messages should be logged locally on the Packet Analyzer, on a remote host, or both

Set a host destination to which Packet Analyzer sends trap

Allow extension of evaluation period and permanent usage of the vNAM without expiration

Change the Packet Analyzer display or logging characteristics

Import or Export configuration details

Monitoring Packet Analyzer Health and Traffic Statistics

Ensuring that your Packet Analyzer processes your traffic efficiently and effectively without becoming overloaded is a critical task.

to check how much traffic is sent to Packet Analyzer. If you can't see any traffic coming in on this page, check the traffic source and cable connections.

Use the data provided in the Inputs and Resources tabs to determine scalability issues and to assist with troubleshooting.

describes the types of information of the System Overview window.

Setting Network Parameters

If you want to use IP hostname resolution in Packet Analyzer, you must configure the nameservers first. Packet Analyzer supports three DNS servers. If this task is not complete, you will be unable to perform DNS lookup. You can also set

Tip Ensure your name server addresses are correct, otherwise some of your Monitor dashboards and Capture Decode windows may seem slow to load.

To view and set your name servers:

.

The Network Parameters window displays.

Step 2 Enter or change the IPv4 or IPv6 information.

Step 4 Do one of the following:

- To save the changes, click Submit .

- To cancel the changes, click Reset .

.

Setting the SNMP Agent

An SNMP Agent is a network management software module that resides in a managed device. It has local knowledge of management information and translates that information into a form compatible with SNMP.

.

Also, to further alleviate any security concerns, the SNMP exchanges between Packet Analyzer blades and the switch take place on an internal backplane bus. These SNMP packets are not visible on any network, nor any interface outside of the switch. It is a completely secure out-of-band channel inside the switch.

For other platforms, such as Packet Analyzer appliances, you can type in any IP address and use it as the managed device. In setting managed devices, virtual Packet Analyzer platforms managed devices function just like the Packet Analyzer appliances. On all platforms, Packet Analyzer can only monitor and display data for one managed device at a time.

In this case, the managed device may only want to use SNMPv3 since it is more secure.

For RISE appliances, if the managed device is a Nexus switch/VDC, RISE service is configured on the Nexus switch SUP. When RISE service is configured, Nexus device and Packet Analyzer will automatically sync up the VDC and interfaces information. Packet Analyzer in this environment is used to manage more than one VDC's interface statistics, without moving physical data port connections between Packet Analyzer and switch.

To view and set the Packet Analyzer SNMP agent, follow these steps:

.

.

.

.

.

Working with Packet Analyzer Community Strings

You use community strings so that other applications can send SNMP get and set requests to the Packet Analyzer, set up collections, poll data, and so on.

Creating Packet Analyzer Community Strings

To create the Packet Analyzer community strings:

.

under Packet Analyzer Community Strings.

displays.

Step 3 Enter the community string (use a meaningful name).

Step 4 Enter the community string again in the Verify Community field.

Step 5 Assign read-only or read-write permissions using the following criteria:

- Read-only allows only read access to SNMP MIB variables (get).

- Read-write allows full read and write access to SNMP MIB variables (get and set).

.

Deleting Packet Analyzer Community Strings

To delete the Packet Analyzer community strings:

.

.

Caution Deleting the Packet Analyzer community strings blocks SNMP requests to the Packet Analyzer from outside SNMP agents.

Testing the Router Community Strings

Before the router can send information to the Packet Analyzer using SNMP, the router community strings set in the Packet Analyzer must match the community strings set on the actual router. The Router Parameters dialog box displays the router name, hardware, Supervisor engine software version, system uptime, location, and contact information.

The local router IP address and the SNMP community string must be configured so that the Packet Analyzer can communicate with the local router.

To set the community strings on the router, use the router CLI. For information on using the CLI, see the documentation that accompanied your device.

Caution The router community string you enter must match the read-write community strings on the router. Otherwise you cannot communicate with the router.

To test router community strings:

.

The Device Information dialog box displays.

Step 2 Enter the Device's Community String.

.

.

Synchronizing Your System Time

Ensure that the Packet Analyzer system time is configured correctly. If the system time is incorrect, Packet Analyzer data presentation may be inaccurate due to time ranges, hence providing incorrect interpretations of Packet Analyzer data.

.

You can configure the Packet Analyzer system time by using one of the following methods:

- Configuring the Packet Analyzer System Time with an NTP Server

This is valid for all platforms and is the recommended option.

- Synchronizing the Packet Analyzer System Time Locally

Configuring the Packet Analyzer System Time with an NTP Server

To configure the Packet Analyzer system time with an NTP server:

.

radio button.

Step 3 Enter one or two NTP server names or IP address in the NTP server name/IP Address text boxes.

Step 4 Select the Region and local time zone from the lists.

.

Synchronizing the Packet Analyzer System Time Locally

To configure the Packet Analyzer system time locally using the Packet Analyzer command line:

Step 1 Log into the Packet Analyzer command line interface.

command.

.

radio button.

Step 5 Select the Region and local time zone from the lists.

to save the changes.

Understanding Packet Analyzer System Time

Ensure that the Packet Analyzer software application's Linux system time is synchronized with the packet timestamp and the standard time source outside of the Packet Analyzerplatform. Packet timing analysis uses system time to support application response time measurements, voice and video quality metrics, packet decode data, reporting, and many other network statistics.

The Packet Analyzer gets the UTC (GMT) time from several sources, depending on its Packet Analyzer platform type. All Packet Analyzer can be set up to get their time from an external NTP server. Other Packet Analyzer platforms may prefer to use an IEEE 1588 Precision Time Protocol (PTP)-based time master due to its high accuracy and precision.

You should also configure any PTP switches that are between the Packet Analyzer and the master clock to use Edge-to Edge (E2E) mode. E2E is preferred because it reduces PTP messaging bandwidth and eliminates delay accumulation when daisy chaining many nodes. If the master clock and/or PTP switches are not configured correctly, all of the clocks on the Packet Analyzer will be synced with each other, but to the wrong time.

Caution Both the client computer and the Packet Analyzer server must have the time set accurately for their respective time zones. If either the client or the server time is incorrect, then the data shown in the GUI is incorrect.

The clock identity is the first three octets of the MAC address, followed by “ff fe,” and then the last three octets of the MAC address, as shown in the example below.

0xec:44:76:ff:fe:5d:12:0

After the Packet Analyzer acquires the time, you can set the local time zone using the Packet Analyzer System Time configuration window.

For details on how to configure the Packet Analyzer system time for your specific hardware platform, see Synchronizing Your System Time.

Setting Up E-Mail Notifications for Alarms

You can configure Packet Analyzer to provide e-mail notification of alarms and to e-mail reports.

To set up e-mail notifications:

.

check box and enter the required or optional field information.

describes the Mail Configuration Options.

check box and enter the details in the fields provided.

to clear the dialog of any characters you entered or restore the previous settings.

Sharing Packet Analyzer Data by Enabling Web Data Publication

Web Data Publication allows general web users and websites to access (or link to) selected Packet Analyzer monitor and report windows without a login session.

Web Data Publication can be open or restricted using Access Control List (ACL) and/or publication code. The publication code, if required, must be present in the URL address or cookie to enable access to published data.

To enable Web Data Publishing:

.

check box.

would be able to access the following published window:

Step 4 Enter an ACL Permit IP Address/Subnets to permit only those IP addresses or subnets access to web publications. No entry provides open access to all.

to clear the dialog of any characters you entered.

Setting Remote Servers to Receive Syslog Messages

Packet Analyzer syslogs are created for alarm threshold events, voice threshold events, or system alerts. You can specify whether syslog messages should be logged locally on the Packet Analyzer, on a remote host, or both. You can use the Packet Analyzer to view the local Packet Analyzer syslogs.

is handled properly.

To set up the Packet Analyzer syslog:

.

The Packet Analyzer Syslog Setting window displays.

Step 2 In the Remote Server Names field, enter the IP address or DNS name of up to five remote systems where syslog messages are logged. Each address you enter receives syslog messages from all three alarms (Alarm Thresholds, Voice Signaling Thresholds, and System).

to cancel.

Configuring Hosts to Receive SNMP Traps from Packet Analyzer

Traps are used to store alarms triggered by threshold crossing events. When an alarm is triggered, you can trap the event and send it to a separate host. Trap-directed notifications can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests.

To configure, edit, or delete a host destination to which Packet Analyzer will send traps:

.

The SNMP Trap Setting window displays.

.

Step 3 In the Community field, enter the community string set in the Packet Analyzer Thresholds.

Step 4 In the IP Address field, enter the IP address to which the trap is sent if the alarm and trap community strings match.

Step 5 In the UDP Port field, enter the UDP port number.

to cancel and leave the configuration unchanged.

Customizing System Preferences

describes the fields of the Preferences window and why you may want to change the defaults.

Importing/Exporting Configuration Details

To import/export the configuration details:

.

at the top of the window.

from the protocol drop-down list.

Step 4 Enter the IP address of the host.

Step 5 Enter the username and password of the host. This is optional if you select FTP as the protocol.

Step 6 Enter the configuration filename of the application which you want to import or export.

Step 7 Enter the location where you want to import or export the application details.

Step 8 Enter the configuration filename of the DSCP which you want to import or export.

Step 9 Enter the location where you want to import or export the DSCP details.

Step 10 Enter the configuration filename of the Site which you want to import or export.

Step 11 Enter the location where you want to import or export the Site details.

.

While importing, it will replace the existing configuration details with the new details.

Troubleshooting Using Diagnostics Tools

menu provides tools to aid in troubleshooting. You can use these tools when you have a problem that might require assistance from the Cisco Technical Assistance Center (TAC). There are options for:

- System Alerts

- Audit Trail

- Tech Support

For additional information on troubleshooting Packet Analyzer, see Troubleshooting Network and Packet Analyzer Issues.

System Alerts

.

to see all of the alerts.

to remove the list of alerts to see if additional alerts occur.

Audit Trail

.

The following user activities are logged in the audit trail:

- All CLI commands

- User logins (including failed attempts)

- Unauthorized access attempts

- SPAN changes

- NetFlow data source changes

- Enabling and disabling data collections

- Starting and stopping captures

- Adding and deleting users

Each log entry will contain the following:

- User ID

- Time stamp

- IP address (in case of remote web access)

- Activity description

There are two additional logs, Samba (SMB) and SSH/SFTP which are logged events from the File Sharing feature. These events get logged when the file operations are performed either on a network device through SMB or from SSH/SFTP connections.

. The Audit Trail window appears and provides a way to view the user access log and filter entries based on time, user, (IP address) from or activity. The internal log files are rotated after reaching certain size limits.

Tech Support

.

This information is unlikely to be meaningful to the average user. It is intended to be used by your technical support team for debugging purposes. You are not expected to understand this information; instead, you should save the information and attach it to an e-mail message to your support team or, if applicable, Cisco TAC.

Before You Begin

.

To view the tech support information:

.

After a few minutes, extensive diagnostic information generates and displays in the window.

. Save the files to your local disk. You can analyze the files locally or, if requested forward on to your technical support team for review.

Downloading Core Files

and follow the instructions.

Controlling User Access

In order to make your Cisco Packet Analyzer solution more secure, you can take several steps including:

- Enable Secure Sockets Layer (SSL) on the Cisco Packet Analyzer for secure, encrypted HTTP sessions. See your installation guide for details.

- Enable Secure Shell (SSH) protocol for secure Telnet to the Cisco Packet Analyzer.

- Enable TACACS+ for authentication and authorization. Cisco Packet Analyzer provide support for multiple TACACS+ servers.

This section covers how to control your user’s access using the Administration options:

- Local Database

- Establishing TACACS+ Authentication and Authorization

- Configuring a TACACS+ Server to Support Packet Analyzer Authentication and Authorization

- Current User Sessions

Local Database

When you first install the Packet Analyzer, use the Packet Analyzer command-line interface (CLI) to enable the HTTP server and establish a username and password to access the Packet Analyzer for the first time.

After setting up the initial user accounts (root, admin, and webuser), you can create additional accounts, enabling or disabling different levels of access independently for each user.

provides information about User Privileges and describes each privilege.

.

If you have forgotten your password, use the helper utility to reset your root or user passwords (see Resetting Passwords).

Resetting Passwords

based on your needs.

Table 5-2 Password Reset Options

Packet Analyzer User

Method

Description

Root, Admin, and webuser

Boot into helper utility

at the Packet Analyzer CLI.

Root and webuser

Packet Analyzer CLI command

The easiest way to reset Packet Analyzer passwords. This command resets both the root and guest user passwords to the factory default state. You must have appropriate privileges to reset passwords.

Root, Admin, and webuser

CLI commands on the switch or router

.

Packet Analyzer Admin users

Delete the user for whom you have forgotten the password; then create a new one.

Webuser

Packet Analyzer CLI command

Use if no other local users are configured other than the user for whom you have forgotten the password. Then enable http or https to prompt for the creation of a Packet Analyzer user.

Changing Predefined Packet Analyzer User Accounts on the Switch or Router

command or a Telnet login to the Packet Analyzer CLI) are static and independent of the Packet Analyzer. You cannot change these static accounts nor can you add other CLI-based users with the Packet Analyzer.

Creating a New User

To create a new user:

.

The GUI displays the users in the local database. Checks indicate the privileges each user has for the functions listed.

.

The GUI displays the New User Dialog Box.

describes the fields in the New User Dialog Box.

Note If you delete user accounts while users are logged in, they remain logged in and retain their privileges. The session remains in effect until they log out. Deleting an account or changing permissions in mid-session affects only future sessions. To force off a user who is logged in, restart the Packet Analyzer.

provides information about each privilege.

to clear the dialog of any characters you entered.

Invalid User Name and Password Characters

For usernames, do not use the following:

- Exclamation point !

- At sign @

- Pound sign #

- Dollar sign $

- Percent %

- Carot ^

- Ampersand &

- Asterisk *

- Left or right parentheses ( )

- Greater than <

- Less than >

- Comma ,

- Period .

- Double quote "

- Single quote '

- Forward slash /

- Backward slash \

For web user passwords, do not use the following:

- Double quote "

- Single quote '

- Greater than <

- Less than <

For root or guest user passwords, only the single quote is not allowed.

Establishing TACACS+ Authentication and Authorization

Terminal Access Controller Access Control System (TACACS) is an authentication protocol that provides remote access authentication, authorization, and related services such as event logging. With TACACS, user passwords and privileges are administered in a central database instead of an individual switch or router to provide scalability.

TACACS+ is a Cisco Systems enhancement that provides additional support for authentication and authorization.

When a user logs into the Packet Analyzer, TACACS+ determines if the username and password are valid and what the access privileges are.

To establish TACACS+ authentication and authorization:

. The TACACS+ Authentication and Authorization Dialog Box displays.

.

Step 3 Do one of the following:

- To save the changes, click Submit .

- To cancel, click Reset .

Tip If you cannot log into the Packet Analyzer with TACACS+ configured, verify that you entered the correct TACACS+ server name and secret key.

Configuring a TACACS+ Server to Support Packet Analyzer Authentication and Authorization

In addition to enabling the TACACS+ option, you must configure your TACACS+ server so that it can authenticate and authorize Packet Analyzer users. Packet Analyzer supports ACS versions 5.2, 5.1 (including Patch 1), and 4.2.

Note Configuration methods vary depending on the type of TACACS+ server you use. When configuring Packet Analyzer within ACS 5.x, uncheck the check box for the Single Connect Device option under the TACACS+ settings.

Continue to the section specific to your particular version:

- Configuring a Cisco ACS Server, Version 4.2

- Configuring a Cisco ACS Server, Version 5.x

- Configuring a Generic TACACS+ Server

Configuring a Cisco ACS Server, Version 4.2

To configure a version 4.2 Cisco ACS server, you must perform two tasks:

- Configure the Packet Analyzer hostname and IP address on the ACS server. See Configuring Packet Analyzer on ACS for Windows NT and 2000 Systems for Version 4.2 .

- Add a Packet Analyzer user or user group. See Adding a Packet Analyzer User or User Group for Version 4.2.

Configuring Packet Analyzer on ACS for Windows NT and 2000 Systems for Version 4.2

To configure a Cisco ACS TACACS+ server (version 4.2):

Step 1 Log into the ACS server.

.

.

Step 4 For the Network Access Server, enter the Packet Analyzer hostname and IP address.

Step 5 Enter the secret key.

Note The secret key must be the same as the one configured on the Packet Analyzer.

.

.

Step 8 Continue to Adding a Packet Analyzer User or User Group for Version 4.2 to complete the next configuration task.

Adding a Packet Analyzer User or User Group for Version 4.2

To add a Packet Analyzer user or user group:

.

Step 2 Enter the user login name.

.

Step 4 Enter the user data.

Step 5 Enter a user password.

Step 6 If necessary, assign a user group.

Step 7 In the TACACS+ settings:

.

.

.

.

.

f. In the Arguments field, enter:

permit capture

permit system

permit collection

permit account

permit alarm

permit view

.

.

Configuring a Cisco ACS Server, Version 5.x

To configure a version 5.1 (Patch 1) or 5.2 Cisco ACS server, you must perform these tasks. There is an additional configuration task that enables you to set up policy rules for your users or groups.

Use the following sections to configure your Cisco ACS server:

- Configure the Packet Analyzer hostname and IP address on the ACS server. See Configuring Packet Analyzer on ACS For Windows NT and 2000 Systems for Version 5.x.

- Add a Packet Analyzer user or user group. See Adding a Packet Analyzer User or User Group for Version 5.x.

- Set up your policy rules. See Configuring Access Policies for ACS and Packet Analyzer for Version 5.x.

Configuring Packet Analyzer on ACS For Windows NT and 2000 Systems for Version 5.x

To configure a Cisco ACS TACACS+ server (version 5.1(P1) or 5.2):

Step 1 Log into the ACS server.

.

to add Packet Analyzer devices.

Step 4 For the Network Access Server, enter the Packet Analyzer hostname and IP address.

.

Step 6 Enter the secret key and deselect the check box for the Single Connect Device option under the TACACS+ settings.

Note The secret key must be the same as the one configured on the Packet Analyzer.

.

Step 8 Continue to Adding a Packet Analyzer User or User Group for Version 5.x to complete the next configuration task.

Adding a Packet Analyzer User or User Group for Version 5.x

To add a Packet Analyzer user or user group:

.

Step 3 Enter the user login name.

Step 4 Enter the user data.

Step 5 If necessary, assign a user group.

Step 6 Enter the password information.

.

Configuring Access Policies for ACS and Packet Analyzer for Version 5.x

In versions 5.1(P1), 5.2, and 5.3 you must set up access policies to complete your ACS and Packet Analyzer configuration.

to create Packet Analyzer command sets.

.

when you have completed entering the Packet Analyzer command sets. Ensure you include all of the following commands:

permit capture

permit system

permit collection

permit account

permit alarm

permit view

; Service Type = Device Administration.)

with the service you created in this step.

to set up the condition to qualify all login requests. Packet Analyzer devices use these conditions and follow the command set (created in Step 1). For example, your condition may be == NDG: Device Type is All Device Types: Packet Analyzer device which you set up in Step 2.

to choose a service (for example, the service you created in Step 3).

to set up the ACS server IP and secret key.

Configuring a Generic TACACS+ Server

To configure a generic TACACS+ server:

Step 1 Specify the Packet Analyzer IP address as a Remote Access Server.

Step 2 Configure a secret key for the TACACS+ server to communicate with the Packet Analyzer.

Note The secret key must be the same as the one configured on the Packet Analyzer.

Step 3 For each user or group to be allowed access to the Packet Analyzer, configure the following TACACS+ parameters:

Parameter

Enter

service

shell

cmd

web

cmd-arg

One or more the following:

accountmgmt

system

capture

alarm

collection

view

password authentication method—Password Authentication Protocol (PAP)

pap

Current User Sessions

a user session times out, that row is removed from the table.

To view the current user sessions table:

.

) displays.

Managing System Data

One of the roles of an administrator is to manage Packet Analyzer’s network data collection and retention so that it:

- Scales to fit the real needs of the system’s users.

- Minimizes the burden on monitored devices, applications, and network bandwidth.

- Survives hardware failures.

The following sections explain how to achieve these goals, and how to perform other data management tasks.

- Handling Backups

- Shrinking Storage Requirements

Handling Backups

.

Shrinking Storage Requirements

Network administrators are consistently looking for ways to shrink their network storage requirements and improve bandwidth efficiency on tasks like backup and recovery.

By configuring Packet Analyzer packet deduplication on supported platforms, packets whose inspected segments match another packet within the specific time window are marked as duplicates and not forwarded.

For configuration guidelines and instructions, see Configuring Hardware Deduplication.

You can also move capture files to an external storage location to save on local disk space. See About Capturing to Data Storage.

Packet Analyzer Deployment

This chapter describes some usage cases on how to deploy Packet Analyzer in your networks. It contains details on network performance management as well as usage scenarios for the Cisco Security Packet Analyzer Software.

The use cases focus on a specific need to be addressed or a problem to be solved. Each scenario takes into account the deployment considerations discussed in Overview and then uses one or more of Packet Analyzer’s features to meet the need or solve the problem. The goal of these use cases is to provide real-world examples. These examples discuss best practices and approaches to effective Packet Analyzer deployment and are grouped into several categories.

This chapter contains the following sections:

- Deploying in the Data Center

- Deploying in a Campus Environment

- Deploying in the Branch

- General Usage Scenarios

- Packet Analyzer Integrations with Monitoring and Reporting Applications

Note Some of the graphics represented in this section may be different than what you see on the screen. These illustrations are for examples only.

Deploying in the Data Center

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for TCP-Interactive Applications

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for UDP Real-Time Applications

- Using Packet Analyzer to Monitor QoS/DiffServ (DSCP)

- Monitoring Cisco WAAS and Measuring Its Impact

Deploying in a Campus Environment

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for TCP-Interactive Applications

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for UDP Real-Time Applications

- Using Packet Analyzer to Monitor QoS/DiffServ (DSCP)

- Using Packet Analyzer to Monitor VoIP Quality

Deploying in the Branch

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for TCP-Interactive Applications

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for UDP Real-Time Applications

- Using Packet Analyzer to Monitor QoS/DiffServ (DSCP)

- Monitoring Cisco WAAS and Measuring Its Impact

- Using Packet Analyzer to Monitor VoIP Quality

General Usage Scenarios

These use cases are applicable to any part of the network:

- Using Packet Analyzer for Historical Trends via Interactive Report

- Using Packet Analyzer for Problem Isolation

- Creating Custom Applications

- Auto-Discovery Capabilities of Packet Analyzer

- Using Packet Analyzer for SmartGrid Visibility

Packet Analyzer Integrations with Monitoring and Reporting Applications

- Integrating Packet Analyzer with Prime Infrastructure

- Integrating Packet Analyzer with Third Party Reporting Tools

Deployment Examples

- Using Packet Analyzer to Monitor VoIP Quality

- Auto-Discovery Capabilities of Packet Analyzer

- Creating Custom Applications

- Integrating Packet Analyzer with Prime Infrastructure

- Integrating Packet Analyzer with Third Party Reporting Tools

- Monitoring Cisco WAAS and Measuring Its Impact

Using Packet Analyzer to Monitor VoIP Quality

Voice quality analysis has been significantly enhanced in Packet Analyzer. The software is now capable of accurately measuring voice quality by using the industry-standard MOS algorithm. Call quality measurements are computed every 1 minute and made available through the GUI. Note that the voice-related screens on the Packet Analyzer GUI are significantly different from previous releases. Changes have been made to provide useful information quickly and automatically, while allowing easy navigation to details.

Deployment: Packet Analyzer deployments for voice quality analysis require that Packet Analyzer be able to monitor VoIP packets from the calling phone to the called phone. The branch edge location in the network provides visibility into all calls entering and leaving the branch; similarly a campus edge location monitors calls crossing the campus boundary. Often, the distribution layer is a good location to deploy Packet Analyzer for this purpose, especially if specific phones or particular portions of the network are to be monitored. For example, a new Multi protocol Label Switching (MPLS) link is being piloted and three buildings that are part of Company X's headquarters are part of the pilot. In order to monitor voice quality for those three buildings, a Packet Analyzer could be deployed at the distribution Catalyst 6500 that serves those users.

Note The data center is typically not an appropriate location for RTP stream analysis because calls will seldom go through the data center. However, the data center is a good location to monitor signaling messages between phones and Cisco Unified Communications Manager. Packet Analyzer decodes signaling messages to track call history, caller names, phone numbers, and other relevant call details.

Use the following steps to monitor the network to make sure that call quality is good. If quality issues appear, isolate and troubleshoot the problem rapidly.

. This chart indicates current voice quality of all RTP streams being monitored. MOS values range from 1 to 5, where 1 is poor and 5 is excellent (see the legend for a breakdown into categories-Poor, Fair, Good and Excellent). The figure below displays the Top N RTP Source and Destination endpoints. Notice that there are calls that are in the poor range.

Step 2 To isolate calls that had a poor MOS, scroll down to Top N RTP Streams and click on the chart to drill down into the RTP Stream Details. See Figure 6-1.

Figure 6-1 Top N RTP Streams by MOS

Step 3 With the endpoints’ IP addresses, you can look at the network topology to identify where in the network the 50.5.10.38 subnet is located. For the purposes of this use case, this subnet is in Building 3 of the main campus. You know that the Building 3 distribution switch has a Packet Analyzer located in it.

. This page lists all interfaces and errors or discards on each interface. Look up the link that leaves Building 3 and connects to the core. That interface is likely the source of the packet loss. Check the interface for faults and fix as needed.

See Analyzing Traffic, RTP Streams and Setting Voice Signaling Thresholds.

Auto-Discovery Capabilities of Packet Analyzer

Auto-discovery data source is enabled by default for ERSPAN, NetFlow, and WAAS data that are sent from remote device to Packet Analyzer management port. Packet Analyzer user has the option to disable any of the three auto-discovery. When auto-discovery is enabled, Packet Analyzer automatically creates ERSPAN data source, NetFlow data source, and/or WAAS data source based on the data type being received at the Packet Analyzer management interface.

Creating Custom Applications

Packet Analyzer identifies applications/protocols based on the TCP/UDP port number, so if there are applications using custom ports, the Packet Analyzer can be configured to identify those applications by name instead of the port.

See Creating Deeper Visibility Into Application Traffic.

Integrating Packet Analyzer with Prime Infrastructure

Cisco Prime supports integrated lifecycle management of networks, services, and endpoints for Cisco borderless network, data center, and collaboration architectures with end-to-end assurance. You can use Cisco Prime Infrastructure to centrally manage the Cisco Packet Analyzer platforms such as the Packet Analyzer appliance to track inventory, view configurations, and perform image and fault management. Prime Infrastructure also rolls up the performance intelligence from Packet Analyzer deployed across the network into a consolidated dashboard.

on Cisco.com.

Step 1 Ensure you configure NTP and DNS for all the Packet Analyzer in your network. You can now configure those without going to the CLI or logging in to the individual Packet Analyzer web GUI. Use the Cisco Prime Infrastructure Device Work Center to perform this task. For detailed steps, see your Prime Infrastructure product documentation.

Step 2 Add the Packet Analyzer HTTPS credentials from the Prime Infrastructure’s Device Work Center Edit Device window so that Prime Infrastructure can retrieve data from them. You must add them only after the discovery process is complete or the modules have been added to the Prime Infrastructure inventory.

If you have licensed Assurance features, most Assurance features depend on Packet Analyzer data to work so this is a required step.

You can repeat this task for all Packet Analyzer from which you want Prime Infrastructure to collect data.

Step 3 To ensure that you can collect data from your Packet Analyzer using Prime Assurance, you must enable Packet Analyzer data collection and configure your NetFlow-enabled switches, routers, and other devices (ISR/ASR) to export this data to Prime Infrastructure. You can do this for each discovered or added Packet Analyzer, or for all Packet Analyzer at the same time.

Step 4 To manage and troubleshoot a network problem such as a suspected network attack, you can use multiple Packet Analyzer to create packet captures, save them as files, and then decode them to inspect the suspicious traffic.

For application developers who want to use the Packet Analyzer REST API to connect with Packet Analyzer, ask your Cisco representative about using the Cisco Security Packet Analyzer REST API.

Integrating Packet Analyzer with Third Party Reporting Tools

Packet Analyzer integrates with the CA NetQoS SuperAgent for the purpose of aggregating Application Response Times. Packet Analyzer also integrates with CompuWare Vantage and InfoVista 5View for Host, Conversation, RTP, and Response Time.

to find out more about the Packet Analyzer Northbound Interface, also referred to as the REST API (Application Programming Interface). The API enables you to provision Packet Analyzer and extract performance data.

You can write your own scripts based on the Packet Analyzer Northbound API, but you must perform some setup in the GUI.

For details on what data can be collected, see Using Response Time Summary.

Monitoring Cisco WAAS and Measuring Its Impact

Cisco Wide Area Application Services (WAAS) is a comprehensive WAN optimization solution that accelerates applications over the WAN, delivers video to the branch office, and provides local hosting of branch-office IT services. Cisco WAAS allows IT departments to centralize applications and storage in the data center while maintaining LAN-like application performance and provides locally hosted IT services while reducing the branch-office device footprint.

One of the challenges facing IT personnel who deploy WAAS is to measure and report on the benefits provided by their WAN optimization deployment. Accurate measurement provides many benefits: IT can show return on investment; IT can assess whether the improvement gained meets originally advertised expectations from the solution; and finally, IT can use WAAS ongoing for monitoring, troubleshooting, and planning information for expanding the deployment.

The Packet Analyzer can monitor WAAS-optimized flows by using WAE devices as the data source. Using this capability, the Packet Analyzer is able to provide visibility into optimization-related metrics for the three distinct segments that are created by WAAS: the branch, the WAN, and the data center segments.

Placing a Cisco Packet Analyzer appliance at the edge of the data center is recommended for WAAS deployments. From this location in the network, the Packet Analyzer can measure local metrics using SPAN technology, and for information on the remote branch segment, it relies on flow agent exports from the remote WAE device. See Figure 6-2.

Figure 6-2 Cisco Packet Analyzer's Ability to Analyze from Multiple Data Sources

To deploy this solution:

. The Top Talker display includes such data as utilization, concurrent connections, and average transaction time for top applications, network links, clients, and servers that are possible candidates for optimization.

Step 2 Create a WAAS Client Side and WAAS Server Side for the WAAS flows from the DC and Branch WAEs.

Step 3 The Packet Analyzer provides an interactive dashboard to view the analyzed data. Figure 6-3 displays Client Transaction Time, Traffic Volume and Compression Ratio, Number of Concurrent Connections (Optimized vs. Passthru), and Multi-Segment Network Time (Client LAN - WAN - Server LAN). As you can see in the first graph, all non-optimized traffic is displayed as Passthru.

Figure 6-3 Application Performance Analysis -- Optimized

The screen shot above illustrates the significant improvement experienced by users in the branch when WAAS is turned on. Such reports are very useful to justify an investment in WAN optimization technologies and to show returns on those investments in terms of increase in employee productivity and improved user experience from remote sites.

Figure 6-4 Application Performance Analysis

Step 4 From the perspective of the Packet Analyzer located in the data center, there are two sources of information for response time measurements. SPAN provides measurement at the data center and exports from the branch; WAAS flow or PA via Prime Infrastructure provides measurements from the branch. Using these two sources of information, the Packet Analyzer at the data center can continuously monitor current response times for each branch and help IT personnel keep user experience within known bounds. When abnormal response times are detected, the Packet Analyzer can be configured to send alerts to appropriate personnel with information relevant to troubleshooting the problem.

Monitoring

- Using Packet Analyzer to Monitor QoS/DiffServ (DSCP)

- Using Packet Analyzer for Historical Trends via Interactive Report

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for TCP-Interactive Applications

- Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for UDP Real-Time Applications

Using Packet Analyzer to Monitor QoS/DiffServ (DSCP)

Differentiated Services (DiffServ) provides insight into how traffic is being classified by QoS and detects incorrectly marked or unauthorized traffic. The Packet Analyzer identifies the application/protocol based on the type of service (ToS) bits setting. The administrator can configure DSCP Groups or use the ones provided. The voice template can be used to monitor whether voice traffic is marked properly. Figure 6-6 displays the DiffServ application statistics for all DSCP value. Looking at this, you will notice that RTP and Session Initiation Protocol (SIP) are listed, which indicates that they are not being correctly marked throughout its path.

In the following scenario, IT has deployed QoS to prioritize VoIP traffic to improve voice quality across the network. The Packet Analyzer are deployed in the data center and branches and utilized to monitor the DSCP to validate QoS policies.

to display the default groups.

for details.

to find any misclassified traffic. In Figure 6-5, the RTP protocol is displayed for ToS0 classification.

Figure 6-5 DSCP Group - ToS0

button to view all DSCP and applications.

Step 5 In Figure 6-6, RTP and SIP are highlighted. The protocols are listed for DSCP 0, which is incorrect since the standard classification for voice traffic is DSCP 46 and 24. This means that some of the voice traffic is misclassified on the network. You can also view the branch Packet Analyzer to investigate whether voice traffic is being misclassified.

Figure 6-6 All DSCP Table

to display the clients using those protocols. This helps to troubleshoot why RTP or SIP traffic from these clients is not marked correctly. As shown in Figure 6-7, the Packet Analyzer displays the IP addresses of the phones using those protocols. This helps you review the QoS policy implemented on the routers and switches between the clients.

Figure 6-7 RTP Host Table

Using Packet Analyzer for Historical Trends via Interactive Report

Historical trending is an important component of network performance management. While real-time analysis provides information about events, historical trending provides visibility into event sequences. Such sequences offer valuable information about various aspects of the network such as changes in network traffic behavior, anomalies and unusual activities, and network usage in peak times versus low times. It is also helpful in planning future network upgrades, application roll outs, and hardware buildouts. Here are some things to take note of regarding Packet Analyzer’s historical trending capabilities:

- Use the Interactive Report > Filter button (located on the left side of the Packet Analyzer window) to look at short term and long term trends by changing the Time Range. The interactive reports can be exported or the filter setting saved for quick view in the future. The exported data can be sent via e-mail in CSV or PDF format.

- Figure 6-8 displays host traffic for the last day, and using the middle graph you can zoom down to the required time range to view what other application this host is using.

Figure 6-8 Host Traffic for Last 1 Day

In the following deployment scenario, you will predict the capacity needed for a new branch build out due in six months by studying the usage of an existing branch office of a similar size. To deploy a Packet Analyzer located in the branch router (ISR) of the existing branch:

(enter a date covering a month).

Step 2 Open a conversation report from today and find a stream that has a mildly increasing trend but is unable to confirm the rate at which it is increasing (see Figure 6-9).

Figure 6-9 A Stream with a Mildly Increasing Trend

Step 3 Change the Time Range dynamically in the Interactive Report to study the trend with a granularity of one month. You may find that the pattern does show periodic increases (see Figure 6-10). You are then able to conclude that the ISP link needed at the new site would be similar, and so a standard T1 line would be more than sufficient for the needs of the new remote office.

Figure 6-10 The Trend Shown with a Granularity of 1 Month

Studying historical trends is a valuable exercise in planning and creating baselines in a network. Monitor and trend on business critical applications and servers. These trends should provide handy information in a variety of day-to-day decisions.

Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for TCP-Interactive Applications

Application Performance Response Time Analysis provides up to 45 metrics. You can configure thresholds based on many of these metrics, and receive an alert when the thresholds are passed. Thresholds should be set for critical applications or servers using Average Server Response Time, or Average Transaction Time, or Average Network Time and Average Server Network Time. These thresholds will help identify where the problem lies in the application performance, and show whether the problem is a server or network issue. Depending on the alarm, you can access the Packet Analyzer to see the applications and clients accessing the server, or to check the devices in the traffic path monitoring device and interface utilization.

See Application Response Time.

See Defining Thresholds.

Using Packet Analyzer to Evaluate Application-Level Performance Monitoring for UDP Real-Time Applications

The Packet Analyzer monitors and analyzes RTP streams and voice calls statistics by intercepting the data collected by endpoints. So, when a phone call ends, the endpoints calculate the information and send it to the Unified Communications Manager (aka the Call Manager), the Packet Analyzer collects the data (as log as it is along that path).

Packet Analyzer uses the voice call statistics from the endpoint with the RTP stream to correlate the phone number with the IP address of the endpoint. Alerts are sent based on analysis of the RTP streams for MOS, Jitter, and Packet Loss.

To use Packet Analyzer to monitor the application-level performance for UDP real-time applications:

.

.

See Analyzing Traffic, RTP Streams.

, Media Monitor Setup Window.

Troubleshooting

- Using Packet Analyzer for Problem Isolation

- Using Packet Analyzer for SmartGrid Visibility

Using Packet Analyzer for Problem Isolation

). An example of the alarm is:

2013 SEPT 28 9:17:0:Application:Exceeded rising value(1000);packets;60653;Site(San Jose), Application)

to view which conversations are chatty, and therefore causing the increase traffic for this application.

to drill down on what hosts are accessing the application. Identify the application server and view what other applications are hosted and all the clients accessing that server.

See Monitor: Using Response Time Summary.

See Analyze: Measuring Response Time.

Using Packet Analyzer for SmartGrid Visibility

, you will see all hosts using that application. It will be identified as a Telnet application.

Customizing Cisco Packet Analyzer

This chapter provides set up details for advanced tools and customization. You can use these tools to take your network monitoring to another level. It provides information about functions that will begin automatically, optional tasks, and other setup tasks you will need to perform for advanced feature configuration.

This chapter contains the following sections:

- Advanced Configuration Overview

- Setting Up Traffic Configurations

- Setting Up Alarms and Alarm Thresholds

- Setting Up Data Export

- Accessing Device Interface and Health Details

- Configuring Network Parameters

- Configuring Application Classification

- Setting Up Packet Analyzer Monitoring

For information about how to install the product, configure it, and log in, see the installation guide for your specific Packet Analyzer platform.

Advanced Configuration Overview

leads you through the advanced configuration steps you can follow for Packet Analyzer. See the description to understand why or when to perform these tasks.

Table 7-1 Advanced Configuration Overview

Action

Description

GUI Location

User Guide Location

Configure the Managed Device information

If you want to monitor an extended level of your managed device’s data (health and interface information), you can set up your managed device using Packet Analyzer. If you do not set up this feature, your data collection is limited.

GUI.

For Packet Analyzer platforms, the Packet Analyzer managed device IP address, SNMP, and/or NetConf interface credential must be provided for Packet Analyzer to get managed device health and interface information.

See Accessing Device Interface and Health Details.

Configure sites

A site is a collection of hosts (network endpoints) partitioned into views that help you monitor traffic and troubleshoot problems.

If you want to limit the view of your network data to a specific city, a specific building, or even a specific floor of a building, you can use the sites function.

We recommend that sites are configured using prefix-based subnets instead of based on data source.

Setup > Network > Sites

See Configuring Sites.

Define alarms and thresholds

Alarms are predefined conditions based on a rising data threshold, a falling data threshold, or both. You can choose for what types of events you want the software to notify you, and how you want to be notified.

Create alarms that will be used for thresholds, then create the thresholds.

and

See Viewing Alarm Actions.

See Defining Thresholds.

Configure capture

Capture allows you to configure up to ten sessions for capturing, filtering, and decoding packet data, manage the data in local or remote storage, and display the contents of the packets.

Per file location, you can have only one capture session. We support up to ten capture sessions.

See Capturing and Decoding Packets.

Configure scheduled export

You can set up scheduled jobs that generate daily reports at a specified time, in a specified interval, and then e-mail it to a specified e-mail address or addresses.

Some windows may not support data export.

. Scheduled Export can only be done from a Monitor or Analyze window.

See Scheduling Data Report Exports.

Set up TACACS+ server

TACACS+ is a Cisco Systems enhancement that provides additional support for authentication and authorization.

When a user logs into Packet Analyzer, TACACS+ determines if the username and password are valid and what the access privileges are. For TACACS+ to work, both Packet Analyzer and the TACACS+ server has to be configured.

See Configuring a TACACS+ Server to Support Packet Analyzer Authentication and Authorization.

Change system preferences

You can change many preferences, such as refresh interval, Top N Entries, Data Displayed, and enabling Audit Trail, as needed.

Setting Up Traffic Configurations

To set up Packet Analyzer traffic, you should perform the following:

- Configuring Traffic to Monitor

- (Optional) Setting Up Packet Analyzer Data Sources

- (Optional) Configuring Hardware Deduplication (For specific Packet Analyzer appliances only)

Configuring Traffic to Monitor

Packet Analyzer can monitor your network traffic to perform many tasks including helping you to optimize your network resources and troubleshoot performance issues. Before you can monitor data, you must direct specific traffic flowing through a switch or router to the Packet Analyzer software for monitoring purposes.

A switched port analyzer (SPAN) session is an association of a destination port with a set of source ports, configured with parameters that specify the monitored network traffic.

Packet Analyzer allows you to create LOCAL SPAN session only. There are limitations of total number of SPAN sessions per managed device platform. See the managed device document for SPAN limitations.

There are three different ways to configure LOCAL SPAN session on the SUP:

- By using SNMP—Packet Analyzer supports SNMPv1, SNMPv2c, and SNMPv3. For the SPAN feature to work under this condition, the managed device must support entity MIB.

- By using NetConf interface—This option is available for Packet Analyzer appliances. You must provide the SSH credential for NetConf interface. The SUP must have SSH enabled and support NetConf. Cisco Nexus OS devices support this NetConf interface.

- By using RISE—This option is available for Packet Analyzer appliance with Nexus 7000 devices only. RISE service must be configured on the Nexus device. After RISE is configured, Packet Analyzer and switch device will sync up automatically.

The following sections describe SPAN sessions on devices running Packet Analyzer:

- Understanding How the Packet Analyzer Uses SPAN

- Creating a SPAN Session for RISE Appliance

- Creating a SPAN Session for Appliances and other Virtual Platforms

- Editing a SPAN Session for RISE Appliance

- Editing a SPAN Session for Appliances and other Virtual Platforms

Creating a SPAN Session for RISE Appliance

To create a SPAN session for the VDCs of a managed device in RISE environment:

.

The SPAN Session window appears.

drop-down list.

You can view the VDCs of the managed device, and the SPAN sessions created for each VDC.

.

drop-down list.

Step 5 Fill in the appropriate information on the Create SPAN Session window.

.

to create the SPAN session for the selected managed device.

Creating a SPAN Session for Appliances and other Virtual Platforms

To create a SPAN session on a switch:

. The SPAN window displays.

.

The Create SPAN Session Dialog displays. DataPort is the default for the SPAN Type. Contents of this window may be different depending on your Packet Analyzer platform.

.

. The Active Sessions window displays.

in the active SPAN session window.

Note For switches running Cisco IOS software, all pending running-configuration changes will be saved to the startup-configuration.

).

Editing a SPAN Session for RISE Appliance

To edit a SPAN session for the VDCs of a managed device in RISE environment:

.

The Active SPAN Sessions dialog box displays.

drop-down list.

Step 3 Select the VDC.

.

. Depending on your Packet Analyzer platform, there may be different fields that display.

Step 5 Make the appropriate changes on the Edit SPAN Session window.

Editing a SPAN Session for Appliances and other Virtual Platforms

You can only edit SPAN sessions that have been directed to the Packet Analyzer. You can only delete certain SPAN sessions using the user interface. Packet Analyzer allows you to edit and delete SPAN sessions that are destined to one of its DATAPORT. ERSPAN sessions on the main screen are for information only. You cannot edit or delete ERSPAN sessions even if the ERSPAN sessions are for Packet Analyzer management interface.

Note Editing an existing SPAN session that has multiple SPAN destinations will affect all destinations.

To edit a SPAN session:

.

The Active SPAN Sessions dialog box displays.

.

. Depending on your Packet Analyzer platform, there may be different fields that display.

Step 3 Make the appropriate changes on the Edit SPAN Session window.

Setting Up Packet Analyzer Data Sources

Data sources are where the traffic sent to Packet Analyzer originates. Some examples of the data sources are:

- Physical dataports of the Packet Analyzer where you get SPAN data

- A specific router or switch that sends NetFlow to the Packet Analyzer

- A WAAS device segment that sends data to Packet Analyzer

- ERSPAN and which goes to Packet Analyzer management port.

Packet Analyzer allows you to combine two or more data sources to generate a consolidated report for analyzing the traffic.

Caution If you have configured sites (see Configuring Sites), you can assign data sources to that particular site. If you do this, and you also configure data sources, the two could overlap since sites can also be a primary “view” into data sources. If there is a mismatch between the two, you will not see any data.

Note We recommend that you configure a site using subnets instead of selecting a data source. For examples on how to specify a site using subnets, see Configuring Sites Using Subnets.

The following sections contains setup steps and specific information about the types of data sources available:

- Data Source Overview

- Forwarding SPAN Traffic

- Forwarding ERSPAN Traffic

- Forwarding VACL Traffic

- Forwarding NetFlow Traffic

- Forwarding CEF Traffic

- Managing WAAS and WAN Traffic

- Ports and Hardware Details

Forwarding SPAN Traffic

A switched port analyzer (SPAN) session is an association of a destination port with a set of source ports, configured with parameters that specify the monitored network traffic. Depending on your platform, you can configure multiple SPAN sessions.

For more information about SPAN sessions, see Configuring Traffic to Monitor or your platform operating system documentation.

Forwarding ERSPAN Traffic

This section describes how to configure Encapsulated Remote Switched Port Analyzer (ERSPAN) on your remote device as a Packet Analyzer data source. You configure ERSPAN as a Packet Analyzer data source from the remote device command line interface, not the Packet Analyzer GUI.

As an ERSPAN consumer, Packet Analyzer can receive ERSPAN packets on its management port from devices such as Cisco routers and switches. Those packets are analyzed as if that traffic had appeared on one of the Packet Analyzer dataports. Packet Analyzer supports ERSPAN versions 1 and 3. Incoming ERSPAN data is parsed by Packet Analyzer, stored in its internal database, and presented in the GUI in the same way as traffic from other data sources.

Before You Begin

For the Packet Analyzer to receive ERSPAN from an external switch or router, that device must be configured to send ERSPAN packets to the IP address of the Packet Analyzer.

To enable ERSPAN as a data source:

- Enabling Autocreation of ERSPAN Data Sources Using the Web GUI

- Enabling Autocreation of ERSPAN Data Sources Using the CLI

- Aggregating Data Ports Using the Web GUI

- Disabling Autocreation of ERSPAN Data Sources Using the Web GUI

- Disabling Autocreation of ERSPAN Data Sources Using the CLI

- Creating ERSPAN Data Sources Using the Web GUI

- Creating ERSPAN Data Sources Using the CLI

- Deleting ERSPAN Data Sources Using the Web GUI

- Deleting ERSPAN Data Sources Using the CLI

- Configuring ERSPAN on Devices

Note Depending on the Cisco IOS/Nexus OS version on the managed device, the CLI format for configuring an ERSPAN session may be different than what appears in this document. For details on using ERSPAN as a data source, see your specific OS product documentation.

Enabling Autocreation of ERSPAN Data Sources Using the Web GUI

There is a convenient autocreate feature for data sources, which is enabled by default. With the autocreate feature, a new data source will automatically be created for each device that sends ERSPAN traffic to the Packet Analyzer, after the first packet is received. Manual creation of ERSPAN data sources using the Packet Analyzer GUI or the CLI is typically not necessary. When manually creating a data source, you may specify any name you want for the data source. A data source entry must exist on the Packet Analyzer in order for it to accept ERSPAN packets from an external device.

. You can edit these autocreated data sources and change the name if desired.

check box, and enter a Session ID in the Value field, the data source will only apply to that specific session. If you leave the check box unchecked, all ERSPAN traffic from the device will be grouped together into this data source, regardless of Session ID.

To configure Packet Analyzer to automatically create data sources when it receives ERSPAN packets from an external device, use the following steps. Remember however, that the autocreate feature is turned on by default, so these steps are typically not necessary.

.

on the bottom left of the window.

check box to toggle autocreation of ERSPAN data sources to “on”.

.

Enabling Autocreation of ERSPAN Data Sources Using the CLI

You can also configure the autocreate feature using the Packet Analyzer CLI. The autocreate feature is turned on by default, in most cases these steps are not necessary.

command as follows:

root@172-20-104-107.cisco.com# autocreate-data-source erspan

ERSPAN data source autocreate successfully ENABLED

Packet Analyzer will now automatically create a ERSPAN data source for each device that sends ERSPAN packets to it. The data source will have the specific Session ID that is populated by the device in the ERSPAN packets sent to the Packet Analyzer. If the same device happens to send ERSPAN packets to the Packet Analyzer with different Session ID values, a separate data source will be created for each unique Session ID sent from the device.

Aggregating Data Ports Using the Web GUI

To aggregate the datasources:

.

.

A pop up window appears.

to combine two or more datasources for generating a consolidated report to analyze the traffic.

Disabling Autocreation of ERSPAN Data Sources Using the Web GUI

.

on the bottom left of the window.

check box to toggle autocreation of ERSPAN data sources to “off”.

.

Disabling Autocreation of ERSPAN Data Sources Using the CLI

command as follows:

root@172-20-104-107.cisco.com# no autocreate-data-source erspan

ERSPAN data source autocreate successfully DISABLED

root@172-20-104-107.cisco.com#

Creating ERSPAN Data Sources Using the Web GUI

To manually configure a ERSPAN data source on the GUI, for example if the autocreation feature is turned off, use the following steps:

.

along the bottom of the window.

.

Step 4 Enter the IP address of the device that will export ERSPAN to the Packet Analyzer.

Step 5 Give the Data Source a name. This name will appear anywhere there is a Data Source drop-down list.

check box and enter an Session ID into the Value field if the data source should only apply to that specific session. If you leave the check box unchecked, all ERSPAN traffic from the device will be grouped together into this data source, regardless of Session ID.

Devices can be configured with multiple ERSPAN Sessions. The packets exported may have the same source IP address, but the Session ID exported will be a different for each session. If you want to include only one Session in the data source, you must check the “Session” box and provide the value of that Session ID.

.

Creating ERSPAN Data Sources Using the CLI

To manually configure a ERSPAN data source on the Packet Analyzer using the CLI (for example if the autocreation feature is turned off), use the following steps. Note that when using the CLI, there are two separate phases involved: First, you must create a “device” entry on the Packet Analyzer and remember the device ID, and then you must create a data source entry using this device ID. In the Packet Analyzer GUI, these two phases for creating ERSPAN data sources are combined together.

. You will now be in erspan device subcommand mode as shown here:

root@172-20-104-107.cisco.com# device erspan

Entering into subcommand mode for this command.

Type 'exit' to apply changes and come out of this mode.

Type 'cancel' to discard changes and come out of this mode.

root@172-20-104-107.cisco.com(sub-device-erspan)#

to see all the command options available, as in the example below:

root@172-20-104-107.cisco.com(sub-device-netflow)# ?

? - display help

address - device IP address (*)

cancel - discard changes and exit from subcommand mode

exit - create device and exit from sub-command mode

help - display help

show - show current config that will be applied on exit

(*) - denotes a mandatory field for this configuration.

root@172-20-104-107.cisco.com(sub-device-netflow)#

Step 3 Enter the IP address of the device as shown in this example (required):

root@172-20-104-107.cisco.com(sub-device-erspan)# address 192.168.0.1

to look at the device configuration that will be applied and verify that it is correct:

root@172-20-104-107.cisco.com(sub-device-erspan)# show

DEVICE TYPE : ERSPAN (Encapsulated Remote SPAN)

DEVICE ADDRESS : 192.168.0.1

root@172-20-104-107.cisco.com(sub-device-erspan)#

to come out of the subcommand mode and create the device. Remember the ID value that was assigned to the new device (you will need it to create the data source).

root@172-20-104-107.cisco.com(sub-device-erspan)# exit

Device created successfully, ID = 1

root@172-20-104-107.cisco.com#

. You will now be in erspan data source subcommand mode as shown here:

root@172-20-104-107.cisco.com# data-source erspan

Entering into subcommand mode for this command.

Type 'exit' to apply changes and come out of this mode.

Type 'cancel' to discard changes and come out of this mode.

root@172-20-104-107.cisco.com(sub-data-source-erspan)#

to see all the command options available, as in the example below:

root@172-20-104-107.cisco.com(sub-data-source-erspan)# ?

? - display help

cancel - discard changes and exit from subcommand mode

device-id - erspan device ID (*)

exit - create data-source and exit from sub-command mode

help - display help

name - data-source name (*)

session-id - erspan Session ID

show - show current config that will be applied on exit

(*) - denotes a mandatory field for this configuration.

root@172-20-104-107.cisco.com(sub-data-source-erspan)#

Step 8 Enter the device ID from Step 4.

root@172-20-104-107.cisco.com(sub-data-source-erspan)# device-id 1

Step 9 Enter the name you would like for the data source (required):

root@172-20-104-107.cisco.com(sub-data-source-erspan)# name MyFirstErspanDataSource

Step 10 If desired, supply the specific Session ID for this ERSPAN data source (optional):

root@172-20-104-107.cisco.com(sub-data-source-erspan)# session-id 123

to look at the data source configuration that will be applied and verify that it is correct:

root@172-20-104-107.cisco.com(sub-data-source-netflow)# show

DATA SOURCE NAME : MyFirstErspanDataSource

DATA SOURCE TYPE : ERSPAN (Encapsulated Remote SPAN)

DEVICE ID : 1

DEVICE ADDRESS : 192.168.0.1

SESSION ID : 123

root@172-20-104-107.cisco.com(sub-data-source-erspan)#

to come out of the subcommand mode and create the data source:

root@172-20-104-107.cisco.com(sub-data-source-erspan)# exit

Data source created successfully, ID = 3

The data source is now created, and ERSPAN records from the device will be received and accepted by Packet Analyzer as they arrive.

Deleting ERSPAN Data Sources Using the Web GUI

To delete an existing ERSPAN data source, use the following steps. Note that if the autocreation feature is turned on, and the device continues to send ERSPAN packets to the Packet Analyzer, the data source will be recreated again automatically as soon as the next ERSPAN packet arrives. Therefore, if you wish to delete an existing ERSPAN data source, it is usually advisable to first turn the ERSPAN autocreate feature off, as described earlier.

Step 2 Choose the data source you would like to delete.

along the bottom of the window.

Deleting ERSPAN Data Sources Using the CLI

To delete a ERSPAN data source using the CLI, use the following steps. Note that when using the CLI, there are generally two separate phases involved. First you should delete the data source, then delete the device if you have no other data sources using the same device (for example with a different Engine ID value). As a shortcut, if you simply delete the device, then all data sources using that device will also be deleted.

Step 1 Show all data sources so you can find the ID of the one you want to delete:

root@172-20-104-107.cisco.com# show data-source

DATA SOURCE ID : 1

DATA SOURCE NAME : DATA PORT 1

TYPE : Data Port

PORT NUMBER : 1

-----------

DATA SOURCE ID : 2

DATA SOURCE NAME : DATA PORT 2

TYPE : Data Port

PORT NUMBER : 2

-----------

DATA SOURCE ID : 3

DATA SOURCE NAME : MyFirstErspanDataSource

TYPE : ERSPAN (Encapsulated Remote SPAN)

DEVICE ID : 2

DEVICE ADDRESS : 192.168.0.1

ENGINE ID : 123

-----------

root@172-20-104-107.cisco.com#

command to delete the data source:

root@172-20-104-107.cisco.com# no data-source 3

Successfully deleted data source 3

root@172-20-104-107.cisco.com#

Step 3 Show all devices so you can find the ID of the one you want to delete:

root@172-20-104-107.cisco.com# show device

DEVICE ID : 1

DEVICE TYPE : ERSPAN (Encapsulated Remote SPAN)

IP ADDRESS : 192.168.0.1

INFORMATION : No packets received

STATUS : Inactive

------

root@172-20-104-107.cisco.com#

command to delete the device:

root@172-20-104-107.cisco.com# no device 1

Successfully deleted device 1

root@172-20-104-107.cisco.com#

Note that if the autocreation mode is on, and the device continues to send ERSPAN packets to the Packet Analyzer, the data source (and device entry) will be recreated again automatically as soon as the next ERSPAN packet arrives. Therefore, if you wish to delete an existing ERSPAN data source, it is usually advisable to first turn the ERSPAN autocreate feature off, as described earlier.

Configuring ERSPAN on Devices

There are two ways to configure ERSPAN so that the Packet Analyzer receives the data:

- Sending ERSPAN Data to Layer 3 Interface

- Sending ERSPAN Data Directly to the Packet Analyzer Management Interface

Note Depending on the Cisco IOS or NX-OS version on your managed device, the CLI format for configuring an ERSPAN session may be different than what appears in this document. For details on using ERSPAN as a data source, see your specific OS product documentation.

Sending ERSPAN Data to Layer 3 Interface

To send the data to a layer 3 interface on the Switch housing the Packet Analyzer, configure the ERSPAN source session. The ERSPAN destination session then sends the traffic to a Packet Analyzer data-port. After performing this configuration, you can select the DATA PORT X data source to analyze the ERSPAN traffic.

Note This method causes the ERSPAN traffic to arrive on one of the Packet Analyzer dataports, which is the most efficient method and will not have any adverse effect on the Packet Analyzer’s IP connectivity. Therefore, we recommend this method. The configuration below may be different depending on your platform and OS version. See your OS product documentation for additional help.

Sample Configuration of ERSPAN Source

monitor erspan origin ip-address aa.bb.cc.dd global

monitor session 4 type erspan-source

erspan-id N

vrf default

destination ip aa.bb.cc.ii

source interface Ethernet12/1 bo

rate-limit auto

no shut

Interface that is connected to the Packet Analyzer data port:

interface Ethernet12/11

description connect to 24042400 ee.ff.gg.hh DP2

mtu 9216

ip address aa.bb.cc.dd/24

no shutdown

On Packet Analyzer:

root@appliance-2400-90.cisco.com# data-port 2 ip-address aa.bb.cc.ii

root@appliance-24002404-90.cisco.com# show data-port 2 ip-address

Port number: 2

IPv4 address: aa.bb.cc.ii

root@appliance-2400-90.cisco.com#

Where:

- N matches the ERSPAN ID at the source switch

- aa.bb.cc.dd is the IP address defined at the destination

- aa.bb.cc.ii is the IP address of the Packet Analyzer data port

- ee.ff.gg.hh is the IP address of the Packet Analyzer management port

Sending ERSPAN Data Directly to the Packet Analyzer Management Interface

To send the data directly to the Packet Analyzer management IP address (management-port), configure the ERSPAN source session. No ERSPAN destination session configuration is required. After performing this configuration on the Catalyst 6500 switch, when ERSPAN packets are sent to the Packet Analyzer, it will automatically create a data source for that packet stream. If the autocreate feature is not enabled, you will have to manually create the data source for this ERSPAN stream of traffic (see Creating ERSPAN Data Sources Using the Web GUI).

Note This method causes the ERSPAN traffic to arrive on the Packet Analyzer management port. If the traffic level is high, this could have negative impact on the Packet Analyzer’s performance and IP connectivity.

Sample Configuration

monitor session 1 type erspan-source

no shut

source interface Fa3/47

destination

erspan-id Y

ip address aa.bb.cc.dd

origin ip address ee.ff.gg.hh

Where:

- Interface fa3/47 is a local interface on the erspan-source switch to be monitored

- Y is any valid span session number

- aa.bb.cc.dd is the management IP address of the Packet Analyzer

- ee.ff.gg.hh is the source IP address of the ERSPAN traffic

Forwarding VACL Traffic

You can use VLAN access control (VACL) lists to filter packet data and expand your device’s capability beyond the two SPAN session limitation.

VACL can forward traffic from either a WAN interface or VLANs to a dataport on some of the Packet Analyzer platforms. A VACL provides an alternative to using SPAN; a VACL can provide access control based on Layer 3 addresses for IP and IPX protocols. The unsupported protocols are access controlled through the MAC addresses. A MAC VACL cannot be used to access control IP or IPX addresses.

Configuring VACL on a WAN Interface

Because WAN interfaces do not support the SPAN function, you must use the switch CLI to manually configure a VACL in order to monitor WAN traffic with the Packet Analyzer. This feature only works for IP traffic over the WAN interface.

VACL can also be used if there is no available SPAN session to direct traffic to the Packet Analyzer. In this case, a VACL can be set up in place of a SPAN for monitoring VLAN traffic.

The following example shows how to configure a VACL on an ATM WAN interface and forward both ingress and egress traffic to the Packet Analyzer. These commands are for switches running Cisco IOS version 12.1(13)E1 or higher. For more information on using these features, see your accompanying switch documentation.

Cat6509#config terminal

Cat6509(config)# access-list 100 permit ip any any

Cat6509(config)# vlan access-map wan 100

Cat6509(config-access-map)# match ip address 100

Cat6509(config-access-map)# action forward capture

Cat6509(config-access-map)# exit

Cat6509(config)# vlan filter wan interface AM6/0/0.1

Cat6509(config)# analysis module 3 data-port 1 capture allowed-vlan 1-4094

Cat6509(config)# analysis module 3 data-port 1 capture

Cat6509(config)# exit

To monitor egress traffic only, get the VLAN ID that is associated with the WAN interface by using the following command:

Cat6509#show cwan vlan

Hidden VLAN swidb->i_number Interface

1017 94 ATM6/0/0.1

After you have the VLAN ID, configure the Packet Analyzer dataport using the following command:

Cat6509(config)# analysis module 3 data-port 1 capture allowed-vlan 1017

To monitor ingress traffic only, replace the VLAN number in the capture configuration with the native VLAN ID that carries the ingress traffic. For example, if VLAN 1 carries the ingress traffic, you would use the following command:

Cat6509(config)# analysis module 3 data-port 1 capture allowed-vlan 1

Configuring VACL on a LAN VLAN

For VLAN Traffic monitoring on a LAN, traffic can be sent to Packet Analyzer by using the SPAN feature of the switch. However, in some instances when the traffic being spanned exceeds the monitoring capability of the Packet Analyzer, you might want to pre-filter the LAN traffic before it is forwarded. This can be done by using VACL.

The following example shows how to configure VACL for LAN VLAN interfaces. In this example, all traffic directed to the server 172.20.10.221 on VLAN 1 is captured and forwarded to the Packet Analyzer located in slot 3.

Cat6509#config terminal

Cat6509#(config)#access-list 100 permit ip any any

Cat6509#(config)#access-list 110 permit ip any host 172.20.10.221

Cat6509#(config)#vlan access-map lan 100

Cat6509#(config-access-map)match ip address 110

Cat6509#(config-access-map)#action forward capture

Cat6509#(config-access-map)#exit

Cat6509#(config)#vlan access-map lan 200

Cat6509#(config-access-map)#match ip address 100

Cat6509#(config-access-map)#action forward

Cat6509#(config-access-map)#exit

Cat6509#(config)#vlan filter lan vlan-list 1

Cat6509#(config)#analysis module 3 data-port 1 capture allowed-vlan 1

Cat6509#(config)#analysis module 3 data-port 1 capture

Cat6509#(config)#exit

Forwarding NetFlow Traffic

Packet Analyzer functions as a NetFlow consumer. You can configure NetFlow on the device side so that Packet Analyzer can receive NetFlow packets from devices such as Cisco routers and switches. Those records are stored in its collection database as if that traffic had appeared on one of the Packet Analyzer dataports. Packet Analyzer understands NetFlow version 5 and version 9. Incoming NetFlow data is parsed by Packet Analyzer, stored in its internal database, and presented in the user interface in the same way as traffic from other data sources.

For Packet Analyzer to receive NetFlow packets from an external switch or router, you must configure that device to forward export flow records to the Packet Analyzer’s IP address and the correct UDP port number. The default port number on which Packet Analyzer listens for NetFlow packets is port 3000. This port can be modified using the Packet Analyzer CLI, but it is critical that the same port be configured on the Packet Analyzer and the exporting device or devices. Depending on the external device, you may need to enable the NetFlow feature on a per-interface basis.

See the following sections about NetFlow as a data source:

- Understanding NetFlow Interfaces

- Understanding NetFlow Flow Records

- Managing NetFlow Data Sources

- Configuring NetFlow on Devices

Configuring NetFlow on Devices

The configuration commands for NetFlow devices to export NetFlow packets to Packet Analyzer are platform and device specific. The example configuration commands provided here are the ones most commonly found for devices running Cisco IOS. For more detailed NetFlow configuration information, see your device documentation.

Enabling Autocreation of NetFlow Data Sources Using the Web GUI

To configure Packet Analyzer to automatically create data sources when it receives NetFlow packets from an external device, use the following steps. Remember however, that the autocreate feature is turned on by default, so these steps are typically not necessary.

.

on the bottom left of the window.

check box to toggle autocreation of NetFlow data sources on.

.

Enabling Autocreation of NetFlow Data Sources Using the CLI

Configuration of the autocreate feature is also possible using the Packet Analyzer CLI. Remember that the autocreate feature is turned ON by default, so in most cases these steps are not necessary.

To configure the Packet Analyzer to automatically create data sources when it receives NetFlow packets from an external device, use the following steps:

command as follows:

root@172-20-104-107.cisco.com# autocreate-data-source netflow

NetFlow data source autocreate successfully ENABLED

Packet Analyzer will now automatically create a NetFlow data source for each device that sends NetFlow packets to it. The data source will have the specific Engine ID that is populated by the device in the NetFlow packets sent to the Packet Analyzer. If the same device happens to send NetFlow packets to the Packet Analyzer with different Engine ID values, a separate data source will be created for each unique Engine ID sent from the device.

Disabling Autocreation of NetFlow Data Sources Using the Web GUI

.

on the bottom left of the window.

check box to toggle autocreation of NetFlow data sources off.

.

Disabling Autocreation of NetFlow Data Sources Using the CLI

command as follows:

root@172-20-104-107.cisco.com# no autocreate-data-source netflow

NetFlow data source autocreate successfully DISABLED

root@172-20-104-107.cisco.com#

Creating NetFlow Data Sources Using the Web GUI

To manually configure a NetFlow data source using the Packet Analyzer GUI, for example if the autocreation feature is turned OFF, use the following steps:

.

along the bottom of the window.

Step 3 Give the Data Source a name. This name will appear anywhere there is a Data Source drop-down list.

.

Step 5 Enter the IP address of the device that will export NetFlow to Packet Analyzer (required).

check box can be left blank and you don't have to worry about the Engine ID value).

Some devices have multiple Engines which independently export NetFlow records. For example, on some Cisco routers, NetFlow records can be exported by the Supervisor module as well as individual line cards. The packets exported may have the same source IP address, but the Engine ID exported by the Supervisor will be a different value than the Engine ID(s) exported by the line card(s). If you want to include only one Engine in the data source, you must check the “Engine” box and provide the value of that Engine ID.

Step 7 (Optional) SNMP v1/v2c RO Community String: If SNMP v1 or v2c will be used to communicate with the device, enter the community string that is configured on the device that is going to export NetFlow packets to the Packet Analyzer.

Step 8 (Optional) “Enable SNMP v3”: If SNMP v3 will be used to communicate with the device, fill in the fields within the v3-specific dialog.

.

to see if the information you provided is accurate.

.

Creating NetFlow Data Sources Using the CLI

To manually configure a NetFlow data source on the Packet Analyzer using the CLI, for example if the autocreation feature is turned off, use the following steps. Note that when using the CLI, there are two separate phases involved. First you must create a “device” entry on the Packet Analyzer and remember the device ID. Then you must create a data source entry using this device ID. For convenience, these two phases are combined together when using the GUI to create NetFlow data sources.

. You will now be in netflow device subcommand mode as shown here:

root@172-20-104-107.cisco.com# device netflow

Entering into subcommand mode for this command.

Type 'exit' to apply changes and come out of this mode.

Type 'cancel' to discard changes and come out of this mode.

root@172-20-104-107.cisco.com(sub-device-netflow)#

to see all the command options available, as in the example below:

root@172-20-104-107.cisco.com(sub-device-netflow)# ?

? - display help

address - device IP address (*)

cancel - discard changes and exit from subcommand mode

community - SNMPv2c community string

exit - create device and exit from sub-command mode

help - display help

show - show current config that will be applied on exit

snmp-version - SNMP version to use to communicate with device

v3-auth-passphrase - SNMPv3 authentication passphrase

v3-auth-protocol - SNMPv3 authentication protocol

v3-priv-passphrase - SNMPv3 privacy passphrase

v3-priv-protocol - SNMPv3 privacy protocol

v3-sec-level - SNMPv3 security level

v3-username - SNMPv3 username

(*) - denotes a mandatory field for this configuration.

root@172-20-104-107.cisco.com(sub-device-netflow)#

Step 3 Enter the IP address of the device as shown in this example (required):

root@172-20-104-107.cisco.com(sub-device-netflow)# address 192.168.0.1

Step 4 If desired, enter the SNMP credentials for the device, as in the example below. If you specify snmp-version v2c, then you should enter the community string for the device. If you specify snmp-version v3, then you should enter the security level, username, authentication protocol, authentication passphrase, privacy protocol, and privacy passphrase.

root@172-20-104-107.cisco.com(sub-device-netflow)# snmp-version v2c

root@172-20-104-107.cisco.com(sub-device-netflow)# community public

to look at the device configuration that will be applied and verify that it is correct:

root@172-20-104-107.cisco.com(sub-device-netflow)# show

DEVICE TYPE : NDE (Netflow Data Export)

DEVICE ADDRESS : 192.168.0.1

SNMP VERSION : SNMPv2c

V2C COMMUNITY : public

V3 USERNAME :

V3 SECURITY LEVEL : No authentication, no privacy

V3 AUTHENTICATION : MD5

V3 AUTH PASSPHRASE :

V3 PRIVACY : DES

V3 PRIV PASSPHRASE :

root@172-20-104-107.cisco.com(sub-device-netflow)#

to come out of the subcommand mode and create the device. Remember the ID value that was assigned to the new device, you will need it to create the data source!

root@172-20-104-107.cisco.com(sub-device-netflow)# exit

Device created successfully, ID = 1

root@172-20-104-107.cisco.com#

. You will now be in netflow data source subcommand mode as shown here:

root@172-20-104-107.cisco.com# data-source netflow

Entering into subcommand mode for this command.

Type 'exit' to apply changes and come out of this mode.

Type 'cancel' to discard changes and come out of this mode.

root@172-20-104-107.cisco.com(sub-data-source-netflow)#

to see all the command options available, as in the example below:

root@172-20-104-107.cisco.com(sub-data-source-netflow)# ?

? - display help

cancel - discard changes and exit from subcommand mode

device-id - netflow device ID (*)

engine-id - netflow Engine ID

exit - create data-source and exit from sub-command mode

help - display help

name - data-source name (*)

show - show current config that will be applied on exit

(*) - denotes a mandatory field for this configuration.

root@172-20-104-107.cisco.com(sub-data-source-netflow)#

Step 9 Enter the device ID from Step 4 (required):

root@172-20-104-107.cisco.com(sub-data-source-netflow)# device-id 1

Step 10 Enter the name you would like for the data source (required):

root@172-20-104-107.cisco.com(sub-data-source-netflow)# name MyFirstNdeDataSource

Step 11 If desired, supply the specific Engine ID for this NetFlow data source (optional):

root@172-20-104-107.cisco.com(sub-data-source-netflow)# engine-id 123

to look at the data source configuration that will be applied and verify that it is correct:

root@172-20-104-107.cisco.com(sub-data-source-netflow)# show

DATA SOURCE NAME : MyFirstNdeDataSource

DATA SOURCE TYPE : NDE (Netflow Data Export)

DEVICE ID : 1

DEVICE ADDRESS : 192.168.0.1

ENGINE ID : 123

root@172-20-104-107.cisco.com(sub-data-source-netflow)#

to come out of the subcommand mode and create the data source:

root@172-20-104-107.cisco.com(sub-data-source-netflow)# exit

Data source created successfully, ID = 3

The data source is now created, and NetFlow records from the device will be received and accepted by the Packet Analyzer as they arrive.

Deleting NetFlow Data Sources Using the Web GUI

To delete an existing NetFlow data source, use the following steps. If the autocreation feature is turned on, and the device continues to send NetFlow packets to the Packet Analyzer, the data source will be recreated again automatically as soon as the next NetFlow packet arrives. Therefore, if you wish to delete an existing NetFlow data source, it is usually advisable to first turn the NetFlow autocreate feature off, as described earlier.

.

Step 2 Click on the data source you would like to delete.

.

Deleting NetFlow Data Sources Using the CLI

To delete a NetFlow data source using the CLI, use the following steps. Note that when using the CLI, there are generally two separate phases involved. First you should delete the data source, then delete the device if you have no other data sources using the same device (for example with a different Engine ID value). As a shortcut, if you simply delete the device, then all data sources using that device will also be deleted.

Step 1 Show all data sources so you can find the ID of the one you want to delete:

root@172-20-104-107.cisco.com# show data-source

DATA SOURCE ID : 1

DATA SOURCE NAME : DATA PORT 1

TYPE : Data Port

PORT NUMBER : 1

-----------

DATA SOURCE ID : 2

DATA SOURCE NAME : DATA PORT 2

TYPE : Data Port

PORT NUMBER : 2

-----------

DATA SOURCE ID : 3

DATA SOURCE NAME : MyFirstNdeDataSource

TYPE : NDE (Netflow Data Export)

DEVICE ID : 2

DEVICE ADDRESS : 192.168.0.1

ENGINE ID : 123

-----------

root@172-20-104-107.cisco.com#

command to delete the data source:

root@172-20-104-107.cisco.com# no data-source 3

Successfully deleted data source 3

root@172-20-104-107.cisco.com#

Step 3 Show all devices so you can find the ID of the one you want to delete:

root@172-20-104-107.cisco.com# show device

DEVICE ID : 1

DEVICE TYPE : NDE (Netflow Data Export)

IP ADDRESS : 192.168.0.1

SNMP VERSION : SNMPv2c

V2C COMMUNITY : public

V3 USERNAME :

V3 SECURITY LEVEL : No authentication, no privacy

V3 AUTHENTICATION : MD5

V3 AUTH PASSPHRASE :

V3 PRIVACY : DES

V3 PRIV PASSPHRASE :

INFORMATION : No packets received

STATUS : Inactive

------

root@172-20-104-107.cisco.com#

command to delete the device:

root@172-20-104-107.cisco.com# no device 1

Successfully deleted device 1

root@172-20-104-107.cisco.com#

Note that if the autocreation mode is on, and the device continues to send NetFlow packets to the Packet Analyzer, the data source (and device entry) will be re-created again automatically as soon as the next NetFlow packet arrives. Therefore, if you wish to delete an existing NetFlow data source, it is usually advisable to first turn the NetFlow autocreate feature off, as described earlier.

Testing NetFlow Devices

for a description of the fields.

If the device is sending NetFlow Version 9 (V9) and the Packet Analyzer has received the NetFlow templates, then a V9 Templates button appears below the Device System Information window.

Note NetFlow v9 templates do not appear in all NetFlow packets. When there are no templates, the V9 Templates button does not appear.

Forwarding CEF Traffic

You can configure CEF traffic copy and forward it to Packet Analyzer session as a Packet Analyzer data source from the remote device command line interface and not from the Packet Analyzer GUI.

As a CEF consumer, Packet Analyzer can receive CEF packets on its data port from Cisco monitoring interface. Packet Analyzer supports monitoring and analysis of incoming CEF data to be parsed by Packet Analyzer, stored in its internal database, and presented in the GUI in the same way as traffic from other data sources.

Before You Begin

For the Packet Analyzer to receive CEF traffic from router, the device must be configured to copy and forward the CEF packets to Cisco Packet Analyzer.

To enable CEF as a data source:

- Configure CEF and CEF monitoring on devices

- CEF data port will be auto created on physical port receiving CEF traffic on devices

for CEF configuration examples.

Note Depending on the Cisco IOS/Nexus OS version on the managed device, the CLI format for configuring a CEF copy and forward session may be different from what appears in this document. Ensure that your IOS/Nexus OS version supports UCSE platform. Before you create CEF traffic monitoring session on a router, enable Packet Analyzer feature through UCSE CIMC. For list of router platforms and IOS releases support UCSE, see Getting Started Guide for Cisco UCS E-Series Servers and the Cisco UCS E-Series Network Compute Engine, Release 2.x.

See Understanding How the Packet Analyzer uses CEF for details of how to configure CEF monitoring.

Managing WAAS and WAN Traffic

This section contains the following topics about using the Packet Analyzer GUI to manage WAAS data sources:

- Understanding WAAS

- Considering Deployment Scenarios

- Using the WAAS Central Manager

- Monitoring Response Time from WAAS Data Sources

- Monitoring Client Data Sources

- Monitoring WAN Data Sources

- Monitoring Server Data Sources

- Enabling WAAS Flow Agent

- Adding Data Sources for New WAAS Device

- Editing WAAS Data Sources

- Deleting a WAAS Data Source

- Auto Create of New WAAS Devices

Understanding WAAS

Cisco Wide Area Application Services (WAAS) software optimizes the performance of TCP-based applications operating in a wide area network (WAN) environment and preserves and strengthens branch security. The WAAS solution consists of a set of devices called Wide Area Application Engines (WAEs) that work together to optimize WAN traffic over your network.

When client and server applications attempt to communicate with each other, the network devices intercept and redirect this traffic to the WAEs to act on behalf of the client application and the destination server.

WAEs provide information about packet streams traversing through both LAN and WAN interfaces of WAAS WAEs. Traffic of interest can include specific servers and types of transaction being exported. Packet Analyzer processes the data exported from the WAAS and performs application response time calculations and enters the data into reports you set up.

The WAEs examine the traffic and use built-in application policies to determine whether to optimize the traffic or allow it to pass through your network not optimized.

You can use the WAAS Top Talkers Detail Dashboard to analyze the traffic for optimization. See Analyzing Traffic for Optimization Using the Top Talkers Detail for more information.

Cisco WAAS helps enterprises to meet the following objectives:

- Provide branch office employees with LAN-like access to information and applications across a geographically distributed network.

- Migrate application and file servers from branch offices into centrally managed data centers.

- Minimize unnecessary WAN bandwidth consumption through the use of advanced compression algorithms.

- Provide print services to branch office users. WAAS allows you to configure a WAE as a print server so you do not need to deploy a dedicated system to fulfill print requests.

- Improve application performance over the WAN by addressing the following common issues:

– Low data rates (constrained bandwidth)

– Slow delivery of frames (high network latency)

– Higher rates of packet loss (low reliability)

.

Considering Deployment Scenarios

lists six different deployment scenarios you might consider to monitor the optimized traffic on your WAAS network.

Table 7-2 WAAS Data Source Configurations

Deployment Scenario

Edge WAE Data Source

Core WAE Data Source

1

- Clients in the edge (branch)

- Servers in the core (data center)

- Packet Analyzer in the edge

Client

Client WAN

Server

2

- Servers in the edge (branch)

- Clients in the core (data center)

- Packet Analyzer in the core

Server

Client

Client WAN

3

- Servers in the edge (branch)

- Clients in the core (data center)

- Packet Analyzer in the edge

Server

Server WAN

Client

4

- Clients and servers in the edge (branch) and the core (data center)

- Packet Analyzer in the core

Client

Server

Client

Server

Client WAN

Server WAN

5

- Clients and servers in the edge (branch) and the core (data center)

- Packet Analyzer in the edge

Client

Server

Client WAN

Server WAN

Client

Server

Using the WAAS Central Manager

The Cisco WAAS is centrally managed by a scalable, secure, and simple function called the Cisco WAAS Central Manager, which runs on Cisco WAE Appliances. The Cisco WAAS Central Manager provides a centralized mechanism for configuring features, reporting, and monitoring, and can manage a topology containing thousands of Cisco WAE nodes.

Packet Analyzer is accessible from within the Central Manager interface. Packet Analyzer integration with WAAS Central Manager provides for easier viewing of Packet Analyzer reports that are directly associated with Application Response Time measurements through the WAN, in both WAAS optimized and non-optimized environments.

Below is a standard configuration workflow that you can follow.

Prerequisites are that the WAAS Central Manager is installed and functional, and the Packet Analyzer (device or virtual blade) is installed and functional.

Step 1 From the WAAS Central Manager, configure the Packet Analyzer IP address and login credentials.

Step 2 From the router or switch, configure the data source(s) for baseline (SPAN).

Step 3 From the WAAS Central Manager, configure the Site definition. See Configuring Sites for more information.

Step 4 In the Monitor section of WAAS Central Manager, one can observe the Top Talkers under the Network Analysis tab. See Analyzing Traffic for Optimization Using the Top Talkers Detail for more information.

Step 5 From the WAAS Central Manager, configure the WAAS Flow Agent and branch/data center WAEs.

Step 6 Create Device Groups for the branch and data center on the WAAS Central Manager, and assign a device to the Device Groups.

Step 7 Enable the Flow Agent on the WAAS, pointing to the Packet Analyzer IP. Segments are automatically selected (enabled only if Packet Analyzer is configured). Packet Analyzer will start to compute baseline ART, protocol distribution, and Top Talkers. See Enabling WAAS Flow Agent.

Step 8 Turn on WAAS optimization. See Optimizing WAN for more information.

Step 9 Turn on the Flow Agent and identify the servers to monitor to get ART improvements. See Editing WAAS Data Sources.

Monitoring Response Time from WAAS Data Sources

Packet Analyzer processes the TCP flow data exported from the WAAS and performs application response time (ART) calculations and reports. You use the Packet Analyzer GUI to create a WAAS data source to monitor WAAS traffic statistics. In addition to ART, Packet Analyzer monitors and reports other traffic statistics of the WAAS data sources including application, host, and conversation information.

Packet Analyzer provides different ART metrics by collecting data at different points as packets flow along their paths. Packet Analyzer provides five different collection points, each represented by a WAAS data source. Figure 7-1, WAAS Data Sources (Data Collection Points), shows an example of the data collection points. The solid line represents data exported from a WAAS device and/or directly monitored traffic like SPAN. The broken line represents data exported from a WAAS device only.

Figure 7-1 WAAS Data Sources (Data Collection Points)

.

Table 7-3 WAAS Data Collection Points

Setting

Description

Client

This setting configures the WAE device to export the original (LAN side) TCP flows originated from its clients to Packet Analyzer for monitoring. To monitor this point, configure a Client data source.

Client WAN

This setting configures the WAE device to export the optimized (WAN side) TCP flows originated from its clients to Packet Analyzer for monitoring. To monitor this point, configure a Client WAN data source.

Server WAN

This setting configures the WAE device to export the optimized (WAN side) TCP flows from its servers to Packet Analyzer for monitoring. To monitor this point, configure a Server WAN data source.

Server

This setting configures the WAE device to export the original (LAN side) TCP flows from its servers to Packet Analyzer for monitoring. To monitor this point, configure a Server data source.

Passthrough

This setting configures the WAE device to export the TCP flows that are passed through unoptimized.

You can also configure a data source to use Export Passthrough data. For more information about configuring WAAS data sources, see Editing WAAS Data Sources.

Monitoring Client Data Sources

By monitoring the TCP connections between the client and the WAE device (Client segment in Figure 7-1), you can measure the following ART metrics:

- Total Response Time as experienced by the client

- Total Transaction Time as experienced by the client

- Bandwidth usage (bits/packets) before optimization

- Number of transactions and connections.

- Network Time broken down into two segments: client-edge and edge-server

submenu.

Monitoring WAN Data Sources

By monitoring the TCP connections between the edge and core WAE devices (Client WAN and Server WAN segments in Figure 7-1), you can measure the following:

- Bandwidth usage (bits/packets) after optimization

- Network Time of the WAN segment

Monitoring Server Data Sources

By monitoring the TCP connections between the core WAE devices and the servers (Server segment in Figure 7-1), you can measure the following ART metrics:

- Server Response Time (without proxy acceleration/caching server)

- Network Time between the core WAE device and the servers

Note Packet Analyzer measures Network Time by monitoring the TCP three-way handshake between the devices.

Enabling WAAS Flow Agent

command to enable the Flow Agent on the WAAS:

flow monitor tcpstat-v1 enable

After you enable flow export to the Packet Analyzer using WAAS CLI commands like those above, WAAS devices will be detected and automatically added to the Packet Analyzer’s WAAS device list.

You must then configure the WAAS segments you want to monitor as WAAS data sources: Client, Client WAN, Server WAN, and/or Server. See Editing WAAS Data Sources, for more detailed information.

You can also use the WAAS Central Manager to centrally issue WAAS CLI commands to configure a large number of WAEs at one time. Packet Analyzer is accessible from within the WAAS Central Manager interface. For more information about WAAS Central Manager, refer to the WAAS technical documentation.

Note In addition to configuring the WAAS devices, you must specify which application servers you want to monitor among the servers being optimized by WAAS devices. See Configuring WAAS Monitored Servers, for more detailed information.

.

This section contains the following topics:

- Adding Data Sources for New WAAS Device

- Editing WAAS Data Sources

- Deleting a WAAS Data Source

Adding Data Sources for New WAAS Device

Packet Analyzer uses WAAS data sources to monitor traffic collected from different WAAS segments: Client, Client WAN, Server WAN, and Server. Each WAAS segment is represented by a data source. You can set up Packet Analyzer to monitor and report other traffic statistics of the WAAS data sources such as application, host, and conversation information in addition to the monitored Response Time metrics.

Note This step is not usually necessary because export-enabled WAAS devices are detected and added automatically. See Enabling WAAS Flow Agent, for more information about how to enable WAAS export to the Packet Analyzer.

To manually add a WAAS device to the list of devices monitored by Packet Analyzer:

.

.

The Packet Analyzer Data Source Configuration Dialog appears.

Step 3 Choose “WAAS” from the list of Types.

Step 4 Enter the device IP address in the IP field.

.

to add the new WAAS custom data source.

Editing WAAS Data Sources

Packet Analyzer uses WAAS data sources to monitor traffic collected from different WAAS segments: Client, Client WAN, Server WAN, and Server. Each WAAS segment is represented by a data source. You can set up Packet Analyzer to monitor and report other traffic statistics of the WAAS data sources such as application, host, and conversation information in addition to the monitored Response Time metrics.

To edit a WAAS device’s custom data source:

. The data sources are displayed.

.

You can configure the WAAS data sources to monitor the following WAAS segments as shown in Figure 7-1, WAAS Data Sources (Data Collection Points):

- Client—This setting configures the WAE device to export the original (LAN side) TCP flows originated from its clients to Packet Analyzer for monitoring.

- Client WAN— This setting configures the WAE device to export the optimized (WAN side) TCP flows originated from its clients to Packet Analyzer for monitoring.

- Server WAN—This setting configures the WAE device to export the optimized (WAN side) TCP flows from its servers to Packet Analyzer for monitoring.

- Server—This setting configures the WAE device to export the original (LAN side) TCP flows from its servers to Packet Analyzer for monitoring.

. For example, if you already configure SPAN to monitor the server LAN traffic, it is not necessary to enable the Server data source on the WAE device.

Note The following step is optional and applies only when Packet Analyzer is configured to export data to an External Response Time Reporting Console, such as the NetQos Super Agent.

Deleting a WAAS Data Source

To delete a WAAS custom data source:

. The data sources are displayed.

.

A dialog box displays the device address and asks if you are sure you want to delete the device.

Auto Create of New WAAS Devices

If you have numerous WAE devices, you can set up Packet Analyzer to configure newly discovered WAE devices using a predefined configuration template using the Packet Analyzer auto configuration option.

Note If most of your WAE devices are edge WAE, you might want to set the auto configuration to be that of the edge device, then manually configure the data center WAE. For example, select the Client segment for monitoring.

To configure WAAS autoconfiguration:

. The data sources are displayed.

.

The Packet Analyzer Data Source Configuration Dialog displays.

check box.

Step 4 Check the check boxes for the desired Segments. See Editing WAAS Data Sources, for more information.

Configuring Hardware Deduplication

Note This section applies only to Cisco Cisco Security Packet Analyzer 2400appliance.

Packet Analyzer supports hardware-based detection of duplicate packets and allows you to configure a single deduplication filter that reduces the amount of duplicate traffic across all adapter ports.

You can use deduplication to eliminate redundant data. This can help to significantly shrink storage requirements and improve bandwidth efficiency on tasks like backup and recovery.

After you enable deduplication, the Packet Analyzer detects and filters the duplicated packets. The packet is identified as duplicated if all inspected segments match another packet within the specific time window.

be dropped.

To configure packet deduplication:

.

check box to enable packet deduplication.

Enter a value in the Time Window (1-127 in millisecond (ms)) for the search or buffer period.

The value you set in the Time Window indicates the length of time (ms) in which two packets can be considered duplicates. If the Time Window is 100 ms but two identical packets arrive 120 ms apart, the second packet would not be dropped. If the identical packets arrive 80 ms apart, the second packet would be dropped.

Step 3 Click to choose a segment of the packet to inspect for deduplication.

The default inspects the entire packet. The second option inspects all segments except the ISL portion of the packet. The third option inspects all segments except the ISL, MAC, and VLAN portions of the packet. The fourth option inspects all segments except the ISL, MAC, and VLAN portions of the packet. The final (bottom) option inspects only the UDP/TCP and payload segments of the packet.

Note Regardless of the option you choose, the packet checksum is ignored.

to cancel any change.

Setting Up Alarms and Alarm Thresholds

Alarms are predefined conditions based on a rising data threshold, a falling data threshold, or both. You can choose what types of events for which you want Packet Analyzer to notify you, and how you want to be notified. Monitoring alarms enables you to watch problem areas and collect data on areas such as increased utilization, severe application response delays, and voice quality degradation.

This is the order that you typically follow for setting up alarms and alarm thresholds:

Step 1 Define the way you would like to be notified when an alarm occurs (by e-mail, trap, trigger capture, or syslog).

- For e-mail server settings: Choose Administration > System > E-Mail Setting

- For trap settings: Choose Administration > System > SNMP Trap Setting

- For capture session settings: Choose Capture > Packet Capture/Decode > Sessions

- For syslog settings: Choose Administration > System > Syslog Setting

.

.

The tasks for setting up alarms are:

- Configuring Alarm Actions

- Viewing Alarm Actions

- Defining Thresholds

Configuring Alarm Actions

Alarms are predefined conditions based on a rising data threshold, a falling data threshold, or both.

When a threshold’s rising water mark is crossed, the alarm condition is met. This triggers the alarm action to take effect.

To configure an alarm action:

.

.

Step 3 Enter a Name for the action (up to 63 characters).

Step 4 Choose the type of alarm action. Packet Analyzer supports any combination of these four actions in one alarm condition:

Alarm Action

Description

Important Notes

An alarm action that e-mails the syslog content of the alarm condition. To avoid e-mail flooding the network, Packet Analyzer does not send more than five e-mails in any given hour.

. Packet Analyzer alarm mail is sent as a result of Packet Analyzer alarms, not router or switch alarms.

Packet Analyzer sends up to five e-mails per hour per function (traffic and NetFlow, voice signaling, RTP, and application response time). Also, in each e-mail, there could be up to five alarm messages. These limits are in place to avoid e-mail overload.

If you have configured e-mail alarms and do not receive e-mail, then your Packet Analyzer does not have any alarms.

If Packet Analyzer sends you many alarm messages, the e-mail may state, for example, “5 of 2,345 alarm messages.”

An alarm action that sends Packet Analyzer trap messages to one or more trap servers. Any trap server that has the same community string will receive the trap message. Packet Analyzer uses Cisco Syslog MIB in the trap message. To avoid trap flooding, the limit is ten trap messages per interval.

. After the “Community field appears, choose the community string from the drop-down list.

An alarm action to start or stop a pre-defined capture session or stop a capture to save it to a file.

radio button. For more details, see Understanding Trigger Capture.

An alarm action that sends syslog messages to remote syslog servers. The limit is ten syslog messages per interval to avoid flooding the network.

.

Step 5 To edit or delete alarm actions, select the alarm and use the appropriate button.

.

The Alarm Action table displays the newly configured action in its list.

Viewing Alarm Actions

Alarms are predefined conditions based on a rising data threshold, a falling data threshold, or both. You can set thresholds and alarms on various network parameters such as increased utilization, severe application response delays, and voice quality degradation and be alerted to potential problems.

Packet Analyzer supports IPv6 for all alarm functionality.

Note You could see two alarms for the same occurrence if both the source and the destination are in the same site.

for descriptions of the fields on the Alarm Configuration window.

To configure alarm actions, see Configuring Alarm Actions.

Understanding Trigger Capture

This section describes how to use a trigger capture to start a capture session based on the alarm parameters you set. For example, you can set alarm parameters on various thresholds to start a capture session which can be used to investigate some kind of questionable network activity.

You must set your alarm threshold parameters so that Packet Analyzer has defined rising or falling numbers that will cause an action, or trigger, to start a capture session. You can also use the stop-and-save and Scheduled Capture option. The actions are defined below:

- Trigger Capture Start —An alarm condition occurs based on threshold parameters you have set; the capture session starts automatically.

- Trigger Capture Stop : An alarm condition occurs based on the threshold parameters you have set; the capture session stops automatically.

- Trigger Capture Stop Capture and Save to File —An alarm condition occurs, stopping the capture session. If the captured packet data is in memory, it is saved to a file. The buffer memory is then clear to wait for next alarm event.

- Trigger Capture Scheduled Capture —An alarm condition occurs, starting the capture session on specific date time for certain duration (in minutes).

When an event occurs that you have defined as an alarm threshold, Packet Analyzer stops any existing capture session and saves the captured packets from memory into a file. The capture session then restarts. Packet Analyzer can save up to five files, depending on your local hard disk storage.

Packet Analyzer monitors for threshold parameters every minute. For real-time data, the default is 5 minutes.

Defining Thresholds

Packet Analyzer can inspect incoming performance records and apply a configured set of thresholds to the most recent interval of data. Using thresholds allows you to target specific network traffic issues and set up notifications that are triggered when certain thresholds are crossed. For example:

- if a server's CPU load exceeds 90%

- if a device or the whole network uses more bandwidth than usual, or

- if the remaining file size on a disk drive is less than 15% or 100 MB.

In general, you should set thresholds so that only severe traffic problems that impact quality of service generate events. These critical events are intended to provide actionable notification of problems to network operators. When setting thresholds try to identify a traffic level that will have a noticeable effect on network service levels. Set a duration that corresponds to an unacceptable period of poor service. The goal is to generate very few, significant events indicating severe problems that require immediate attention. Thresholds are not intended as a reporting tool to generate statistical information about network traffic.

To set up alarm thresholds for variables with values that trigger alarms, see Viewing Alarm Actions.

Note You could receive two alarms for the same occurrence if both the source and the destination are in the same site.

You can also decide whether you want to be notified if the threshold is being crossed just once, or whether you only want an alarm to be triggered if this state persists for a certain time. This helps you to ensure an effective network monitoring system, which will not bombard you with unnecessary notifications.

) displays thresholds you have configured. If you hover over the arrow next to the threshold Name a detailed view of the selected threshold displays.

.

You can set up alarm thresholds by defining threshold conditions for monitored variables on the Packet Analyzer.

You can configure the following thresholds:

- Setting Host Thresholds

- Setting Conversation Thresholds

- Setting Application Thresholds

- Setting Response Time Thresholds

- Setting DSCP Thresholds

- Setting RTP Stream Thresholds

- Setting Voice Signaling Thresholds

- Setting NetFlow Interface Thresholds

- Setting Video Stream Thresholds

- Setting MDI Stream Thresholds

Related Topics

- Configuring Alarm Actions

- Viewing Alarm Actions

Setting Host Thresholds

.

tab.

Step 3 The Host Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available on this window.

Note If you leave a selection blank, it means that the parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting Conversation Thresholds

.

tab.

Step 3 The Conversation Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available in this window.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting Application Thresholds

.

tab.

Step 3 The Application Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available in this window.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting Response Time Thresholds

.

tab.

Step 3 The Response Time Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available in this window.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting DSCP Thresholds

.

tab.

Step 3 The DSCP Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available in this window.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting RTP Stream Thresholds

Packet Analyzer sends syslog, trap, e-mail, and trigger captures for RTP streams that violate stream statistics thresholds on the following metrics:

– Number of Consecutive Packet Loss

Each RTP packet has an RTP header that contains a sequence number. The sequence number increments by one for each RTP packet received in the same RTP stream. A gap in the sequence numbers identifies a packet loss. If the gap in sequence numbers jump is more than the threshold, the software raises an alarm condition.

– Packet Loss percent

There are two types of percent packet loss percent: Adjusted Packet Loss and Actual Packet Loss. Actual Packet Loss indicates expected packets that never appear in Packet Analyzer. Adjusted Packet Loss includes actual packets lost and packets that arrive with large delay beyond the expected buffer capacity of the endpoint.

– Jitter: Packets delay compare to the expected receiving time

– Concealment Seconds: Seconds in which there is one or more packets lost

– Severe Concealment Seconds: Seconds in which there is more than 5% of packet lost

To set thresholds for RTP streams:

.

tab.

Step 3 The RTP Stream Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available in this window.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting Voice Signaling Thresholds

You can set up software to monitor voice call quality. When Cisco Unified Communication Manager’s call detail records option is enabled, Cisco IP phones, both SCCP and SIP, will report the call’s jitter and packet loss at the end of the call. Packet Analyzer intercepts this information and raises an alarm when the alarm condition crosses the rising threshold.

To set up a voice signaling threshold:

.

tab.

Step 3 The Voice Signaling Alarm Threshold Configuration window displays. Fill in the fields as appropriate.

describes the fields available under the Voice Signaling Metrics drop-down menu.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting NetFlow Interface Thresholds

.

tab.

.

Note If you leave a selection blank, it means that parameter will not be considered. If you select Any, it will use any of the selections for that parameter, if encountered.

to remove any changes you might have made.

Setting Video Stream Thresholds

Packet Analyzer can monitor the quality of video streams and trigger alarms for video streams that violates stream statistics thresholds. Each video stream contains a series of video frames. The video frames are of different frame type such as I (Intra), P (Predicted) and B (Bi-predictive). I frames are the most important frames in the video. The metrics are given with regard to only I frames or to all frame types. The metrics are as follows:

- Number of Video Frame Loss Count

- I or All frame loss count in the current interval

- Video Frame Loss Percentage

- All frame loss percentage in the current interval

To set thresholds for Video streams:

.

tab.

describes the fields available in this window.

to remove any changes you might have made.

.

Setting MDI Stream Thresholds

MDI streams are defined as video streams that are carried over MPEG-TS. Packet Analyzer can monitor the quality of MDI streams and trigger alarms for streams that violates stream statistics thresholds on the following metrics:

- Delay Factor: RFC-4445 delay factor.

- Media Loss Rate: RFC-4445 media loss rate.

To set thresholds for Video streams:

.

tab.

The MDI Stream Alarm Threshold Configuration window displays. Fill the fields as appropriate. The following table describes the fields available in this window.

to remove any changes you might have made.

.

Editing or Deleting an Alarm Threshold

You can edit alarm thresholds on an as-needed basis. You can delete thresholds when you no longer need them. Any changes take effect immediately.

To edit or delete an alarm threshold:

.

The Thresholds table displays.

.

Step 3 Depending on your selection:

- If you selected to edit, the dialog box displays for the type of alarm; for example, Host Threshold . Make the necessary changes. Then

to save your changes

to reset the thresholds to the values set before you edited them, or

to cancel the edit and return to the previous page.

- If you selected to delete, click OK to confirm deletion, or click Cancel to leave the configuration unchanged.

Setting Up Data Export

The tasks for setting up data export are:

- Configuring NetFlow Export Templates

- Scheduling Data Report Exports

- Sharing Files

Configuring NetFlow Export Templates

This section contains the following topics:

- Creating NetFlow Export Templates

- Editing NetFlow Export Templates

- Deleting NetFlow Export Templates

Creating NetFlow Export Templates

To create NetFlow Export templates:

.

The NetFlow Export Template page appears.

.

The Export Configuration page appears.

.

to save your changes.

Editing NetFlow Export Templates

To edit NetFlow Export templates:

.

Step 2 Click the template that you want to edit.

.

Step 4 Modify the information as desired.

to submit to save the changes.

Deleting NetFlow Export Templates

To delete NetFlow Export templates:

.

Step 2 Click the template that you want to delete.

.

to return to the previous window without deleting.

Sharing Files

This feature allows you to easily access the Packet Analyzer data files. You can map the Packet Analyzer as a network drive and it will appear like any other folder in your machine. You will be able to only read and delete the files for security and stability reasons.

To share the Packet Analyzer data files:

check boxes to enable the SMB and SFTP file sharing services.

Step 2 Enter the port details for SMB and SFTP services.

to share or hide the capture files and scheduled reports.

The dataset access behavior varies between SMB and SFTP. If SMB is enabled, and if the dataset is hidden, the directory will not be visible. If SFTP is enabled, and dataset is hidden, the directory will be visible but you will not be able to access or view any files within it.

access the shared files via SMB or SFTP using web-user's username and password.

Using SMB file sharing on Windows

Click Start button and provide the Packet Analyzer IP address of the shared object. For example, 172.20.124.164 to access the shared files on Windows operating system.

You can also access the files on Linux and set a customized port too.

Using SFTP file sharing on Windows

Windows does not support SFTP by default, you must install a third part FTP application, such as Filezilla to use the SFTP file sharing on windows.;

Step 1 Launch the FTP application and provide the SFTP IP address. For example, 172.20.124.164.

Step 2 Click Quickconnect to access the shared file.

Note TACACS users cannot use the file sharing feature. You have to use Packet Analyzer's local web-users to access the shared files.

Scheduling Data Report Exports

You can use Packet Analyzer to schedule data collection over a period of time for trend analysis and troubleshooting activities and then export the reports to be viewed at your convenience. For example, if you see a spike in application response time on a certain day or time you can set up a scheduled report. The report exports collected data from a specific range of time so that you have a snapshot of what might be causing issues.

You can set up scheduled jobs that will generate a daily report at a specified time, in a specified interval, and e-mail it to a specified e-mail address or addresses.

button, rather than wait for the scheduled time. This report can also be sent after you preview it.

Tip Packet Analyzer displays time in preview report based on the browser that initiated the report. So if your browser is in San Jose, CA, the time zone displayed in the report is based on the time zone of that machine. Scheduled email report shows Packet Analyzer server timezone. The data is not based on the Packet Analyzer server time if the two machines are not synchronized. To synchronize your time, see Synchronizing Your System Time.

This section covers the following topics:

- Creating a Scheduled Report Export

- Editing a Scheduled Export Job

- Deleting a Scheduled Export Job

- Downloading a Scheduled Report

- Renaming a Scheduled Report

- Deleting a Saved Reports

Creating a Scheduled Report Export

Scheduled export of data reports is a convenient way to collect traffic of interest in Packet Analyzer. We strongly recommend you to define your data report time range first and then set your export time right after your report end time. This is the most straight-forward way to use this feature.

To set up a scheduled report and export it to an e-mail address or addresses:

.

Step 2 Enter the Report Name and Report Description. Report name should be at least four characters long.

Step 3 Enter the e-mail address to which you would like the report to be delivered.

Step 4 Choose either CSV or PDF as the delivery option.

Step 5 Choose Save to save the report to your local disk.

time.

Step 7 Choose the Export Time (which is the day of the week on which to generate the weekly report and hour that report will be sent). Multiple days are supported. You can also specify what time to start the export.

The actual data time range used to generate the report for export is always the last available and complete time span specified in the Report Time step above. Packet Analyzer does not generate reports using data in any future time. For example:

Export Time

Report Time

Data Reported and Exported

If Every Day and Hour is 09:00

07:00 to 08:00

07:00 to 08:00 the same day (recommended use case)

If Monday and Friday and Hour is 03:00

05:00 to 05:59

Sunday and Thursday 05:00 to 05:59

If Every Day and Hour is 00:00

18:00 to 01:00

Starts two days before current day from 18.00 to the next day 1.00

Tip Set your Export Time to occur right after the end of Report Time. This gives you the most recent data and is the easiest way to use this feature.

to generate the report immediately.

Note Remember that report results are based on the local time of the browser that initiated the report.

Editing a Scheduled Export Job

.

Step 2 Click the job you want to edit.

.

Step 4 Modify the information as desired.

to submit the request for the scheduled job.

Deleting a Scheduled Export Job

.

Step 2 Click the job you want to delete.

Delete All to delete all the jobs.

to return to the previous window without deleting the job.

Downloading a Scheduled Report

To download a scheduled report:

.

tab.

You will be able to view the saved reports in a tabular format.

Step 3 Select the reports that you want to download.

.

Renaming a Scheduled Report

To rename a scheduled report:

.

tab.

You will be able to view the saved reports in a tabular format.

Step 3 Select the reports that you want to rename.

.

Deleting a Saved Reports

.

tab.

Step 3 Click the reports you want to delete.

Delete All to delete all the jobs.

to return to the previous window without deleting the job.

Accessing Device Interface and Health Details

You can enable your Packet Analyzer to access interface and health device details if they are available on the device you identify using the Packet Analyzer Managed Device feature.

This section contains the following topics:

- Understanding How Platform-Specific Packet Analyzer Handle Managed Device Data

- Configuring and Viewing Managed Device Information

Understanding How Platform-Specific Packet Analyzer Handle Managed Device Data

A managed device can represent a router or switch being monitored by Packet Analyzer. Depending on your Packet Analyzer platform, the managed device is accessed by the Packet Analyzer differently and may support different MIBs based on the device support.

The following details list how Packet Analyzer accesses the managed device:

- For a physical or virtual blade or service module, the managed device is the device in which Packet Analyzer software or hardware is located. The managed device information is automatically updated without user intervention and cannot be modified on the Packet Analyzer. One of the benefits of having a blade or service module is that there is no configuration required for this feature.

- For a physical appliance, you identify the managed device as a switch or router that shares its traffic using SPAN or user credentials. You must enter the device address and either the SNMP credentials or NetConf credentials to configure the Packet Analyzer SPAN session on the managed device. On certain platforms, NetConf is an alternative for Packet Analyzer to configure a Packet Analyzer SPAN session on a managed device which does not support configuring Packet Analyzer SPAN sessions using SNMP. If you choose to use NetConf, you must enable NetConf on the managed device interface and enable SSH to support the SPAN session. This enables you to monitor managed device information such as interface statistics.

. For MIB support, see

Configuring and Viewing Managed Device Information

The managed device information that is required is dependent on your platform device type. For details, see Understanding How Platform-Specific Packet Analyzer Handle Managed Device Data.

For details on how to ensure Packet Analyzer is managing your device interface and other traffic, see:

- Configuring Managed Device Information on Appliances

- Configuring Managed Device Information on RISE Appliances

Configuring Managed Device Information on Appliances

Enabling Multi-Managed Device Feature

This feature is available on Cisco Security Packet Analyzer 2400 series appliances. By default, these Packet Analyzer appliances support a single managed device, which could be either a Cisco Catalyst 6000 or Nexus 7000 switch. When the multi-managed device feature is enabled, the Packet Analyzer appliance instead supports one Catalyst 6000 switch per data port.

To enable the multi-managed device feature:

Step 1 Log into the Packet Analyzer CLI.

.

After you enable this feature, the following Packet Analyzer GUI pages will have a different layout compared to the default single managed device GUI layout:

- Setup > Managed Device > Device Information

- Setup > Traffic > SPAN Sessions

- Analyze > Managed Device > Interface

GUI page will no longer be available.

Configuring a Managed Device per Packet Analyzer Data Port

After you enable the multi-managed device feature, you can use the Packet Analyzer GUI or CLI to configure a single managed device per Packet Analyzer data port.

Note The multi-managed device feature supports only Cisco Catalyst 6000 series switches as managed devices. For Nexus 7000 series switches, RISE provides similar functionality.

To configure the managed device for a Packet Analyzer data port using Packet Analyzer GUI:

.

The Device Information window shows a list of managed devices that are currently setup in the Packet Analyzer.

button to add a managed device for Packet Analyzer data port.

for field descriptions.

.

To edit a managed device using Packet Analyzer GUI:

.

.

for field descriptions.

.

Note If the mapping from Packet Analyzer data port to Packet Analyzer managed device interface is not set correctly, network functions on the Packet Analyzer managed device (Cisco Catalyst 6000 switch) may be disrupted while configuring a SPAN session for the Packet Analyzer data port.

To configure the managed device for a Packet Analyzer data port using the Packet Analyzer CLI instead:

- For SNMPv2, use the command managed-device snmp-v2c .

- For SNMPv3, use the command managed-device snmp-v3 . After entering the snmpv3 subcommand mode, enter ? to display a list of subcommands. Use the appropriate subcommands to configure the SNMPv3 parameters as necessary, then use exit to exit from the subcommand mode and apply the settings.

Configuring a SPAN Session

You can configure a SPAN session only from Packet Analyzer GUI.

To add or configure a SPAN session for a managed device:

.

The window shows a list of SPAN sessions that are currently configured on the managed device.

Step 2 Select a managed device from the drop-down list.

to add a SPAN session.

window appears.

window.

for field descriptions.

Step 5 Click Create to create the SPAN session for the selected managed device.

Note If the SPAN configuration has been modified from the managed device side, those changes will not be reflected in the Packet Analyzer GUI automatically. Click the Refresh button before making SPAN configuration changes to ensure that up-to-date SPAN session information is displayed.

Warning Limitations on SPAN sources, destinations, and traffic rates vary by Catalyst 6000 system and IOS image. Refer to the SPAN configuration document of your managed device to avoid network problems due to SPAN oversubscription.

Configuring Managed Device Information on RISE Appliances

window.

To edit your managed device parameters:

.

The managed devices and the VDC details appear.

.

When you modify the interval, the existing data will be removed.

.

.

Viewing Managed Device Information

.

.

Viewing Managed Device Interface Statistics

button in the Interactive Report window, and select the desired managed device.

To view the interface statistics of a managed device:

.

drop-down list.

drop-down list.

button.

The window shows a graphical representation of interface statistics of the device across the specified time range. The Interface Statistics line chart is updated upon selection of a row in the Interface Statistics table.

Configuring Network Parameters

This section describes how to set up the network parameters including:

- Configuring Sites

- Setting Interface Speed using NetFlow Interface Capacity

- Configuring DSCP Groups

Configuring Sites

.

is a collection of hosts (network endpoints) partitioned into views. You can limit the view of your network analysis data to a specific city, a specific building, or even a specific floor of a building, and can use sites to focus collection and analysis of data. Sites are optional, but recommended.

See the following sections to set up sites:

- Defining a Site

- Viewing Defined Sites

- Configuring Sites Using Subnets

Defining a Site

A site can be defined as a set of subnets specified by an address prefix and mask, or using other criteria such as a remote device data source (for example, remote WAE device and segment information).

Configuring Sites Using Subnets gives specific information about various scenarios.

To set up a site or sites:

.

Step 2 The Site Configuration window appears. Enter a Name, Description, Subnet, and Data Source as appropriate.

for field descriptions.

to tell the software to look for subnets in the traffic. See Detecting Site Subnets.

.

Note The “Unassigned” site (with a description of “Unclassified hosts”) includes any that do not match any of your site configurations. Sites are classified at the time of packet processing.

Detecting Site Subnets

for information about the fields.

, Packet Analyzer finds those subnets that meet the criteria that you entered.

Viewing Defined Sites

To view already-defined sites:

.

Step 2 The Sites window appears. Defined sites will be listed in the table.

.

Editing a Site

You can edit sites that have been created. The Unassigned site cannot be edited or deleted.

.

Step 2 Highlight the site that you have configured.

and edit the desired field.

.

to cancel any changes and return to the main Sites page.

Configuring Sites Using Subnets

for examples of site definitions.

Note VLAN option is removed from the Site definition.

For details on how Packet Analyzer resolves overlapping IP addresses, see Resolving Ambiguity (Overlapping Site Definitions)

Table 7-4 Site Definition Details

Site Definition

Example

Notes

Subnet (IP address prefix)

Preferred. Normally, subnets alone are sufficient to define a site.

Overlapping IP addresses (subnet from data source)

data source.

data source.

data source.

data source.

In certain scenarios when there are overlapping IP address spaces in the networks (for example, in private networks where hosts from different sites have the same IP addresses), then data sources can be used to differentiate the subnets.

WAE device serving the site

For WAAS traffic, you can define a site associated with a WAE device without specifying the site’s subnets. Simply select all of the WAAS data sources coming from the WAE device(s) serving that site.

We recommend that you use subnets to specify WAAS-optimized sites. Use this method only if the site’s subnets cannot be determined.

If you are configuring a WAAS device, you will need to add WAAS servers to Packet Analyzer. See Auto Create of New WAAS Devices.

Multiple Rules

You can define a site using a combination of multiple rules described in this table. For example, if a site has both optimized and non-optimized traffic, it can be defined using a combination of WAAS data sources and a subnet from a NetFlow data source.

When defining a site using multiple data sources, be careful to make sure that those data sources do not have duplicated traffic to avoid double counting the site traffic statistics.

Unassigned site

The Unassigned site includes hosts that do not match any of your site configurations. Sites are classified at the time of packet processing.

Cannot be edited or deleted.

Resolving Ambiguity (Overlapping Site Definitions)

Conflicting rules are not allowed in site definitions. Of the following two scenarios, the second one is not allowed.

1.2.3.0/24 from DATASOURCE1 = SiteA

Using a prefix is the preferred method. Data source is secondary. In the following two scenarios, the first would receive the higher priority.

WAE1-Client datasrc = Site E

The longest prefix has higher priority (same data source). In the following two scenarios, the first would receive the higher priority.

1.2.0.0/16 from DATASOURCE1 = Site C

The more refined (specific) rule has higher priority. In the following two scenarios, the first would receive the higher priority.

1.2.3.0/24 (any datasrc) = Site D

Setting Interface Speed using NetFlow Interface Capacity

). Otherwise, the Packet Analyzer software can only display the throughput of the interface, but cannot show its utilization.

.

To add a new or edit an existing interface, continue to Creating or Editing a NetFlow Interface.

Creating or Editing a NetFlow Interface

.

Note It is normally not necessary to manually create NetFlow interfaces. They should be discovered automatically when the device sends NetFlow packets to the Packet Analyzer.

.

Configuring DSCP Groups

Differentiated services monitoring (DiffServ) is designed to monitor the network traffic usage of Differentiated Services Code Point (DSCP) values. To monitor DSCP, you must configure at least one aggregation profile, and one aggregation groups associated with each profile. This section describes how to set up the DSCP groups.

You can define two or three different groups of traffic, and assign the various DSCP values to each group. Or you can assign one particular value for the first group and give it a name, and then assign all the rest to the other (or default) group and give that a name.

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml

The following tasks help you set up and manage the DSCP groups:

- Creating a DSCP Group

- Editing a DSCP Group

- Deleting a DSCP Group

Creating a DSCP Group

To create a DSCP Group:

.

The DSCP Groups table displays.

.

The DSCP Group Configuration window displays.

.

shows the available formats and associated values.

to save your changes.

Editing a DSCP Group

To edit a DSCP group:

.

The DSCP groups window displays.

.

to cancel.

Deleting a DSCP Group

.

Configuring Application Classification

Packet Analyzer provides two ways of enhancing how your traffic is displayed in the dashboard and reports. Packet Analyzer uses application classification to:

- Expand the number of application’s for which Packet Analyzer can provide down to Layer 7 application details. See Adding More Detail into Dashboard and Application Reports.

- Create custom applications using a list of rules based on HTTP URL or Server /Port definition. This is referred to as the classic application classification model. See Creating Deeper Visibility Into Application Traffic.

You can use one or both of these methods to ensure Packet Analyzer provides the level of traffic detail you need.

Adding More Detail into Dashboard and Application Reports

You can add more detail enable deep packet inspection to see Layer 7 application visibility by using application classification. To understand more about application classification and Layer 7 application visibility, see About Deeper Application Classification.

In order to enable application classification for deep packet inspection in Packet Analyzer:

. Then select the Deep Packet Inspection check box in order to enable your Packet Analyzer dashboards to display key critical details, such as hostname and port, in your traffic captures and reports.

in the Protocol Pack pane to download the latest NBAR2 Protocol Pack (PP). The PP is a single compressed file that contains the rules used for classifying traffic when Deep Packet Inspection is enabled. Packet Analyzer stores the default plus one additional PP.

Step 3 Enter the PP URL to download the PP files.

This URL supports ftp, http[s], scp, and sftp protocols. The User Name and Password fields are used only if the server requires authentication. Alternatively, the username and password can be specified directly within the following URL:

ftp://username:password@hostname/

product links at the CCO software download location at following URL:

Timesaver Use Downloads Home >Products > Cloud and Systems Management > Cisco Security Packet Analyzer Products > Cisco Security Packet Analyzer Software to locate the protocol pack.

.

About Deeper Application Classification

This release of Packet Analyzer supports a more comprehensive, or deep, application classification method. This method allows you to see more details in your monitoring dashboards and packet captures (including application names, interface details, and so on).

To expand the level of application information your Packet Analyzer can monitor and analyze, enable the deeper level of application classification and download application signature updates when you need them.

In addition to providing the application name, this method also brings attributes to simplify application management for both classification and reporting. Application categorization, for example, allows the grouping of similar applications.

When this method is enabled you can view extracted information from applications such as HTTP URL, HTTP User Agent, and SIP URL, for export or classification.

Note Depending on your installation or upgrade method you may need to enable deep packet inspection.

You can use protocol packs to add new and update existing application signatures. Packet Analyzer support of protocol packs allows you to see any new and updated application signatures in Packet Analyzer traffic monitoring. For more details on Protocols Packs, see About Protocol Packs and Application Classification.

You can also use the Packet Analyzer CLI to change the classification status to use the deeper application classification method and check which classification setting your Packet Analyzer is using.

on Cisco.com.

About Protocol Packs and Application Classification

Packet Analyzer uses Cisco’s Network-Based Application Recognition to recognize and classify a wide variety of protocols and applications, including web-based and other difficult-to-classify applications and protocols that use dynamic TCP/User Datagram Protocol (UDP) port assignments. The support of Protocol Packs (PP) allow you to update your application signatures so that dashboard and traffic data provide the most detailed information available. Packet Analyzer Protocol Packs can be found in the CCO software download location. These are the only protocol packs you should use with Packet Analyzer.

You do not need a license to download a protocol pack for Packet Analyzer. For this release, updating the protocol pack may cause a temporary interruption of operation for several seconds, similar to changing the system time.

.

For details, see Adding More Detail into Dashboard and Application Reports.

If you choose not to use the deep application classification method, Packet Analyzer defaults to a less comprehensive classification method that may not include all applications or protocols.

About Packet Analyzer Classic Deep Packet Application Classification

This section covers how you can customize your Packet Analyzer to provide a deeper level of visibility into the application data presented in the dashboard and reports.

Packet Analyzer uses the application ID classification system. When defining applications, you can view and select from a list of protocols and port numbers, and candidate IP addresses and port numbers for the traffic being analyzed. You can also create URL-based application classifications. For an in depth overview of application types, see Understanding Application Traffic.

You can also configure custom applications using the Application Programming Interface (API), also referred to as the North Bound Interface (NBI). This is needed to ensure uniform application classification across a number of Packet Analyzer. See your customer service representative for details on how to get access to the NBI documentation.

To set up classifications use the following tasks:

- Creating Deeper Visibility Into Application Traffic

- Configuring Application Groups

- Filtering Encapsulations

Creating Deeper Visibility Into Application Traffic

This section provides details into the application classification method known as Network Based Application Recognition (NBAR) classic.

You can use Packet Analyzer to monitor pre-determined or custom applications in your Data Center so that your traffic analysis is more focused and therefore optimal.

. This means that you may not have enough insight into the monitoring traffic. After configuring your application or ports, you can gain visibility into those application details on the monitoring screens. Similarly for the URL-based applications, instead of having all web traffic being grouped under the HTTP URL, you can specify a more granular layer of monitoring by using the application and port.

This section describes the following tasks:

- Creating Custom Applications

- Editing Custom Application Classifications

- Adding More Detail into Dashboard and Application Reports

- Deleting an Application Rule

- Understanding Application Traffic

To find out more about Layer 7 visibility and deep packet inspection, see Adding More Detail into Dashboard and Application Reports.

Creating Custom Applications

You can create a custom applications using the list of rules based on HTTP URL, Protocol, or Server IP addresses. If you create a custom application, you can later edit it if you choose. Standard, pre-defined applications cannot be edited.

For details on application types or other options, see Understanding Application Traffic.

To create a new application classification:

..

.

Step 2 Enter an application classification name.

Step 3 (Optional) Enter an application description that gets displayed in the view table. There is a 75 character limit.

Step 4 (Optional) You can skip the Selector value. This is an arbitrary number, unique within an engine-id. It will be automatically assigned if left blank.

Step 5 Select the application classification rule type drop-down menu.

in the Application Classification Rule drop-down menu.

Then select the definition drop-down menu to enter the following required information.

– To choose a Server, Protocol, and Port or Port Range, select the drop-down menu then enter the required information.

.

– To choose a port or port range, enter the required information.

in the Application Classification Rule drop-down menu then enter the required information. (See Understanding URL-Based Application Classification for additional field details.)

Tip You can also add or remove multiple rule definitions to this application classification by clicking the gear icon and selecting Insert new rule or Delete.

to create the new application classification signature.

You can now monitor the new applications using the Interactive Report filter with the application dashboards.

Editing Custom Application Classifications

in the Engine ID column.

To edit an application:

.

.

The Application configuration window displays.

Step 3 Make the desired changes.

Step 4 Do one of the following:

- To accept the changes, click Submit .

- To leave the configuration unchanged, click Cancel .

- To delete the application rule, click Delete .

Deleting an Application Rule

You may want to delete an application rule when you are no longer using it in your network.

.

You cannot delete preconfigured system applications, only custom applications.

Understanding Application Traffic

This section contains information on application types, rules, and other details you may find helpful.

There are two types of application classification rules:

rules defines a a server IP address. For server-based application classification, Packet Analyzer analyzes traffic for the candidate IP addresses and port number or numbers you specify. You can also define port or protocol-based application (for example, based on a TCP port). You can create additional ports to enable Packet Analyzer to handle additional traffic for standard applications. Port ranges for IP are 1-255 for IP. TCP and UDP port ranges are1-65535.

engine ID.

Tip To create Protocol or Server IP Address applications, you can check the Application Configuration table in Analyze > Traffic > Application. To create an HTTP URL-based application, you can analyze the incoming URLs on Analyze > Traffic > URL Hits. NBAR is enabled through CLI and GUI.

Packet Analyzer recognizes an application based on either:

- An application which resides on a specific server IP address—You can filter using an IP address, a protocol, and a port or range of port numbers. After configuring the server information, the monitoring dashboard displays more detailed application information instead of just the unknown grouping.

- A set list of application IDs—The protocol, port number, or port number range, along with the focused inspection of traffic (for example, voice signaling traffic or FTP), heuristics (for example, DCE-RPC or SUN-RPC), or standardized application identifiers exported by Cisco platforms with NetFlow.

. You can configure the application reported as unknown to create custom applications.

- A custom application based on a URL-based HTTP request—You can include URL Host, or URL Path and allows you to gain additional visibility instead of grouping all web traffic HTTP. For details, see Understanding URL-Based Application Classification.

.

Caution There is no limit on the number of URL-based applications that can be created. It is important to consider that these types of applications use large amounts of CPU bandwidth and may impact your performance if too many are defined.

describes the fields on the Applications view page.

Understanding URL-Based Application Classification

URL-based applications are extensions to the list of applications. When the URL in an HTTP request (a URL on any port that is part of the iana-l4:http protocol, or protocol named http under the iana-l4 engine ID) matches the criteria of a URL-based application, the traffic is classified as that protocol. The device interface statistics are collected by regularly (once a minute) polling the ifTable statistics of all interfaces on the managed device.

A URL-based application can be used the same way as any other application. For example, a URL-based application can be used in collections, captures, and reports.

An incoming URL is matched against the criteria of the configured URL-based applications in the order of the selector in ascending order. When a match is found, the remaining URL-based applications are not considered.

A URL consists of the following parts:

- a host (host.domain.com)

- a path (dir_secpa/dir_name)

- an argument/content type

Tip Content-type argument should rarely be used in combination with the other two fields. It can be used alone, for example to identify WAP traffic you could define an application with a content type of *wap.*. In almost all other cases, we recommend you use host and path only.

Example—Creating an URL-Based Application

).

enter:

- the host part is host.domain.com , for example, Cisco.com

- the path part is /go/secpa

- the argument part is null/empty

.

Note The host, path, and argument parts of a URL are matched against the corresponding POSIX regular expressions specified in the application definition. For details on regular expression syntax, refer to the IEEE Std.

Configuring Application Groups

An application group is a set of applications that can be monitored as a whole. The following topics help you set up and manage the application group:

- Creating an Application Group

- Editing or Deleting an Application Group

- Deleting an Application Group

Creating an Application Group

To create an application group:

.

The Application Groups window displays.

and enter the name in the Application Group Name field.

, all applications with that name appear in the list below.

. Applications appear in the Selected Applications box.

to save your changes.

Editing or Deleting an Application Group

To edit or delete an application group:

.

.

Note You can only delete one application group at a time.

Deleting an Application Group

button.

Filtering Encapsulations

Using encapsulation gives you increased flexibility when trying to view different types of application traffic (such as counting or grouping). The encapsulation settings affect how traffic of certain IP-based tunneling protocols are treated.

You can use this software to set up the way you want to view different types of encapsulations in network traffic for the following protocols:

- CAPWAP Data—Control And Provisioning of Wireless Access Points

- ERSPAN—Encapsulated Remote Switched Port Analyzer

- FabricPath

- GRE—IP over GRE tunneling (Generic Routing Encapsulation)

- GTP—GPRS (General Packet Radio Service) Tunneling Protocol

- IP.IP4—IP4 over IP4/IP6

- IP.IP6—IP6 over IP6

- IPESP—IP with Encapsulating Security Payload

- L2TP Data—Layer 2 Tunneling Protocol

- LISP Data—Locator/ID Separation Protocol

- LWAP Data—Lightweight Access Point Protocol

- MPLS—Multiprotocol Label Switching

- OTV—Overlay Transport Virtualization

- PPPoE—Point to Point Protocol over Ethernet

- Segment ID—Rule to match one or more fields with a regular expression.

- SGT—Security Group Tag

- VNTAG—Virtual Network Tag

- VxLAN—Virtual Extensible LAN

To filter encapsulations:

.

to display the filter options,

Step 3 Use the available options to select filtering for the encapsulation traffic reports. Unavailable options will be grayed out.

Step 4 Enter whether you want to include filtering on the site and specify the data source.

Step 5 Select encapsulation options to filter on including the time range.

Step 6 If you add a filter name, the filter is saved below the Interactive Report pane for reuse.

to run the filter and update the Encapsulation Traffic graphs and Top N dashboards based on your filter settings.

.

Setting Up Packet Analyzer Monitoring

This section discusses how to set up monitoring over and above the default monitoring parameters. You can customize these monitoring parameters.

To set up Packet Analyzer monitoring perform these tasks:

- Setting Aggregation Intervals

- Configuring Response Time

- Setting Up Media Monitoring

- Creating RTP Filters

- Configuring URL Collections

- Configuring WAAS Monitored Servers

Setting Aggregation Intervals

Packet Analyzer has short-term and long-term aggregation intervals . Aggregated data is displayed in the dashboards if the query is longer than one day.

The purpose of gathering short term aggregation interval data is for troubleshooting. It has a finer granularity than long term data (by default, the short term aggregation interval for Traffic/Media is one minute, and short term response time interval is five minutes).

The purpose of gathering long term interval data is for trending analysis. The smallest aggregation interval for long term data is one hour (60 minutes).

Caution If you modify the aggregation intervals, existing collected data that is not in the same aggregation interval will be completely removed. Data will then start being collected from the beginning again at the moment the intervals are modified and applied.

Traffic and Media refer to applications, hosts, RTP streams, and voice calls monitoring. Response Time refers only to application response time. Packet Analyzer does not support long term aggregations of data for the following media: conversations, RTP streams, and voice signaling calls monitoring.

To set up aggregation intervals:

.

Step 2 Choose the desired durations for Short Term Interval and Long Term Interval.

check box if you want the Packet Analyzer long term data to contain information only for hosts classified to the user-defined sites. This check box only applies to the long term data; short term always collects all hosts.

Note Enabling the “Collect only hosts from user-define sites” option can significantly speed up report queries, because it excludes unclassified hosts’ statistics from the database.

When you first start the Packet Analyzer, in monitoring windows that show site information, you will see a site named “Unassigned” and with a description of “Unclassified Hosts.” The Unassigned site includes any that do not match the site configurations. By default, long-term storage will include data for all sites, including the Unassigned site. In some cases, you may not want to view long term data of hosts that are not in your network, in which case you would check the check box.

.

for information about short and long-term data retention. This calculation is based on a worst case scenario where tables are full or almost full. It is based on recommended database sizes.

Table 7-5 Data Retention

Short-Term Aggregated Data (Normal)

Short-Term Aggregated Data (Minimum)

Long-Term Aggregated Data (Normal) 1

Long-Term Aggregated Data (Minimum)

All supported platforms

72 hours

14 hours

100 days (with default polling interval)

30 days (with default polling interval)

1.Can depend on how the user configures the LT polling interval. The more frequent polling, the shorter the duration.

1.Can depend on how the user configures the LT polling interval. The more frequent polling, the shorter the duration.

Configuring Response Time

To configure the timing parameters for response time data collections:

.

The Response Time Configuration page displays. The settings you make on this window comprise the time distribution in microseconds for the detailed Response Time data collection.

check box.

. Click Configure Filter to configure a filter if you need to enable your monitor server filter.

.

to save your changes.

Setting Up Media Monitoring

This section covers the following topics:

- Setting up Voice Monitoring

- Setting up Video Monitoring

Setting up Voice Monitoring

You can use the Mean Opinion Score (MOS) to quantify the perceived level of quality you are receiving in your network voice traffic. This allows you to assess the work of codes, or algorithms, which compress audio traffic to save on bandwidth utilization but may result in a drop in quality.

. For more information on viewing the voice data, see Analyzing Media.

Note Voice monitoring features are supported with Cisco IP telephony devices only.

To set up voice monitoring:

.

The Media Monitoring page displays.

check box.

.

Note To report jitter and packet loss for the SCCP protocol, you must enable CDR on Cisco Unified Communications Manager. For more information on Cisco Unified Communications Manager, see the Cisco Unified Communications Manager documentation.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html

to cancel and revert to the previous settings.

Setting up Video Monitoring

.

To set up video monitoring:

.

The Media Monitoring page displays.

check box.

.

Step 4 Accept the default codec streams quality range or modify the values as you prefer.

to cancel and revert to the previous settings.

Note You can enable the video signaling monitoring only when voice signaling monitoring is enabled, and when you disable voice signaling monitoring, video signaling monitoring also gets disabled.

Creating RTP Filters

to apply the change.

To create an RTP filter:

.

.

Step 3 From the drop-down menu, choose the protocol (IP or IPv6).

Step 4 Enter the Source Address, Source Mask, Destination Address, and Destination Mask.

.

Configuring URL Collections

The URL collection listens to traffic on TCP port 80 of a selected data source and collects URLs. Any protocol which has its master port set to TCP port 80 can be used for URL collections. URL collection can be enabled on multiple data sources such as Data Port(s), CEF Data Port(s) and ERSPAN.

).

Note Since the argument is matched against a regular expression, a literal ?id=123 is not a valid regular expression. The ? needs to be escaped with a backslash character, \ , so the actual regular expression needed is \?id=123.

The collection can be configured to collect all parts or it can configured to collect only some of the parts and ignore others.

This section contains the following procedures:

- Enabling a URL Collection

- Changing a URL Collection

- Disabling a URL Collection

Enabling a URL Collection

To enable a URL collection:

.

to return to the entire list of data sources.

Note Depending on which radio button option is collected, the format of the URL varies. For example, the leading http: part is only present if the host part is collected. Keep this variable in mind, when configuring a match only expression.

check box to recycle entries.

Step 4 Select the check box for one of the following:

- Collect complete URL (Host, Path and Arguments)—You might use this if you are a network security engineer and suspect a virus infection may be caused by a website. This information could be used to identify which web page has the virus embedded and how it may have spread. It can also be shared for further analysis to help create a solution to stop the spread.

- Collect Host only (ignore Path and Arguments)—You might use this if your network administrator changed your firewall policies to block certain hosts.

- Collect Host and Path (ignore Arguments)

- Collect Path and Arguments (ignore Host)

- Collect Path only (ignore Host and Arguments)

to cancel.

Changing a URL Collection

To change a URL collection:

.

.

Note Changing any parameters and applying the changes flushes the collected URLs and restarts the collection process.

to cancel.

Disabling a URL Collection

When you disable URL collection monitoring, all collection stops immediately and any collection that was in progress is deleted.

To disable a URL collection:

.

check box.

.

Configuring WAAS Monitored Servers

WAAS monitored servers specify the servers from which WAAS devices export traffic flow data to the Packet Analyzer monitors. To enable WAAS monitoring, you must list the servers to be monitored by Packet Analyzer using the WAAS device's flow monitoring.

until you set up WAAS monitored servers.

To configure a WAAS monitored server:

. The WAAS Servers page displays.

check box if you want Packet Analyzer to compute response time data only for the servers from this list for all data sources, including non-WAAS data sources. All other servers will be ignored in response time monitoring views. This enables you to reduce Packet Analyzer workload and to improve its overall performance.

and enter the server IP address in the Server Address field. You can paste multiple IP addresses here as well.

Tip Specify the WAAS monitored servers from which WAAS devices export traffic flow data to the Packet Analyzer monitors. Do not use the WAE device IP address.

.

Understanding Packet Analyzer Traffic Sources

Before you can monitor data using Packet Analyzer software, you must direct specific traffic flowing through a switch or router to the Packet Analyzer. This appendix explains the various data sources that you can configure for Packet Analyzer.

This appendix contains the following topics:

- Data Source Overview

- Understanding How the Packet Analyzer Uses SPAN

- Understanding How the Packet Analyzer Uses VACLs in Catalyst Switch

- Understanding How the Packet Analyzer Uses NetFlow

- Understanding How the Packet Analyzer Uses WAAS

- Understanding How the Packet Analyzer uses CEF

Data Source Overview

Packet Analyzer uses various data sources to deliver its performance troubleshooting functionality:

.

Table A-1 Methods of Directing Traffic

Method

Usage Notes

Switch SPAN 1

You can direct a set of physical ports, a set of VLANs, or a set of EtherChannels to the Packet Analyzer.

Selecting an EtherChannel as a SPAN source is the same as selecting all physical ports comprising the EtherChannel as the SPAN source.

On some Packet Analyzer platforms, using SPAN allows for Packet Analyzer configuration without having to use the switch.Forwarding SPAN Traffic.

Switch Remote SPAN (RSPAN)1

You can monitor packet streams from remote switches, assuming that all traffic from a remote switch arrives at the local switch on a designated RSPAN VLAN. Use the RSPAN VLAN as the SPAN source for the Packet Analyzer.

Encapsulated Remote Switched Port Analyzer (ERSPAN)1

You can monitor traffic on one or more ports, or one or more VLANs, and send the monitored traffic to one or more destination ports using ERSPAN. ERSPAN sends traffic to a network analyzer such as a SwitchProbe device or other Remote Monitoring (RMON) probe. ERSPAN supports source ports, source VLANs, and destination ports on different routers or switches, which provides remote monitoring of multiple routers or switches across your network. See Forwarding ERSPAN Traffic.

NetFlow Data Export (NDE)

Packet Analyzer analyzes NetFlow from Managed Devices (Routers/Switches) You can monitor NetFlow records directly from remote switches or routers. You must configure the NetFlow packet source to the Packet Analyzer from a local switch or remote router using the device CLI. For received NetFlow traffic, a default site will be created including all interfaces from that device. See Configuring Sites.

SPAN and NetFlow sources can be in effect simultaneously. See Forwarding NetFlow Traffic.

WAAS

You can access Packet Analyzer from within the Central Manager interface. Packet Analyzer integration with WAAS Central Manager provides for easier viewing of Packet Analyzer reports that are directly associated with Application Response Time measurements through the WAN, in both WAAS optimized and non-optimized environments. See Configuring WAAS Monitored Servers.

SNMP

Used as a southbound interface for configuration and data retrieval from switches and routers. Packet Analyzer uses web services as the northbound interface for data objects. The software continues to support baseline manageability features of SNMP such as MIB-2 and IF-TABLE for the Packet Analyzer, and the health status and interface statistics that can be used by external products like Fault and Configuration Management offerings (for example, CiscoWorks LMS and Prime Infrastructure).

Network Tap Device

Applies to Packet Analyzer appliances only. For details, see your appliance installation guide.

CEF

You can enable CEF traffic monitoring on one or more ports and send the monitored CEF traffic to an UCSE Packet Analyzer. See Understanding How the Packet Analyzer Uses VACLs in Catalyst Switch

null

describes the fields in the Packet Analyzer Data Sources window.

summarizes the traffic sources that are used for Packet Analyzer monitoring.

Table A-2 Summary of Traffic Sources for Packet Analyzer Monitoring

Traffic Source

LAN

WAN

Ports

VLANs

Ports

VLANs

VACL capture

Yes

Yes

Yes

N/A

NetFlow Data Export NDE (local)

Yes

Yes

Yes

Yes

NetFlow Data Export NDE (remote)

Yes

Yes

Yes

Yes

SPAN

Yes

Yes

No

No

ERSPAN

Yes

Yes

No

No

Ports and Hardware Details

Cisco Security Packet Analyzer has four dataports. Each dataport can accept one SPAN session. Depending on the managed device operating system (OS) version, the number of SPAN sessions allowed may vary. Most IOS versions support two SPAN sessions. Nexus OS may support more than two SPAN sessions.

Depending on the IOS running on the Supervisor, port names are displayed differently. Newer versions of IOS software display a port name as Gi2/1 to represent a Gigabit port on module 2 port 1. In the VSS, a port name might be displayed as Gi1/2/1 to represent a Gigabit port on switch 1, module2, port 1.

Some Cisco switches do not support SNMP MIB objects that are required by Packet Analyzer when configuring SPAN sessions. On these switches, you can use the switch device CLI command to configure the SPAN session for Packet Analyzer. Alternatively, for the Packet Analyzer only, if the Packet Analyzer managed device supports NetConf interface over SSH, you can configure the Packet Analyzer to use NetConf to configure SPAN sessions on the managed device.

Understanding How the Packet Analyzer Uses SPAN

A switched port analyzer (SPAN) session is an association of a destination port with a set of source ports, configured with parameters that specify the monitored network traffic. You can configure up to two SPAN sessions in a Catalyst 6500 chassis. Newer Cisco IOS images may support more than two SPAN sessions. Consult the Cisco IOS document for the number of SPAN sessions supported per switch or router.

describes the types of SPAN sources and the possible ways to configure them.

Table A-3 SPAN Sources

SPAN Source

Configured with one of the following:

Any set of physical ports

- Packet Analyzer (the GUI)

- Switch CLI

Any EtherChannel

- Packet Analyzer (the GUI)

- Switch CLI

Any set of VLANs configured on the local switch

- Packet Analyzer (the GUI)

- Switch CLI

for a description of the fields on the SPAN Sessions window.

lists the possible SPAN states. The SPAN state displays in parenthesis in the Source - Direction column.

Table A-4 Possible SPAN States

State

Description

Active

SPAN source is valid and packet traffic from the source is copied to the SPAN destination (Packet Analyzer Dataport).

Inactive

Packet traffic from the source is not copied to the SPAN destination (Packet Analyzer Dataport).

Up

Supervisor displays this when packets are forwarded to the Packet Analyzer.

Down

Supervisor displays this when packets are not forwarding to the Packet Analyzer.

Note Due to potentially very high volume of ERSPAN traffic from the source, we recommend that you do not terminate the ERSPAN session on the Packet Analyzer management port. Instead, you should terminate ERSPAN on the switch, and use the switch’s SPAN feature to SPAN the traffic to Packet Analyzer dataports.

Understanding How the Packet Analyzer Uses VACLs in Catalyst Switch

A VLAN access control list can forward traffic from either a WAN interface or VLANs to a dataport on the Packet Analyzer. A VACL provides an alternative to using SPAN; a VACL can provide access control based on Layer 3 addresses for IP and IPX protocols. The unsupported protocols are access controlled through the MAC addresses. A MAC VACL cannot be used to access control IP or IPX addresses.

There are two types of VACLs: one that captures all bridged or routed VLAN packets and another that captures a selected subset of all bridged or routed VLAN packets. Catalyst operating system VACLs can only be used to capture VLAN packets because they are initially routed or bridged into the VLAN on the switch.

A VACL can provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN or, with Release 12.1(13)E or later releases, a WAN interface. Unlike regular Cisco IOS standard or extended ACLs that are configured on router interfaces only and are applied on routed packets only, the VACLs apply to all packets and can be applied to any VLAN or WAN interface. The VACLs are processed in the hardware.

A VACL uses Cisco IOS access control lists (ACLs). A VACL ignores any Cisco IOS ACL fields that are not supported in the hardware. Standard and extended Cisco IOS ACLs are used to classify packets. Classified packets can be subject to a number of features, such as access control (security), encryption, and policy-based routing. Standard and extended Cisco IOS ACLs are only configured on router interfaces and applied on routed packets.

After a VACL is configured on a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VACL. Packets can either enter the VLAN through a switch port or through a router port after being routed. Unlike Cisco IOS ACLs, the VACLs are not defined by direction (input or output).

A VACL contains an ordered list of access control entries (ACEs). Each ACE contains a number of fields that are matched against the contents of a packet. Each field can have an associated bit mask to indicate which bits are relevant. Each ACE is associated with an action that describes what the system should do with the packet when a match occurs. The action is feature dependent. Catalyst 6500 series switches and Cisco 7600 series routers support three types of ACEs in the hardware: IP, IPX, and MAC-Layer traffic. The VACLs that are applied to WAN interfaces support only IP traffic.

When you configure a VACL and apply it to a VLAN, all packets entering the VLAN are checked against this VACL. If you apply a VACL to the VLAN and an ACL to a routed interface in the VLAN, a packet coming into the VLAN is first checked against the VACL and, if permitted, is then checked against the input ACL before it is handled by the routed interface. When the packet is routed to another VLAN, it is first checked against the output ACL applied to the routed interface and, if permitted, the VACL configured for the destination VLAN is applied. If a VACL is configured for a packet type and a packet of that type does not match the VACL, the default action is deny.

When configuring VACLs, note the following:

- VACLs and context-based access control (CBAC) cannot be configured on the same interface.

- TCP Intercepts and Reflexive ACLs take precedence over a VACL action on the same interface.

- Internet Group Management Protocol (IGMP) packets are not checked against VACLs.

Note You cannot set up VACL using the Packet Analyzer interface.

For details on how to configure a VACL with Cisco IOS software, see Cisco.com.

For details on how to configure a VACL on a WAN interface and on a LAN VLAN, see Forwarding VACL Traffic.

Understanding How the Packet Analyzer Uses NetFlow

The Packet Analyzer uses NetFlow as a format for the ongoing streaming of aggregated data, based on the configured set of descriptors or queries of the data attributes in Packet Analyzer. NetFlow Data Export (NetFlow) is a remote device that allows you to monitor port traffic on the Packet Analyzer; the Packet Analyzer can collect NetFlow from local or remote switches or routers for traffic analysis.

To use an NetFlow data source for the Packet Analyzer, you must configure the remote device to export the NetFlow packets. The default UDP port is 3000, but you can configure it from the Packet Analyzer CLI as follows:

root@nam3-61.cisco.com# netflow input port ?

<port> - input NetFlow port number

The distinguishing feature of the NetFlow v9 format, which is the basis for an IETF standard, is that it is template-based. Templates provide an extensible design to the record format, a feature that must allow future enhancements to NetFlow services without requiring concurrent changes to the basic flow-record format.

For more detailed information about Packet Analyzer and NetFlow, see Forwarding NetFlow Traffic.

(contact your Cisco account representative if you need to refer to this document).

Understanding NetFlow Interfaces

To use a device as an NetFlow packet data source for the Packet Analyzer, you must configure the device itself to export NetFlow packets to UDP port 3000 on the Packet Analyzer. You might need to configure the device itself on a per-interface basis. A NetFlow packet device is identified by its IP address. In the Packet Analyzer, the default UDP port of 3000 can be changed with a Packet Analyzer CLI command (see Configuring NetFlow on Devices).

You can define additional NetFlow packet devices by specifying the IP addresses and (optionally) the community strings. Community strings are used to upload convenient text strings for interfaces on the managed devices that are monitored in NetFlow records.

), you can view information for any selected interface on the device. This page will display the interface utilization or throughput over time, as well as show the top Applications, Hosts, and DSCP groups in both the input and output directions for the interface.

Understanding NetFlow Flow Records

A NetFlow packet contains multiple flow records. Each flow record has two fields:

- Input SNMP ifIndex

- Output SNMP ifIndex

Note This information might not be available because of NetFlow feature incompatibility with your Cisco IOS version, or because of a NetFlow flow-mask configuration.

direction of the interface. As a result, the input SNMP ifIndex field in the flow record has the ifIndex of the interface on which NetFlow was turned on. Sample NetFlow Network, Figure A-1, shows a sample network configuration with a NetFlow router.

Figure A-1 Sample NetFlow Network

lists the reported flows if NetFlow is enabled on interface a.

Table A-5 Reporting Flow Records

Input Interface

Output Interface

Are Flows Reported?

a

b

Yes

a

c

Yes

b

c

No

b

a

No

c

a

No

c

b

No

Managing NetFlow Data Sources

A data source entry must exist on Packet Analyzer in order for it to accept NetFlow records from an external device. Data source entries may be created manually using the Packet Analyzer web GUI or the CLI. When manually creating a data source, you may specify any name you want for the data source.

For convenience, manual creation of NetFlow data sources is not necessary. There is an “autocreate” feature which is enabled by default. With the autocreate feature, a new data source will automatically be created for each device which sends NetFlow packet traffic to the Packet Analyzer when the first packet is received.

is the Engine-ID that the device populates in the packets (part of the NetFlow Data Export standard). An example might be “NetFlow-10.10.0.1-ID-12” for device 10.10.0.1 sending NetFlow packets with the Engine ID field set to 12. You can edit these autocreated data sources and change the name if you want to, as well as optionally specifying SNMP credentials for the device, as described later in this guide.

Understanding How the Packet Analyzer Uses WAAS

Cisco Wide Area Application Services (WAAS) software optimizes the performance of TCP-based applications operating in a wide area network (WAN) environment and preserves and strengthens branch security. The WAAS solution consists of a set of devices called Wide Area Application Engines (WAEs) that work together to optimize WAN traffic over your network.

When client and server applications attempt to communicate with each other, the network devices intercepts and redirects this traffic to the WAEs to act on behalf of the client application and the destination server.

WAEs provide information about packet streams traversing through both LAN and WAN interfaces of WAAS WAEs. Traffic of interest can include specific servers and types of transaction being exported. Packet Analyzer processes the data exported from the WAAS and performs application response time and other metrics calculations and enters the data into reports you set up.

The WAEs examine the traffic and using built-in application policies to determine whether to optimize the traffic or allow it to pass through your network not optimized.

You can use the WAAS Central Manager GUI to centrally configure and monitor the WAEs and application policies in your network. You can also use the WAAS Central Manager GUI to create new application policies so that the WAAS system will optimize custom applications and less common applications. Packet Analyzer is accessible from within the Central Manager interface. The Cisco Packet Analyzer integration with WAAS Central Manager provides for easier viewing of Packet Analyzer reports that are directly associated with Application Response Time measurements through the WAN, in both WAAS optimized and non-optimized environments. See Using the WAAS Central Manager.

For more information about WAAS data sources and managing WAAS devices, see Understanding WAAS.

Understanding How the Packet Analyzer uses CEF

Packet Analyzer uses CEF to monitor all IP traffic on a router interface. For Cisco 2900 Series or Cisco 3900 Series Integrated Services Router Generation 2 (Cisco ISR G2) support Packet Analyzer, you can configure to monitor CEF traffic on many data ports to copy and forward all IP traffic to Packet Analyzer monitoring interface on a Cisco ISR G2.

The Cisco Unified Computing Server type E (Cisco UCSE) can host Packet Analyzer and other services. See UCSE product introduction for more details:

Understanding UCSE Physical Interfaces

Internal PCIE/MGF ports are named as GE0/GE1 and the front panel ports are named as GE2/GE3.

In CIMC GUI, PCIE/MGF ports are named as GE1/GE2 and front panel ports are named as GE3/GE4.

1. Packet Analyzer can analyze Ethernet VLAN traffic from the following sources: Ethernet, Fast Ethernet, Gigabit Ethernet, trunk port, or Fast EtherChannel SPAN, RSPAN, or ERSPAN source port.

Configuring Packet Analyzer Security

The Cisco Packet Analyzer software provides a number of security features with user-customizable parameters. This appendix provides an overview of the security features, and describes the parameters that can be customized.

This section consists of the following security features:

- Idle Timeout

- SSL/TLS Security

- SSH Security

Idle Timeout

To prevent unauthorized access to the Packet Analyzer GUI or CLI, an idle/inactivity timeout is supported.

On the CLI, the idle timeout is disabled by default. An idle timeout can be configured using the following command:

command.

SSL/TLS Security

The Packet Analyzer GUI supports HTTPS for secured connections. The HTTPS server can be enabled using the following command:

Configuring a Self-Signed Certificate

Packet Analyzer is configured with a built-in self-signed certificate, by default. If you intend to continue using a self-signed certificate, we recommend that you generate a unique self-signed certificate using the following command:

The lifetime defaults to 730 days (2 years), but you can specify a different lifetime, if desired. This command will prompt you for organizational details that are customarily included in SSL/TLS certificates to help identify the server. You must ensure that the "Common Name" field matches whatever name you use to access your Packet Analyzer, as this is the field a web browser uses to verify that an SSL/TLS certificate properly matches the host that is presenting it.

- If you access the Packet Analyzer through an IP address (For example, https://10.0.0.10/, enter just the IP address "10.0.0.10").

- If you access the Packet Analyzer through a hostname (For example, https://secpa.cisco.com/, enter just the hostname "secpa.cisco.com").

The first time you connect to the Packet Analyzer using a particular web browser, it must show a warning that the certificate of Packet Analyzer is untrusted (because it is self-signed, rather than signed by a trusted Certificate Authority). You need to click the warning each time your browser is restarted, unless you save it to your local certificate store. The procedure for saving the certificate depends on your browser and/or operating system.

Note Ensure that the Common Name of your certificate is set correctly, before saving the certificate.

- Some browsers (such as Mozilla Firefox) maintain their own certificate store, and adding a new certificate is as simple as selecting "Add Exception", and then making sure that the "Permanently store this exception" option is checked.

- Other browsers (such as Microsoft Internet Explorer and Google Chrome) use the operating system's certificate store. On Windows, one possible procedure is:

– Run the show certificate command from the Packet Analyzer CLI and copy the entire certificate text (including the "BEGIN CERTIFICATE" and "END CERTIFICATE" markers) into a .cer file (for example, "secpa-cert.cer").

– Run the "certmgr.msc" program (you may have to enter the Win+R key sequence to access the Run menu). Right-click the "Trusted Root Certification Authorities" item, select All Tasks > Import to start the Certificate Import wizard, and then import the certificate file (for example, "secpa-cert.cer").

– Your browser should now show the Packet Analyzer as a trusted host. In some cases, you may need to restart the browser to recognize the new certificate.

- For other browsers or operating systems, consult your local documentation.

Configuring a CA-Signed Certificate

For optimal security, it is recommended that the Packet Analyzer must be configured with a certificate signed by a trusted Certificate Authority (CA). This configuration will avoid the browser warning messages without the hassle of installing a self-signed certificate on each individual machine used to access the Packet Analyzer. Many larger enterprises have an in-house CA that can sign certificates for internal use. There are also external CAs that can sign a certificate, typically for a fee.

To configure the Packet Analyzer to use a CA-signed certificate, first issue the following CLI command to generate a certificate request, which will be output to the screen:

Copy and paste the text of the certificate request and submit it to the CA for signing. Once the CA-signed certificate is received, use the following CLI command and paste the signed certificate text into the terminal window:

The Packet Analyzer will read the text and install the certificate.

Configuring SSL/TLS Parameters

The Packet Analyzer is configured for a balance between security and usability in the enterprise, by default. However, some users have particular requirements for the SSL/TLS ciphersuites and protocol versions that must be allowed by HTTPS servers on their networks, so the Packet Analyzer also offers the ability to customize the parameters.

Configuring SSL/TLS Ciphersuites

To configure the ciphersuites that the Packet Analyzer HTTPS server will accept, use this command:

argument, refer to the following links:

argument using the Packet Analyzer's particular version of OpenSSL, use this command:

represents.

To examine or verify the currently-configured ciphersuite specification, use this command:

Configuring SSL/TLS Protocols

To configure the SSL/TLS protocol versions that the Packet Analyzer HTTPS server will accept, use this command:

argument, refer to th following link:

TLS v1.0, v.1.1, and v1.2 are enabled by default, while SSLv2 and SSLv3 are disabled. Note that you must not attempt to enable SSLv2 or SSLv3 protocols, as these versions of SSL have severe security flaws, and the industry as a whole is transitioning towards removing support for these protocols entirely.

). However, some older browser versions do not enable support for the more recent versions of TLS, so you may have to visit an advanced settings dialog or similar to enable such TLS versions explicitly. Make sure that enabling the newer TLS versions may expose incompatibilities with other web servers (particularly older versions) that may be running in your environment.

SSH Security

The Packet Analyzer CLI supports SSH for secured connections. The SSH server can be enabled using the following command:

Configuring SSH Authorized Keys

In addition to logging into the CLI using password, the Packet Analyzer also supports logins using an SSH private key. To enable this functionality, a list of authorized keys must first be imported using the command:

is "root" (for password-less CLI access) or a valid web username (for password-less access to capture or report files via SFTP). The format of this file is the standard OpenSSH authorized_keys file described in the "AUTHORIZED_KEYS FILE FORMAT" section in the following URL:

Note that SSH key options, if present, are removed when a key is imported.

The authorized keys for a given user can be displayed using the command:

displays the full contents.

Configuring SSH Ciphers and MACs

The Packet Analyzer is configured for a balance between security and usability in the enterprise, by default. However, some users have particular requirements for the ciphers and MACs that must be allowed by SSH servers on their networks, so the Packet Analyzer also offers the ability to customize the parameters.

To configure the ciphers that the Packet Analyzer SSH server will accept, use this command:

is simply a comma-separated list of the ciphers to be allowed, in order of preference (highest first).

The Packet Analyzer is configured to allow only SSH connections using AES CTR mode ciphers, by default. To examine or verify the currently-configured ciphers directive, or to see the list of available cipher options, use this command:

To configure the MACs that the Packet Analyzer SSH server will accept, use the following analogous commands:. .

The Packet Analyzer is configured to allow only SSH connections using HMAC-SHA1 and HMAC-RIPEMD160 MACs, by default.

Secure File Transfers

The Packet Analyzer has many commands that involve transferring files between the Packet Analyzer and external servers. A few examples of such commands are:

- Packet Analyzer software image upgrades: upgrade <image_url>

- Packet Analyzer software patch installation: patch <patch_url>

- Packet Analyzer configuration backup to network location: config upload <url>

- Packet Analyzer configuration restore from network location: config network <url>

In all these cases, the URL provided is allowed to utilize an insecure plain text protocol like FTP or HTTP, if desired. However, for optimal security, using a secure protocol is recommended. The secure protocols supported by the Packet Analyzer are:

- SCP (Secure Copy) - relies on SSH for secure transport.

- SFTP (Secure File Transfer Protocol) - relies on SSH for secure transport.

- HTTPS (Hypertext Transfer Protocol Secure) - relies on SSL/TLS for secure transport.

Here are some examples of commands that perform file transfers:

- upgrade https://files.cisco.com/upgrade_image.bin.gz

- patch scp://user:pass@ssh-server.cisco.com/patch.rpm

- config upload sftp:// user:pass@ssh-server.cisco.com/~/

Protecting Against Man-in-the-Middle Attacks

A man-in-the-middle (MITM) attack is one in which a user unknowingly communicates with an impostor server, either because the impostor is positioned to intercept traffic en route to the legitimate server, or because the legitimate server is offline and the impostor has taken its place. To protect against such attacks, we recommend that the Packet Analyzer be configured such that it can verify that an external server it is communicating with is legitimate.

SSH Known Hosts

file is a list of the public keys of SSH servers that the Packet Analyzer must consider "known" (legitimate). A known_hosts file can be imported using the command:

The format of this file is the standard OpenSSH known_hosts file described in the "SSH_KNOWN_HOSTS FILE FORMAT" section in the following URL:

After importing a known_hosts file, enable host key verification to ensure that only connections to known hosts are successful (connections to unknown hosts fail with an error message). Host key verification can be enabled using the command:

SSL/TLS CA Certificates

For SSL/TLS, the CA certificates file contains the list of Certificate Authority (CA) root certificates that the Packet Analyzer must trust. This file must contain PEM-formatted X.509 certificates (the format used by the cURL tool). An example of such a file can be found at the following URL:

If you have HTTPS servers with self-signed certificates that the Packet Analyzer must consider trusted, simply include the self-signed certificate in this file.

A CA certificates file can be imported using the command:

After importing CA certificates file, enable CA certificate verification to ensure that only connections to hosts with valid signed certificates are successful (connections to hosts with invalid certificates fail with an error message). The CA certificate verification can be enabled using the command:

Software Image Upgrades

command displays MD5 and SHA-512 checksums for the downloaded image file prior to installation. The checksums are useful for ensuring that the image was not corrupted during download, but in the event that the image was downloaded to the Packet Analyzer without CA certificate or SSH host key verification enabled, the checksums can also be used to verify the authenticity of the image by comparing them to the checksums published on Cisco.com for the given software image.

Understanding Packet Analyzer Behavior Reference

This appendix includes details on how Cisco Security Packet Analyzer works including how to navigate and use the control elements in the user interface.

This section includes the following topics:

- Menu Bar

- Filters

- Displaying Detailed Views

- Accessing Context Menus

- Performing a Quick Capture

- Determining How to Use Sites to View Data

- Filtering Traffic for Viewing on the Dashboards

- Switching Chart Formats Using the Chart View / Table View

- Accessing Other Tasks Using Mouse-Over for Details

- Changing the Time Interval Using Zoom/Pan Charts

- Using Sort Grid to Change Sort Order

- Displaying Bits or Bytes or Packets in Charts

- Statistics

- Context-Sensitive Online Help

- Feedback

Menu Bar

.

Table C-1 Summary of Menu Tasks

Menu Name

Description

Brings you to the Traffic Summary Dashboard (Monitor > Overview > Traffic Summary).

View summary dashboards with network traffic, application performance, site performance, and alarms information at a glance.

See various views for traffic over a time period, WAN optimization, response time, managed device, and media functions.

Configure multiple sessions for capturing, filtering, and decoding packet data, manage the data in local or remote storage, and display the contents of the packets.

Perform setup options needed to access Packet Analyzer features.

Set dashboard preferences, perform user and system administration tasks, and generate diagnostic information for obtaining technical assistance.

Filters

You can use the Filter feature to display specific information on the Packet Analyzer interface. The Filter icon is provided wherever the data is displayed in a tabular format. The following types of filters are available:

- Quick Filter

- Advanced Filter

Quick Filter

This filter allows you to narrow down the data inside a table by applying a filter to a specific table column or columns. To apply different operators, use the Advanced Filter option.

from the Filter drop-down menu.

To clear the Quick Filter, click the Filter icon.

Advanced Filter

This filter allows you to narrow down the data in a table by applying a filter using multiple operators such as Does not contain, Does not equal, Ends with, Is empty, and so on. For example, you can choose the filter pattern by table column names and operator from the drop-down menu. In addition, you must enter filter criteria based on the data available in the Packet Analyzer database.

from the Filter drop-down list.

To clear the Advanced Filter, click the Filter icon.

Displaying Detailed Views

. For an example of the Applications submenu see Figure C-1.

Accessing Context Menus

On most charts that appear on the dashboards (except for pie charts), you can left-click on a colored bar of data to get a context menu, with which you can get more detailed information about that item. See Figure C-1.

Figure C-1 Context Menu Showing Application Submenus

).

The menu items above the separator line are specific to the selected element of the Top N chart. The items below the separator line are not specific to the selected element, but apply to the Top N chart. The selections with no icons display in the current page. Selections with icons open in a separate page.

Performing a Quick Capture

From the Context menu of many of the bar charts that show Applications or Hosts or VLANs. you can start a Capture. For example, when you click on an Application in a bar chart (as in Figure C-1) and choose Capture, the following is done automatically:

- A memory-based capture session is created

- A software filter is created using that application

- The capture session is started

- The decode window pops open and you can immediately see packets being captured.

Note Quick Capture does not use site definition/filter.

From both the selectors in the upper left of the dashboards and from the item the user clicks on in the barchart, the following are carried into the context for the capture session:

- Application

- VLAN

- Host

- Data Source (if it is a DATA PORT)

If you open up the associated Capture Session and its associated Software Filter, the above settings will be shown.

Determining How to Use Sites to View Data

is an optional collection of hosts, or network endpoints, partitioned into views that help you monitor traffic and troubleshoot problems (see Configuring Sites for more detailed information).

and view data relevant to that site only. In some cases, you can select both a Client Site and a Server Site to view data pertaining to interaction between hosts at different sites.

Filtering Traffic for Viewing on the Dashboards

data and the Analyze windows to view data over time.

button to change the parameters of the information displayed in the charts. An asterisk represents required fields.

button and enter the Layer 1 VLAN options on which you want to filter. You can select multiple values and additional layers.

.

You may need to enter the time range filter several times before seeing the data that you need. The default filter time range is for the last hour.

The reporting time interval selection changes depends upon both the dashboard you are viewing and your Packet Analyzer platform.

.

.

The software supports up to five saved filters. Saved reports display at the bottom of the Interactive Report panel. You can also edit or delete filters after creating them using the icons in the saved filter dialog box.

Filtering Data Using Global Search

You can use the global search filter to limit your overall view to specific host data. The global search tool appears in the top-right corner of the user interface. Enter the host IP address in the global search tool. The host search dashboard appears. On the Top N Applications chart, you can left-click a colored bar to get the context menu, and choose Analyze Host Traffic to see the host dashboard and analyze the host traffic for the selected application using Over Time chart.

Step 1 From your Monitor or Analyze dashboard enter your IPv4, IPv6, and Layer 2 traffic MAC addresses. You may also search using hostnames if you have enabled hostname (DNS lookup) in Packet Analyzer.

Specified host filters are also in effect for context menu charts. For example, if you specify a hostname filter in Monitor > Response Time Summary, the dashboard refreshes with only data specific to this host (including the IP address and site, if applicable). You can hover over table data for instant details. drill down menus also reflect this host’s data.

Step 2 To change the time range, select one of the default ranges or create a custom range.

Switching Chart Formats Using the Chart View / Table View

Using the Chart view lets you see an overview of the data in an integrated manner, and can show you trending information. To get the exact value of any data in the graphical view, hover over a data point to see the tool tip. The chart view may be To toggle between the two views, use the Chart and Table icons at the bottom of the panel:

Accessing Other Tasks Using Mouse-Over for Details

When in Chart view, you can mouse over the chart to get more detailed information about what occurred at a specific time.

Many of the line charts in Packet Analyzer are dual-axis, meaning there is one metric shown on the left axis of the chart and another metric shown on the right axis of the chart.

For example, in the DCSP Group Traffic chart, Megabits per second is shown on the left axis, and Packets per second is shown on the right axis.

Changing the Time Interval Using Zoom/Pan Charts

For many charts, you can drag the beginning or end to change the time interval, as shown below.

The time interval change on the zoom/pan chart affects the data presented in the charts in the bottom of the window. The zoom/pan time interval also affects the drill down navigations; if the zoom/pan interval is modified, the context menu drill downs from that dashboard will use the zoom/pan time interval.

Note In a bar chart which you can zoom/pan, each block represents data collected during the previous interval (the time stamp displayed at the bottom of each block is the end of the time range). Therefore, you may have to drag the zoom/pan one block further than expected to get the desired data to populate in the charts in the bottom of the window.

Using Sort Grid to Change Sort Order

When looking at information in Grid view, you can sort the information by clicking the heading of any column. Click it again to sort in reverse order.

Displaying Bits or Bytes or Packets in Charts

.

.

Statistics

The Statistics legend gives you the minimum, maximum, and average statistics of the data. This will display the initial data retrieved for the selector.

Context-Sensitive Online Help

link on the top-right corner of the Packet Analyzer interface to bring you to the Help page for that particular window of the GUI.

If available, the Help link appears on the top-right corner of each page; some pages also have a blue “i”, which provides help for that specific subject.

On some fields, hovering over the field displays tip information.

Feedback

Click the feedback link on the top-right corner of the Packet Analyzer interface to view the email id to which you can send your feedback. You can click the Product Info button to view the Cisco Security Packet Analyzer (Packet Analyzer) Products page.

GUI Field Descriptions

This appendix describes critical field descriptions for the following windows. Not all fields are described as some are self-explanatory and others have tips that appear in the user interface.

- Setup User Interface Windows

- Monitor User Interface Windows

- Capture User Interface Windows

- Administration User Interface Windows

- Report Descriptions

Setup User Interface Windows

This section describes the field descriptions for the following dialog boxes:

- Create SPAN Session Dialog Box

- Packet Analyzer Data Sources

- Edit SPAN Session Dialog Box

- SNMP Credential Options in Packet Analyzer Data Sources Window

- Device System Information Dialog Box

- Alarm Configuration Window

- Threshold Configuration

- Host Alarm Thresholds

- Conversation Alarm Thresholds

- Application Alarm Thresholds

- Response Time Thresholds

- DSCP Alarm Thresholds

- RTP Streams Thresholds

- Voice Signaling Thresholds

- NetFlow Interface Alarm Thresholds

- Router/Managed Device System Information

- Switch Device Information

- NBAR Interface Details

- Site Configuration

- Subnet Detection

- Sites Window

- Add NetFlow Interface Capacity

- Create or Edit Applications

- DSCP Group Setup Dialog Box

- Applications

- URL-Based Applications

- Response Time Configuration Window

- Media Monitor Setup Window

- URL Collection Configuration Dialog Box

- NetFlow Export Template Window

- Add Managed Device

Create SPAN Session Dialog Box

describes the critical fields on the Create SPAN Session dialog box. Depending on Packet Analyzer platform and SPAN configuration options such as SNMP, NetConf, or RISE the fields will vary in the Create SPAN Session Dialog Box.

Table D-1 Create SPAN Session Dialog Box

Field

Description

Managed Device

Managed device IP address and VDC on the managed device.

Session ID

ID of the SPAN session.

Span Session Options

- Extended: Allows for IP extended input ACLs to receive a copy of a dropped packed on a destination port even if the actual incoming packet is dropped.

- Multicast Best Effort:  Multicast packets are delivered to a group using best - effort reliability, just like IPv6 unicast packets.

- Sampling: Collects NetFlow statistics for a subset of incoming (ingress) IPv4 traffic on the interface, selecting only one out of "N" sequential packets, where "N" is a configurable parameter.

- MTU Truncation: Maximum bytes allowed for each replicated packet in a SPAN session

- Rate Limit: Sets Committed Access Rate and Distributed Committed Access Rates for the interface's bandwidth

SPAN Type

- Switch Port

- VLAN

- EtherChannel

- RSPAN VLAN

You can have only one RSPAN VLAN source per SPAN session.

SPAN Destination Interface

The Packet Analyzer interface to which you want to send data.

Switch Module

Module of the switch

SPAN Traffic Direction

Direction of the SPAN traffic.

Available and Selected Sources

SPAN sources available for the selected SPAN type.

Packet Analyzer Data Sources Dialog Box

describes the critical fields on the Packet Analyzer Data Sources dialog box.

Table D-2 Packet Analyzer Data Sources

Field

Description

Device

DATA PORT if it is a local physical port or the IP address of the device that is sending Packet Analyzer data.

Type

The source of traffic for the Packet Analyzer.

DATA PORT if it is a local physical port.

WAAS, ERSPAN, or NETFLOW, if a data stream exported from the router or switch or WAE device.

Activity

Enter the activity details.

Status

ACTIVE or INACTIVE.

Data Source

Choose the data source.

Data Source Details

Physical Port or information about the data source being Enabled or Disabled.

Edit SPAN Session Dialog Box

describes the critical fields on the Edit SPAN Session dialog box. Depending on Packet Analyzer platform and SPAN configuration options such as SNMP, NetConf, or RISE the fields will vary in the Create SPAN Session Dialog Box.

Table D-3 Edit SPAN Session Dialog Box

Field

Description

Managed Device

Managed device IP address and VDC on the managed device.

Session ID

ID of the SPAN session.

Span Session Options

- Extended: Allows for IP extended input ACLs to receive a copy of a dropped packed on a destination port even if the actual incoming packet is dropped.

- Multicast Best Effort:  Multicast packets are delivered to a group using best - effort reliability, just like IPv6 unicast packets.

- Sampling: Collects NetFlow statistics for a subset of incoming (ingress) IPv4 traffic on the interface, selecting only one out of "N" sequential packets, where "N" is a configurable parameter.

- MTU Truncation: Maximum bytes allowed for each replicated packet in a SPAN session

- Rate Limit: Sets Committed Access Rate and Distributed Committed Access Rates for the interface's bandwidth

SPAN Type

- Switch Port

- VLAN

- EtherChannel

- RSPAN VLAN

You can have only one RSPAN VLAN source per SPAN session.

SPAN Destination Interface

The Packet Analyzer interface to which you want to send data.

SPAN Traffic Direction

Direction of the SPAN traffic.

Available and Selected Sources

SPAN sources available for the selected SPAN type.

SNMP Credential Options in Packet Analyzer Data Sources Window

describes the options on the Packet Analyzer Data Sources window for SNMP Credentials.

Table D-4 SNMP Credential Options in Packet Analyzer Data Sources Window

Field

Description

Mode: No Auth, No Priv

SNMP will be used in a mode with no authentication and no privacy.

Mode: Auth, No Priv

SNMP will be used in a mode with authentication, but no privacy.

Mode: Auth and Priv

SNMP will be used in a mode with both authentication and privacy.

User Name

Enter a username, which will match the username configured on the device.

Auth Password

Enter the authentication password associated with the username that was configured on the device. Verify the password.

Auth Algorithm

Choose the authentication standard which is configured on the device (MD5 or SHA-1).

Privacy Password

Enter the privacy password, which is configured on the device. Verify the password.

Privacy Algorithm

Enter the privacy algorithm, which is configured on the device (AES or DES).

Device System Information Dialog Box

describes the critical fields on the Device System Information dialog box.

Table D-5 Device System Information Dialog Box

Field

Description

Hardware

A textual description which should contain the manufacturer's name for the physical entity and be set to a distinct value for each version or model of the physical entity.

Device Software Version

The current software version running on the device.

System Uptime

Total time the device has been running since the last reboot.

SNMP read from device

SNMP read test result. For the local device only.

Alarm Configuration Window

describes the critical fields on the Alarm Configuration Window.

Table D-6 Alarm Configuration Window

Field

Description

Name

Name given to the alarm at setup.

E-mail

.

Trap

.

Trigger Capture

.

Syslog Remote

.

Status

means that the trap configured for that alarm action has been deleted.

means the Alarm action was successfully created.

Threshold Configuration Window

describes the critical fields on the Threshold Configuration window.

Table D-7 Threshold Configuration

Field

Description

Type

You can configure eight types of thresholds.

Application

Choose an application from the list.

Site

Choose a site from the list.

Host

Choose a host from the list.

Severity

). You can choose to view High, Low, or High and Low alarms.

Action

Rising action and Falling action (if configured). Alarms are predefined conditions based on a rising data threshold, a falling data threshold, or both.

Status

).

Add Metrics (button)

Adds another row.

Delete (button)

Removes that Metrics row.

Host Alarm Thresholds Window

describes the critical fields on the Hold Alarm Threshold window.

Table D-8 Host Alarm Thresholds

Field

Description

Name

Enter the name.

Site

Choose a site from the list. See Configuring Sites for information on setting up a site.

Host

Choose a host from the list.

You can enter the name of the host if the drop-down list does not contain the desired host.

Application

Choose an application from the list. You can enter the first few characters to narrow the selection in the drop-down list.

DSCP

Choose a DSCP value from the list. You can enter the first few characters to narrow the selection in the drop-down list.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

From the drop-down lists, choose a Rising action and a Falling action (optional). During threshold creation, by default, the falling action is the same as rising action. See Viewing Alarm Actions for information on setting up alarm actions.

Host Metrics

(per second)

Choose the type of metric from the list, and then enter a value for a Rising threshold and a Falling threshold.

Conversation Alarm Thresholds Window

describes the critical fields on the Conversation Alarm Thresholds window.

Table D-9 Conversation Alarm Thresholds

Field

Description

Name

Enter the name.

Application

Choose an application from the list. You can start typing the first few characters to narrow the list.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Source Site/Host

. See Configuring Sites for information on setting up a site.

Destination Site/Host

. See Configuring Sites for information on setting up a site.

Actions

From the lists, choose a Rising action and a Falling action (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Conversation Metrics (per second)

Choose from one of the six metrics, and then enter a Rising threshold and a Falling threshold.

Application Alarm Thresholds Configuration Window

describes the critical fields on the Application Alarm Thresholds Configuration window.

Table D-10 Application Alarm Thresholds

Field

Description

Name

Enter the name.

Site

Choose a site from the list. See Configuring Sites for information on setting up a site.

Application

Choose an application from the list. You can start typing the first few characters to narrow the list.

DSCP

Choose a DSCP value 0-63, or Any.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

From the lists, choose a Rising action and a Falling action (optional). See Configuring Alarm Actions for information on setting up alarm actions.

Application Metrics (per second)

Choose Bits or Bytes, and then enter a Rising threshold and a Falling threshold.

Response Time Alarm Threshold Configuration Window

describes the critical fields on the Response Time Alarm Threshold Configuration window.

Table D-11 Response Time Thresholds

Field

Description

Name

Enter the name.

Application

Choose an application from the list. You can start typing the first few characters to narrow the list.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Client Site/Host

Make a selection from the lists. See Configuring Sites for information on setting up a site.

Server Site/Host

Make a selection from the lists, or leave as “Any.” See Configuring Sites for information on setting up a site.

Actions

From the lists, choose a Rising action and a Falling action (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Response Time Metrics

Choose a metric from the list, and then enter a Rising threshold and a Falling threshold. For the Packets and Bytes-related metrics, the entry is per second. For the time-related metrics, the unit is per microseconds (u).

DSCP Alarm Threshold Configuration Window

describes the critical fields on the DSCP Alarm Threshold Configuration window.

Table D-12 DSCP Alarm Thresholds

Field

Description

Name

Give the DSCP Alarm Threshold a name.

Site

Choose a site from the list. See Configuring Sites for information on setting up a site.

DSCP

Choose a DSCP value from the list.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

From the drop-down lists, choose a Rising action and a Falling action (optional).

DSCP Metrics (per second)

Choose one of the metric types from the list, and then enter a Rising threshold and a Falling threshold.

RTP Streams Threshold Configuration Window

describes the critical fields on the RTP Threshold Configuration window.

Table D-13 RTP Streams Thresholds

Field

Description

Name

Enter the name.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Codec

Choose a Codec from the list.

Source Site/Host

Make a selection from the drop-down lists, or leave as “Any.” See Configuring Sites for information on setting up a site.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

From the drop-down lists, choose a Rising action and a Falling action (optional). See Viewing Alarm Actions for information on setting up alarm actions.

RTP Stream Metrics

Choose a metric from the list:

- Jitter: Variation of packet arrival time compare to expected arrival time.

- Adjusted packet loss percent: Percent of packet loss which includes packets actually lost and packets that arrived beyond the expected buffering capability of the endpoint.

- Actual packet loss percent: Percent of packets that Packet Analyzer has never seen.

- MOS: Mean opinion score that is composed of both jitter and adjusted packet loss.

- Concealment seconds: Number of seconds in which Packet Analyzer detected packets lost.

- Severe concealment seconds: Number of seconds in which Packet Analyzer detected packets lost of more than 5%.

Enter a Rising threshold and a Falling threshold.

Voice Signaling Threshold Configuration Window

describes the critical fields on the Voice Signaling Threshold Configuration window.

Table D-14 Voice Signaling Thresholds

Field

Description

Name

Enter the name.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

Choose a Rising action and a Falling action from the lists (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Voice Signaling Metrics

Choose Jitter to enable an alarm when the software detects jitter to be more than the value set here.

Check Packet Loss % to enable an alarm when the software detects Packet Loss percentage to be outside of the values you entered.

NetFlow Interface Threshold Configuration Window

describes the critical fields on the Network Interface Threshold Configuration window.

Table D-15 NetFlow Interface Alarm Thresholds

Field

Description

Direction

Choose Ingress or Egress.

Severity

), where you can choose to view High, Low, or High and Low alarms.

Actions

Choose a Rising action and a Falling action from the lists (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Application Metrics (per second)

Choose Bytes or Packets, and enter a Rising and Falling threshold.

Video Stream Threshold Configuration Window

describes the critical fields on the Video Stream Threshold Configuration window.

Table D-16 Video Stream Thresholds

Field

Description

Name

Name given to the video stream,

Severity

Choose High or Low. These display on the Alarm Summary dashboard (Monitor > Overview > Alarm Summary), where you can choose to view High, Low, or High and Low alarms.

Codec

Choose a Codec from the list.

Source Site/Host

Make a selection from the drop-down lists, or leave as “Any.” See Configuring Sites for information on setting up a site.

Severity

Choose High or Low. These display on the Alarm Summary dashboard (Monitor > Overview >Alarm Summary), where you can choose to view High, Low, or High and Low alarms.

Actions

From the drop-down lists, choose a Rising action and a Falling action (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Video Stream Metrics

Choose a metric from the list:

- I Frame Loss%: Percentage of I frame loss.

- I Frame Loss Count: The loss count of I frames.

- All Frame Loss%: Percentage of frame loss of all types.

- All Frame Loss Count: The loss count of all types of frames.

Enter a Rising threshold and a Falling threshold.

Video MDI Stream Threshold Configuration Window

describes the critical fields on the Video MDI Stream Threshold Configuration window.

Table D-17 Video MDI Stream Thresholds

Field

Description

Name

Name given to the video MDI Stream.

Severity

Choose High or Low. These display on the Alarm Summary dashboard (Monitor > Overview >Alarm Summary), where you can choose to view High, Low, or High and Low alarms.

Source Site/Host

Make a selection from the drop-down lists, or leave as “Any.” See Configuring Sites for information on setting up a site.

Severity

Choose High or Low. These display on the Alarm Summary dashboard (Monitor > Overview >Alarm Summary), where you can choose to view High, Low, or High and Low alarms.

Actions

From the drop-down lists, choose a Rising action and a Falling action (optional). See Viewing Alarm Actions for information on setting up alarm actions.

Video Stream Metrics

Choose a metric from the list:

- Delay Factor: RFC-4445 delay factor.

- Media Loss Rate: RFC-4445 media loss rate.

Enter a Rising threshold and a Falling threshold.

Router System Information Window

describes the critical fields on the Router System Information window.

Table D-18 Router/Managed Device System Information

Field

Description

Name

Enter the name.

Hardware

A textual description which should contain the manufacturer's name for the physical entity and be set to a distinct value for each version or model of the physical entity.

Managed Device Software Version

Current software version of the router.

Managed Device System Uptime

Total time the router or switch has been running.

Location

Choose the location.

Contact

The textual identification of the contact person for this managed device and information on how to contact this person.

Managed Device

IP address of the router.

SNMP v1/v2c RW Community String

Enter the community string.

Verify String

Reenter the community string.

Enable SNMP V3

Check the check box to enable SNMP Version 3. If SNMPv3 is not enabled, the community string is used.

Mode: No Auth, No Priv

SNMP is used in a mode with no authentication and no privacy.

Mode: Auth, No Priv

SNMP is used in a mode with authentication, but no privacy.

Mode: Auth and Priv

SNMP is used in a mode with both authentication and privacy.

User Name

Enter a username, which will match the username configured on the device.

Auth Password

Enter the authentication password associated with the username that was configured on the device. Verify the password.

Auth Algorithm

Choose the authentication standard which is configured on the device (MD5 or SHA-1).

Privacy Password

Enter the privacy password, which is configured on the device. Verify the password.

Privacy Algorithm

Enter the privacy algorithm, which is configured on the device (AES or DES).

Switch/Managed Device System Information

describes the critical fields on the Switch System Information window.

Table D-19 Switch Device Information

Field

Description

SNMP Test information

Displays the IP address of the Packet Analyzer and the switch on which the SNMP test occurred.

Name

Enter the name.

Hardware

A textual description which should contain the manufacturer's name for the physical entity and be set to a distinct value for each version or model of the physical entity.

Supervisor Software Version

The software version of the device.

System Uptime

Total time the device has been running.

SNMP read from chassis

SNMP read test result.

SNMP write to chassis

SNMP write test result.

Mini-RMON on chassis

For Cisco IOS devices, displays the status if there are any ports with Mini-RMON configured (Available) or not (Unavailable).

NBAR on chassis

Displays if NBAR is available on the device.

VLAN Traffic Statistics on chassis

Displays if VLAN data is Available or Unavailable.

Note Catalyst 6500 Series switches require a Supervisor 2 or MSFC2 card.

NetFlow Status

.

NBAR Interfaces Window

describes the critical fields on the NBAR Interfaces window.

Table D-20 NBAR Interface Details

Field / Operation

Description

Enable

(check box)

Check indicates that NBAR is enabled.

Interface

Depending on the IOS running on the Supervisor, port names are displayed differently.

Newer versions of IOS software display a port name as Gi2/1 to represent a Gigabit port on module 2 port 1.

In the Virtual Switch software (VSS), a port name might be displayed as Gi1/2/1to represent a Gigabit port on switch 1, module2, port 1.

Interface Description

Description of the interface.

Site Configuration Window

describes the critical fields on the Site Configuration window.

Table D-21 Site Configuration

Field

Description

Name

Enter the name.

Description

Enter the description.

Disable Site

(check box)

If you check this check box, the software will skip this site when classifying traffic. This is useful if the site is no longer active, but the user would still like to access historical site data in the database. Otherwise, the user should delete sites that are not needed.

Subnet

to get information about Site Rules.

button to tell the software to look for subnets in the traffic. See Configuring Sites Using Subnets.

Data Source

Specify the data source from where the site traffic originates.

Leave this field blank if the site traffic can come from multiple data sources.

Subnet Detection Window

describes the critical fields on the Subnet Detection window.

Table D-22 Subnet Detection

Field

Description

Subnet Mask

Enter the subnet mask.

Note If the bit mask is 32 or less, the software will detect an IPv4 subnet. If the bit mask is between 33 and 64, then it will detect an IPv6 subnet.

Data Source

Choose the data source in which you would like to detect subnets.

Interface

Choose the interface in which you would like to detect subnets.

Filter Subnets Within Network

Enter an IPv4 or IPv6 address

Unassigned Site (check box)

The “Unassigned” site includes any that do not match any of your site configurations. Sites are classified at the time of packet processing.

Sites Window

describes the critical fields on the Sites window.

Table D-23 Sites Window

Field

Description

Name

Enter the name.

Description

Enter the description.

Rule

Lists the first rule assigned to the selected site. If you see periods next to the site rule (...), then multiple rules were created for that site. To see the list of all rules, click the quick view icon (after highlighting the site, click the small arrow on the right).

Status

Shows if the site is Enabled or Disabled.

Add NetFlow Interface Window

describes the critical fields on the NetFlow Interface Add window.

Table D-24 Add NetFlow Interface Capacity

Field

Description

Device

Enter the IPv4 or IPv6 address.

ifIndex

Unique identifying number associated with a physical or logical interface. Valid characters: 0-9.

ifName

Name of the interface. Valid characters are A-Z, a-z, 0-9.

ifSpeed(Mbps)

An estimate of the interface’s current bandwidth in bits per second.

DSCP Group Setup Dialog Box

describes the critical fields on the DSCP Group Setup dialog box.

Table D-25 DSCP Group Setup Dialog Box

Field

Description

Usage Notes

Name

Name of the profile.

Enter the name of the profile you are creating. The maximum is 64 characters.

Label Format

DSCP

DSCP numbers from 0 to 63. After selecting the DSCP radio button, you can freely choose any of the 64 possible values and assign them to Groups.

AF / EF / CS

Assured Forwarding (AF) guarantees a certain amount of bandwidth to an AF class and allows access to extra bandwidth,

Expedited Forwarding (EF) is used for traffic that is very sensitive to delay, loss and jitter, such as voice or video traffic.

Class Selector (CS) the last 3 bits of the 6-bit DSCP field, so these correspond to DSCP 0 through DSCP 7.

Bit Field

Six bits in the IP header of a packet.

DSCP Group Label Formats

describes the DSCP Group label formats.

Table D-26 DSCP Group Label Formats

DSCP Format (DSCP 0 through DSCP 63)

AF/EF/CS Format

Bit Field Format

DSCP 0

-

000000

DSCP 8

CS1

001000

DSCP 10

AF11

001010

DSCP 12

AF12

001100

DSCP 14

AF13

001110

DSCP 16

CS2

010000

DSCP 18

AF21

010010

DSCP 20

AF22

010100

DSCP 22

AF23

010110

DSCP 24

CS3

011000

DSCP 26

AF31

011010

DSCP 28

AF32

011100

DSCP 30

AF33

011110

DSCP 32

CS4

100000

DSCP 34

AF41

100010

DSCP 36

AF42

100100

DSCP 38

AF43

100110

DSCP 40

CS5

101000

DSCP 46

EF

101110

DSCP 48

CS6

110000

DSCP 56

CS7

111000

Application Window

describes the critical fields on the Add Application Window.

Table D-27 Create or Edit Applications

Field

Description

Name

Unique 1 to 64 character descriptive name.

Description

Enter the description.

Selector

(Optional) Leave blank. An arbitrary number up to 4-digits, unique within an engine-id. It is automatically assigned if left blank. Identification number is autogenerated if left blank. Range is from 1 to 65535.

This allows you to configure applications consistently across multiple Packet Analyzer, so that the same user-created application is exported with the same value. This should be used when configuring the same custom applications on multiple Packet Analyzer.

The application tag for user-created applications is a combination of the engine ID and the Selector. The 32 bit is generated by using the engine ID as the highest order byte, and the Selector makes up the other 3 bytes. For standard application/protocols, the application tag is predefined.

Application Classification Rule

Select application type: Protocol, HTTP URL-based or Server IP Address.

Application Rule: Protocol/Port

Add the application protocol and port you want to track.

—Lists predefined protocols. If your option is not included, you can create a custom URL-based application classification.

—Enter the port number or port number range to monitor. The port is an arbitrary number you assign to handle the additional ports for the protocol family. This protocol number must be unique so it does not conflict with standard protocol/port assignments.

The port number range will vary depending on the protocol type selected. You can create additional ports to enable Packet Analyzer to handle additional traffic for standard applications.

Application Rule: HTTP URL

Create custom URL-based applications by selecting this option. Enter at least one of the values below.

—The host name identified in the header from which the traffic is originating.

—The specific URL path that identifies the traffic.

Engine ID

Identifies the type of application (including ethertype, iana-14, iana-13, lic, L7, or custom).

Application Tag

System generated tag which can be used when multiple Packet Analyzer are being monitored.

Description

(Optional) Custom description to define your application. Limited to 75 characters.

Status

Active means that network traffic is being analyzed. Inactive means that the application is not being analyzed, possibly due to a duplication of effort. The Interactive Report filter may still list inactive applications if there is any historical data for the inactive application in the database, but it is not collecting new data.

Applications Window

describes the critical fields on the Applications Window.

Table D-28 Applications

Field

Description

Application

Unique 1 to 64 character descriptive name.

Rule

Displays application type: Protocol, HTTP URL-based or Server IP Address.

Selector

An arbitrary number up to 4-digits, unique within an engine-id. It is automatically assigned if left blank.

This allows you to configure applications consistently across multiple Packet Analyzer, so that the same user-created application is exported with the same value. This should be used when configuring the same custom applications on multiple Packet Analyzer.

The application tag for user-created applications is a combination of the engine ID and the selector. The 32 bit number is generated by using the engine ID as the highest order byte, and the selector makes up the other 3 bytes. For standard application/protocols, the application tag is predefined.

Engine ID

Identifies the type of application (including ethertype, iana-14, iana-13, lic, L7, or custom)

Application ID

System generated tag which can be used when multiple Packet Analyzer are being monitored.

Description

If a system-defined, contains system information about the application type. If user-defined, enter custom description to define your application. Limited to 75 characters.

Status

Active means that network traffic is being analyzed. Inactive means that the application is not being analyzed, possibly due to a duplication of effort. The Interactive Report filter may still list inactive applications, but it is not monitored by Packet Analyzer and is therefore not classified or displayed on Packet Analyzer dashboards.

URL-Based Applications Window

describes the critical fields on the URL-Based Applications window.

Table D-29 URL-Based Applications

Field

Description

Index

A unique number (1-64) of each URL-based application. You can define up to 64 URL-based applications in Packet Analyzer.

Host

Matching criteria in the host portion of the URL string appears in HTTP packets. This match is a POSIX Regular Expression1.

Path

.

Content-Type

.

Protocol Description

Description of this URL-based application.

1.A regular expression provides a concise and flexible means for matching strings of text, such as particular characters, words, or patterns of characters. A regular expression is written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification. The IEEE POSIX Basic Regular Expressions (BRE) standard (released alongside an alternative flavor called Extended Regular Expressions or ERE) was designed mostly for backward compatibility with the traditional (Simple Regular Expression) syntax but provided a common standard which has since been adopted as the default syntax of many Unix regular expression tools, though there is often some variation or additional features. Many such tools also provide support for ERE syntax with command line arguments. In the BRE syntax, most characters are treated as literals - they match only themselves (in other words, a matches "a").

1.A regular expression provides a concise and flexible means for matching strings of text, such as particular characters, words, or patterns of characters. A regular expression is written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification. The IEEE POSIX Basic Regular Expressions (BRE) standard (released alongside an alternative flavor called Extended Regular Expressions or ERE) was designed mostly for backward compatibility with the traditional (Simple Regular Expression) syntax but provided a common standard which has since been adopted as the default syntax of many Unix regular expression tools, though there is often some variation or additional features. Many such tools also provide support for ERE syntax with command line arguments. In the BRE syntax, most characters are treated as literals - they match only themselves (in other words, a matches "a").

Response Time Configuration Window

describes the critical fields on the Response Time Configuration Window.

Table D-30 Response Time Configuration Window

Field

Description

Usage Notes

Range 1 (μs)

Upper response time limit for the first container

Enter a number in microseconds. The default is 1 to 1,000 μs

Range 2 (μs)

Upper response time limit for the second container

Enter a number in microseconds. The default is 1,001 to 5,000 μs

Range 3 (μs)

Upper response time limit for the third container

Enter a number in microseconds. The default is 5,001 to 10,000 μs

Range 4 (μs)

Upper response time limit for the fourth container

Enter a number in microseconds. The default is 10,001 to 50,000 μs

Range 5 (μs)

Upper response time limit for the fifth container

Enter a number in microseconds. The default is 50,001 to 100,000 μs

Range 6 (μs)

Upper response time limit for the sixth container

Enter a number in microseconds. The default is 100,001 to 500,000 μs

Range 7 (μs)

Upper response time limit for the seventh container

Enter a number in microseconds. The default is 500,001 to 1,000,000 μs

Range 8 (μs)

Upper response time limit for the eighth container. This is the maximum interval that Packet Analyzer waits for a server response to a client request.

This range cannot be edited. Enter a number in microseconds. The default is 1,000,001 μs to infinity.

Media Monitor Setup Window

describes the critical fields on the Media Monitor Setup Window.

Table D-31 Media Monitor Setup Window

Field

Description

Voice Monitoring

Enabled

Enables voice monitoring. Ensure this check box is selected if you are interested in voice monitoring.

MOS Values

Excellent

.

Good

.

Fair

.

Poor

. This default cannot be changed.

Video Monitoring

Enabled

Enables video monitoring. Ensure this check box is selected if you are interested in video monitoring.

MDI Values

Poor

.

Fair

.

Good

.

Excellent

. This default cannot be changed.

URL Collection Configuration Window

describes the critical fields on the URL Collection Configuration Window.

Table D-32 URL Collection Configuration Dialog Box

Element

Description

Usage Notes

Data Source

Identifies type of traffic incoming from the application.

Select one of the options from the drop- down box.

Max Entries

Maximum number of URLS to collect.

Select one of the following options from the drop-down box:

- 100

- 500

- 1000

Match only

The application URL to match.

Optional parameter to limit collection of URLs that match the regular expression of this field.

NetFlow Export Template Window

describes the critical fields on the NetFlow Export Template Window.

Table D-33 NetFlow Export Template Window

Field

Description

Description

A description of the NetFlow Export.

Destination IP Address

The IP address of the device to be exported to. IPv4 and IPv6 addresses are supported.

Destination Port

The port number of the device to be exported to.

Valid characters: 1-9. Length: Min 1, Max 65535.

Export Record Type

The record types supported by Packet Analyzer for NetFlow are:

- Client Server Response Time

- Application Conversation

- Network Conversation

- RTP Metrics

Export Interval

This will be five minutes for Client Server Response Time and one minute for the other record type.

Version

Select v9 or IPFIX to export.

Options

The NetFlow option selection contains a set of check boxes. These allow independent selections of on or off settings for individual NetFlow options, which can be exported in addition to the NDE packets with data and templates, as follows:

- Mapping of integer application ID values into application names (as strings)

- Mapping of integer site ID values into site names and descriptions (as strings)

If there are several NetFlow Export Descriptors defined for the same destination, then the last user’s selection of option exports flags is enforced on all descriptor instances that exist for the same export.

Add Managed Device

describes the fields in the Add Managed Device window. This window appears only when multiple managed-device feature is enabled.

Table D-34 Add Managed Device Window

Field

Description

Managed Device

IP Address of the managed device.

DATA PORT#

to find the appropriate ifIndex value.

Note The number of DATA PORT# items displayed will vary depending on the Packet Analyzer platform. For example, Packet Analyzer-2400 have 2 data ports.

SNMP Version

v1/v2 or v3

SNMP Credential Related fields

If SNMP v1/v2 is selected, then the SNMP community string must be provided.

If SNMP v3 is selected, then appropriate SNMPv3 security parameters (e.g., security mode/level, username, auth password, auth protocol/algorithm, privacy password, and/or privacy protocol/algorithm) must be provided.

Note If selecting a mode that requires Auth Password and/or Privacy Password, each must be at least 12 characters long.

Monitor User Interface Windows

describe the various optional and data templates.

Table D-35 Optional Templates

ID

Length

Name

Application Template

95

4

Application ID

96

24

Application Name

94

55

Application Description

42006

4

Site ID

4 42016

24

Site Name

42017

55

Site Description

Data Source Template

42001

4

Data source ID

42018

24

Data source name

42019

55

Data source description

Table D-36 Data Templates

ID

Length

Name

8

4

IPv4 source address

12

4

IPv4 destination address

42002

4

source site ID

4

destination site ID

42001

4

data source ID

10

4

input SNMP if-index

14

4

output SNMP if-index

58

2

input VLAN ID

59

2

output VLAN ID

195

1

input DSCP

98

1

output DSCP

151

4

flow end seconds

1

8

byte count

2

8

packet count

Network Conversation IPv6 Template

27

16

IPv6 source address

28

16

IPv6 destination address

42002

4

source site ID

4

destination site ID

42001

4

data source ID

10

4

input SNMP if-index

14

4

output SNMP if-index

58

2

input VLAN ID

59

2

output VLAN ID

195

1

input DSCP

98

1

output DSCP

151

4

flow end seconds

1

8

byte count

2

8

packet count

8

4

IPv4 source address

12

4

IPv4 destination address

42002

4

source site ID

42003

4

destination site ID

42001

4

data source ID

95

4

application ID

42010

4

network encapsulation ID

10

4

input SNMP if-index

14

4

output SNMP if-index

58

2

input VLAN ID

59

2

output VLAN ID

4

1

protocol

195

1

input DSCP

98

1

output DSCP

151

4

flow end seconds

1

8

byte count

2

8

packet count

8

4

IPv4 source address

12

4

IPv4 destination address

27

16

IPv6 source address

28

16

IPv6 destination address

42004

4

server site

42007

4

server IPv4 address

42005

4

client site

42008

4

client IPv4 address

95

4

app ID

42001

4

data source

58

2

VLAN ID

195

1

DSCP

151

4

duration of the flow

42010

4

net encapsulation

32792

2

server port

42020

1

waas optimization segments

42060

4

number of responses

42061

4

number of responses in bucket1

42062

4

number of responses in bucket2

42063

4

number of responses in bucket3

42064

4

number of responses in bucket4

42065

4

number of responses in bucket5

42066

4

number of responses in bucket6

42067

4

number of responses in bucket7

42068

4

number of late responses

42071

4

sum response time

42072

4

maximum response time

42073

4

minimum response time

42074

4

sum application response time

42075

4

maximum application response time

42076

4

minimum application response time

42077

4

sum total response time

42078

4

maximum total response time

42079

4

minimum total response time

42040

4

sum number of transaction

42041

4

sum transaction time

42042

4

maximum transaction time

42043

4

minimum transaction time

42050

4

number of new connections

42054

4

sum session duration

42084

4

sum client network time

42085

4

maximum client network time

42086

4

minimum client network time

42087

4

sum server network time

42088

4

maximum server network time

42089

4

minimum server network time

42081

4

sum network delay

42004

4

server site

28

16

server IPv6 address

42005

4

client site

27

16

client IPv6 address

95

4

app ID

42001

4

data source

58

2

VLAN ID

195

1

DSCP

151

4

duration of the flow

42010

4

net encapsulation

32792

2

server port

42020

1

waas optimization segments

42060

4

number of responses

42061

4

number of responses in bucket1

42062

4

number of responses in bucket2

42063

4

number of responses in bucket3

42064

4

number of responses in bucket4

42065

4

number of responses in bucket5

42066

4

number of responses in bucket6

42067

4

number of responses in bucket7

42068

4

number of late responses

42071

4

sum response time

42072

4

maximum response time

42073

4

minimum response time

42074

4

sum application response time

42075

4

maximum application response time

42076

4

minimum application response time

42077

4

sum total response time

42078

4

maximum total response time

42079

4

minimum total response time

42040

4

sum number of transaction

42041

4

sum transaction time

42042

4

maximum transaction time

42043

4

minimum transaction time

42050

4

number of new connections

42054

4

sum session duration

42084

4

sum client network time

42085

4

maximum client network time

42086

4

minimum client network time

42087

4

sum server network time

42088

4

maximum server network time

42089

4

minimum server network time

8

4

source IPv4 Address

12

4

destination IPv4 Address

42002

4

source site

42003

4

destination site

42101

4

rtp ssrc

42102

1

rtp payload type

7

2

source port

11

2

destination port

195

1

DSCP

58

2

VLAN ID

151

4

flow end seconds

42001

4

data source

42010

4

net encap

42112

4

rtp duration

42113

4

average MOSx100

42115

4

worst/lowest MOSx100

37023

4

jitter x 100

37019

4

actual packet loss count

37014

4

expected packet count

27

4

source IPv6 Address

28

4

destination IPv6 Address

42002

4

source site

42003

4

destination site

42101

4

rtp ssrc

42102

1

rtp payload type

7

2

source port

11

2

destination port

195

1

DSCP

58

2

VLAN ID

151

4

flow end seconds

42001

4

data source

42010

4

net encap

42112

4

rtp duration

42113

4

average MOSx100

42115

4

worst/lowest MOSx100

37023

4

jitter x 100

37019

4

actual packet loss count

37014

4

expected packet count

This section describes field descriptions for the following windows:

- All Alarms Table

- Applications Detail

- Application Groups Detail

- Client-Server Application Responses Window

- Client-Server Application Transactions Window

- Client-Server Network Responses Window

- DSCP Detail

- Host Detail

- Interfaces Stats Table

- Last 50 Alarms

- Server Application Responses Metrics

- Server Application Transactions Metrics

- Server Network Responses Window

All Alarms Table

describes the critical fields on the All Alarms table.

Table D-37 All Alarms

Field

Description

Site

This contains site or source and destination sites (source - destination) of the network traffic that generated the alarm message.

Alarm Triggered By

Details information of the network traffic that generated the alarm message. The format of the alarm triggered by string are:

- Triggered by application threshold: application

- Triggered by application with DSCP threshold: DSCP:codepoint - application

- Triggered by host threshold: host

- Triggered by host with application threshold: host - application

- Triggered by host with application and DSCP: DSCP: code point - host - application

- Triggered by host with DSCP: DSCP: code point - host

- Triggered by conversation: source - destination

- Triggered by conversation with application: source - application - destination

- Triggered by response time: IAP: client - application - server.

- Triggered by DSCP: DSCP: code point

- Triggered by RTP stream: source - source port - codec(codec string) - SSRC(number) - destination - destination port

- Triggered by voice signaling: Calling (address - number) Called (address - number) ID/References (id() - ref (calling:called))

- Triggered by NetFlow interfaces: NetFlow: Device (address) - If-Index(number) - Ingress/Egress

Threshold Variable

Parameter of the threshold that is used to evaluate alarm condition.

Threshold Value

User defined rising value of the threshold variable.

Triggered Time

Time when the alarm condition was found occurred.

Triggered Value

Parameter value when the alarm condition was raised. Note: The triggered value could be - when the viewing window does not included the alarm when it was occurring.

Clear Time

Time when the alarm condition was resolved. The alarm variable has fallen below the falling threshold value.

Applications Detail Window

describes the critical fields in this window.

Table D-38 Applications Detail

Field

Description

Application

Software services classified by Packet Analyzer from analyze and monitor traffic.

Application Group

The application group (set of applications that can be monitored as a whole).

Bytes/sec

Traffic rate; number of bytes per second

Packets/sec

Traffic rate; number of packets per second

Application Groups Detail Window

describes the critical fields in this window.

Table D-39 Application Groups Detail

Field

Description

Application Group

The application group (set of applications that can be monitored as a whole).

Site

Applicable site (or Unassigned if no site)

Bytes/sec

Traffic rate; number of bytes per second

Packets/sec

Traffic rate; number of packets per second

Application Response Time (ART) Metrics

describes the metrics measured for response time.

Table D-40 Application Response Time (ART) Metrics

Metric

Description

Average Response Time

Response Time is the time between the client request and the first response packet from the server, as observed at the Packet Analyzer probing point. Increases in the response time usually indicate problems with server resources, such as the CPU, Memory, Disk, or I/O due to a lack of necessary resources or a poorly written application.

This and other Response Time metrics are in microseconds (μs) units.

Min Response Time

Max Response Time

Number of Responses

Total number of request-response pairs observed during the monitoring interval

Number of Late Responses

Total number of responses that exceed the Max Response Time

Number of Responses 1

Number of responses with a response time less than RspTime1 threshold

Number of Responses 2

Number of responses with response time less than RspTime2 and larger than RspTime1

Number of Responses 3

Number of responses with response time less than RspTime3 and larger than RspTime2

Number of Responses 4

Number of responses with response time less than RspTime4 and larger than RspTime3

Number of Responses 5

Number of responses with response time less than RspTime5 and larger than RspTime4

Number of Responses 6

Number of responses with response time less than RspTime6 and larger than RspTime5

Number of Responses 7

Number of responses with response time less than LateRsp and larger than RspTime6

Client Bits

Number of TCP payload bits sent from the client(s) during the monitoring interval

Server Bits

Number of TCP payload bits sent from the server(s) during the monitoring interval

Client Packets

Number of TCP packets sent from the client(s) during the monitoring interval

Server Packets

Number of TCP packets sent from the server(s) during the monitoring interval

Average number of concurrent connections

Average number of concurrent TCP connections during the reporting interval

Number of new connections

Number of new TCP connections made (TCP 3-way handshake) during the monitoring interval

Number of closed connections

Number of TCP connections closed during the monitoring interval

Number of unresponsive connections

Number of TCP connection requests (SYN) that are not responded during the monitoring interval

Number of refused connections

Number of TCP connection requests (SYN) that are refused during the monitoring interval

Average Connection duration

Average duration of TCP connections during the monitoring interval

Average Server Response Time

, which is the time between the client request arriving at the server and the first response packet being returned by the server.

Increases in the server response time usually indicate problems with application and/or server resources, such as the CPU, Memory, Disk, or I/O.

Min Server Response Time

Max Server Response Time

Average Network Time

Network time between a client and a server. Network Time is the sum of Client Network Time and Server Network Time. Packet Analyzer measures the Network Time using TCP 3-way handshakes. If there are no new TCP connections made during the monitoring interval, this metric is not reported.

Min Network Time

Max Network Time

Average Client Network Time

Client Network Time is the network time between a client and the Packet Analyzer switch or router.

In WAAS monitoring, Client Network Time from a WAE client data source represents the network RTT between the client and its edge WAE, while Client Network Time from the WAE server data source represents the WAN RTT (between the edge and core WAEs).

Min Client Network Time

Max Client Network Time

Average Server Network Time

Server Network Time is the network time between a server and Packet Analyzer probing point.

In WAAS monitoring, Server Network Time from a server data source represents the network time between the server and its core WAE.

Min Server Network Time

Max Server Network Time

Average Total Response Time

Total Response Time is the total amount of time between the client request and when the client receives the first response packet from the server.

Use Total Response Time with care because it is not measured directly and mixes the server response time metric with the network time metric.

Min Total Response Time

Max Total Response Time

Average Transaction Time

Transaction Time is the total amount of time between the client request and the final response packet from the server.

Transaction times may vary depending upon client usages and application types. Transaction Time is a key indicator for monitoring client experiences and detecting application performance anomalies.

Min Transaction Time

Max Transaction Time

Number of Transactions

The number of transactions completed during the monitoring interval.

Average Data Transmission Time

Elapsed time from the first server-response packet to the last server-response packet, excluding retransmission time.

Average Data Time

Data Time: Average data time portion of transaction time.

Packets Retransmitted

Number of retransmitted packets detected during the monitoring interval

Bits Retransmitted

Number of retransmitted bits detected during the monitoring interval

Average Retransmission Time

Average time to retransmit lost packets per transaction

Client ACK Round Trip Time

Average network time for the client to acknowledge (ACK) a server data packet as observed at Packet Analyzer probing point

Number of Client ACK Round Trips

Number of client ACK RTs observed during the monitoring interval

Client Server Application Responses Window

provides definitions of the critical fields of the Client-Server Application Responses window.

Table D-41 Client-Server Application Responses Window

Field

Description

Number of Responses

Total number of responses observed during the monitoring interval

Minimum Client Network Time (ms)

Minimum network time measured by analyzing TCP three-way handshake sequence.

Average Client Network Time (ms)

Average network time measured by analyzing TCP three-way handshake sequence.

Maximum Client Network Time (ms)

Maximum network time measured by analyzing TCP three-way handshake sequence.

Minimum Server Network Time (ms)

Minimum network time between a server and Packet Analyzer probing point.

Average Server Network Time (ms)

Average network time between a server and Packet Analyzer probing point.

Maximum Server Network Time (ms)

Maximum network time between a server and Packet Analyzer probing point.

Minimum Total Response Time (ms)

The total amount of time between the client request and the final response packet from the server.

Average Total Time (ms)

Average time (ms) elapsed from the start of a client request to the completion of server response. Transaction times might vary significantly depending upon application types. Relative thresholds are useful in this situation.

Transaction time is a key indicator when detecting application performance anomalies.

Maximum Total Time (ms)

The total amount of time between the client request and the final response packet from the server.

Client-Server Application Transactions Window

provides definitions of critical fields in the Client-Server Application Transactions window.

Table D-42 Client-Server Application Transactions Window

Field

Description

Number of Transactions

Total number of transactions observed during the monitoring interval.

Average Transaction Time (ms)

Average time elapsed from the start of a client request to the completion of server response. Transaction times might vary significantly depending upon application types. Relative thresholds are useful in this situation.

Transaction time is a key indicator when detecting application performance anomalies.

Average Server Response Time (ms)

Amount of time it takes a server to send the initial response to a client request as seen by the Packet Analyzer.

Average Data Transmission Time (ms)

Elapsed time from the first server-response packet to the last server-response packet, excluding retransmission time.

Average Retransmission Time (ms)

Average time to retransmit lost packets per transaction

Client ACK Round Trip Time (ms)

Average network time for the client to acknowledge (ACK) a server data packet as observed at Packet Analyzer probing point

Client-Server Network Responses Window

describes the critical fields of the Client-Server Network Response Time window.

Table D-43 Client-Server Network Responses Window

Field

Description

Minimum Client Network Time (ms)

Minimum network time measured by analyzing TCP three-way handshake sequence.

Average Client Network Time (ms)

Average network time measured by analyzing TCP three-way handshake sequence.

Maximum Client Network Time (ms)

Maximum network time measured by analyzing TCP three-way handshake sequence.

Minimum Server Network Time (ms)

Minimum network time measured by analyzing TCP three-way handshake sequence.

Average Server Network Time (ms)

Average network time measured by analyzing TCP three-way handshake sequence.

Maximum Server Network Time (ms)

Maximum network time measured by analyzing TCP three-way handshake sequence.

Minimum Network Time (ms)

Minimum of the network time measured by analyzing TCP three-way handshake sequence.

Network Time is the sum of Client Network Time and Server Network Time. Packet Analyzer measures the Network Time using TCP 3-way handshakes. If there are no new TCP connections made during the monitoring interval, this metric is not reported.

Average Network Time (ms)

Average of the network time measured by analyzing TCP three-way handshake sequence.

Maximum Network Time (ms)

Maximum of the network time measured by analyzing TCP three-way handshake sequence.

DSCP Detail Window

describes the critical fields in this window.

Table D-44 DSCP Detail

Field

Description

Bytes/sec

, you can choose to display Packet Analyzer data in Bits or Bytes.

Packets/sec

Traffic rate; number of packets per second

Host Detail Window

describes the critical fields in this window.

Table D-45 Host Detail

Field

Description

In Bits/sec

Number of bits per second incoming

In Packets/sec

Number of packets per second incoming

Out Bits/sec

Number of bits per second outgoing

Out Packets/sec

Number of packets per second outgoing

Interfaces Stats Table

. describes the critical fields in the Interfaces Stats table.

Table D-46 Interfaces Stats Table

Field

Description

Interface

Interface number.

In % Utilization

Utilization percentage of the port.

Out % Utilization

Utilization percentage of the port.

In Packets/s

Number of incoming packets collected per second.

Out Packets/s

Number of outgoing packets sent out per second.

In Bits/s

Number of bits collected per second.

Out Bits/s

Number of bits sent out per second.

In Non-Unicast/s

Number of non-unicasts collected per second.

Out Non-Unicast/s

Number of non-unicasts sent out per second.

In Discards/s

Number of discards collected per second.

Out Discards/s

Number of discards sent out per second.

In Errors/s

Number of errors collected per second.

Out Errors/s

Number of errors sent out per second.

Last 50 Alarms Table

describes the critical fields on the Last 50 Alarms table.

Table D-47 Last 50 Alarms

Field

Description

Site

This contains site or source and destination sites (source - destination) of the network traffic that generated the alarm message.

Alarm Triggered By

Details information of the network traffic that generated the alarm message. The format of the alarm triggered by string are:

- Triggered by application threshold: application

- Triggered by application with DSCP threshold: DSCP:codepoint - application

- Triggered by host threshold: host

- Triggered by host with application threshold: host - application

- Triggered by host with application and DSCP: DSCP: code point - host - application

- Triggered by host with DSCP: DSCP: code point - host

- Triggered by conversation: source - destination

- Triggered by conversation with application: source - application - destination

- Triggered by response time: IAP: client - application - server.

- Triggered by DSCP: DSCP: code point

- Triggered by RTP stream: source - source port - codec(codec string) - SSRC(number) - destination - destination port

- Triggered by voice signaling: Calling (address - number) Called (address - number) ID/References (id() - ref (calling:called))

- Triggered by NetFlow interfaces: NetFlow: Device (address) - If-Index(number) - Ingress/Egress

Threshold Variable

Parameter of the threshold that is used to evaluate alarm condition.

Threshold Value

User defined rising value of the threshold variable.

Triggered Time

Time when the alarm condition was found occurred.

Triggered Value

Parameter value when the alarm condition was raised. Note: The triggered value could be - when the viewing window does not included the alarm when it was occurring.

Clear Time

Time when the alarm condition was resolved. The alarm variable has fallen below the falling threshold value.

Server Application Responses Window

provides definitions of the critical fields of the Server Application Responses window.

Table D-48 Server Application Responses Metrics

Field

Description

Average Client Network Time (ms)

Client Network Time is the network time between a client and the Packet Analyzer switch or router.

In WAAS monitoring, Client Network Time from a WAE client data source represents the network RTT between the client and its edge WAE, while Client Network Time from the WAE server data source represents the WAN RTT (between the edge and core WAEs).

Maximum Client Network Time (ms)

Average Server Response Time (ms)

, which is the time between the client request arriving at the server and the first response packet being returned by the server.

Increases in the server response time usually indicate problems with application and/or server resources, such as the CPU, Memory, Disk, or I/O.

Maximum Server Response Time (ms)

Average Total Response Time (ms)

Total Response Time is the total amount of time between the client request and when the client receives the first response packet from the server.

Maximum Total Response Time (ms)

Server Application Transactions Window

provides definitions of the critical fields of the Server Application Transactions window.

Table D-49 Server Application Transactions Metrics

Field

Description

Average Transaction Time (ms)

Average time (ms) elapsed from the start of a client request to the completion of server response. Transaction times might vary significantly depending upon application types. Relative thresholds are useful in this situation.

Transaction time is a key indicator when detecting application performance anomalies.

Average Server Response Time (ms)

Amount of time it takes a server to send the initial response to a client request as seen by the Packet Analyzer.

Average Data Transfer Time (ms)

Average elapsed time from the first server-response packet to the last server-response packet, excluding retransmission time. Data transfer time is always measured in the server-to-client direction and can be used to detect problems for a particular type of transaction of an application.

Average Retransmission Time (ms)

Average time to retransmit lost packets, per transaction.

Client ACK Round Trip Time (ms)

Average round trip time for the client to acknowledge (ACK) a server TCP packet.

Server Network Responses Window

provides definitions of the critical fields of the Server Network Response Times window.

Table D-50 Server Network Responses Window

Field

Description

Average Server Network Time (ms)

Average of the Server Network Time (network time between a server and Packet Analyzer probing point).

Maximum Server Network Time (ms)

Maximum of the Server Network Time (network time between a server and Packet Analyzer probing point).

Average Network Time

Average of the network time between client and server. Network Time is the sum of Client Network Time and Server Network Time. Packet Analyzer measures the Network Time using TCP 3-way handshakes. If there are no new TCP connections made during the monitoring interval, this metric is not reported.

Maximum Network Time

Maximum of the network time between client and server.

Server Bytes

Number of TCP payload bytes sent from the server(s) during the monitoring interval.

Client Bytes

Number of TCP payload bytes sent from the client(s) during the monitoring interval.

Calls Table

.

Table D-51 Calls Table

Field

Description

Calling Number

Calling number as it appears in the signaling protocol.

Called Number

Called number as it appears in the signaling protocol.

Calling Host Address

RTP receiving address of the calling party detected by the Packet Analyzer from inspecting the call signaling protocol.

Calling Port

RTP receiving port of the calling party detected by Packet Analyzer from inspecting call signaling protocol.

Calling Alias

Calling party name detected by Packet Analyzer from inspecting call signaling protocol.

Called Host Address

IP address of the phone receiving the call.

Called Port

Port of the phone receiving the call.

Called Alias

Alias name, MGCP endpoint ID, or SIP URI of the called party phone.

Calling Reported Jitter (ms)

Jitter value reported by calling party at the end of the call.

Calling Reported Packet Loss (%)

Percentage of packet loss reported by calling party at the end of the call.

Start Time

Time when the call was detected to start.

End Time

Time when the call was detected to end.

Duration

Duration of the call.

Note When the call signaling’s call tear down sequence is not detected by the Packet Analyzer, the Packet Analyzer will assume:

- the call ended after 3 hours in low call volume per interval

- the call ended after 1 hour in high call volume per interval (high call volume is defined as call table filled up during the interval.)

Called Reported Jitter (ms)

Jitter value reported by called party at the end of the call.

Called Reported Pkt Loss (%)

Percentage of packet loss reported by called party at the end of the call.

RTP Stream for Selected Call Report Statistics

provides definitions of the critical fields of the RTP stream statistics of a selected call calculated by the Packet Analyzer.

Table D-52 RTP Streams for the Selected Call Table

Field

Purpose

Source Address

IP Address of the originator of the RTP stream

Source Port

UDP port of the originator of the RTP stream

Destination Address

IP address of the receiver of the RTP stream

Destination Port

UDP port of the receiver of the RTP stream

Codec

Encoding decoding format/algorithm of the RTP stream

SSRC

Synchronization source number as it appear in the RTP header

Duration Weighted MOS

Packet Analyzer calculated score that takes into account of the duration of the stream

Duration Weighted Jitter

Jitter that takes into account of the duration of the RTP stream among all per-interval reports

Overall Adjusted Packet Loss

Percentile of adjust packets lost against total packets of all per-interval RTP reports.

Video Signaling Channel

provides definitions of the critical fields of the video signaling channel.

Table D-53 Video Signaling Channel

Field

Description

Video Source IP/Port

Video stream sending IP address/L4 port of the signaling session detected by the Packet Analyzer from the media signaling protocol.

Video Destination IP/Port

Video stream receiving IP address/L4 port of the signaling session detected by the Packet Analyzer from the media signaling protocol.

Signaling Protocol

Signaling protocol.

Codec

Encoding decoding format/algorithm of the video stream.

Payload Type

RTP payload type in video stream detected by Packet Analyzer from inspecting call signaling protocol.

Media Transport Protocol

Transport protocol of video stream detected by Packet Analyzer from inspecting call signaling protocol.

Source Alias

Video source host name or calling party name detected by Packet Analyzer from inspecting call signaling protocol.

Destination Alias

Video destination host name or calling party name detected by Packet Analyzer from inspecting call signaling protocol.

SSRC

Synchronization source number in the RTP header from inspecting call signaling protocol.

Start Time

Time when the video channel was setup and detected by the Packet Analyzer.

End Time

Time when the video channel was ended and detected by the Packet Analyzer.

Duration

Video stream duration.

Signaling Server IP/Port

IP Address/L4 port of signaling server.

Signaling Client IP/Port

IP Address/L4 port of signaling client.

Signaling Session VLAN

VLAN of signaling session packets.

Signaling Transport Protocol

Transport layer protocol of signaling session.

Video Stream Conversations

provides definitions of the critical fields of the Video Stream Conversations.

Table D-54 Video Stream Conversations

Field

Description

Source Address/Port

IP Address/L4 port of the originator of video stream.

Destination Address/Port

IP Address/L4 port of the receiver of video stream.

SSRC

Synchronization source number as it appears in the RTP header of the video stream.

Program ID: Sortable

Program ID for MPEG2-TS video traffic.

Codec

Encoding decoding format/algorithm of the video stream.

Protocol

Codec protocol, it could be H264, MPEG2-TS or the others supported by Packet Analyzer.

Avg I Frame Loss Rate (%)

I-Frame loss rate in average of this period in percentage.

Avg All Frame Loss Rate (%)

Frame loss rate in average of this period in percentage.

Avg DF(ms)

Delay Factor average of this period in unit of ms.

Avg MLR (packet(s))

Media Loss Rate in average of this period, it is the percentage rate of packets loss.

Media Signaling Sessions

provides definitions of the critical fields of the media signaling sessions.

Table D-55 Media Signaling Sessions

Field

Description

Called or Server IP/Port

IP Address/L4 port of video server or video sender of calling party.

Calling or Client IP/Port

IP Address/L4 port of video client or video receiver of calling party.

Called or Server alias

Calling party name detected by Packet Analyzer from inspecting call signaling protocol or video server alias. It could be MGCP endpoint ID, or SIP URI of the called party phone and so on.

Calling or Client Alias

Called party name detected by Packet Analyzer from inspecting call signaling protocol or video client alias. It could be MGCP endpoint ID, or SIP URI of the called party phone etc.

Protocol

Signaling protocol of this media session.

Start Time

Time when the signaling session was detected to start.

End Time

Time when the signaling session was detected to end.

Duration

Duration of this signaling session.

Calling Number

Calling number as it appears in the signaling protocol, if it is a VoIP call.

Called Number

Called number as it appears in the signaling protocol, if it is a VoIP call.

RTP Stream for Selected Media Signaling Session

provides definitions of the critical fields of the RTP stream statistics of a selected media signaling session.

Table D-56 RTP Streams for the Selected Media Signaling Session

Field

Purpose

Source Address/Port

IP address or UDP port of the originator of the RTP stream.

Destination Address/Port

IP address or UDP port of the receiver of the RTP stream.

Codec

Encoding decoding format/algorithm of the RTP stream.

SSRC

Synchronization source number as it appears in the RTP header.

Duration Weighted MOS

Packet Analyzer calculated score that takes into account of the duration of the stream.

RTP Conversations Table

provides definitions of the critical fields of the RTP Conversations Table.

Table D-57 RTP Conversations Table

Field

Purpose

Start Time

Time when the RTP stream was discovered by the Packet Analyzer

Source Address

IP Address of the originator of the RTP stream

Source Port

UDP port of the originator of the RTP stream

Destination Address

IP address of the receiver of the RTP stream

Destination Port

UDP port of the receiver of the RTP stream

Codec

Encoding decoding format/algorithm of the RTP stream

SSRC

Synchronization source number as it appear in the RTP header

Duration Weighted MOS

Packet Analyzer calculated score that takes into account of the duration of the stream

Capture User Interface Windows

This section includes the following topics:

- Capture Analysis Window

- Capture Session Fields

- Capture Setting Fields

- Custom Decode Filter Dialog Box

- Custom Decode Subexpressions Fields

- Error Scan Window

- Hardware Filter Dialog Box

- Cisco Security Packet Analyzer Decode Window

- Software Filter Dialog Box

- Capture Query Fields

Capture Analysis Window

describes the Capture Analysis window fields.

Table D-58 Capture Analysis Window Fields

Field

Description

Capture Overview

Provides a summary of the displayed capture including number of packets captured, bytes captured, average packet size, capture start time, duration of capture, and data transfer rate (both bytes and bits per second)

Traffic over Time

Displays a graphic image of network traffic (KB/second)

Protocol Statistics

Displays packets and bytes transferred for each protocol

Hosts Statistics

Displays packets and bytes transferred for each host address

Capture Session Fields

page.

Table D-59 Capture Session Fields

Operation

Description

Start Time

Time the capture was last started. You can stop and restart the capture as many times as necessary.

Size (MB) (Capture to Memory)

Size (MB) x No. files (Capture to Files)

Size of the session
indicates the capture is being stored in one or more files and is a link to those files.
The capture file size is limited to 500 MB on Nexus 1000V and vNAM. On all other Packet Analyzer platforms, the capture file size limit is 2,000 MB.

State

The current status of the capture:

- Running—Packet capture is in progress

- Stopped—Packet capture is stopped. Captured packets remain in buffer, but no new packets are captured

- Full—The memory or file is full, and no new packets will be captured.

Location

The location of the capture (Memory, Local Disk, and external storage).

Capture Operation Buttons

Create

Create a new capture session. See Configuring Capture Sessions.

Edit

Edit the settings of the selected capture.

Delete

Delete a selected session. Not available if capture session is running.

Start

Start capturing to a selected session. The number in the Packets column for that session will start to increase.

Stop

Stop capturing to the selected session (no packets will go through). Capture data remains in the capture memory buffer, but no new data is stored. Click Start to resume the capture.

Clear

Clear captured data from memory.

Decode

Display details of the capture session.

Save to File

Save a session to a file on the Packet Analyzer hard disk. See Working with Capture Files.

Capture Setting Fields

describes the Capture Settings fields.

Table D-60 Capture Settings Fields

Field

Description

Usage Notes

Packet Slice Size (bytes)

The slice size in bytes; used to limit the size of the captured packets.

Enter a value between 64 and 9000. Enter zero (0) to not perform slicing.

If you have a small session but want to capture as many packets as possible, use a small slice size.

If the packet size is larger than the specified slice size, the packet is sliced before it is saved in the capture session. For example, if the packet is 1000 bytes and slice size is 200 bytes, only the first 200 bytes of the packet is stored in the capture session.

Capture Source

Data-Ports or ERSPAN

Choose the capture source (check one or more check boxes):

- Data-ports: This accepts SPAN, RSPAN, and VACL capture.

- ERSPAN: Locally terminated is recommended.

Note On some platforms, you may be limited to selecting only one of the dataports at a time. Most platforms allow you to select both dataports at once.

Storage Type: Memory

Check to store captures in memory

for this capture. Enter a number from 1 up to your platform maximum. If system memory is low, the actual session size allocated might be less than the number specified here.

, the capture will end when the amount of data reaches size of session.

Storage Type: File(s)

File Size (MB)

(file size can be from 1 MB to 500/2000 MB depending on your platform). If disk space is not available, you are not able to start new capture-to-disk sessions.

Number of Files

Enter a value for Number Of Files to use for capture. The maximum is determined on the size of the file, numbers of files stored, and the amount of disk space available at the location where these files are stored.

Rotate Files

Use this feature if you plan to capture sets of small files that allow you to perform instantaneous downloads, decodes, and analysis. Rotating files allows you to automatically maintain your storage space.

Check the Rotate Files check box to rotate files. Available only for remote storage or Packet Analyzer appliances. For information about configuring remote storage, see About Capturing to Data Storage.

. To determine the most recent capture, check each file’s time stamp.

File Location

If file data storage is available, choose one of the storage targets in the drop-down list. The drop-down list displays only those targets in the Ready state.

Local disk is the default, or choose a previously configured remote storage location if available. Each option shows the amount of disk space available for capture packet storage.

page (see Utilizing Capture Data Storage).

Custom Decode Filter Dialog Box

describes the critical fields on the custom decide filter window.

Table D-61 Custom Decode Filter Dialog Box

Field

Description

Usage Notes

Protocol

The protocol to match with the packet.

to match all packets regardless of protocol.)

Address

(MAC or IP)

Indicates whether to filter by MAC or IP address.

Choose MAC to filter using the source/destination MAC address of the packets.

Choose IP to filter using the source/destination addresses of the packets.

Both Directions

Indicates whether the filter is applied to traffic in both directions.

If the source is host A and the destination is host B, enabling both directions filters packets from A to B and B to A.

If the source is host A and the destination is not specified, enabling both directions filters packets both to and from host A.

Offset

The offset (in bytes) from the Base where packet data-matching begins.

Enter a decimal number.

Base

The base from which the offset is calculated.

If you select absolute, the offset is calculated from the absolute beginning of the packet (for example, the beginning of the Ethernet frame).

If you select protocol, the offset is calculated from the beginning of the protocol portion of the packet. If the packet does not contain the protocol, the packet fails this match.

or a protocol.

Data Pattern

The data to be matched with the packet.

are hexadecimal numbers from 0-9 or a-f. Leave blank if not applicable.

Filter Expression

An advanced feature to set up complex filter conditions.

.

See Tips for Creating Custom Decode Filter Expressions.

Custom Decode Subexpressions Fields

describes the custom decode fields and provides filter and format details.

Table D-62 Custom Decode Field Subexpressions

Field

Filter By

Format

eth.dst

MAC address

, where h is a hexadecimal number from 0 to 9 or a to f.

ip.dst

IP address

, where n is a number from 0 to 255 and s is a 0-32 hostname that does not contain a hyphen.

tcp.dstport

TCP port number

A decimal number from 0 to 65535.

udp.dstport

UDP port number

A decimal number from 0 to 65535.

Protocol

Click the Protocol list in the Custom Decode Filter dialog box to see the list of protocols on which you can filter.

Protocol data pattern

is a hexadecimal number fro 0 to 9 or a to f.

are decimal numbers.

portion of the packet.

frame.pkt_len

Packet length

A decimal number that represents the packet length, not the truncated capture packet length.

Error Scan Window

describes the Error Scan window fields.

Table D-63 Error Scan Window Descriptions

Field

Description

Severity

: Warning; for example, an application returned an unusual error code

: A serious problem, such as malformed packets

Group

: A checksum was invalid

: Protocol sequence is problematic

: Problem with the application response code

: An application request

: Dissector incomplete or data can’t be decoded

: Problems while reassembling

: Malformed packet or dissector has a bug; dissection of this packet aborted

Hardware Filter Dialog Box

describes the Create Hardware Filter dialog box.

Table D-64 Create Hardware Filter Dialog

Attribute

Options

Range

Data Ports

Both Ports, Data Port 1, Data Port 2

—

Frame Length

Equal To, Not Equal To, Greater Than, Less Than

Min. 64, Max 65535

VLAN IDs

Equal To, Not Equal To, Greater Than, Less Than

Min. 1, Max 4095

MPLS Label

Equal To, Not Equal To

Min. 0, Max 1048575

Source Address / Mask

Equal To, Not Equal To

IPv4 address

Destination Address / Mask

Equal To, Not Equal To

IPv4 address

L4 Protocol

Equal To, Not Equal To

ICMP, IGMP, IP in IP, GRE, L2Tp, TCP, UDP, Integer

With Custom, you can enter a custom value that is not in the list of common protocols. Enter min. 1, max 255.

L4 Source Port

Equal To, Not Equal To

Min. 1, Max 65535

L4 Destination Port

Equal To, Not Equal To

Min. 1, Max 65535

Pattern Match

Filters packets based on 4-byte hexadecimal patterns anywhere in the first 256 bytes.

Equal To, Not Equal To

Cisco Security Packet Analyzer Decode Window

describes the critical fields on the Cisco Security Packet Analyzer window.

Table D-65 Packet Browser

Field

Description

No.

Packet numbers, listed numerically in capture sequence. If the decode (display) filter is active, the packet numbers might not be consecutive.

Time

Time the packet was captured relative to the first packet displayed (not the first packet in the session). To see the absolute time, see the Detail window.

Source

Packet source, which might be displayed as hostname, IP, IPX, or MAC address. To turn hostname resolution on and off for IP addresses, choose the Setup tab and change this setting under Preferences.

Destination

Packet destination, which might be displayed as hostname, IP, IPX, or MAC address.

Protocol

Top-level protocol of the packet.

Length

Size of the packet, in bytes.

Info

Brief text information about the packet contents.

Software Filter Dialog Box

describes key Software Filter dialog box fields.

Table D-66 Software Filter Dialog Box

Field

Description

Usage Notes

Name

Name of the software filter.

Enter the name of the software filter.

Source Address /

Mask

Source address of the packets.

- For IP, IPIP4, GRE.IP, or GTP.IPv4 addresses, enter a valid IPv4 address in dotted-quad format n.n.n.n, where n is 0 to 255. The default (if blank) is 255.255.255.255.

- For IPv6 or GTP.IPv6 addresses, enter a valid IPv6 address in any allowed IPv6 address format. For example:

– 1080::8:800:200C:417A

– ::FFF:129.144.52.38

Note See RFC 5952 for valid text representations.
is a hexadecimal number from 0 to 9 or a to f. The default is ff ff ff ff ff ff.

The mask applied to the source address.

- If a bit in the Source Mask is set to 1, the corresponding bit in the address is relevant.

- If a bit in the Source Mask is set to 0, the corresponding bit in the address is ignored.

Destination Address / Mask

Destination address of the packets.

- For IP, IPIP4, GRE.IP, or GTP.IPv4 addresses, enter a valid IPv4 address in dotted-quad format n.n.n.n, where n is 0 to 255. The default (if blank) is 255.255.255.255.

- For IPv6 or GTP.IPv6 addresses, enter a valid IPv6 address in any allowed IPv6 address format. For example:

– 1080::8:800:200C:417A

Note See RFC 5952 for valid text representations.
ff ff ff ff ff ff.

The mask applied to the destination address.

- If a bit in the Dest. Mask is set to 1, the corresponding bit in the address is relevant.

- If a bit in the Dest. Mask is set to 0, the corresponding bit in the address is ignored.

Network Encapsulation

The protocol to match with the packet.

Both Directions (check box)

This check box indicates whether the filter is applied to traffic in both directions.

If the source is host A and the destination is host B, enabling both directions filters packets from A to B and B to A.

If the source is host A and the destination is not specified, enabling both directions filters packets both to and from host A.

The “both directions” check box also affects the ports and not only the addresses (the same logic applies).

VLAN Identifier(s)

The 12-bit field specifying the VLAN to which the packet belongs.

Choose a VLAN Range or enter an individual VLAN IDs.

Packet Analyzer filters the first VLAN only. If you include a range, note this limitation.

The VLAN ID can range from 1-4095.

TCP Flag Bits

- URG – Indicates that the urgent pointer field is significant.

- ACK – Indicates that the acknowledgment field is significant.

- PSH – Indicates Push function.

- RST – Indicates to reset the connection (You can see this on rejected connections).

- SYN – Indicates that it synchronizes sequence numbers (You can see this on new connections).

- FIN – Indicates that there is no more data from sender (You can see this after a connection is closed).

This is for TCP packets only. The six flags can be selected individually or combined with other flag(s) using AND/OR logic. Only packets that have those selected flags set will be captured.

Application 2

drop list to filter by application.

Select one protocol to capture from the Application drop-down list.

Source Port(s)

radio button to filter by port.

Enter one or more ports separated by commas.

Destination Port(s)

Enter one or more ports separated by commas.

IP Protocol

Choose TCP, UDP, or SCTP. No selection (default) means that any will be allowed.

2.The application filter can be used to filter on the highest layer of the protocol parsing; that is usually a layer 4 protocol (based on port). If you want to filter on the transport protocol (for example, UDP or TCP), you will need to use the “IP Protocol” selector. Selecting, for example, TCP in the “IP Protocol” selector will filter on all packets using TCP.

2.The application filter can be used to filter on the highest layer of the protocol parsing; that is usually a layer 4 protocol (based on port). If you want to filter on the transport protocol (for example, UDP or TCP), you will need to use the “IP Protocol” selector. Selecting, for example, TCP in the “IP Protocol” selector will filter on all packets using TCP.

Capture Query Fields

Table D-67 Capture Query Dialog Box

Field

Description

Name

Enter the query name. It can only contain letters, numbers, "-" and "_". Maximum 63 characters are allowed.

Capture Session

Select the capture session that you want to query.

From Time

The start of the time range in which the query will look for packets. It is in seconds.

To Time

The end of the time range in which the query will look for packets. It is in seconds.

Protocol

Select TCP, UDP or All protocol.

Source IP Address

Enter the Source IP Address (IPv4/IPv6 address).

Destination IP Address

Enter the Destination IP Address (IPv4/IPv6 address).

Bi-Directional

If an IP is provided and if this check box is selected, the filter will search all the packets which has this IP as the source or destination IP.

This check box indicates whether the filter is applied to traffic in both directions. When this check box is selected, the query will search packets with the specified IP as either source or destination IP.

Filter

This will get populated automatically on entering the source and destination IP addresses. You can also enter the string manually. Maximum 255 characters are allowed.

Storage Location

Select the storage location.

Max PCAP File Size (MB)

Maximum size of each PCAP file (1-2000 MB).

Administration User Interface Windows

This section includes the following sections:

- System Overview

- SNMP Agent

- Preferences

- New User Dialog Box

- User Privileges

- Current User Sessions

System Overview

Table D-68 System Overview

Field

Description

Inputs Tab

Cumulative Input Statistics

Health and usage information on all the traffic received by the Packet Analyzer. It shows the number of packets received (Rx Packets), number of packets lost or dropped (Rx Packets Lost), and number of bytes received (Rx Bytes). The Cumulative column shows cumulative counts since the start of the Packet Analyzer, and the Rate column one shows the same counters for the last ten seconds.

Input Traffic

Usage information in bytes and packets based on the input you select. You can toggle between a chart or table format. Data is updated every 30 seconds and contains data from the past hour. The table time interval cannot be changed. The input table rate is calculated every 10 seconds. A table legend provides data for standard statistics provided by the software for data collected over a period of time.

at the bottom of Input Traffic chart.

Resources Tab

Date

Current date and time synchronized with the switch, router, or NTP server.

IPv4 Address

IPv6 Address

Based on your configuration, IPv4 address and/or IPv6 address displays.

System Uptime

Length of time the host has been running uninterrupted.

Disk Usage

Config, data, and root partitions with their total and free space. Also shows the amount of disk space used by the performance data base files (DB) and the packet capture to disk (capture files).

Use this information to ensure you have enough disk space and perform the needed maintenance as necessary.

Utilization

Percentage of memory resources being consumed by the Packet Analyzer as well as the total memory available.

CPU Usage

Percentage of CPU resources being consumed by the Packet Analyzer. Each individual CPU in a multi-CPU platform is listed separately.

SNMP Agent

Table D-69 System SNMP Agent Dialog Box

Field

Description

Location

(Optional) The physical location of the switch or router in which the Packet Analyzer is installed.

Community String

Add permission and community string information.

E-Mail Setting

Table D-70 Mail Configuration Options

Field

Description

Enable Mail

Enables e-mail of reports and notification of alarms

External Mail Server

IP address or hostnameof external mail server

Send Test Mail to

Optional. List e-mail addresses for up to three e-mail recipients.Use this as a verification of your mail setup.

Mail Alarm to

This recipient will receive alarm notifications and scheduled exports. Enter multiple addresses using space or comma delimiters.

Advanced Settings

Enables you to designate an e-mail access server port, as well as select a encryption protocol.

Mail Server Port

Optional. Designate an e-mail port for the Packet Analyzer.If your mail server is configured with a non-default server port number, use this field to ensure it works with Packet Analyzer.

Mail Server Encryption

Optional. Select Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption for e-mail messaging. Use these encryption protocols to authenticate servers and clients and  encrypt messages between you and Packet Analyzer.

Preferences

describes the critical fields of the Preferences window.

Table D-71 System View and Logging Preferences

Field

Description

Idle Timeout (1-1440 min)

An idle timeout is supported to prevent unauthorized access to the Packet Analyzer GUI or CLI. Default value is 30 minutes.

Refresh Interval (60-3600 sec)

Amount of time between refresh of information on dashboards. Default is 300.

Top N Entries (1-10)

Number of entries on the Top N charts. Default is 5. To view up to 100 entries, use the Table view versus the chart view.

Perform IP Host Name Resolution

Display hostnames instead of IP Addresses. This option performs translation using DNS lookup. Ensure you set your DNS nameserver parameters. See Setting Network Parameters.

Traffic Display Unit

Data displayed in graph and tables; Bits (default) or Bytes.

Response Time Display Unit

Default is automatic. Options include: microseconds, milliseconds, and seconds.

International Notation

Display options for numbering. May affect report accuracy; see the Cisco Bug Search tool for details.

Audit Trail

.

IP TOS Flow Key

Include type of service (TOS) data in the Packet Analyzer network flow. Select only if you are measuring Differentiated Services Code Point (DSCP) for monitored traffic. If you require ART and other flow-based analysis and expect that the TOS information in your network may change in an on-going flow, do not select TOS information to be part of flow configuration.

Note If TOS byte changes in an on-going flow this results in a new flow being created. If this option is not selected, the entire flow transaction is treated as one flow regardless of a TOS change in this flow.
If your network configuration allows the IP TOS value to change dynamically during the life of a flow, and you enable the IP TOS Flow Key option, then the ART and application classification features may not work accurately. These features are based on the state of each flow, and rely on seeing all the packets for a flow grouped together. However, if the IP TOS value changes during a flow, then that flow will be broken into two or more flows when the IP TOS is used as a key. Disabling the IP TOS Flow Key option will correct these issues. However, in this case your DSCP statistics becomes inaccurate because only the first IP TOS value will be recorded for each monitored flow.

See Using Packet Analyzer to Monitor QoS/DiffServ (DSCP).

New User Dialog Box

describes the critical fields in the New User dialog box.

Table D-72 New User Dialog Box

Field

Description

Usage Notes

Password

Verify Password

The account password

Enter a password that adheres to your site security policies.

Privileges

Privileges associated with this account

Select each privilege to grant to the user.

User Privileges

describes the critical fields in the User Privileges window.

Table D-73 User Privileges

Privilege

Access Level

Report

Enables a user to schedule and view the saved reports through the web interface, as well as access the saved reports through file sharing. See Sharing Files for details.

AccountMgmt

Enables a user to create, delete, and edit user accounts.

SystemConfig

Enables a user to edit basic Packet Analyzer system parameters such as IP address, gateway, HTTP port, and so on.

Capture

Enables a user to perform packet captures, manage capture sessions, use the Cisco Security Packet Analyzer to decode packet data and access capture files through file sharing.

AlarmConfig

Enables a user to create, delete, and edit alarms on the switch/router and Packet Analyzer.

MonitorConfig

Enables a user to create, delete, and edit the following:

- Collections and reports

- Protocol directory entries

- Protocol groups

- URL-based applications

MonitorView

Enables a user to view monitoring data and reports (granted to all users).

TACACs+ Authentication and Authorization

Table D-74 TACACS+ Authentication and Authorization Dialog Box

Field

Usage Notes

Enable TACACS+ Authentication and Authorization

Determines whether TACACS+ authentication and authorization is enabled.

- To enable, check the check box.

- To disable, uncheck the check box.

Primary TACACS+ Server

Enter the IP address of the primary server.

Backup TACACS+ Server

Enter the IP address of the backup server (optional).

Note If the primary server does not respond after 30 seconds, the backup server will be contacted.

Secret Key

Enter the TACACS+ secret key.

Verify Secret Key

Reenter the TACACS+ secret key.

Current User Sessions

describes the critical fields in the Current User Sessions window.

Table D-75 Current User Sessions

Field

Description

From

The name of the machine the user logged in from.

Last Activity

The time stamp of the last user activity.

Report Descriptions

lists the MIB objects supported by the Packet Analyzer.

Table D-76 Packet Analyzer RMON Support

Description

Source

MIB-II: All groups except Exterior Gateway Protocol (EGP) and transmission.

RFC 1213

RMON-MIB: Alarm and Event groups only

RFC 2819

RMON2: trapDestTable only

RFC 2021

CDP-MIB: Cisco Discovery Protocol

EntityMIB

RFC 2737

Troubleshooting Network and Packet Analyzer Issues

This appendix addresses some common issues you might encounter while using Cisco Security Packet Analyzer Software as well as how to use Packet Analyzer to troubleshoot Packet Analyzer network connection issues.

This appendix contains the following topics:

- Resolving Typical Packet Analyzer Issues

- Troubleshooting Login Issues

- Understanding Typical Error Messages

- Troubleshooting WAAS Data Issues

- Troubleshooting Video Streams

- Using the CLI to Troubleshoot Issues

Resolving Typical Packet Analyzer Issues

on my dashboard reports. What should I do?

You may have created a filter that needs to be changed in order to see data. Use the Interactive Report Filter to do any or all of the following actions until your data displays:

– Change the site filters

– Change the application filter

– Incrementally expand the time range from the default to a greater time range

Review the following question for additional details if this does not resolve your issue.

Q. I am sending traffic to the Packet Analyzer but nothing comes up on the default monitoring page. What could be wrong?

There are two typical issues that are seen when first setting up traffic to the Packet Analyzer:

– Wait for at least five minutes after traffic is sent to the Packet Analyzer. Packet Analyzer collects and displays information at intervals and traffic may not display in charts immediately.

– Ensure the client time is synchronized with the Packet Analyzer time. Typically this means setting your NTP server to synchronize your Packet Analyzer time. For details, see Synchronizing Your System Time.

Q. What information should I collect and what else should I do when the Packet Analyzer is not responding?

Determine the answers to the following questions and gather the following information:

- Does session from the switch/router CLI work?

- Does ping over EOBC (127 subnet) work?

- Does ping to the management IP address work?

- Collect output of show tech-support command from both the Packet Analyzer and the switch or router.

- Collect core files.

- Check if Packet Analyzer hardware is seated correctly in chassis

Perform the following tasks to troubleshoot your issue:

- Reset Packet Analyzer

- Reset into maintenance image or helper

- Clear the configuration

- Reinstall the application image (using the -- reformat option)

Q. How can I view Packet Analyzer log files and send them to TAC for review?

. Save the files to your local disk. You can analyze the files locally or, if requested forward on to your technical support team for review.

Troubleshooting Login Issues

Log into the Packet Analyzer by using the username and password that the Packet Analyzer administrator provided you, and click the Login button. If you are having problems logging in:

- Make sure you are using a browser that is currently supported for use with Packet Analyzer:

Mozilla Firefox ESR 38 or Microsoft Internet Explorer 11 (Microsoft Internet Explorer 7 is not supported)

- Make sure you are using a platform that is currently supported for use with Packet Analyzer:

Microsoft Windows XP or Microsoft Windows 7. The Macintosh platform is not supported on this release.

- Clear the browser cache and restart the browser (not necessary if installing Packet Analyzer for the first time).

- Make sure cookies are enabled in your browser.

- If you see the following message: “Initializing database. Please wait until initialization process finishes,” you must wait until the process finishes.

- Make sure your username and password does not use any special characters.

- If your platform requires licensing, make sure you accepted the license agreement and that the license has not expired.

To view the full documentation set (including the User Guide and Release Notes) for the Cisco Packet Analyzer software, go to the Packet Analyzer software Technical Documentation area on Cisco.com:

- http://www.cisco.com/en/US/products/sw/cscowork/ps5401/

tsd_products_support_series_home.html

Understanding Typical Error Messages

Q. I’m waiting for the graphical data to populate on a dashboard. What does this red error “Request Error -- Please Try Again” mean?

This means an internal error has occurred, or the login session may have timed out.

Q. I’m waiting for the graphical data to populate on a dashboard. What does this red error “Query resulted in no data” mean?

button to check the filter settings and data sources to make sure the Packet Analyzer is getting data. You can also check the Overview page to ensure the traffic is reaching the Packet Analyzer. If no traffic appears, check your data sources and SPAN session configuration.

Q. What does the message “Client or Packet Analyzer time is incorrect” mean?

The browser or client time and the Packet Analyzer time must be synchronized to avoid this error. See Synchronizing Your System Time.

Frequently Asked Questions about Packet Analyzer Behavior

Q. How does Packet Analyzer calculate network latency?

To calculate network latency, the software looks at each packet and associates it to a transaction. For example, Packet Analyzer looks at SYN and SYN-ACK and timestamps these packets to perform these calculations.

Q. How can Packet Analyzer be restricted to one tenant’s traffic when using SPAN or ERSPAN on a Nexus 1000V?

Packet Analyzer can be deployed per tenant so they each Packet Analyzer has their own portal. Packet Analyzer processes VxLAN, LISP, FabricPath, and OTV for multiple tenants.

Q. Why is the browser behaving strangely? It is displaying data for no apparent reason or is not displaying expected data.

Clear the browser cache, close the browser, and open a new session and try again. Also, make sure you are using a supported browser.

Q. Why is the Packet Analyzer performance lower than expected?

Disk capture will reduce the Packet Analyzer performance considerably. It is due to the disk input/output speed. You will see a warning in the top right corner of the window.

Q. Why won’t the system change the storage option for my capture session from disk to memory and then back to disk?

state. You cannot delete the capture session to release the disk for capture. The workaround is to reboot the Packet Analyzer. This has been fixed in the latest patch (patch 5) on the Cisco software download web page.

Q. What MIBs do the Packet Analyzer support?

lists the MIB objects supported by Packet Analyzer.

Table E-1 Supported MIBs

Description

Source

MIB-II: All groups except Exterior Gateway Protocol (EGP) and transmission.

RFC 1213

RMON2: trapDestTable only

RFC 2021

CDP-MIB: Cisco Discovery Protocol1

EntityMIB

RFC 2737

1.CDP is received on Packet Analyzer management ports only. Packet Analyzer does not transmit CDP packets.

1.CDP is received on Packet Analyzer management ports only. Packet Analyzer does not transmit CDP packets.

Q. Which platforms require MIBs?

Packet Analyzer does not require MIBs.

Troubleshooting WAAS Data Issues

Q. Why does Packet Analyzer display the status of WAAS devices as pending?

Packet Analyzer is unable to monitor WAAS traffic until you set up WAAS monitored servers. To change the pending status, you must set up WAAS monitored servers. See your product documentation for more details.

Q. Why is no WAAS data seen in the Monitor windows?

Perform the following steps:

- Use the Packet Analyzer GUI to verify that the Monitored Servers list is configured with the correct server IP addresses.

- Use the Packet Analyzer GUI to verify that WAAS data sources have data collection enabled for applicable segments.

- Use the WAAS CLI show statistics flow filters to verify that the servers have active traffic flows that are optimized and monitored.

- Use the WAAS CLI show statistics flow mon tcpstat to verify that WAAS Flow Agent exports flow data to the correct Packet Analyzer IP address.

Q. The WAAS is not sending data to the Packet Analyzer, and the reports are not showing any values.

, and check the “Filter Response Time for all Data Sources by Monitored Servers” check box.

Troubleshooting Video Streams

Use Packet Analyzer to monitor the network to ensure that the video quality is good. If quality issues appear, isolate and troubleshoot the problem rapidly as follows:

- Choose Analyze > Media to view the Video Streams. You can access this from the Video Streams Conversation table by clicking a specific stream or from the Video Channels Table window by clicking the stream that is associated with the video signaling stream. This chart indicates current video quality of all video streams that are being monitored. I/All frame loss rate are the main metrics to indicate the video quality. High loss rate indicates poor quality and low loss rate indicates excellent quality. Use the Top N Video Streams source and destination endpoints to view whether there are video streams in the poor range.

- To isolate video streams that have poor quality, scroll down to Top N Video streams and click the chart to drill down into the Video Stream details. You can examine the I/All frame loss rate together with other metrics to determine the main cause for poor quality. If the video stream is MPEG-TS stream, you can also look at the MDI metrics to determine whether DF/MLR is large.

- With the endpoint’s IP addresses, you can look at the network topology to identify where your subnet is located in the network.

Using the CLI to Troubleshoot Issues

- Locating Packet Drops

- Handling an Unresponsive Packet Analyzer

- Using the CLI to Troubleshoot Performance Agent (PA)

Locating Packet Drops

Q. How can I find out using the CLI if packets are being dropped?

The following CLI command shows packet drops at different layers of the Packet Analyzer system at 5 minute intervals and up to the last 24 hours:

root@NAM3-18.cisco.com# show pkt-drop-counters Hour-0

Start time of the hour: 2010-11-05 13:00 PDT

Time hardware pkts dropped FM pkts dropped ART pkts dropped

13:05 3548 0 0

13:10 3354 0 0

13:15 2843 0 0

13:20 2629 0 0

13:25 3592 0 0

13:30 3298 0 0

13:35 1823 0 0

13:40 2549 0 0

00:00 0 0 0

00:00 0 0 0

00:00 0 0 0

00:00 0 0 0

Handling an Unresponsive Packet Analyzer

Q. Why is my Packet Analyzer Blade not responding?

Do the following:

- Check the Packet Analyzer IP configuration (using the CLI command show ip )

- Check VLAN configuration of management port on Sup:

analysis module <slot> management-port access-vlan <#>

- Does the session from the switch/router work?

- Does a ping to Packet Analyzer mgmt IP address work?

- What is the module status on Sup/router?

show modules CLI

Using the CLI to Troubleshoot Performance Agent (PA)

Q. Why is the Packet Analyzer not receiving data from PA?

Packet Analyzer no longer uses Performance Agent as a remote data source. Use Prime Infrastructure or Prime Assurance to collect PA data.

Cisco Security Packet Analyzer User Guide

Release 6.2(2)

October 2016

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco Security Packet Analyzer User Guide

© 2005-2016 Cisco Systems, Inc. All rights reserved.