Path measurement: Difference between revisions

*remote device inaccessible (are the IP and port settings correct?)

* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.

=== Two-Way-Latency ===

For each second, the average, minimum, and maximum two-way-latency is accounted and shown the graph.  

To the left of the graph the statistics for the visible time range is shown, changing the zoom level or time interval will update the values accordingly.

=== Lost packets ===

If this value is not zero, those packets are accounted as packet loss even though it might not be actually losses.  

For correct measurements, make sure the graph for remote packet drops is never non-zero. These drops may happen due to several reasons:

#System capture overload: If multiple captures are running in parallel, the CPU might be overloaded. Check the '''All''' tab in the Capture page to see how many captures are running.  In best case there is only the one capturing connection to the master device.

#Capture drops can also occur if the network connection is not capable of transferring the data fast enough. Rule of thumb is that approximately 5% of the total traffic is used for the measurement connection. For example, if the traffic is 500 MBit/s, the measurement requires ~25 MBit/s of bandwidth on the management port.  

The fourth graph shows all packets that are monitored for the path measurement. This will cover all connections that have been seen on both devices.

=== IP statistics ===

The second tab shows packet loss information for each pair of IP addresses. This statistic covers all IP connections that has been seen on both measurement sides. The table shows the number of packets that have been counted for each communication pair. Additionally the number of packets seen on the master device and the corresponding packet loss is shown. The same statistics are shown for the client device too. You can click on the IP address to go to the detailed statistics of the IP module to check which kind of traffic was happening for that IP. Two graphs are shown for each IP pair which shows the packet loss for both direction on one graph and the total packets in the second graph.

There is also a capture button to capture traffic for the IP pair.  The captured traffic is only the traffic seen on the master device, it will not contain any packet from the client device as the master device does not have the packet data information available. To capture traffic from the client device, you have to go to the web interface of the client device and start a capture on that device.

=== Switching graph modes ===

# WAN optimizer and similar devices which rewrite some of the traffic are not supported either. If packet data is changed (like modifying the TCP header, adding TCP options, etc) the flow will account packet loss on both sides as the original packets are not seen on the other side. If the device in between also modifies the IP addresses or ports, the flows will be accounted as unmonitored.

# The global setting for the packet length accounting should be set to the same value on both devices.Otherwise identical packets might be considered different because of different length and the bandwidth information will be inconsistent.

== Typical use cases==

See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.

==  Debug information ==

This value should always be much lower than the maximum packet delay configured in the path measurement configuration.  

The value cannot be larger than the maximum as then packets can no longer be matched. If the value keeps reaching the maximum, two problems are possible:

#The delay between master and client is large due to generic network delay. For example, if a high-latency connection is used for path measurement, it can even take a few seconds for a packet info to arrive. Configure a larger maximum packet delay.

Usually there will always be a drift between the clocks of both devices (if they are not synchronized by some mean). Even large drifts (hours, days, etc) are typically not a problem as the two-way latency zero-out the drift.  

But if the drift increased dramatically (like multiple seconds) constantly over a large period of time, it usually indicates a bandwidth overload just like the first graph.

== FAQ ==