547
edits
Path measurement: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 36: | Line 36: | ||
The following '''Remote device''' configuration section configures the access to the remote device: | The following '''Remote device''' configuration section configures the access to the remote device: | ||
* Device | * Device to use: To use a remote device for path measurement, you first need to add that device as a remote device the list of [[Multi-device settings]]. It does not matter if the device is active or not. | ||
: You can select the device from the list of known multi-devices. | |||
* Device description: Similar to the description of the master device, this field is for informational purpose only and has no other effect than helping identifying the remote device in the statistics. Usually the location of the remote device is entered. | * Device description: Similar to the description of the master device, this field is for informational purpose only and has no other effect than helping identifying the remote device in the statistics. Usually the location of the remote device is entered. | ||
Measurement settings: | |||
* Maximum packet delay: This field describes the maximum amount of seconds to wait for packet information from the remote device. | |||
: It basically means that the master devices waits for this number of seconds before deciding if a packet has been lost or not. If the data from the remote device arrives before those number of seconds, the path measurement can account the packet loss, if any and the two-way latency. This value must be at least as large as the worst-case latency between both measurement sites. | |||
: Usually 3 seconds are more than enough but when the network in between can have a very long delay, you can increase the value. This will, however, use more main memory for the packet buffer. | |||
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'''. | |||
| Line 54: | Line 55: | ||
:'''Required actions:''' 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. | :'''Required actions:''' 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. | ||
| Line 131: | Line 129: | ||
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement. | # The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement. | ||
# 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. | # 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. | ||
#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. | # Different VLAN combinations on master and client are not supported by default. Connections which are visible on both sites with different VLAN tags are accounted as unmonitored flows in the debug view. However, the feature "ignore VLAN tags in flow keys" in the expert settings can be enabled so that the VLAN is completely ignored (for all other measurement modules as well). | ||
#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. | # 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. | |||