Network Computingwww.networkcomputing.com

Bill: Again, there were no missing packets or packets with CRC errors for any of the SMB write requests.

Scott: Then why wasn't the remote server responding?

Bill: Perhaps a trip to the remote site (thankfully, it was only a few miles away) would yield some clues. But before we traveled to the remote site, we set up a continuous ping to the remote NT server, generating packets once per second at the maximum Ethernet MTU. As expected, the loss rate was around 50 percent.

Scott: We then went to the remote site and looked at the ping both on the T1 and the Ethernet networks.

Bill: We could see the originating ping packets wit hout error.

Scott: Yet the server didn't respond to every request, resulting in the loss rate we were experiencing at the client.

Bill: Could the server's adapter, drivers, protocol stack or something else inside be bad?

Scott: We looked closer at the hub.

Bill: It was one of those modular doodads, which allows multiple hub modules to be plugged into a chassis.

Scott: There were four modules plugged in--one router and three hubs.

Bill: Tracing the server to a hub port, we decided to move our analyzer to the same hub module as the server.

Scott: Then by capturing and reanalyzing the ping request packets, we could see that every request not returned by the server had a CRC error!

Bill: Bingo! Problem pinpointed. But why the CRC errors?

Scott: Closer scrutiny of the bad packets gave us the answer.

Bill: The packets that had the CRC errors were the same length as the good ones, meaning there could have been one or more bit errors in the packet.

Scott: By looking at the packet in hex format from beginning to end, we saw that the hub was corrupting the last dozen or so bytes in the packet with a repeating bit pattern of 1s and 0s. This was definitely not a single bit error.

Bill: Obviously, the 10BASE-T repeater function in the hub was malfunctioning, but only toward the end of larger packets.

Scott: Looking at the third and final hub module, only some of the packets that were not returned by the server were repeated bad.

Bill: So one of the hub modules was perfectly fine, another was partially bad and the third was really bad.

Scott: By moving the server connection over to a port on the good hub module, our remote pings went from a 50 percent success rate to 100 percent, and both TCP/IP and NetBEUI users were able to reliably transfer files at roughly 500 Kbps over the fractional T1. Finally, for complete reliability, the two bad hub modules had to be replaced, so that users at the remote site could function reliably.

Bill and Scott can be reached at otw@pmg.com. Portions of trace files from selected columns are available via Pine Mountain Group's Home Page (www.pmg.com).