Observer Analyzer : Observer Analyzer : Expert Analysis : Using MultiHop Analysis : Configuring MultiHop Analysis settings
Configuring MultiHop Analysis settings
Click the Settings button on the MultiHop analysis tool bar to specify capture files and other configuration options. Usually, the default settings will provide satisfactory results; only adjust if you run into performance problems.
The first tab, Settings, has options to specify the methods that MultiHop analysis uses to identify connections and synchronize timestamps on the files.
IP Address + IP ID (Port mapped)
This option is best for networks that implement Network Address Translation (NAT) firewalls between segments.
IP Address + IP ID + TCP/UDP Ports (Ports will match)
Choose this option (which is the default) for networks without address translation or port mapping.
IP Address + TCP Sequence number (TCP only, port mapped)
Choose this option if your network includes Network Address Translation (NAT) firewalls, and the volume of packets in the captures is causing the IP ID numbers to be recycled (i.e., reset to 0).
IP Address + TCP Sequence number (TCP only, ports will match)
Choose this option if your network does not have any Network Address Translation or port mapping, and the volume of packets in the captures is causing the IP ID numbers to be recycled (i.e., reset to 0).
Maximum packets to analyze per connection
Allows you to select the maximum number of packets you want to analyze; only active if the Enable is selected.
Allows you to limit the number of packets to be analyzed.
Changes the settings back to their default values.
File Synchronization Method
File synchronization is at the heart of MultiHop Analysis. By aligning the files in time and determining whether timestamp differences are the result of delay versus clock drift and other collection artifacts, Observer can show you not only aggregate delay, but also the proportion of delay with each hop.
Identifying how much data to synchronize and where to start
There are many possible methods that Observer can use to synchronize the files. The best one to use depends on two factors: How long were the captures? and How closely in time were the captures started and stopped?
This is because of a phenomenon called clock drift: two system clocks inevitably drift apart because no two clock crystals are exactly the same, and even if they were, ambient temperature differences also affect clock rates. On shorter captures (i.e., four minutes or less), this is not usually an issue, so choose the first option. For longer captures (more than four minutes), the best method to choose depends on how closely the buffer files’ start and stop times conform to each other.
Synchronize using all data from both files—This method is best for shorter captures (of four minutes or less) where all the captures were started and stopped within a second of each other, and clock drift is not an issue.
Synchronize using a sliding window having the smallest variance—Using this method, Observer analyzes the two packet captures to find a window of time where the timestamps coincide with the least variance. This method is best for finding transactions across longer captures that were not very precisely synchronized regarding start and stop times.
Synchronize at the beginning of the files with a clock drift correction—This method (the default) corrects for the inevitable differences between probe system clocks by comparing the beginning and end packets of all captures to determine clock drift. This method is best for longer captures (of four minutes or more) where all the captures were started and stopped within a few seconds of each other.
Identifying synchronization artifacts versus actual delay
Different methods work better for determining synchronization artifacts (such as clock drift and other system clock differences) versus actual delay caused by the network.
Calculate synchronization using average delay times—Choose this option if delay times are fairly uniform and short (such as delay times typical between local network segments).
Calculate synchronization using minimum delay times—Choose this option (the default) if there are longer delays between segments, or delay times vary from short to long (such as delay times that would be typical of a WAN connection to a remote segment of your network that experiences congestion).
Time Synchronization Window (msecs)—Use the default value (20000) in most cases. If packet IDs are being recycled (e.g. reset to zero) because they are being used up too quickly due to the volume of traffic, you can set this value lower.
Use Header following the GRE or GTP Header for Encapsulation/Tunneling—GRE (Generic Routing Encapsulation) and GTP (GPRS Tunneling Protocol) are two encapsulation protocols that may have been deployed on your network. To show the encapsulation IP addresses, leave the box unchecked; to show the nested IP addresses, check the box.