547
edits
Path measurement: Difference between revisions
no edit summary
mNo edit summary |
No edit summary |
||
| Line 59: | Line 59: | ||
*'''Ignore VLAN tags for connection matching''': The path measurement only calculate loss and latency for connections seen on both devices. Usually the connection ID takes the IP pairs, port ports and possible VLAN tags into account. If a VLAN is different on both machines for the some connection, then this option must be enabled to be able to correlate the connection and calculate correct statistics. | *'''Ignore VLAN tags for connection matching''': The path measurement only calculate loss and latency for connections seen on both devices. Usually the connection ID takes the IP pairs, port ports and possible VLAN tags into account. If a VLAN is different on both machines for the some connection, then this option must be enabled to be able to correlate the connection and calculate correct statistics. | ||
* '''Account latency also per IP connection''': Enabling this option will let the path measurement also store the latency for each individual IP connection, which of course increases the memory usage. | * '''Account latency also per IP connection''': Enabling this option will let the path measurement also store the latency for each individual IP connection, which of course increases the memory usage. | ||
* '''Enable NAT mode''' (Firmware >= 4.3): This feature will enable support for Network-Address-Translation setup (typical for firewalls or internet uplink routers). | |||
** '''Internal NAT subnet/mask:''' This value describes the internal IP addresses that gets translated into an external IP address. | |||
** '''NAT-side internal subnet/mask:''' This value defines the external IP address. It can also be an IP subnet (for example, if multiple external IP addresses are used). | |||
** '''Account unmatched flows:''' This option allows to monitor also connections there are not seen on the other measurement side. This is useful to see blocked connections in firewall setups. | |||
The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required, a notification 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, a notification will tell so at the bottom of the page under '''Required actions'''. | ||
| Line 142: | Line 146: | ||
==== Monitored packet rate ==== | ==== Monitored packet rate ==== | ||
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. | ||
==== NAT collision packet rate ==== | |||
This graph shows the number of packets per second that appeared in connections with colliding IP addresses/ports in NAT setups. This happens if matching packets are seen on both sides for more than two connections (the internal and the external connection). Since this is only relevant for matching packets within the defined timeout, it may help to reduce the timeout if possible. | |||
=== IP addresses === | === IP addresses === | ||
| Line 162: | Line 169: | ||
# Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time differentiation must be avoided. This means that time synchronization (e.g. NTP/PTP) should either be enabled or disabled on both devices for best results. Clock differentiation miss-measurements are however one-time events, and will not lead to false values for the following packets. | # Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time differentiation must be avoided. This means that time synchronization (e.g. NTP/PTP) should either be enabled or disabled on both devices for best results. Clock differentiation miss-measurements are however one-time events, and will not lead to false values for the following packets. | ||
# 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. | ||
# 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. | # 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. | # 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. | ||
# (Only firmware < 4.3): NAT setups and different VLAN combinations on main and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. | |||
== Typical use cases== | == Typical use cases== | ||
| Line 202: | Line 209: | ||
# Ignored on main device: These packets are ignored because the flow is unknown to the main devices. This happens when the packet checksum is received from the client but no connection information for that packet is known by the main device. This value should always be zero. Otherwise it means that the number of active flows is too high. | # Ignored on main device: These packets are ignored because the flow is unknown to the main devices. This happens when the packet checksum is received from the client but no connection information for that packet is known by the main device. 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. This happens when the packet rate is higher than the supported packet rate of the main device. | #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 main device. | ||
#NAT collision packets: This counter counts all packets that are seen on both sides for multiple connections so the Network Address Translation could not be reversed for connection tracking. | |||