Thanks for the reply. I had previously read that web page, it only contains information about how to disable path mtu discovery. Or to reset the mtu size of an interface. Not how to look at the info.

I'm trying to find out how to view the path mtu information. So in a situation where path mtu discovery is enabled, I want to be able to look at that information, to see what path mtu discovery has, discovered

You might have to resort to using protocol analyzer. By capturing traffic sent/received by the host(s) in question, you should be able to see the MTU that they use.

Last time I supported Windows machines was back in W2K around 6 years ago. Back then, I never heard of any built-in utility that would provide you with this functionality. Maybe some 3rd party tools?

The easiest way I know of is to set the size of an ICMP packet - set the DF bit, and reduce the size until you know the right size MTU from site A to site B

Don't forget that MTU & MSS are directly related, the MSS is negotiated in the TCP hadnshake with the remote end and depends on the MTU.

If you start the test with a packet size of 1460 - which is 1500 (the default MTU of any NIC) minus 20 Bytes for the TCP header, and 20 Bytes for the IP header.

ping -l 1460 -f <>

if the packet it to large you will recevice something like:-

c:\>ping -l 1460 -f 158.152.1.58

Pinging 158.152.1.58 with 1460 bytes of data:

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Ping statistics for 158.152.1.58:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

c:\>

Keep reducing the number until you find the number.

Another way is to install wireshark (formerly Ethereal) set the packet capture and create a TCP connection - you will see in the TCP and TCP SYN in the

TCP header options field you will see the MSS that host a can send, the response with what host b can send - the lowest number generally wins. Do not forget

the whole point is to find out the maximum size of data that can be sent un-fragmented. If you have MTU/MSS issues - this can break internet connections to

web sites, also internal Active Directory server communication etc.

There are a few ways to fix this - reducing the MTU on the router WAN interfaces, setting the tcp adjust-mss feature on the cicso plaltforms - not all IOS platforms

suppport this, you could write a route map - that sets the DF bit to 0 on the WAN edge - so down stream the session could be fragmented if required. Or just reduce

the MTU size on the NICs - this does not scale well when you have over 50+ servers.....but nothing is perfect!!

HTH.

Thanks for the responses. I am familiar with and quite frequently use wireshark. I understand that I could capture the data and see this info. I'm not working on a specific network problem, I'm trying to put together some training material to explain PATH MTU. If you search on the web for info about it, there's tons of sites that tell you what it does, but it would seem to all happen magically in the background. I was hoping to provide for the students a simple command line method to determine the status of PATH MTU discovery on a host, and see what the MTU of the hops are. As I stated previously the only place I've found so far that provides this info is to look at the destination cache on a windows machine (at least an XP machine)that is running IPV6. Though it doesn't show each hop it does show the MTU to the destination. It was, and still is my hope that there is some command line way to see this info on other OSes. Linux, Solaris, WIN 2000 etc.

Thanks

That is tricky - as I know of no generic tools that can do that on the platforms you have mentioned, the best source of information I have found in the past is the RFC:-

http://www.ietf.org/rfc/rfc1191.txt

If you find any tools/cli way of viewing PMTU in action - post in the forums.

The reason why you don't see hop-by-hop MTU size is because the MTU size used at each hop is the same. Any hosts conforming to Path MTU discovery standard would basically attempt to determine the max MTU size that can be transmitted end-to-end without being fragmented by using ICMP. Once that size is found, the transmitting host will simply fix the MTU size.

If I'm not mistaken, if a device along the path does not support Path MTU discovery, then the transmitting host is supposed to use MTU size of 576 bytes.

For what it's worth, the author of the following document appears to have determined that this capability (i.e.: monitoring Path MTU) is absent on the Windows platform:

http://regions.cmg.org/regions/cacmg/Nalini%20-%20TCPProfileParametersPrint.pdf

Edit: See page 27, second frame/slide.

... unfortunately, the document is not dated. If you were to contact this individual, maybe they would have more info to share.

There is a third party tool that may be of interest, although it doesn't capitalize on the OSs own discovery awareness.

http://www.elifulkerson.com/projects/mturoute.php

Cisco has a document that discusses the subject quite well. If you're not already aware of it, you might find it of interest:

http://www.cisco.com/application/pdf/paws/25885/pmtud_ipfrag.pdf