Another way to check the MTU of a remote destination is pinging (for example) a remote device with the size of the packet (MTU) and the Don't fragment bit (DF) set.
An example of this would look like this:
R1#ping 126.96.36.199 size 1500 df-bit
If the ping is successful the MTU sended to the remote destination is supported, but if fails, the MTU is not supported, so fragmentation would be required.
Message was edited by: Elvin Arias
Funny, I was researching this very same thing, as I'm studying for R&S. Haven't used/configured Frame Relay in a production network since 2005. I feel like I'm looking at my high school year book LOL
Data - Contains encapsulated upper-layer data. Each frame in this variable-length field includes a user data or payload field that will vary in length up to 16,000 octets. This field serves to transport the higher-layer protocol packet (PDU) through a Frame Relay network.
I'm gonna sound like such a genius for quoting RFC 3070, but I confess I found it in a search... http://www.ietf.org/rfc/rfc3070.txt
5.0 MTU Considerations
FRF.12  is the Frame Relay Fragmentation Implementation Agreement.
If fragmentation is not supported, the two Frame Relay endpoints MUST
support an MTU size of at least 1526 which is based on adding the PPP
Max-Receive-Unit size with the PPP header size with the Max L2TP
Header Size with the Frame Relay header size (PPP header size is the
protocol field size plus HDLC framing bytes, which is required by
L2TP). To avoid packet discards on the Frame Relay interface, the
RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default
MRU of 1500. The means to ensure these MTU settings are left to