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:
  • 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.
So I had to scrap my VC++ 2008 installation, download VC++ 2005, reinstall the Microsoft Platforms SDK and (after a few hours) recompiled the program: . Update (2007-10-03): I've rebuilt the image with static runtime library, so the VC++ runtime DLL is no longer needed. Thanks to Vladimir Kocjancic for figuring this out for me.
  • 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):
    • 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

    2 comments:

    1. Works of Vista now, Thanks.
    2. Couple comments:

      # 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 ;)
    Add comment
    Sidebar