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.