Hello Network Engineers,
I've been tasked with identifying weather or not my current network has (egress / ingress) MTUs greater than 1400.
My question is, what is the best method of capturing/depicting the network's current MTU sizes and where should I preform this capture/monitor?
This is my first question on the site. I look forward to working with all of you.
v/r
Errdisabled
You can test path MTU discovery across a live network with a tool like tracepath (part of the Linux IPutils package) or mturoute (Windows only). Here's a sample of tracepath output from the lab pictured above, with the MTU of F0/1 reduced to 1400 bytes using the ip mtu command:
Host$ tracepath -n 192.168.1.2
1: 192.168.0.2 0.097ms pmtu 1500
1: 192.168.0.1 0.535ms
1: 192.168.0.1 0.355ms
2: 192.168.0.1 0.430ms pmtu 1400
2: 192.168.1.2 0.763ms reached
Resume: pmtu 1400 hops 2 back 254
The easiest way to check supported MTU sizes is ping - provided your routing nodes support echo requests/replies.
E.g. in Windows you can use ping -f -l 1472 [destination IP] to check for 1500 byte MTU all the way to the [destination IP]. If you get a fragmentation error or no reply at all the destination path does not support the tested MTU.
Ping uses ICMP echo requests, the ICMP packet and the encapsulating IPv4 packet cause 28 bytes of overhead. -l 1472 adds 1472 bytes of test data to the packet headers for a total size of 1500 bytes. The -f option sets the 'Don't Fragment' bit to avoid fragmentation (which would hide the inability to transport the requested packet in whole). Obviously, to test for other MTU sizes you subtract 28 from the desired MTU and use that with -l.
ping on n*x has many variations.
Once you have determined MTU values for a given path (see Maverick's answer), it might be worth looking for traces of TCP MSS clamping (a.k.a ip tcp adjust-mss in Cisco speak) happening along the path between source an destination.
Why? If the tests happen to be TCP based, results might be skewed by MSS clamping.
In a typical scenario on plain Ethernet, an initiator (mostly called 'client', but TCP has no concept of client nor server), in its intial TCP SYN segment, will announce a TCP Maximum Segment Size (MSS) of own-NIC's-MTU_minus_(TCP+IPv4-Headers), or 1500 - 40 = 1460 (1428 if TCP timestamps are in use).
And the responder ('server') will do the same, deriving the maximum TCP payload size from it's own NIC and sending that value in it's SYN/ACK segment.
Routers, along the path, interconnecting different links/media with different MTU characteristics, can and will manipulate that value, so that fragmentation can be avoided. This becomes very important if further encapsulation is happening on some sections of the path, like PPPoE, GRE or IPSec tunnels.
To observe the effects of TCP MSS clamping, you need to be able to capture the initial SYN and SYN/ACK packets on both initiatior and responder for a TCP session.
If, in the same SYN segment, upon arrival at the responder, the value is lower than it was when it left the receiver, then at least one router (or L3-switch or firewall or VPN concentrator or...) is doing TCP MSS clamping.
Be sure to compare the values in both directions (with the SYN/ACK packet of the same tcp session). PathMTU in itself is something unidirectional that occurs independently in the other direction, and also the MSS clamping configuration bits on a given device can be of unidirectional nature (only ingress, only egress, both) - depending on vendor, that is.
UDP has no concept of MSS; either the application knows how many bytes to send per packet, or it relies on PMTU discovery and it's hints of lower MTU, and adapts accordingly. But PMTU on IPv4 is not especially famous for being reliable.
Out of experience, if I were asked (by application people, that is) about "do we have 1400bytes MTU on our network?", I would bounce the question back: "1400 is what you need? If I confirm, will you be happy with sending a maximum of 1360bytes of payload per packet on non-timestamped TCP and 1372 on UDP?" In the end, I would want them to bring forth their requirements in terms of n bytes of payload per packet, not as MTU or packet size or whatever they believe the unit is.
