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. 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? Please advise. Vince Fuller, BARRNet technical director P.S. Note to BARRNet NOC folks: the FDDI MTU change, which I have applied to SU-A, SU-B, SU-CAMPUS, and XX1, has not been committed to NVRAM, so a reload (or crash) will cause it to be backed-out.