Network Computingwww.networkcomputing.com

Bill: Exactly. Normally the transport layer would take care of this, but since there wasn't any, SMB had to ask again for anything it didn't get.

Scott: Indeed, just like the workstation, we didn't always see the reply packet in the analyzer either, until the workstation asked for it a second time.

Bill: Either the request packet never got to the NT server or the reply packet didn't make it back to our segment.

Scott: It was time to analyze the network chain back to the server.

Bill: Since we were already at the remote site, we broke out our trusty WAN analyzer, and hooked it up to the same V.35 interface that the router was using to send/receive synchronous data to/from the CSU/DSU.

Scott: Beyond that, it was telco and frame relay territory, so we were hoping we could spot the problem at this point.

Bill: Interestingly, we could see a valid response packet (one that was perfectly formed with no CRC error) from the NT server for every SMB request.

Scott: Since the analyzer could see a good response for every request, this ruled out the case where the request packet didn't make it to the server.

Bill: This meant that the T1 was OK, the frame relay was OK and all the stuff at the other end was OK.

Scott: As it turns out, the problem was pinpointed to none other than our trusty little router dropping packets. After all, we were literally seeing the exact same valid replies on the same input as the router, since both were connected via a V.35 "Y" ca ble.

Bill: Ironically, every packet that came across the 10-Mbps Ethernet would be sent out over T1 OK, but every packet coming from the slower T1 wouldn't always make it over to Ethernet.

Scott: The router only had the two interfaces, so we didn't feel it was a loading issue, and the router configuration didn't give us any further clues to the internal nature of this problem, so we had to place this problem in the hands of the router vendor.

Bill: Meanwhile, a different router solved the problem. The user and the router vendor are working on the dropped-packets bug, uh, feature.

B ill 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).