Data Center RUM Documentation

Skip to end of metadata
Go to start of metadata

CAS ► Tools ► Diagnostics ► Traffic diagnostics

The Traffic Diagnostics report offers an AMD health report relative to the traffic coming into them. Use it for network performance monitoring (NPM). The report lists monitored devices and offers you a link to start a traffic capture on any device whose performance thresholds are met. Adjust the resolution and time range as needed.

Important:

Icon
  • If you see no statistics (other than the Packet drop rate percentages in the Attached AMDs list), you probably haven't selected a device yet. To select a device, click the device address in the Attached AMDs list.

  • It is normal (and desirable) to not see all of the statistics listed here. A statistic is displayed only if it crosses a certain threshold. You should concentrate on the statistics that are displayed, and not worry about the statistics that are not displayed (because they are within normal limits).

  • The statistics on this report are generally prioritized from top to bottom. Resolve issues starting from the top of the list, like it's a sequential procedure.

Attached AMDs

Click and select the address of the AMD you want to analyze.

Non-zero Packet drop rate statistics (Controlled and Uncontrolled) can be quick indicators of trouble on a server.

  • Uncontrolled packet drops indicate that the AMD could not cope with the load and started dropping packets on the driver level (overflow). The result is erratic and unreliable performance measurement results.

  • A high controlled packet drop rate indicates that the AMD cannot process the traffic stream it is receiving due to performance reasons, so it has dropped some sessions in a controlled manner.

If the list is long, use the Find box to narrow the displayed list to one or more devices that match your search string.

Click a device address and then click the Capture packets on AMD link to capture a sample of traffic on the selected device. For more information, see Capturing packets on AMD.

Status of sniffing interfaces

If this list is empty, you probably haven't selected a device yet. To select a device, click the device address and then click Select Table Row in the pop-up window.

After you select a device, this table lists the following interface information about all sniffing interfaces detected on that device:

Sniffing ifc name

The name of the interface.

State

The state of the interface.

Rx data

The amount of traffic received on the interface.

Important:

Icon
These are cumulative values that should be increasing with each report update if your AMD is receiving traffic on these sniffing ports. If a port does not increase with screen updates, you may have a SPAN configuration problem on that port.

Traffic Statistics

  • Click any point on a chart to see a numerical value for that point on the chart. The graphs are there to give you a quick idea of trends; you can't see actual values unless you click the graph.

  • These are statistics for the Time range and Resolution specified at the top of the report. You can change these settings to suit your purposes.

  • Consider the recommended actions for each statistic.

All possible statistics that could be displayed on this report:

Traffic volume

The volume is provided per AMD, so you first select an AMD from the list of attached AMDs and then get more detailed information.

The AMD’s capacity to receive and analyze traffic depends on factors such as a traffic profile, number of monitored users, sites, and protocols. In general, the amount of traffic monitored by the AMD should be adjusted so that the AMD has some safety margin.

The chart compares the incoming traffic stream (bps) to the number of requests calculated based on traffic analysis. If the shapes of the two data series are similar, the selected AMD is processing incoming traffic and producing relevant performance data. If the shapes are dissimilar, inspect the AMD status details in the RUM Console.

AMD packet drop rate (Uncontrolled)

This is a graph of the selected AMD's uncontrolled packet drops. The AMD is designed to handle traffic bursts, but sometimes the amount of traffic exceeds the AMD’s capacity. Such a condition is indicated by the packet drop rate measures (controlled or uncontrolled).

Uncontrolled packet drops indicate that the AMD could not cope with the load and started dropping packets on the driver level (overflow). The result is erratic and unreliable performance measurement results.

The AMD first copes with excessive traffic by ignoring some TCP sessions. We call such a condition controlled packet drop. Controlled packet drop preserves the quality of performance measurements, though not all TCP sessions are taken into account. However, if the amount of traffic far exceeds the AMD’s capabilities, it begins uncontrolled packet dropping, which means that packets are dropped at the interface level, thus significantly degrading the performance measurements.

Recommended actions: uncontrolled packet drops cannot be fixed other than by decreasing the monitored traffic level or attaching another AMD so that the entire traffic stream can be handled.

  • If you do not need to monitor that amount of traffic, limit the traffic feed.

  • If you need to monitor that amount of traffic, attach another AMD.

AMD packet drop rate (Controlled)

A high controlled packet drop rate indicates that the AMD cannot process the traffic stream it is receiving due to performance reasons, so it has dropped some sessions in a controlled manner. This data sampling is turned on or off automatically as needed to prevent further AMD performance degradation.

Recommended actions:

  • Change your SPAN configuration to limit the traffic stream the AMD receives.

  • Inspect AMD capacity metrics to learn what might cause the AMD overload.

Driver errors

This indicates that the AMD cannot process the traffic stream it is receiving due to errors on the sniffing interfaces.

Recommended action: inspect AMD capacity metrics to learn what the nature of AMD errors is.

Sequence number gap rate

Graphs breaks in sequence numbers. A gap in the packet sequence means that some packets never reached the AMD, and the sessions with missing packets cannot be measured for performance.

This issue is quite common when a SPAN is overloaded, or when a network packet broker used to aggregate and forward the traffic to the AMD cannot preserve the order of forwarded packets.

Recommended action: inspect SPAN (or NPB) configuration to eliminate losses.

Unidirectional traffic rate

Graphs unidirectional traffic volume. Unidirectional traffic frequently occurs when using a SPAN to mirror traffic. A misconfigured SPAN or network packet broker will result in unidirectional traffic coming from a server or a client only. When more than 5 percent of the traffic is unidirectional, it indicates the AMD cannot reliably monitor and analyze traffic, and that a significant portion of user sessions is not being taken into account during performance analysis.

Recommended action: Change SPAN configuration to minimize unidirectional traffic and make sure it mirrors bi-directional client-server conversations.

IPv4 Duplicates

IPv6 Duplicates

Graphs duplicate IPv4 or IPv6 packets (or both). While not a severe issue, duplicates may significantly influence the AMD’s capacity if the AMD is spending too much time finding and removing duplicates during performance analysis.

A high level of duplicates may be a side effect of SPAN misconfiguration.

Recommended action: inspect SPAN (or NPB) configuration to eliminate or minimize duplicates.

Top retransmission-affected servers (last hour)

This is a table of the servers with the highest two-way loss (retransmission) rates. If you have a high level of packet duplicates (see above) and servers with a high two-way loss rate, you have a low-quality traffic stream. While duplicates mainly affect AMD performance, a retransmission rate above approximately 10 percent is a clear indicator that the monitored traffic stream contains too many out-of-order packets that cannot be processed, which means you will receive irrelevant performance measurements.

Recommended action: inspect and correct your network packet broker settings so your NPB retains the correct order of packets it passes to the AMD.

Non-IP traffic

Graphs non-IP traffic volume. The AMD considers non-IP traffic to be noise, as such traffic is not analyzed for performance.

A high rate of non-IP traffic (5 percent or more ) indicates that the traffic the AMD is monitoring is mainly traffic that is not part of a client-server data exchange. Either there is no user activity in the monitored network, or the SPAN is misconfigured, or the number of monitored client-server conversations is a fraction of the intended traffic to be monitored.

Recommended action: inspect the SPAN configuration to make sure it is mirroring client-server conversations.