The Case Of The IBM 3745 Orphan

E very now and then we have a little extra time after troubleshooting and optimizing a network. This was one of those times, so our customer asked us if we wouldn't mind looking at an IBM 3745 that was collecting dust in the corner of the computer room.

We didn't think "looking" at a 3745 would be very exciting, until we were told that this baby had been idle for 14 months! We couldn't believe our ears when told that the vendor couldn't get it working on our customer's 16-Mbps Token-Ring backbone. Apparently, every time the 3745 was inserted into the backbone, it would bring the backbone to its knees. As our customer put it, "To date, all the king's horses and all the king's men, couldn't put the poor 3745 back together again."

Scott: OK, so an IBM 3745 is not a pretty sight, but we couldn't resist the challenge of getting this thing working on the ring. Right, Bill?

Bill: My adrenaline was really flowing. This is no $99 Ethernet product, so we tried helping our customer, since he already paid for the big blue boat anchor.

Scott: Before we sprang into action, we needed to investigate the history of the problem.

Bill: Right. First off, the 3745 was placed in the computer room more than a year ago.

Scott: Since that time, it has never worked. Correct?

Bill: Not one iota. In fact, IBM apparently replaced every working part e xcept the little feet that touch the floor.

Scott: Incredible. Even several Token-Ring interface controllers (TICs) were tried to no avail.

Bill: So, we decided to hook up the ol' protocol analyzer to the backbone to analyze the traffic before and after inserting the 3745 into the ring.

Scott: To start with, the ring looked squeaky clean with no MAC error report frames being generated by any station nor any ring purges from the active monitor. Then we plugged in the 3745 and the backbone crashed. Our analyzer suddenly showed burst and line errors going crazy! Nobody could get through the backbone.

Bill: After a bit of analysis of the MAC error report frames and the respective fault domains, we recognized this behavior as a Token-Ring shielded twisted-pair (STP) node without a media filter for unshielded twisted-pair (UTP).

Scott: So we decided to look at the wiring infrastructure in more detail. To begin with, the customer has installed and certified Category 5 UTP throughput the entire building.

Bill: Going back to the 3745, we noted that it has one of those built-in universal hermaphrodite self-shorting connectors (that big, ugly, square, black thing). This went to a modified cable allowing an RJ-45 connection so it could be plugged into a twisted-pair hub.

Scott: Well, that's certainly the problem--no media filter. So we asked where we could find the media filter and our customer pulled out a box with 20 different adapters from IBM and others, and said, "Take your pick."

Bill: We had a schematic of the media filter circuit faxed to us. Then we got out an old-fashioned RS-232 break-out box, tore apart a good media filter and went about figuring out how to wire our own.

Scott: With a crowd standing around watching, there we were, standing with wires dangling from the strange looking wiring concoction. Within an hour, we were re ady for the "smoke test."

Bill: With only the grinding hum of the hundreds of computer room equipment fans, we plugged it in and it worked.

Scott: After several minutes observing the 3745 work and watching for errors on the backbone, we carefully studied the wires hanging to and from the breakout box with the twisted-pair cable, to a DB-9 to a DB-25 adapter, to another DB-25 to DB-9 adapter and finally to the big ugly connector on the 3745.

Bill: What we found was incredible. It was, in fact, the same as a DB-9 straight through "gender bender." So we found a nice looking gender bender, took a standard universal Token-Ring workstation cable with a DB-9 male connector and another Token-Ring media filter cable with a DB-9 male connector on one end and twisted-pair RJ-45 jack on the other, used the gender bender in the middle and that was it. Case closed.

Scott: And to think that all of this occurred in the same time it takes to get a new set of glasses--about an hour.

Bill and Scott are principals of Pine Mountain Group, and spend their time troubleshooting large networks, training end users in protocol analysis, and developing tools to allow users to make better use of their protocol analyzers. They can be reached at otw@pmg.com. Pine Mountain Group's WorldWide Web URL is http://www.pmg.com. Portions of actual trace files are available in the Network Computing On-the-Wire CompuServe forum (GO OTW) or via Pine Mountain Group's Home Page on the Web (http://www.pmg.com).