Rub-A-Dub-Dub Three Hubs In A Tub By Bill Alderson and J. Scott Haugdahl   We're having a lot of trouble transferring data to or from a remote Ethernet network. It's connected via two routers over a fractional T1 operating at 768 Kbps. Our Windows95 users can see our Windows NT servers and their directories just fine, but drag-and-drop file transfers fail with a "network resource is no longer available" error message. When we ping the remote site, the packet loss climbs as high as 50 percent when the packet sizes reach the maximum transfer unit (MTU) of Ethernet. By setting both routers' MTU to 1,100 bytes, users running TCP/IP are successful, but NetBEUI users are still having problems. Our regional Bell has tested and says there is no problem with the T1. Locally, we're using an FDDI backbone with Ethernet concentrat ors containing Ethernet-to-FDDI bridges. The routers are set to route IP and bridge NetBEUI. Scott: A logical place to start is to analyze what transpires on the LAN and WAN segments between a user and a server. Bill: A quick analysis of the Ethernet segments on either side of the FDDI backbone (the user's segment and the one connected to the router) showed no evidence of missing packets or corrupted packets containing cyclic redundancy check (CRC) errors. Scott: Nor did we see any dilapidated, broken-down, rotten or shabby packets. Bill: Yet, when a workstation tried writing a file to the remote Windows NT server using NetBEUI, a packet trace showed several Server Message Block (SMB) write block raw retries to the point of failure. Scott: However, TCP/IP users were able to transfer files successfully, so one solution would be to cut over to TCP/IP. Bill: That wouldn't answer the question as to why NetB EUI wouldn't work, and our customer wasn't about to completely switch to IP overnight. Scott: We also wanted to solve the NetBEUI problem, since TCP/IP may be masking the real problem. Bill: It was evident from the trace that TCP/IP never used an MTU higher than 1,100 bytes--the setting at the router's T1 interface. Scott: On the other hand, the SMB write block raw data was inside a 1,504-byte packet, which exceeded the 1,100-byte MTU. Bill: The router was simply dropping the write block raw packets, since NetBEUI has no way to report or recover from mismatched MTUs. Scott: The sender's TCP/IP stack automatically adjusts the packet size down and successfully ge ts the packet to the remote site. Bill: We decided to up the routers' MTU to its original default setting of 1,600 bytes and reanalyze. Scott: Now, the larger SMB write packets would make it through--some of the time. Bill: There was still a major problem, since the TCP/IP clients were having trouble with larger packets, often timing out on several write attempts with large packets.

The Networkologist by Patricia Schnaidt FreeWire by Bill Frezza Coporate View by Brian Walsh In The Middle by Bruce Robertson Updated February 21, 1997