1,775
edits
Path measurement: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 152: | Line 152: | ||
Possible problematic scenarios: | Possible problematic scenarios: | ||
* There is a device between master and client that modifies the traffic (like a WAN optimizer): You will notice a larger value for counter 2 (flow without matching packets), almost zero value for counter 1 (flows seen on both devices). | * There is a device between master and client that modifies the traffic (like a WAN optimizer): You will notice a larger value for counter 2 (flow without matching packets),almost zero value for counter 1 (flows seen on both devices). | ||
* There is a device between master and client that changes ports and IP addresses (a NAT): | |||
You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4. | |||
Both scenarios are not supported by the path measurement. | |||
Please adjust the test setup to disable any device modifying the network as described above. | Please adjust the test setup to disable any device modifying the network as described above. | ||
| Line 166: | Line 169: | ||
#The packets seen only on one devices indicates how much packets are lost on the other devices. | #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. | #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. | #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. | # 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. | ||
# 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 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. | #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 183: | Line 183: | ||
#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. | ||
#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. If the bandwidth is too small, the packet will hit the maximum delay for any value configured, it will just take a little longer. | ||
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. | |||
| Line 198: | Line 196: | ||
==== FAQ ==== | ==== FAQ ==== | ||
#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. 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. Such setup is not supported. | ||
This message box appears if flows have been identified for which not a single packet could be seen on both sides. | #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. 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. | ||
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. | |||
#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. | |||
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. | |||