1,775
edits
Path measurement: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 47: | Line 47: | ||
* Maximum packet delay: This field describes the maximum amount of seconds to wait for packet information from the remote device. | * Maximum packet delay: This field describes the maximum amount of seconds to wait for packet information from the remote device. | ||
:The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required will tell so at the bottom of the page under “Required actions”. | |||
The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required will tell so at the bottom of the page under “Required actions”. | |||
Parameters currently in use: | Parameters currently in use: | ||
This section shows the current state of the measurement engine. | This section shows the current state of the measurement engine. | ||
| Line 56: | Line 55: | ||
It might be different from the selected value in the configuration above, but if so a note appears that a restart is required. | It might be different from the selected value in the configuration above, but if so a note appears that a restart is required. | ||
Required actions: | :Required actions: | ||
An info box appears if the a restart of the packet processing is required. | An info box appears if the a restart of the packet processing is required. The shown link leads to the page “Settings → Administration” where the restart can be triggered. The device itself does not need to be rebooted, only the packet processing must be restarted which usually takes only a few seconds. | ||
The shown link leads to the page “Settings → Administration” where the restart can be triggered. The device itself does not need to be rebooted, only the packet processing must be restarted which usually takes only a few seconds. | |||
Custom remote device SSL certificate: | :Custom remote device SSL certificate: | ||
If a custom SSL certificate is installed on the remote device, you have to upload the public certificate to the master device as well. | If a custom SSL certificate is installed on the remote device, you have to upload the public certificate to the master device as well. Otherwise you will get a SSL error during connect to the remote device. Select the PEM certificate and click on “Install certificate” to upload it to the device. You can also remove an already installed certificate by clicking on the “Remove certificate” button. | ||
Otherwise you will get a SSL error during connect to the remote device. | |||
Select the PEM certificate and click on “Install certificate” to upload it to the device. You can also remove an already installed certificate by clicking on the “Remove certificate” button. | |||
| Line 151: | Line 147: | ||
There are some limitations about the path measurement: | There are some limitations about the path measurement: | ||
1. Due to technical reasons, large clock adjustments cannot be filtered out so if that happens, a very large two-way-latency is measured. Both devices does not need to be time synchronized but large adjustments shall not happen. | '''1.''' Due to technical reasons, large clock adjustments cannot be filtered out so if that happens, a very large two-way-latency is measured. Both devices does not need to be time synchronized but large adjustments shall not happen. That means that time synchronization (for example via NTP) should be enabled on both devices or disabled on both devices for best results. However, such clock adjustment miss-measurements are one-time events and will not lead to false values for the following packets. | ||
That means that time synchronization (for example via NTP) should be enabled on both devices or disabled on both devices for best results. | '''2.''' The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement. | ||
However, such clock adjustment miss-measurements are one-time events and will not lead to false values for the following packets. | '''3.''' NAT setups and different VLAN combinations on master and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. | ||
'''4.'''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. | |||
2. The maximum supported packet size for the path measurement is currently 2048 bytes. | '''5.''' 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. | ||
Larger packets are truncated for the measurement. | |||
3. NAT setups and different VLAN combinations on master and client are not supported at the moment. | |||
Such flows will be accounted as unmonitored flows in the debug view. | |||
4. 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. | |||
5. 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. | |||
| Line 177: | Line 163: | ||
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: | '''1.''' 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. | ||
2. 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. | ||
| Line 188: | Line 174: | ||
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. | ||
3. 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. | ||
4. 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 199: | Line 185: | ||
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 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. | Both scenarios are not supported by the path measurement. | ||
| Line 210: | Line 196: | ||
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. | '''1.''' The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis. | ||
2. 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. | ||
'''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. | |||
'''4.''' 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. | |||
5. 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. | ||
6. 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 234: | Line 218: | ||
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. | '''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. | ||
'''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. | |||
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. | |||
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 251: | Line 234: | ||
==== FAQ ==== | ==== FAQ ==== | ||
'''1.''' What does the note “Network setup problem detected: Packet modification or complete loss” means? | |||
1. 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? | |||
2. 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. | ||