From Vince Fuller:

At what point in the future are you planning to raise the FDDI MTU on the ENSS from 4000 bytes to the default value of 4470 bytes? It has recently come to my attention that we, and any other regional which uses a cisco router on FDDI to peer with an ENSS, may be taking an enormous performance hit by using the non-standard MTU - it seems that the FDDI fast-switching path on a cisco router is automatically disabled if the interface is configured with other than the default MTU. This may explain some of the problems we have been having recently with high CPU utilization levels on our routers which peer with the NSFNET over FDDI.

From: Vimal Solanki, Curtis Villamizar, Jordan Becker Draft Standard RFC-1188 states that "the MTU of FDDI networks shall be 4352 octets". At present, the IBM routers temporarily violate this as explained below. Currently we have 4000 byte MTU paths among all FDDI ENSSs. This is due to the fact that buffers are allocated in the current software such that the RS/960 T3 card can not support larger than a 4000 bytes MTU. Packets received larger than 4000 bytes are fragmented on the FDDI card (with the first fragment being 4000 bytes). This will be fixed when AIX 3.2 is deployed (scheduled for March). The MTU will will then increase to 4352 bytes on both the T3 and FDDI cards. We will still be able to *receive* packets up to 4470 bytes in size, and fragment them (with first fragment being 4352 bytes). However we will not *send* packets of size larger than 4352 bytes.

Can someone estimate for me the impact on an ENSS of fragmenting >4000 byte packets? Given the relative scarcity of full-FDDI-MTU paths through the Internet, the likelihood that packets larger than 4000 bytes will need to be fragmented by an ENSS seems very low to me, so unless an ENSS does something extremely stupid (such as drop packets) when faced with such a fragmentation decision, my guess would be that we will want to optimize the common case and run with default MTUs on our FDDI cisco routers. In fact, as a Friday-night experiment, I have reset the MTUs on all of our FDDI cisco routers with no apparent ill effect. Is this likely to cause problems for the NSFNET?

The FDDI card will handle the maximum possible fragmentation at the maximum possible bandwidth without any performance problems. In other words, if every single packet needs to be fragmented, the FDDI card can still handle it without dropping any packets for 22.5 Mbps full-duplex data stream between itself and the T3 card. This was tested with an ENSS router equipped with FDDI and the 22.5 Mbps HSSI/T3 card. While we did not run this specific test in the presence of T/960 Ethernet, T1 cards, or the new full T3 cards, the performance should still be good. Looking at ENSS128, there are no requests for buffers denied. There have been no errors at all in card-to-card, or card-to-system transfers which is where one would expect to see a problem due to fragmentation.

Please advise.

We suggest that you set your MTUs to 4470 since this will ensure autonomous switching on your Cisco. When we go to AIX 3.2 we will use 4352 bytes MTU. This will still ensure almost zero fragmentation since almost all traffic will be sinked/sourced from end hosts. --------------------- RFC 1188 IP and ARP on FDDI Networks October 1990 MAC Layer Details Packet Size The FDDI MAC specification [4] defines a maximum frame size of 9000 symbols (4500 octets) for all frame fields, including four symbols (two octets) of preamble. This leaves roughly 4470 octets for data after the LLC/SNAP header is taken into account. However, in order to allow future extensions to the MAC header and frame status fields, it is desirable to reserve additional space for MAC overhead. Therefore, the MTU of FDDI networks shall be 4352 octets. This provides for 4096 octets of data and 256 octets of headers at the network layer and above. Implementations must not send packets larger than the MTU. Gateway implementations must be prepared to accept packets as large as the MTU and fragment them when necessary. Gateway implementations should be able to accept packets as large as can be carried within a maximum size FDDI frame and fragment them.