mturoute.exe - Debug the MTU values between you and a host.
mturoute.exe is a small command line application that uses ICMP pings of various sizes in order to determine the MTU values on the path between itself and the target system. It also includes a "traceroute" like mode where it will attempt to determine the lowest MTU between the local host and each hop in the communication.
Download:
Listing directory https://download.elifulkerson.com/files/mturoute/2.5:mturoute-src.zip June 24 2017 16:31:01 21530 Zip archive data, at least v2.0 to extract
mturoute-src.zip.asc June 24 2017 16:35:31 801 GnuPG signature
mturoute-src.zip.md5 June 24 2017 16:35:31 51 MD5 checksum
Behavior/Usage:
Usage: mturoute [-t] [-f] [-m MAX_PAYLOAD_SIZE] host
Flags:
-t : Toggles 'traceroute' mode. (Default is off)
-f : Allow fragmentation. This will return the max ping size that the
target host will respond to, but not necessarily the MTU.
-w : Set the number of milliseconds to wait for a response (default 3000).
-r : Set the maximum number of probe retries on timeout (default = 3).
-i : Set the interval between two echo requests.
-d : Increases the debugging level. Reports ICMP status/failures.
-m : Sets a maximum payload size to test. (Default is 10000)
-v : Print version info and exit.
-z : Fill ICMP packets with random data.
-p : Fill ICMP packets with a specified pattern.
-s : Skip speed optimizations.
-x : Redact IP addresses in output.
-h,-? : Print usage information and exit.
Mturoute sends a non-fragmentable icmp probe to the target IP address with a given payload size. Since the do-not-fragment bit is set, any network equipment that has an MTU setting which is smaller than the packet size will drop the packet.
Based on the ICMP response, or the lack of a response, mturoute adjusts the payload size of its next probe. Subsequent probes are sent with a packet size midway between the highest value for which a response was received and the lowest value for which a response was not received. (For the initial conditions, the low value is 0 and the high value is whatever you set with -m, defaulting to 10000 bytes).
This process is repeated, narrowing the search space by ~50% with each cycle, terminating once the highest possible probe size has been converged upon. It then adds the 28 bytes of ICMP protocol overhead before reporting results.
Note: Speed optimization. By default (unless disabled with -s), mturoute will perform a series of educated guesses before settling down into its search pattern. If the guesswork is successful, the relatively slow search process described above is shortened and/or skipped altogether.
• In -t "traceroute" mode, mturoute performs this same process for each hop between you and the specified host. The output is abbreviated (only the +/- characters remaining to indicate progress), outputting a single MTU value for each hop.
Since each probe has to traverse the entire distance from localhost to a given hop, the reported MTU values represent the smallest MTU setting between you and the given hop, not necessarily the MTU setting between a hop and its immediate predecessor. For instance, if the MTU is narrowed on a hop midway between you and your destination, all subsequent hops will show the same small size - as your packets to more distant hops must pass through that choke point.
For example:
... despite the MTU value widening past hop C, mturoute would display the narrow, green size for both hop D and the destination host.
Due to the nature of the test, it is sensitive to packets dropped for non-MTU related reasons. Packets that are lost for other reasons will result in an incorrect MTU reading. Mturoute will attempt to re-probe to avoid dropped packets, but the mysteries of the Internet may still conspire to give you an incorrect reading. In general, the true MTU cannot be lower than the highest successful probe, but the possibility does exist that the true MTU may in fact be higher than reported.
Also, due to the asymmetrical nature of routing, this is by definition a one-sided test - as is traceroute itself. Responses originating from the target and travelling back to you are not guaranteed to travel the exact same route as your probe if multiple paths are available. Although unlikely, its possible that there might be an MTU issue on the return path which mturoute would not detect. If you have access to a computer on the far side of the network, running mturoute from there would provide information about the reverse path.
Further, again due to asymmetrical routing, there is no guarantee in traceroute mode that the path *to* a given hop is the same path that passes *through* that same hop to get to a different destination. You may see output that appears to disagree with the bottleneck diagram above.
• If the -f flag is specified, mturoute doesn't test MTU sizes. This flag will toggles off the "do not fragment" bit, which will allows intermediate routers to break mturoute's probes into multiple packets if they exceed the MTU size. Fragmented probes are re-assembled at their destination. With MTU is taken out of the equation, this mode instead reports the largest ping that a given host will respond to. This could help you determine whether fragmentation is happening properly.
• The -w setting sets the amount of time you want mturoute to wait for a response for a given probe.
• The -i setting allows you to specify the length of the interval that mturoute will wait between probes.
• The -r setting allows you to specify the number of retries that mturoute will run given a probe timeout. The default number of retries is 3.
• The -d setting instructs mturoute to output more verbose debugging information as it runs.
• The -m setting allows you to set a maximum probe size, in bits. The default is 10,000.
• The -v setting outputs the version information. Versions prior to v2.1 have no version information.
• The -s setting skips speed optimizations. (v2.2+)
• The -x setting toggles redaction of network information. If used, ip addresses will be replaced with "a.a.a.a", "b.b.b.b" etc. (v2.4+)
Platform:
Note: Turns out there is a similar-functioning equivalent in the Linux world for this sort of thing already: tracepath. If you're looking for a version of tracepath for windows, mturoute may suit your needs... and if you are seeking to compile mturoute for Linux, you should probably see if you can do it with tracepath.
History/License:
* Fixed up some buffer size related bugs, hopefully squashing any mysterious crashes that people may have been having. In particular, if large packet sizes crashed for you before (in theory) they should be working now. * added a "-v" option to output version information so I don't get confused. Since I had previously dubbed Ivan's version "v2", I am unceremoniously dubbing this version "v2.1". Incremental fixes will be v2.2, v2.3 etc. Huge changes, if ever, might make a v3. * Speed fixes for dealing with unresponsive hosts. Rather than ticking down from the base test value all the way to the minimum MTU, mturoute will now throw out a minimum sized packet before it begins. If this minimum packet times out, we skip all the larger packets. Under the default settings this should result in an approx 3 second wait for non-responsive hosts. * Fixed some embarrassing spelling errors and cleaned up a bit of output. Non-responsive hosts will no longer report things like "------------------ host: blah max: 120 bytes", rather a message about them being non-responsive will be issued.
* some runtime optimizations (tries 1500 as an mtu before going whole hog and scanning the entire possible range) * some bug fixes
* Clearer output when a connection fails with an ICMP too-big response as compared to a mysterious failure where no ICMP response was recieved at all. * Made debug mode clearer when using the speed optimizations. A bit.
* New "-x" option automatically redacts ip address and host information in the output, replacing them with "a.a.a.a", "b.b.b.b" etc. * Added "-h" and "-?" that show usage information. Running the exe with no arguments will show usage information as well. * When the mtu for the previous hop is known, we start at that mtu when checking the next hop. * No longer double checking the successful MTU. (1500 good... 1501 bad.... 1500 good!). We now remember that we were right on the money with n-1. * Drastically increased the amount of information in debug "-d" mode. Need to clean it up. * If the user hasn't specified agruments for -w and -r, and we get three timeouts in a row "...", mturoute now assumes that ICMP responses will not be coming and adjusts its default -w and -r downward. This should speed things up for people who don't get those responses and don't provide their own -w and -r settings. If either option is specified or optimization is disabled, mturoute will not dynamically adjust its behavior.
* Fixed an off by one error in certain cases
Example Output:
C:\mturoute-src\bin>mturoute www.example.com * ICMP Fragmentation is not permitted. * * Maximum payload is 10000 bytes. * - ICMP payload of 5046 bytes failed.. - ICMP payload of 2569 bytes failed.. + ICMP payload of 1330 bytes succeeded. - ICMP payload of 1949 bytes failed.. - ICMP payload of 1639 bytes failed.. - ICMP payload of 1484 bytes failed.. + ICMP payload of 1407 bytes succeeded. + ICMP payload of 1445 bytes succeeded. + ICMP payload of 1464 bytes succeeded. - ICMP payload of 1474 bytes failed.. + ICMP payload of 1469 bytes succeeded. + ICMP payload of 1471 bytes succeeded. + ICMP payload of 1472 bytes succeeded. - ICMP payload of 1473 bytes failed.. + ICMP payload of 1472 bytes succeeded. + ICMP payload of 1472 bytes succeeded. Path MTU: 1500 bytes. C:\mturoute-src\bin>mturoute -t www.example.com mturoute to www.example.com, 30 hops max, variable sized packets * ICMP Fragmentation is not permitted. * * Maximum payload is 10000 bytes. * 1 --+---+++-+++-++ host: 192.168.2.1 max: 1500 bytes 2 --+---+++-+++-++ host: 10.90.160.1 max: 1500 bytes 3 --+---+++-+++-++ host: 68.87.56.165 max: 1500 bytes 4 --+---+++-+++-++ host: 68.87.56.213 max: 1500 bytes 5 --+---+++-+++-++ host: 68.87.56.209 max: 1500 bytes 6 --+---+++-+++-++ host: 68.87.56.201 max: 1500 bytes 7 --+---+-+++++++ host: 68.87.56.197 max: 1472 bytes 8 --+---+++-+++-++ host: 68.87.56.249 max: 1500 bytes 9 --+---+++-+++-++ host: 68.87.56.253 max: 1500 bytes 10 --+---+++-+++-++ host: 68.87.19.177 max: 1500 bytes 11 --+---+++-+++-++ host: 12.118.149.13 max: 1500 bytes 12 -----+---+-+-- host: 12.123.3.14 max: 285 bytes 13 ---+----+----- host: 12.123.3.109 max: 758 bytes 14 --+---+++-+++-++ host: 192.205.32.198 max: 1500 bytes 15 --+---+++-+++-++ host: 204.70.192.186 max: 1500 bytes *15 (An additional device responded for 204.70.192.186.) *15 (An additional device responded for 204.70.192.186.) 16 --+---+++-+++-++ host: 204.70.192.13 max: 1500 bytes *16 (An additional device responded for 204.70.192.13.) 17 --+---+++-+++-++ host: 204.70.192.65 max: 1500 bytes 18 --+---+++-+++-++ host: 204.70.192.70 max: 1500 bytes 19 --+---+++-+++-++ host: 204.70.192.49 max: 1500 bytes *19 (An additional device responded for 204.70.192.49.) *19 (An additional device responded for 204.70.192.49.) 20 --+---+++-+++-++ host: 204.70.192.117 max: 1500 bytes *20 (An additional device responded for 204.70.192.117.) 21 --+---+++-+++-++ host: 204.70.192.90 max: 1500 bytes 22 --+---+++-+++-++ host: 204.70.192.90 max: 1500 bytes *22 (An additional device responded for 204.70.192.90.) 23 --+---+++-+++-++ host: 208.172.156.198 max: 1500 bytes 24 --+---+++-+++-++ host: 66.35.194.34 max: 1500 bytes *24 (An additional device responded for 66.35.194.34.) 25 --+---+++-+++-++ host: 66.35.250.151 max: 1500 bytes *25 (An additional device responded for 66.35.250.151.) *25 (An additional device responded for 66.35.250.151.)
Related Projects:
The MTU Eyechart - visual debugging of MTU problems with your HTTP connection