Table Of Contents
Diagnostics for Video Endpoints
Features of the Troubleshooting Workflow
Features of the Troubleshooting Workflow for Sessions
Features of the Troubleshooting Workflow for Endpoints
Support Matrix for Troubleshooting Source and Destination Endpoints
Traceroute Command
Cisco Performance Monitor
Starting a Troubleshooting Workflow
Troubleshooting for an MSI-enabled Device
Analyzing Troubleshooting Data
Troubleshooting
Logs
Medianet Path View
CPU and Memory
CPU and Packet Loss
Video IP Bit Rate and Packet Loss
Video Interarrival Jitter and Packet Loss
IP DSCP and Packet Loss
Medianet Enabled Network
Mediatrace Diagnostics
View All Flows
Path Assessment
Exporting Troubleshooting Data
Understanding the Export Troubleshooting Report
Diagnostics for Video Endpoints
You must understand the Prime Collaboration discovery workflow before reviewing this section. For information on the device discovery process, see Discovering Devices.
During the troubleshooting workflow, the devices are polled, based on the values defined for the System Status Polling Interval, Interface Statistics Polling Interval, and Flow Statistics Polling Interval in the Device Monitoring Configuration page.
During the troubleshooting workflow, the endpoints and conference devices are polled every minute to check the status.
For Cisco 500, 1000, and 3000 Series TelePresence Systems, Cisco Unified IP Phone 8900 and 9900 Series, and Cisco Cius, the Prime Collaboration discovery ends after discovering the Layer 2 devices for an endpoint. That is, Prime Collaboration discovers the switches and first hop router to which an endpoint is connected.
The Layer 3 devices between the endpoints are discovered during the troubleshooting workflow. The newly discovered devices are added to the Prime Collaboration inventory. The network topology is discovered using CDP, and the links between devices are persisted in the Prime Collaboration database.
For Cisco C and Ex series TelePresence Systems, Cisco MXP series TelePresence System, Polycom, and Cisco Jabber, the Layer 3 devices between the endpoints are discovered during the troubleshooting workflow. The Layer 2 devices to which an endpoint is connected are not discovered during the Prime Collaboration discovery.
You can view details, such as CPU utilization, memory utilization, interface, and so forth for a network device. In addition to the system details, the fault information is also displayed for a device.
Note 
The troubleshooting workflow impacts the Prime Collaboration system performance. Add a session or an endpoint to the watch list only if it is required.
Figure 22-1 shows the flow diagram for the troubleshooting workflow for a session.
Figure 22-1 Prime Collaboration Troubleshooting Workflow for a Session
Features of the Troubleshooting Workflow
The following are the key features of the troubleshooting workflow:
•It can be started automatically or manually:
–Automatic troubleshooting is triggered when the session is added to the watch list.
–Automatic troubleshooting is triggered when one of the endpoints is in the watch list. You can start a troubleshooting workflow only if the endpoints are in the Managed state.
–Automatic troubleshooting is triggered if the value for packet loss, jitter, or latency alarm exceeds the defined threshold value. This is applicable only for a point-to-point session.
Automatic troubleshooting is not triggered when the packet loss, jitter, or latency alarm occurs in a multipoint session.
–Manual troubleshooting can be started from the Session Monitoring page.
See Starting a Troubleshooting Workflow for details on how to start a troubleshooting workflow for sessions and endpoints.
•For a point-to-point session, the troubleshooting is performed between two endpoints. You can select the direction for troubleshooting between the endpoints, if you are manually starting the troubleshooting workflow.
•For a multipoint session, troubleshooting is performed between a multipoint switch and endpoints. The troubleshooting direction is from an endpoint to a multipoint switch, not in the reverse direction.
•When there is a packet loss, jitter, or latency alarm between the two endpoints, the troubleshooting workflow starts if you have configured for the automatic troubleshooting; when this alarm is cleared, the troubleshooting workflow stops.
•For Cisco C and Ex Series and MCU (point-to-point, multipoint, and multisite):
–Troubleshooting is supported between two endpoints.
–Troubleshooting is not supported between an endpoint and MCU. That is, you cannot troubleshoot from an endpoint to MCU and vice versa.
•Troubleshooting is supported between an endpoint and Cisco TelePresence Server. The troubleshooting direction is from an endpoint to Cisco TelePresence Server, not in the reverse direction.
•Troubleshooting is supported between an endpoint and Cisco MSE. The troubleshooting direction is from an endpoint to Cisco MSE, not in the reverse direction.
•Troubleshooting is supported between an endpoint and Cisco VCS. The troubleshooting direction is from an endpoint to Cisco VCS, not in the reverse direction.
•You can view the third party devices as part of the topology in the session troubleshooting page (from Session Diagnostics). However, you cannot view the performance and other troubleshooting statistics details for third party devices.
For Polycom endpoints, troubleshooting data is collected only when the first hop router is a Cisco device and it is in the Managed state. The router must be configured with read and write CLI access.
•If the endpoint is in an Unknown state, you cannot troubleshoot from and to this endpoint.
•The troubleshooting workflow lasts for a maximum of four hours from the time it is started. If the troubleshooting workflow does not end within this time, Prime Collaboration ends the workflow automatically.
•You can have a maximum of 50 concurrent troubleshooting workflows at a time; that is, you can have 10 VSAA troubleshooting sessions, 30 reactive troubleshooting sessions, and 10 proactive troubleshooting sessions simultaneously.
If this limit is exceeded, an error message is displayed in the troubleshooting log file.
Features of the Troubleshooting Workflow for Sessions
The following are the key behaviors of the troubleshooting workflow, when scheduled sessions are added to the watch list:
•The automatic troubleshooting workflow starts for all sessions added to the watch list.
•In a multipoint session, the troubleshooting starts as soon as the endpoints join the session.
•In a multipoint session, if a troubleshooting is stopped for an endpoint, the troubleshooting workflow continues for the other endpoints in the session. You need to manually start the troubleshooting for this endpoint.
•In a multipoint session, if an endpoint restarts because of a problem, a new troubleshooting workflow is triggered for this endpoint after it rejoins the session. There is no impact on the other endpoints in the session.
•If a session is removed from the watch list, the associated troubleshooting workflow stops, provided:
–There are no packet loss, jitter, or latency alarms triggered for that session.
–There are no manually triggered troubleshooting workflows.
•If a troubleshooting workflow is triggered because of a packet loss, jitter, or latency alarm, the troubleshooting workflow stops when the packet loss, jitter, or latency alarm is cleared, provided:
–The session is not added to watch list.
–There are no manually triggered troubleshooting workflows.
–The troubleshooting workflow is manually stopped, or the session ends.
•If a troubleshooting workflow is triggered manually, the troubleshooting workflow can only be stopped manually; otherwise, it stops when the session ends.
•If a session is added again to the watch list, a new troubleshooting workflow starts.
Features of the Troubleshooting Workflow for Endpoints
You can start a troubleshooting workflow only if the endpoints are in the Managed state. The following are the key behaviors of the troubleshooting workflow, when an endpoint is added to the watch list:
•The automatic troubleshooting for an endpoint starts as soon as it joins a session. You can stop the troubleshooting workflow for a session that is associated with an endpoint (added to a watch list). You need to manually start the troubleshooting for this session.
•During the session, if an endpoint is removed from the watch list, the troubleshooting stops for that endpoint.
•If a session and the associated endpoints are part of the watch list and if an endpoint is removed from the watch list, the troubleshooting workflow continues for the session until it ends.
•If a session and the associated endpoints are part of the watch list and if the session is removed from the watch list, the troubleshooting workflow continues for the endpoints, until they disconnect from the session. That is, if the session and endpoints are part of the watch list, the endpoints are given higher priority.
•CDP needs to be enabled on all network devices if troubleshooting path trace is desired.
If CDP cannot be enabled on any of the devices, you can use Cisco Mediatrace to check whether the adjacent Layer 3 nodes on the media path are directly connected and what ingress and egress interfaces are used.
•For routers and switches, CLI login credentials are required if Medianet-based troubleshooting is desired. Also, privileged EXEC level (level 15) access is required.
•When you start troubleshooting from an MSI-enabled endpoint, Mediatrace will start from the MSI-enabled endpoint itself (not from the nearest Medianet-enabled router). In addition, the Mediatrace Flow Information is not displayed for the source MSI-enabled endpoint from where Mediatrace is initiated.
Support Matrix for Troubleshooting Source and Destination Endpoints
The following table shows the details of troubleshooting support between source and destination endpoints:
Source
|
Destination
|
CTS
|
CTS, CTMS, C_CODEC, TPS, CIUS, MXP, IP Phone, Cisco Jabber
|
C_CODEC
|
CTS, CTMS, VCS, C_CODEC, TPS, CIUS, MXP, MSE Blade, IP Phone, Cisco Jabber, SBC
|
CIUS
|
CTS, CTMS, C_CODEC, TPS, CIUS, MXP, IP Phone, Cisco Jabber
|
MXP
|
CTS, CTMS, VCS, C_CODEC, TPS, CIUS, MXP, IP Phone, Cisco Jabber
|
Phone
|
CTS, CTMS, VCS, C_CODEC, TPS, CIUS, MXP, IP Phone, Cisco Jabber
|
Cisco Jabber
|
CTS, CTMS, VCS, C_CODEC, TPS, CIUS, MXP, IP Phone, Cisco Jabber
|
Switch
|
Switch, Router
|
Router
|
Switch, Router
|
SBC
|
C_CODEC, MCU
|
Traceroute Command
Endpoints with the traceroute or traceroute equivalent command enabled show the path or direction of troubleshooting. While most endpoints have this command enabled, few endpoints such as Cisco Jabber and Polycom do not support this.
For the endpoints that do not support the traceroute or traceroute equivalent command, the First Hop Router (FHR) is determined first. Pathtrace is performed from the first hop router to the destination endpoint. After this is complete, the source endpoint to the first hop router is stitched, and the complete path from source endpoint to destination endpoint is shown in the path topology. The first hop router information is available for endpoints such as Cisco Cius, IP Phones, and so on using the HTTP interface of the device.
For certain endpoints, such as the Cisco Jabber and Polycom, Prime Collaboration cannot get the First Hop Router information from the endpoint itself. For these endpoints, Prime Collaboration initiates the traceroute command from the linux virtual machine appliance to the source endpoint. The result of the traceroute command is processed and the last hop router before the endpoint in Prime Collaboration's traceroute is considered as first hop router for the endpoint.
Cisco Performance Monitor
Cisco Performance Monitor enables you to monitor the flow of packets in your network and become aware of any issues that might impact the flow before it starts to significantly impact the performance of the application. Performance monitoring is especially important for video traffic because high quality interactive video traffic is highly sensitive to network issues. Even minor issues that may not affect other applications can have dramatic effects on video quality.
You can verify whether the Cisco IOS Performance Monitor is configured on the device using Prime Collaboration Inventory.
SNMP access is required for performance monitoring (CLI access is not required).
Table 22-1 lists resources for additional information.
Starting a Troubleshooting Workflow
You can start the troubleshooting workflow for a session from the 360° Session View in the Session Monitoring page.
You can start the troubleshooting workflow for an endpoint from the quick view window (see Table 22-2) in the Endpoint Monitoring page.
Figure 22-2 Starting Troubleshooting from the Endpoint Monitoring Page
1
|
The Endpoint Name column
|
2
|
Rest your mouse pointer over the endpoint for which you want to start the troubleshooting and click the quick view icon.
|
3
|
Add to Watch List link.
|
|
|
Table 22-2 Launch Points for the Troubleshooting Workflow
Troubleshooting Type
|
Launch Points
|
Automatic
|
1. Choose Administration > Alarm and Event Configuration > Threshold Settings > TelePresence Endpoint.
2. Set the threshold value for Rx Packet Loss, Average Period Jitter, and Average Period Latency, based on your requirement.
3. Click Save.
|
|
Automatic
|
1. Choose Operate > Diagnose > Session Diagnostics.
2. Select a scheduled session.
3. Rest your mouse pointer over the Session Subject column in the Video Collaboration Sessions table and click the 360° Session view icon.
4. Click Add to Watch List.
|
Automatic
|
1. Choose Operate > Diagnose > Endpoint Diagnostics.
2. Select an endpoint, which is in the Not In Use usage status.
3. Rest your mouse pointer over the Endpoint Name column in the List of Endpoints table and click the quick view icon that appears.
4. Click Add to Watch List.
The troubleshooting workflow starts as soon as the endpoint joins a session.
|
Manual
|
1. Choose Operate > Diagnose > Session Diagnostics.
2. Select an in-progress session. We recommend that you select an alarmed in-progress session.
3. Rest your mouse pointer over the Session Subject column in the Video Collaboration Sessions table and click the 360° Session view icon.
4. Click  icon to launch the Troubleshooting page and select the direction from where you want to start the troubleshooting.
|
Manual
|
1. Choose Operate > Diagnose > Session Diagnostics.
2. Select an in-progress session. We recommend that you select an alarmed in-progress session.
3. Rest your mouse pointer over the network link (if there is an alarm on the network link) in the session topology pane and click the 360° Session view icon.
4. Click Troubleshoot Network Link.
|
Manual
|
1. Choose Operate > Diagnose > Endpoint Diagnostics.
2. Select an endpoint, which is in the In Use usage status.
3. Rest your mouse pointer over the Endpoint Name column in the List of Endpoints table and click the quick view icon.
4. Click Add to Watch List.
The troubleshooting workflow starts immediately.
|
Troubleshooting for an MSI-enabled Device
Cisco Mediatrace enables you to isolate and troubleshoot network degradation problems for data streams. When Mediatrace-capable devices are deployed in the network, Prime Collaboration provides network path visibility, down to the granularity of video flow statistics.
If an endpoint supports Media Services Interface (MSI) for Mediatrace, Prime Collaboration will use this interface to obtain Mediatrace information, discover media path, and collect statistics for the various midpoints.
If MSI is not enabled on an endpoint, Prime Collaboration will log into the endpoint, obtain 5 tuple information, and use that information to start Mediatrace from a nearby router or switch.
When you start troubleshooting from a MSI-enabled endpoint, Mediatrace will start from MSI-enabled endpoint itself (not from the nearest Medianet enabled router).
MSI-enabled endpoints are displayed with Medianet badge (see Figure 22-3) in the troubleshooting path topology.
Note MSI-enabled endpoints must be discovered using the MSI credentials. For more information on MSI credentials, see Credential Profiles Field Descriptions.
Figure 22-3 Troubleshooting for MSI-enabled Endpoint
Analyzing Troubleshooting Data
During the troubleshooting job, the path between the endpoints is discovered. After the path is discovered, the network device details are collected. The inventory is updated with the discovered network devices details.
After the troubleshooting job is completed the following data is displayed:
•Troubleshooting
•Logs
•Medianet Path View
•Path Assessment
Troubleshooting
You can view the topology (Layer 2 and Layer 3) for the selected direction between endpoints in the Troubleshooting tab (see Figure 22-4).
•A straight line between the devices indicates that the devices are directly connected to each other and Prime Collaboration is able to discover the devices.
•A dotted line between the devices indicates that the devices may not be connected and Prime Collaboration is not able to discover the devices, based on the CDP link details.
Figure 22-4 Troubleshooting Result
1
|
Troubleshooting results tab. Based on the configurations (mediatrace, performance monitor) on the devices, some of the tabs may not be displayed.
|
2
|
Devices that contains the NAM application are displayed with an additional badge on the device.
|
3
|
Mediatrace enabled devices are displayed with an additional badge on the device.
|
4
|
Inaccessible devices are displayed in gray.
|
5
|
An alarm badge on the endpoint indicates that there is a fault in the endpoint.
|
6
|
An information badge on a discovered device indicates that there is an issue with the Memory, CPU utilization, and/or Call Quality Statistics (RTP Packet Loss, RTP Packet Jitter, DSCP) for media flows. The threshold value for the Call Quality Statistics and utilization (memory and CPU) is defined in the TelePresence Monitoring Setting page (Administration > System Setup > Polling & Threshold).
|
If the devices are accessible, you can rest your mouse pointer over the device and click the quick view icon, to view the system, interface, and mediatrace flow details.
Note During troubleshooting, if a device is inaccessible, troubleshooting workflow skips that device. You must update the credentials, rediscover the device, and continue troubleshooting.
Table 22-3 lists the system, interface, and flow details that are listed in the quick view.
Table 22-3 System, Interface, and Flow Details
Field
|
Description
|
Hostname
|
Hostname configured for the device.
|
IP Address
|
IP address used for managing the device. You can launch to the endpoint or infrastructure device log in page, using this link.
|
Mediatrace Capable
This information is displayed only if you have enabled Mediatrace on the device.
|
Mediatrace Role
|
Configured Cisco Mediatrace role on the device.
|
IP SLA Role
|
Configured IP SLA role on the device.
|
Performance Monitor
|
Configured Performance Monitor.
|
System Status
|
Physical Memory Utilization (in%)
|
Percentage of the physical memory utilization.
|
Swap Memory Utilization (in%)
|
Percentage of the swap memory utilization.
|
CPU Utilization (in%)
|
Percentage of the CPU utilization.
|
System Status Multipoint Switch
|
Number of Active Meetings
|
Number of active sessions defined in the multipoint switch.
|
Number of Segments Used
|
Number of segments (individual video displays) being used.
|
Interface Details
|
Speed
|
Speed of the interface, in Mbps as specified in the snmpifSpeed object.
|
Administrative Status
|
Operational state of the interface as specified in the ifAdminStatus object.
|
Operation Status
|
Administrative status of the interface as specified in the ifOperStatus object.
|
Input Metrics
|
The data displayed are based on the RFC1213 MIB attributes.
|
Output Metrics
|
The data displayed are based on the RFC1213 MIB attributes.
|
Network Diagnosis
|
This is displayed only if you are managing these devices in the Cisco Prime NAM or Cisco Prime LMS.
|
Mediatrace Flow Information
|
The following information is a consolidated report for all managed codec on the device. This information is displayed only if you have enabled Mediatrace on the device.
|
DSCP
|
DSCP value configured on the device.
|
IP Packet Drop Count
|
Number of IP packets dropped.
|
RTP Packet Loss
|
Packet loss indicated by the Real-time Transport Protocol (RTP).
|
RTP Packet Jitter (RFC 3550)
|
Jitter indicated by the Real-time Transport Protocol (RTP).
|
Ingress Interface
|
Details on ingress interface.
|
Egress Interface
|
Details on egress interface.
|
View All Flows
|
The flow information is displayed only if you have configured Cisco IOS Performance Monitor on the device.
|
Prime Collaboration inventory uses the DNS name (or the IP address if the DNS name is unavailable) for all devices. But the sysname is displayed for all midpoints in the troubleshooting path topology. The DNS name or IP address of the midpoint is displayed in the quick view.
During troubleshooting, if a device is inaccessible, the troubleshooting workflow skips that device. You must update the credentials, rediscover the device, and continue troubleshooting.
Logs
You can view the detailed troubleshooting workflow status using the Log tab. The log file contains the following information:
•When the troubleshooting workflow started and ended.
•How the troubleshooting started and whether it is automatic or manual.
•When the endpoint system details were retrieved.
•When the path discovery started and ended.
•Whether there were any problems while retrieving the path topology details.
•When the polling started.
•Faults that occurred in any of the devices in the path topology.
Medianet Path View
The Medianet Path View contains output from each mediatrace-enabled device. Prime Collaboration analyzes and shows hop and statistics information for Mediatrace sessions (video flows).
The following graphs are displayed in the Medianet Path View:
CPU and Memory
This graph is displayed for all devices and includes the following information (see Figure 22-5):
•The vertical axis (y-axis) provides 1-minute CPU utilization details as a percentage.
•The horizontal axis (x-axis) provides lists of all network devices that were discovered during the path trace. The devices in gray indicate that the Cisco Mediatrace is not configured.
•The spheres in the graph provides the processor memory utilization details as a percentage. The tool tip on the sphere indicates the exact memory utilization value.
•The size of the sphere varies, based on the processor memory utilization. The smaller the sphere size, the less the processor memory utilization.
Figure 22-5 CPU and Memory Graph
Click on the sphere (red icon) to view the system, interface, and mediatrace flow details.
CPU and Packet Loss
This graph is displayed only for Cisco Mediatrace-configured devices. It displays the following information (see Figure 22-6):
•The vertical axis (y-axis) provides the 1-minute CPU utilization details as a percentage.
•The horizontal axis (x-axis) provides lists of all network devices that were discovered during the path trace. The devices in gray indicate that the Cisco Mediatrace is not configured.
•The spheres in the graph provides video packet loss details as a percentage:
–Green sphere indicates that the video packet loss is zero.
–Orange sphere indicates that the video packet loss is more than 1%. The size of the sphere varies, based on the video packet loss. The smaller the sphere size, the less the video packet loss.
You can click on the sphere to further analyze the packet loss at the interface-level.
–Blue square box indicates that the mediatrace is not configured on the device and hence the video packet loss data are not available.
Figure 22-6 CPU and Packet Loss Graph
Click on the sphere or square box (red icon) to view the system, interface, and mediatrace flow details.
Video IP Bit Rate and Packet Loss
This graph is displayed only for Cisco Mediatrace-configured devices. It displays the following information (see Figure 22-7):
•The vertical axis (y-axis) provides the video IP bit rate in kilobits per second (kbps).
•The horizontal axis (x-axis) provides lists of all network devices that were discovered during the path trace. The devices in gray indicates that the Cisco mediatrace is not configured.
•The spheres in the graph provides the video packet loss details as a percentage.
–Green sphere indicates that the video packet loss is zero.
–Orange sphere indicates that the video packet loss is more than 1%. The size of the sphere varies, based on the video packet loss. The smaller the sphere size, the less the video packet loss.
You can click on the sphere to further analyze the packet loss at the interface-level.
–No sphere indicates that the Cisco Mediatrace is not configured on the device and hence the video packet loss data are not available.
Figure 22-7 Video IP Bit Rate and Packet Loss Graph
Click on the sphere (red icon) to view the system, interface, and mediatrace flow details.
Video Interarrival Jitter and Packet Loss
This graph is displayed only for Cisco Mediatrace-configured devices. It displays the following information (see Figure 22-8):
•The vertical axis (y-axis) provides the average video interarrival jitter in milliseconds (ms).
•The horizontal axis (x-axis) provides lists of all network devices that were discovered during the path trace. The devices in gray indicate that the Cisco Mediatrace is not configured.
•The spheres in the graph provide the video packet loss details as a percentage.
–Green sphere indicates that the video packet loss is zero.
–Orange sphere indicates that the video packet loss is more than 1%. The size of the sphere varies, based on the video packet loss. The smaller the sphere size, the less the video packet loss.
–No sphere indicates that the Cisco Mediatrace is not configured on the device and hence the video packet loss data are not available.
Figure 22-8 Video Interarrival Jitter and Packet Loss Graph
Click on the sphere (red icon) to view the system, interface, and mediatrace flow details.
IP DSCP and Packet Loss
This graph is displayed only for Cisco Mediatrace-configured devices. It displays the following information:
•The vertical axis (y-axis) provides the average IP DSCP (Differentiated Services Code Point). This value is pre-configured on the device.
•The horizontal axis (x-axis) provides lists of all network devices that were discovered during the path trace. The devices in gray indicate that the Cisco Mediatrace is not configured.
•The spheres in the graph provides the video packet loss details as a percentage.
–Green sphere indicates that the video packet loss is zero.
–Orange sphere indicates that the video packet loss is more than 1%. The size of the sphere varies, based on the video packet loss. The smaller the sphere, lesser the video packet loss.
–No sphere indicates that the mediatrace is not configured on the device and hence the video packet loss data are not available.
Figure 22-9 IP DSCP and Packet Loss Graph
Click on the sphere (red icon) to view the system, interface, and mediatrace flow details.
Medianet Enabled Network
Medianet enhances visibility into the network to simplify and accelerate troubleshooting. In Prime Collaboration, the following are the key differences between a medianet-enabled network and a nonmedianet-enabled network.
Details
|
Medianet-Enabled Network
|
Non-Medianet Network
|
Path Topology
|
Yes
|
Yes
|
System Statistics
|
Yes
|
Yes
|
Interface Statistics
|
Yes
|
Yes
|
Medianet Flow Information (DSCP, IP Packet Drop Count, RTP Packet Loss, RTP Packet Jitter (RFC 3550), Ingress Interface, Egress Interface)
|
Yes
|
No
|
View All Flows
|
Yes
|
No
|
Mediatrace Diagnostics
This information is displayed only if you have enabled Mediatrace on the device. See Cisco Mediatracefor further details. If the mediatrace statistics is not available, that is, mediatrace flow information does not appear in the quick view, Prime Collaboration supports application diagnostics to understand why it is not displayed.
You must click Run Diagnostics from the quick view, to see the root cause and recommendation.
Prime Collaboration checks the following:
•Prime Collaboration has CLI access to the device
•Mediatrace initiator role is configured on the device
•Mediatrace responder role is configured on the device
•WSMA is configured
•HTTP server is configured
•Mediatrace is provisioned for the session
•Mediatrace license is installed on the device
•Call is on hold (applicable to CTS only).
Cisco Mediatrace 2.0 is not supported in this release. If you are using a device with an IOS image that supports Mediatrace 2.0, note the following points while you are troubleshooting using Cisco Mediatrace:
•If a device having Mediatrace 2.0 is configured with Mediatrace Initiator role, Prime Collaboration will not start Mediatrace sessions from the device. But the Mediatrace role for that device might be shown as Initiator or Initiator/Responder in the Device Work Center page (Operate > Device Work Center > Current Inventory table). If the IOS image version of the device is 15.2(3)T (which has Cisco Mediatrace 2.0), an error message will be displayed in the Troubleshooting Logs tab.
•If the devices having Mediatrace 2.0 are configured with Mediatrace Responder role, you can view the Mediatrace statistics for these devices only if the Initiator device used during troubleshooting has Mediatrace 1.0.
View All Flows
This information is displayed only if you have configured Cisco IOS Performance Monitor on the device.
To view the flow of the packets in your network:
Step 1 Select a device in the troubleshooting topology.
Ensure that the Performance Monitor field shows Configured (see Figure 22-10).
Step 2 Click View All Flows.
Step 3 Select the interface where you want to monitor the packet flow.
Step 4 Select the type of the traffic.
Step 5 Click Start. See Figure 22-11 for the details that are displayed.
Figure 22-10 Performance Monitor Configured State
Figure 22-11 Performance Monitor
The interface that you have selected is displayed either as ingress or egress. Prime Collaboration displays all the flow details for the selected interface.
Table 22-4 Flow Details for the Interface
Field
|
Description
|
Current Selection
|
Selected device details.
|
Interface
|
Selected interface on the device.
|
Type of Traffic Selected
|
Whether the selected traffic is All or RTP.
|
Maximum Bandwidth
|
Maximum available bandwidth for the interface in Mbps.
|
Interface Usage / Interface Utilization Bar Chart
|
Utilization of the selected interface in Kbps.
|
Flow Usage / Flow Usage Pie Chart
|
This value is the sum of the bandwidth utilized by the individual flows for the selected interface (see Table 22-5).
|
Table 22-5 Individual Flow Details for the Interface
Field
|
Description
|
Ingress
|
Details on ingress interface.
|
Source
|
Name of the source device (from where the packet flow started).
|
Egress
|
Details on egress interface.
|
Destination
|
Name of the destination device.
|
Protocol
|
Protocol used for the packet flow.
|
Source and Destination Port
|
Port used for the flow.
|
Application
|
Type of the application.
|
Application Category
|
Whether audio, video, or other category.
|
Bandwidth (bps)
|
Bandwidth used by the application.
|
Packet Loss (%)
|
Packet loss for audio and video.
|
Jitter (ms)
|
Jitter for audio and video.
|
Path Assessment
You can view the troubleshooting summary information for testable devices, nontestable device, mediatrace-enabled devices, devices with packet loss threshold violation, devices with jitter threshold violation, and devices with DSCP violation.
A set of tests are run for the devices determined during troubleshooting. To start the Path Assessment test, click Path Assessment Tests, after the troubleshooting is complete for the session.
Note Path Assessment tests can be performed only on midpoints that are in the Managed state and have CLI access level (RW/RO). Path Assessment tests cannot be performed on the endpoints.
The following table lists the types of path assessment tests.
Category
|
Tests
|
Interfaces
|
Controller slips
|
Collisions in output queue
|
Controller path code violations
|
Input queue drops
|
Output queue drops
|
Controller line code violations
|
Controller line errors
|
Flapping interfaces
|
Duplex mismatch
|
Controller errored seconds
|
Babbles in output queue
|
Errors in output queue
|
Controller frame loss
|
Classification/Marking
|
DSCP-CoS mapping
|
CoS-DSCP mapping
|
Trust
|
Trust configuration.
|
Queuing
|
Egress priority queue
|
LLQ burst value
|
CBWFQ queue limit
|
CBWFQ/LLQ check
|
Policing/Shaping
|
CBWFQ/LLQ for video streams
|
Output policy-map scan for video traffic
|
Test Result
Test result is displayed as follows:
Icon
|
Description
|
|
Indicates passed. The test result is passed, only if all tests are passed for a device/ category.
|
|
Indicates failed. The test result is failed, if at least one test has failed for a device/ category.
|
|
Indicates that for some reason the test could not be executed, and the result is unknown. For example, if CDP is not enabled, then the ingress and egress interfaces are not determined. As a result, tests such as Trust DSCP cannot be executed and the results are unknown.
|
If the test has failed (shown by 
icon), click the quick view icon on the Result Field, to see the root cause and recommendation for the test.
You can select devices you are interested in, and click the arrow next to the IP address of the device to see the details of the test performed for the device.
To further troubleshoot a single device, rest your mouse pointer over the result column for the failed/unknown test result and click the quick view to see the root cause and recommendation. There is no quick view available for the passed tests.
Note All session and troubleshooting details older than 14 days are purged, every hour.
Exporting Troubleshooting Data
You can export the data only after the session ends. After the troubleshooting job is completed, the troubleshooting job status is displayed in the Session Monitoring page.
To export the troubleshooting data:
Step 1 Choose Operate > Diagnose > Session Diagnostics.
Step 2 Select a past session, where the troubleshooting status icon displays Troubleshooting Report Available.
Step 3 Rest your mouse pointer over the Session Subject column in the Video Collaboration Sessions table and click the 360° Session view icon.
Step 4 Click 
in the 360° Session view window.
Understanding the Export Troubleshooting Report
The export troubleshooting report contains the following details:
Report Field
|
Description
|
Session Identifier
|
A unique ID for the session.
|
Session Subject
|
Displays whether the session is ad hoc, scheduled, or static.
|
Session Date
|
Date when the session occurred.
|
Session Start Time
|
Session start time.
|
Session Duration in Minutes
|
Duration of the session.
|
Session Type
|
Displays whether the session is point-to-point or multipoint.
|
Endpoints
|
Details of the endpoints that were part of the session.
|
Call Segment
|
Displays the direction that was used while troubleshooting.
|
Troubleshooting Session
|
Start and end time of troubleshooting workflow.
|
Troubleshooting Session ID
|
A unique ID for the troubleshooting workflow.
|
Troubleshooting Start Time
|
Start time of the troubleshooting workflow.
|
Troubleshooting Initiation
|
Displays whether the troubleshooting was started manually or whether it started automatically.
|
Path Topology and Metrics
|
Displays information on the troubleshooting path topology and metrics.
The following are the fields and their description:
•Host Name/IP Address—Name of the host or IP address.
•CPU Utilization (Max, Avg)—Displays the maximum and average CPU utilization.
•Memory Utilization (Max, Avg)—Displays the maximum and average memory utilization.
•Max Packet Loss (Video, Audio)—Displays maximum packet loss for video and audio.
•Max Jitter (Video, Audio)—Displays maximum jitter for video and audio.
•DSCP (Video, Audio)—Displays DSCP value for video and audio.
|
Troubleshooting End Time
|
Start time of the troubleshooting workflow.
|
Troubleshooting Termination
|
Displays whether the troubleshooting workflow was ended manually or whether it stopped automatically.
|
Feedback
