547
edits
Path measurement: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
In Firmware version >= 3.3, it is also possible to use a single device to measure the traffic delay/losses between two different [[Virtual Link Group functionality|virtual link groups]]. In this mode, the primary device is used as a client too. | In Firmware version >= 3.3, it is also possible to use a single device to measure the traffic delay/losses between two different [[Virtual Link Group functionality|virtual link groups]]. In this mode, the primary device is used as a client too. | ||
In Firmware version >= 3.7, two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations. | |||
== Overview == | == Overview == | ||
The main device captures packet meta data from the remote (or client) device which takes only a fraction of the total traffic. | The main device captures packet meta data from the remote (or client) device which takes only a fraction of the total traffic. | ||
| Line 19: | Line 21: | ||
The delay must be large enough to cover the actual latency of the connection and delay of the capture connection. | The delay must be large enough to cover the actual latency of the connection and delay of the capture connection. | ||
Typical values are between 2 and 5 seconds. Larger values requires more memory to buffer packet meta data so very large values might only be selectable on larger Multimeter devices (Allegro 1000 or greater). | Typical values are between 2 and 5 seconds. Larger values requires more memory to buffer packet meta data so very large values might only be selectable on larger Multimeter devices (Allegro 1000 or greater). | ||
== Configuration == | == Configuration live measurement == | ||
{|class="wikitable sortable" | {|class="wikitable sortable" | ||
| Line 40: | Line 42: | ||
*# reduce the amount of data required to be transferred to the main device. The path measurement only considers connections seen on both devices, but the client device of course cannot know if any connection it sees also is visible on the main device. If only traffic of a specific virtual linkg group (VLG) actually reaches the main device, using this filter can reduce the amount of data transferred and later dismissed. | *# reduce the amount of data required to be transferred to the main device. The path measurement only considers connections seen on both devices, but the client device of course cannot know if any connection it sees also is visible on the main device. If only traffic of a specific virtual linkg group (VLG) actually reaches the main device, using this filter can reduce the amount of data transferred and later dismissed. | ||
*# filter duplicate traffic: If, for some reason, traffic is seen multiple times, it can create wrong results as the number of occurrences differs from main to client devices. A VLG filter can fix this problem by only considering one part of the total traffic. | *# filter duplicate traffic: If, for some reason, traffic is seen multiple times, it can create wrong results as the number of occurrences differs from main to client devices. A VLG filter can fix this problem by only considering one part of the total traffic. | ||
Measurement settings: | Measurement settings: | ||
| Line 47: | Line 48: | ||
: It basically means that the main 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. | : It basically means that the main 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. | : 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. | ||
* '''Maximum original packet rate:''' This field defines the maximum packet rate that is to be expected. It directly defines the necessary amount of memory for storing packet information for the defined packet delay. The field can be left empty (or zero) to use the maximum supported packet rate of the device. This value usually only has to be adjusted if the debug information about "Packets processed too early" is non-zero which indicates that the packet rate exceeded the assumed packet rate limit. | |||
* '''Ignore IP identification field''': This option can be enabled if the IP identification field in the IPv4 header is modified by some component in the network. Often it remains constant for a single packet so this option should be left disabled as it will also increase the chance of reporting duplicate packets. But if you notice symmetrical packet loss you can enable this option to see if this helps. | * '''Ignore IP identification field''': This option can be enabled if the IP identification field in the IPv4 header is modified by some component in the network. Often it remains constant for a single packet so this option should be left disabled as it will also increase the chance of reporting duplicate packets. But if you notice symmetrical packet loss you can enable this option to see if this helps. | ||
| Line 62: | Line 65: | ||
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. | 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. | ||
== Configuration PCAP measurement == | |||
== Measurement statistics == | == Measurement statistics == | ||