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

†† 65535

†† 32000†††††††††††† Just in case

††††††††††††† 17914† 16Mb IBM Token Ring†††††††††† ref. [6]

†† 17914

††††††††††††† 8166†† IEEE 802.4††††††††††††††††††† RFC 1042

†† 8166

††††††††††††† 4464†† IEEE 802.5 (4Mb max)††††††††† RFC 1042

††††††††††††† 4352†† FDDI (Revised)††††††††††††††† RFC 1188

†† 4352 (1%)

††††††††††††† 2048†† Wideband Network††††††††††††† RFC 907

††††††††††††† 2002†† IEEE 802.5 (4Mb recommended)† RFC 1042

†† 2002 (2%)

††††††††††† ††1536†† Exp. Ethernet Nets††††††††††† RFC 895

††††††††††††† 1500†† Ethernet Networks†††††††††††† RFC 894

††††††††††††† 1500†† Point-to-Point (default)††††† RFC 1134

††††††††††††† 1492†† IEEE 802.3††††††††††††††††††† RFC 1042

†† 1492 (3%)

††††††††††††† 1006†† SLIP††††††††††††††††††††††††† RFC 1055

††††††††††††† 1006†† ARPANET†††††††††††††††††††††† BBN 1822

†† 1006

††††††††††††† 576††† X.25 Networks†††††††††††††††† RFC 877

††††††††††††† 544††† DEC IP Portal†††††††††††††††† ref. [10]

††††††††††††† 512††† NETBIOS†††††††††††††††††††††† RFC 1088

††††††††††††† 508††† IEEE 802/Source-Rt Bridge†††† RFC 1042

††††††††††††† 508††† ARCNET††††††††††††††††††††††† RFC 1051

†† 508 (13%)

††††††††††††† 296††† Point-to-Point (low delay)††† RFC 1144

†† 296

†† 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:





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:



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

this chapter.


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