Update: mturoute
Yesterday's post has generated quite a few comments (obviously a tool like this comes handy :); some of you were unable to run the .exe file I've provided, others wondered about the unexpected results. While testing the first issue, I've figured out that:After these changes, the utility should be able to execute on Vista as well.
Apart from the rebuild, I've fixed the ICMP destination network unreachable handling, which is considered identical to successful ping in the MTU measurement code (I still need to fix its handling in the trace part of the code).
There are also a few caveats when using this program on a Windows platform enabled for Path MTU discovery (default for the last few years):
- Any C program compiled with the free Visual C++ compiler from Microsoft requires runtime library that has to be installed separately. Update: not completely true, if you use change the runtime library to the non-DLL version (Project properties/C++/Code generation tab), the exe size increases, but the external dependencies are removed.
- The Visual C++ 2008 that I've used has no publicly available runtime library that you could install.
- The new build can be downloaded from the same location.
- It includes a README file that documents the changes made to the source.
- To run it, you have to install the VC++ 2005 runtime library from Microsoft
There are also a few caveats when using this program on a Windows platform enabled for Path MTU discovery (default for the last few years):
- Whenever the Windows TCP stack receives an ICMP specifying the maximum MTU, it caches the reported MTU size (makes sense).
- The cached MTU sizes eventually expire (but I was not able to find any documentation on the expiration time).
- I was also not able to find any documented way of purging the path MTU cache. The command that works for me is the route -f which flushes the IP routing table.
- Obviously, after executing route -f, the DHCP-installed default route is gone, so you have to execute ipconfig /renew.
Note: Any hints on the internal workings of path MTU cache on Windows platforms are highly appreciated
# Whenever the Windows TCP stack receives an ICMP specifying the maximum MTU, it caches the reported MTU size (makes sense).
I assume it caches the *minimum* MTU from A to B - not the first one it comes along. Otherwise, why do Path MTU ? :)
# The cached MTU sizes eventually expire (but I was not able to find any documentation on the expiration time).
That's brain-dead. It probably did make sense back in the '80s or so, when for going A to B there was one and only one path. Now that you can have multiple paths - either being used concurrently or in case of failure - caching the MTU for ONE given instance of ONE path from A to B makes little sense.
But I guess that's why (I assume) every given X interval they redo the PathMTU - in case tha path changed.
Obviously, it means that you have a time T0 when the PathMTU is right (and said time might be very low) and a time T1 when you're sending a bunch of datagrams with the incorrect size - which are to be fragmented - until Windows reruns the PathMTU algorithm.
I haven't sniffed, but I'm pretty sure that, to prevent dropping packets, they probably send the packets (even after PathMU) with DF cleared.
Or they send them with DF set, and the 1st time they get a "frag needed, but DF set" they rerun the PathMTU algorithm . . .
RFC-4821 provides for some interesting reading on this whole issue of PMTU (old way) and the "new and improved" suggested method ;)