183
edits
Path measurement: Difference between revisions
Jump to navigation
Jump to search
m
→Path measurement: Drop outdated firmware versions
m (→Path measurement: Drop outdated firmware versions) |
|||
| Line 9: | Line 9: | ||
The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results. | The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results. | ||
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. | |||
Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations. | |||
=== Live analysis === | === Live analysis === | ||
| Line 22: | Line 22: | ||
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. | ||
Approximately 5% additional bandwidth is required for this capture connection. | Approximately 5% additional bandwidth is required for this capture connection. | ||
So for fully loaded 100 | So for fully loaded 100 Mbit/s connection to the remote location an additional load of ~5 Mbit/s is required to get packet information to the main device. | ||
The measurement connection can be a separate line or can be run over the line that is measured, the capture connection will be automatically ignored for the measurement. | The measurement connection can be a separate line or can be run over the line that is measured, the capture connection will be automatically ignored for the measurement. | ||
The measurement module must be configured with a maximum packet delay. | The measurement module must be configured with a maximum packet delay. | ||
| Line 76: | Line 76: | ||
[[File:Path-measurement-pcap-settings.png|border|660x660px]] | [[File:Path-measurement-pcap-settings.png|border|660x660px]] | ||
The path measurement can also be done based on two capture files created from two different network locations. The separate configuration tab "Configuration PCAP Analysis" allows to select two files from attached storage devices. | |||
The files are replayed based on the packet time stamps within each file, in chronological order. Matching packets are only recognized if they are within the maximum packet delay. If the difference of the timestamps is larger, a time-delta adjustment value can be entered which will be added to the timestamp of the client packets. Negative values are possible as well to be able to adjust the time in both directions. If the time difference is too large, a lot of packet loss are reported, or even a "network setup problem" note is shown in the overview tab. If the time delta between both files is not known, a test run can be enabled to calculate the approximate difference. When both files are fully processed in this test run, the result is shown in the overview tab and this value can be used for the actual analysis. | The files are replayed based on the packet time stamps within each file, in chronological order. Matching packets are only recognized if they are within the maximum packet delay. If the difference of the timestamps is larger, a time-delta adjustment value can be entered which will be added to the timestamp of the client packets. Negative values are possible as well to be able to adjust the time in both directions. If the time difference is too large, a lot of packet loss are reported, or even a "network setup problem" note is shown in the overview tab. If the time delta between both files is not known, a test run can be enabled to calculate the approximate difference. When both files are fully processed in this test run, the result is shown in the overview tab and this value can be used for the actual analysis. | ||
| Line 245: | Line 245: | ||
##: This can be verified by looking at the debug graph '''Packet delay between local and remote packets'''. In this event, the time will always be at the top limit that is the maximum packet delay time. | ##: This can be verified by looking at the debug graph '''Packet delay between local and remote packets'''. In this event, the time will always be at the top limit that is the maximum packet delay time. | ||
## Temporary network failure | ## Temporary network failure | ||
##: In this event the packets are really lost on both directions so the loss graph may also look | ##: In this event the packets are really lost on both directions so the loss graph may also look similar. However, since no packet can be transmitted to the other side, you will also see no entries in the two-way-latency graph. | ||
# How is the two-way latency calculated? | # How is the two-way latency calculated? | ||
#:The system monitors individual IP connections and stores the time difference between the occurrence of the same checksum on both the main and client devices. Since this time difference contains the unknown time drift between both systems, it cannot be used directly as a latency value. Instead, the system waits until a packet from the opposite direction has been seen on both systems. Both time differences for direction A->B and B->A build the actual two-way latency. Since both packets may not be directly related, it is not directly comparable with a round-trip time. It gives however an accurate view on how long data took transmitting back and forth during each individual time segment. | #:The system monitors individual IP connections and stores the time difference between the occurrence of the same checksum on both the main and client devices. Since this time difference contains the unknown time drift between both systems, it cannot be used directly as a latency value. Instead, the system waits until a packet from the opposite direction has been seen on both systems. Both time differences for direction A->B and B->A build the actual two-way latency. Since both packets may not be directly related, it is not directly comparable with a round-trip time. It gives however an accurate view on how long data took transmitting back and forth during each individual time segment. | ||