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.
Step 1 View RTP Streams using the menu selection
Analyze > Media
. 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 126.96.36.199 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.
Navigate to that Packet Analyzer and go to the menu selection
Analyze > Managed Device > Interface
. 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.
The following overview describes the steps to complete in Prime Infrastructure to set up Packet Analyzer to view multiple Packet Analyzer on your dashboard. For details steps, see the
Prime Infrastructure User Guide
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 other troubleshooting tips on how to use Packet Analyzer with Prime Infrastructure, see the
Prime Infrastructure User Guide.
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.
Ask your Cisco representative about the Cisco Security Packet Analyzer
API Programmer’s Guide
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:
Step 1 Using a Packet Analyzer 2x20 deployed at the data center, measure application response time before WAAS is enabled using
Analyze > WAN Optimization > Top Talker Detail
. 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.
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.
Step 1 Choose
Setup > Network > DSCP Groups
to display the default groups.
Step 2 Choose
Administration > System > Preferences
to turn the IP TOS Flow Key on. Use caution since this option affects ART and other flow-based traffic. See
Step 3 Choose
Analyze > Traffic > DSCP
to find any misclassified traffic. In Figure 6-5, the RTP protocol is displayed for ToS0 classification.
Figure 6-5 DSCP Group - ToS0
Step 4 Click on the
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
Step 6 Left-click on the RTP graph and select
Application Traffic by Host
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 >
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:
Step 1 Start capturing traffic rates between the branch and the data center. View the traffic for the last month from
Interactive Report > Filter > Time Range > Custom
(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:
Step 1 Set up thresholds to focus on which types of performance metrics you want to monitor at
Setup > Alarms > Thresholds
Step 2 View voice signaling/RTP traffic at
Analyze > Media > RTP Streams
Analyze > Media > Voice Call Statistics
See Analyzing Traffic, RTP Streams.
, Media Monitor Setup Window.