Path measurement: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 18: Line 18:


==== Configuration ====
==== Configuration ====


'''Web interface'''
'''Web interface'''
Line 59: Line 60:


==== Measurement statistics ====
==== Measurement statistics ====


'''Web interface'''
'''Web interface'''
Line 106: Line 108:




'''1.''' 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.
#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.
 
#The capturing connection is encrypted with SSL. The small Allegro 200 has a limited encryption capacity so for large traffic this can be a bottleneck. The only solution is to use a more powerful Multimeter.
'''2.''' The capturing connection is encrypted with SSL. The small Allegro 200 has a limited encryption capacity so for large traffic this can be a bottleneck. The only solution is to use a more powerful Multimeter.
#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.  
 
 
'''3.''' 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.
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.


Line 145: Line 144:
The debug information tab shows additional statistics which are usually only relevant for identifying problems in the path measurement, either program errors or test setup errors.
The debug information tab shows additional statistics which are usually only relevant for identifying problems in the path measurement, either program errors or test setup errors.


'''1.''' Monitored flows seen on both devices:
#Monitored flows seen on both devices:
The monitored flows describes all IPv4 and IPv6 connections that have been seen on both devices and are used for calculating the latency and packet loss.  
The monitored flows describes all IPv4 and IPv6 connections that have been seen on both devices and are used for calculating the latency and packet loss.  
Only this traffic can be considered for the actual measurement.  
Only this traffic can be considered for the actual measurement.  
In a working setup, the value must be non-zero.
In a working setup, the value must be non-zero.
 
#Flows seen on both devices without matching packets:
'''2.''' Flows seen on both devices without matching packets:
If a flow is seen on both devices but not a single packet matches on both sides, it indicates a potential network setup problem.  
If a flow is seen on both devices but not a single packet matches on both sides, it indicates a potential network setup problem.  
This probably means the packet is somehow modified by a device in between both measurement points. This setup is not supported.
This probably means the packet is somehow modified by a device in between both measurement points. This setup is not supported.
Usually this value should be zero.  
Usually this value should be zero.  
Small non-zero values can be ok, if the first number of monitored flows is much larger.
Small non-zero values can be ok, if the first number of monitored flows is much larger.
 
#Unmonitored flows seen only on '''master''':
'''3.''' Unmonitored flows seen only on '''master''':
This counter shows the number of IP connections that are only visible at the master device.  
This counter shows the number of IP connections that are only visible at the master device.  
It means that for those connections no matching client packet has been received. If the master device also sees network traffic that is not routed to the client device, this value can be non-zero.
It means that for those connections no matching client packet has been received. If the master device also sees network traffic that is not routed to the client device, this value can be non-zero.
 
#Unmonitored flows seen only on '''client''':
'''4.''' Unmonitored flows seen only on '''client''':
This is the same counter as for the master device, but counting the connections on the client device that have not been seen on the master.  
This is the same counter as for the master device, but counting the connections on the client device that have not been seen on the master.  
Again, if the client device sees traffic that is not routed to the master, it is fine to see non-zero values here.
Again, if the client device sees traffic that is not routed to the master, it is fine to see non-zero values here.
Line 178: Line 174:
The table below shows the following counters for the master and remote device:
The table below shows the following counters for the master and remote device:


'''1.''' The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.
#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.
 
#The packets seen only on one devices indicates how much packets are lost on the other devices.
'''2.''' The packets seen only on one devices indicates how much packets are lost on the other devices.
#Duplicated packets: This counter includes packets that are duplicated or have the same checksum. It is valid to see non-zero values here. Some protocols like broadcast actually do not differ in the payload so the packet checksum will be identical. If those packets appear within the packet delay time window, it is accounted as a duplicate to the previous one.
'''3.''' Duplicated packets: This counter includes packets that are duplicated or have the same checksum. It is valid to see non-zero values here. Some protocols like broadcast actually do not differ in the payload so the packet checksum will be identical. If those packets appear within the packet delay time window, it is accounted as a duplicate to the previous one.
#Failed to process on master device: This counter indicates that packets from the client have been discarded due to overload of the master.  
 
'''4.''' Failed to process on master device: This counter indicates that packets from the client have been discarded due to overload of the master.  
The master device was not fast enough to process client packets. This usually means the local packet rate (at the master device) is too high.
The master device was not fast enough to process client packets. This usually means the local packet rate (at the master device) is too high.
'''5.''' Ignored on master device: These packets are ignored because the flow is unknown to the master devices.  
# Ignored on master device: These packets are ignored because the flow is unknown to the master devices.  
This happens when the packet checksum is received from the client but no connection information for that packet is known by the master.  
This happens when the packet checksum is received from the client but no connection information for that packet is known by the master.  
This value should always be zero. Otherwise it means that the number of active flows is too high.
This value should always be zero. Otherwise it means that the number of active flows is too high.
 
#Packets processed too early: This counter covers packets that packets could not be stored long enough to hit the configured packet delay limit.  
'''6.''' Packets processed too early: This counter covers packets that packets could not be stored long enough to hit the configured packet delay limit.  
This happens when the packet rate is higher than the supported packet rate of the master device.
This happens when the packet rate is higher than the supported packet rate of the master device.


Line 200: Line 193:




'''1.''' 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.
#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.
'''2.'''The bandwidth of the connection from the client (the client’s upload speed) is too small to satisfy the requirement for the checksum connection.  
#The bandwidth of the connection from the client (the client’s upload speed) is too small to satisfy the requirement for the checksum connection.  
This problem can be identified if even increasing the maximum packet delay does not help.  
This problem can be identified if even increasing the maximum packet delay does not help.  
If the bandwidth is too small, the packet will hit the maximum delay for any value configured, it will just take a little longer.
If the bandwidth is too small, the packet will hit the maximum delay for any value configured, it will just take a little longer.
Line 216: Line 209:


==== FAQ ====
==== FAQ ====
'''1.''' What does the note '''Network setup problem detected: Packet modification or complete loss''' means?  
#What does the note '''Network setup problem detected: Packet modification or complete loss''' means?  
 
This message box appears if flows have been identified for which not a single packet could be seen on both sides.  
This message box appears if flows have been identified for which not a single packet could be seen on both sides.  
Usually this means that there is some device in between both measurement points that modifies the packet.  
Usually this means that there is some device in between both measurement points that modifies the packet.  
This can be WAN optimizer which rewrite TCP connection for improved network performance. Suchsetup is not supported
This can be WAN optimizer which rewrite TCP connection for improved network performance. Suchsetup is not supported
'''2.''' What kind of packet information is used to determine latency and packet loss?  
#What kind of packet information is used to determine latency and packet loss?  
Both measurement devices calculate checksums starting from the layer 3 packet data to compare packet information on both sides.  
Both measurement devices calculate checksums starting from the layer 3 packet data to compare packet information on both sides.  
This means for IPv4 and IPv6 traffic, the Ethernet header including possible VLAN tags is ignored. For non-IP traffic, the complete layer 2 packet is used so this traffic can only be analyzed in switched networks.
This means for IPv4 and IPv6 traffic, the Ethernet header including possible VLAN tags is ignored. For non-IP traffic, the complete layer 2 packet is used so this traffic can only be analyzed in switched networks.
1,775

edits