MTU (Maximum Transmission Unit)
Standard MTU Sizes (Including IP headers, so these are "after encapsulation")
Plateau MTU Comments Reference
------ --- -------- ---------
65535 Official maximum MTU RFC 791
65535 Hyperchannel RFC 1044
32000 Just in case
17914 16Mb IBM Token Ring ref. 
8166 IEEE 802.4 RFC 1042
4464 IEEE 802.5 (4Mb max) RFC 1042
4352 FDDI (Revised) RFC 1188
2048 Wideband Network RFC 907
2002 IEEE 802.5 (4Mb recommended) RFC 1042
1536 Exp. Ethernet Nets RFC 895
1500 Ethernet Networks RFC 894
1500 Point-to-Point (default) RFC 1134
1492 IEEE 802.3 RFC 1042
1006 SLIP RFC 1055
1006 ARPANET BBN 1822
576 X.25 Networks RFC 877
544 DEC IP Portal ref. 
512 NETBIOS RFC 1088
508 IEEE 802/Source-Rt Bridge RFC 1042
508 ARCNET RFC 1051
296 Point-to-Point (low delay) RFC 1144
68 Official minimum MTU RFC 791
Token Ring IEEE 802.5 Networks Maximum Packet Size
It is based on the maximum time a node may hold the token. This time depends on many factors including the data signalling rate and the number of nodes on the ring. The determination of maximum packet size becomes even more complex when multi-ring networks with bridges are considered.
4 Mbps Token Ring - the most common of all Token Ring networks (howvere, there are also many 16 Mbps Token Ring networks) - given a token-holding time of 9 milliseconds and a 4 megabit/second ring, the maximum packet size possible is 4508 octets including all octets between the access control and the FCS inclusive. This allows 4508 - 36 (MAC header+trailer with 18 octet RIF) - 8 (LLC+SNAP header) = 4464 for the IP datagram (including the IP header). The 16 Mbps Token Ring NIC’s can transmit frames up to 17914 bytes.
*** However, some current implementations are known to limit packets to 2046 octets (allowing 2002 octets for IP). It is recommended that all implementations support IP packets of at least 2002 octets.
(Ethernet is not "exactly" IEEE 802.3. Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the standard 802.3 network allows only a 1492 octet IP datagram. )
Setting The MTU for Token Ring Clients
Most workstation token ring NIC's (Network Interface Cards) can be configured to limite the MTU (Maximum Transmission Unit), in order to avoid excessive fragmentation as the frames are encapsulated for transport over a Network. For example, Novell's NTR2000 card has the following parameter, which can be entered in the configoration file, "net.cfg" :
Servers on the LAN should have the same MTU setting for their Token Ring cards.
NTR2000 MAX FRAME SIZE number - Sets the maximum number of bytes that can be put on the network by the LAN driver.
The NTR2000.COM driver's default size is 4216 bytes. But if your board has 8 KB of shared RAM available, the default size is 2168 bytes. The value for number must be a multiple of 8. It must include the number of bytes for the data packet (usually 1, 2, 4, or 8 KB), for adapter overhead (6 bytes), and for the largest possible header (currently, 40 bytes LAN header + 74 bytes protocol header = 114 bytes). For example, to use 2 KB data packets, you would calculate the value for number as
2048 + 6 + 35 + 5 + 74 = 2168
If the total isn't a multiple of 8, then the NTR2000.COM driver rounds it up to the next multiple of 8. The NET.CFG file for a NTR2000 link driver with a maximum size of 2168 would have the following lines:
LINK DRIVER NTR2000
MAX FRAME SIZE 2168
NOTE: When the driver loads, the sign-on message doesn't reflect the 6 bytes of overhead. Therefore, the "Max Frame" for the above example would be displayed as 2162.
IMPORTANT: If you are running Windows in enhanced mode, the VIPX.386 device driver requires the maximum frame size to be less than 8000 bytes. If the frame size exceeds 8000 bytes, network communication will fail. Also, If you are running TBMI2.COM or TASKID, you can't use MAX FRAME SIZE.
If the line speed is 16 Mbps, the value for number must be between 632 and 17,960. If the line speed is 4 Mbps, the value must be between 632 and 4464.
Deciding what to Set MTU to
The basic idea to to send data through the network, end-to-end, with an acceptable of fragmentation. Fragmentation is, in itself, not a bad thing - in fact, it is an integral part of networking. A low to moderate amount of fragmentation is acceptable. Nevertheless, to be safe, always try to design networks with a minimum amount of fragmentation.
You must consider every device that the packets will encounter, and there are no absolutes in the MTU decision. If a LAN communicates with mutiple end devices, then it may be best to set the MTU to the lowest value. However, that will result in more packets being sent than necessary when a host is communicating with another host which allows higher packet sizes.
For the case of connection to Frame Relay networks, it would be best to set the MTU to a somewhat lower value than the Frame Relay MTU, in order to account for the overhead bytes of the Q.922 frames going between the router and the edge switch. For example, if the Frame Relay switch has a maximum frame size of 4096 bytes, then an MTU setting of 4000 bytes would be sufficient to insure that each packet that leaves the token ring network will not be fragmented when it is encapsulated in a frame relay frame. Looking at a couple of other scenarios, if you select 5000 bytes as the MTU, then a large amount of each packet will be encapsulated in the first frame, and a small amount of bytes will be encapsulated in the next frame, which is wasteful - but not necessarily detrimental. If you select 8000 bytes and the MTU (which would be impossible with 4 Mbps Token Ring, but possible with 16 Mbps Token Ring), then each packet would almost fill 2 frames, and would be very efficient, despite the fact that each packet is fragmented into 2 parts.
Now, even if one was to calculate the exact overhead per frame, and set the MTU to that fill one frame exactly, there may be communication with hosts on an Ethernet LAN, which is limited to 1500 bytes, and this would cause the packets to be dropped and a re-transmit at a lower MTU would be requested. Or, there may be 3270 emulation sessions set up between the workstation and a mainframe, which would bring in another MTU limitation.
As you can see, there are many variables to consider. In general, most large networks that have some token ring LAN's, also have other remote Etherner LAN's, and SNA mainframes - and the consensus is to set the MTU to the Ethernet level, of 1500 bytes of data. However, this is certainly not set in stone - and the MTU decision should be looked at on a case-by-case basis.
Understand Path MTU Discovery
RFC 1191: http://andrew2.andrew.cmu.edu/rfc/rfc1191.html
Our routers support the IP Path MTU Discovery mechanism, as defined in RFC 1191. IP Path MTU Discovery allows a host to dynamically discover and cope
with differences in the maximum allowable maximum transmission unit (MTU) size of the various links along the path. Sometimes a router is unable to forward a
datagram because it requires fragmentation (the packet is larger than the MTU you set for the interface with the ip mtu command), but the "Don't fragment" (DF) bit
is set. The router sends a message to the sending host, alerting it to the problem. The host will have to fragment packets for the destination so that they fit the smallest
packet size of all the links along the path. This technique is shown in Figure 18-4.
IP Path MTU Discovery is useful when a link in a network goes down, forcing use of another, different MTU-sized link (and different routers). As shown in Figure
18-4, suppose one is trying to send IP packets over a network where the MTU in the first router is set to 1500 bytes, but then reaches a router where the MTU is
set to 512 bytes. If the datagram's "Don't fragment" bit is set, the datagram would be dropped because the 512-byte router is unable to forward it. All packets larger
than 512 bytes will be dropped in this case. The second router returns an ICMP Destination Unreachable message to the source of the datagram with its Code field
indicating "Fragmentation needed and DF set." To support IP Path MTU Discovery, it would also include the MTU of the next-hop network link in the low-order
bits of an unused header field.
IP Path MTU Discovery is also useful when a connection is first being established and the sender has no information at all about the intervening links. It is always
advisable to use the largest MTU that the links will bear; the larger the MTU, the fewer packets the host needs to send.
Note IP Path MTU Discovery is a process initiated by end hosts. If an end host does not support IP Path MTU Discovery, a router will have no mechanism
available to avoid fragmenting datagrams generated by the end host.
The Cisco 7000, AGS+, and Cisco 4000 routers support fast switching of IP packets between Ethernet and FDDI interfaces. When packets are being sent from
FDDI to Ethernet interfaces and you are not using IP Path MTU Discovery, FDDI packets with data lengths larger than 1500 bytes will be fragmented into multiple
Ethernet packets. This will slow performance. If the majority of your router traffic travels off the FDDI ring, you might want to either lower the MTU size on your
host FDDI interfaces to 1500 bytes or run IP Path MTU Discovery on your hosts.
Because the CTR card does not support the switching of frames larger than 4472 bytes, some interoperability problems may occur if CTR cards are intermixed with
other Token Ring cards on the same network. You can minimize this by setting lower (and the same) IP maximum packet sizes for all devices on the network with
the ip mtu interface command.
To enable Path MTU Discovery for connections initiated by the router (when the router is acting as a host), see the section "Enable Path MTU Discovery" later in
Set the MTU Packet Size
All interfaces have a default MTU packet size. Depending on the hardware, you may be able to adjust the IP MTU size so that if an IP packet exceeds the MTU set for a router's interface, the router will not fragment it.
Changing the MTU value (with the mtu interface configuration command) can affect the IP MTU value. If the current IP MTU value is the same as the MTU value,
and you change the MTU value, the IP MTU value will be modified automatically to match the new MTU. However, the reverse is not true; changing the IP MTU
value has no effect on the value for the mtu interface configuration command.
Also, all devices on a physical medium must have the same protocol MTU in order to operate.
To set the MTU packet size for a specified interface, perform the following task in interface configuration mode:
Task : Set the IP MTU packet size for an interface.
Command ip mtu bytes
Enable Path MTU Discovery
Path MTU Discovery is a method for maximizing the use of available bandwidth in the network between the end points of a TCP connection, and is described in
RFC 1191. By default, this feature is disabled. Existing connections are not affected when this feature is turned on or off. To enable Path MTU Discovery, perform
the following task in interface configuration mode:
Task : Enable Path MTU Discovery.
Command: ip tcp path-mtu-discovery
Customers using TCP connections to move bulk data between systems on distinct subnets would benefit most by enabling this feature. This might include customers
using RSRB with TCP encapsulation, STUN, X.25 Remote Switching (also known as XOT or X.25 over TCP), and some protocol translation configurations.
The ip tcp path-mtu-discovery command is to enable Path MTU Discovery for connections initiated by the router when it is acting as a host.
CTR and MTU Settings
This tech tip explains why the CTR cannot handle 8K frames.
The code specifically checks for a CTR interface before setting the default MTU size, and sets the size to 4K if it is a CTR or 8K for multibus Token Rings at 16
Mbps. The reason for this distinction is that the cbus must carve up a limited amount of buffers between the different interfaces, for instance, CTR, FDDI, and
Ethernet. Parsing up 8K buffers for the Token Ring receive means that there is an 8K buffer available for the incoming frame even if it is a small one (for example, 39
In most situations, the frames are usually smaller that 8K. In fact, if the frames were mainly large then the ring would be dominated by the larger frames since they
would "fill up" the ring on a frame-per-frame basis and thus impact the performance of other stations on the ring. Furthermore, the cbus controller would spend too
much time on these large frames and this would impact the performance of the other interfaces on the complex. It was decided that the Cisco router would show
better performance numbers if the MTU size was limited to 4K on the CTR.
This reasoning is not applicable to the multibus Token Ring interfaces because the overall performance is much slower and so these performance limitations are never