| Previous | Table of Contents | Next |
Whoa! You have eight possible ports on your two four-port hubs, but only four stations are listed. A quick glance at the hubs reveals that, in fact, only four lights are lit out of a possible eight. First of all, NAUN lists reveal only who is on the network while they are on the network. A NAUN lister can’t list something that isn’t there. Still, you work quickly, hoping that you’ll do your figuring before anybody kicks in or out of the ring. By looking at the hubs and correlating the lights that are on to the NAUN list, you deduce that because your workstation with the NAUN lister is #1 on the list and #3 on the hub, then MY-BOSS is #4 on hub #2, HER-BOSS is #2 on hub #1, and OUR-SERVER is #3 on hub #1.
Most of the time, I just do this to quickly figure out the identity of the machine I need to take out of the network. You really, really don’t want to rely on this as a method for after-the-fact documentation, mostly because people are always clicking in and out of the network at exactly the wrong time. This will start to drive you crazy before too long.
You’ll get large numbers of “frame copied” errors on a switched Token-Ring network if you’re using an analyzer that wasn’t designed with switching in mind. The analyzer is telling you that somebody claims they got the frame, but it wasn’t the intended recipient.In fact, because the switch has joined two separate Token-Rings, the receiving station could not have received it without the help of the switch. The switch had to grab it. The switch grabs the frame on the source network and throws it onto a different destination network, where the destination workstation can get it. The destination network is a separate, physical Token-Ring segment and, as such, has a separate active monitor and so on; it’s a separate conference table in a separate room. Therefore, it’s okay for the switch to grab the frame meant for the destination—otherwise, it would never get to the destination. In other words, the analyzer is fretting about nothing. Here’s the bottom line: Don’t worry about “frame copied” errors in this scenario.
Like Ethernet, Token-Ring has overly complex rules about how long the wires can be at what speed using what type of wire, and so on. The most common cable used to be IBM Type 1. Type 1 shielded twisted pair (STP) cable is huge and very resistant to EMI (electromagnetic interference), but hard to work with.
Token-Ring comes in two speeds: 4Mb and 16Mb. If you’re using 4Mb, it’s time to change. I can’t even think of a place where I could get a Token-Ring card that doesn’t also do 16Mb, and I buy used equipment shamelessly! As an incentive for you to treat yourself to 16Mb (and to keep the discussion simple) I’m only going to talk about 16Mb rules.
Token-Ring does not have any hard-and-fast cable length limit on any given run. Instead, there’s a total ring length limitation. If you think about it, this makes sense, because all the cables work together to make one ring, right?
When using STP, the maximum distance around a ring can be 180 meters, or 590 feet. When using CAT-V UTP, your ring distance can be 100 meters, or 330 feet. If you’re using CAT-III UTP, you might as well set it all up in your garage—the longest roundtrip can only be 70 meters, or 230 feet. I’m throwing in these numbers for reference only; you’re not going to need them unless you start designing Token-Rings.
To actually calculate whether your ring is within cable budget, you must use a complicated formula (which gives me a headache when I look at it) that involves the longest individual cable run, the internal wire distance of each MAU on the network, the inter-MAU cable runs, and the price of tea in China, ad nauseam. People who design Token-Ring networks must invoke this mystical little formula. Fortunately for you, though, this formula has little or nothing to do with troubleshooting Token-Ring.
Again, as is the case with Ethernet, if your network was working last week as well as the week before, there’s dust all over the cables, and nobody has played with the cable plant, the last thing you would suspect is that the cables have gotten longer all by themselves. If, on the other hand, someone has added a couple of MAUs or a rather long cable to your Token-Ring and it’s starting to act flaky, you should disconnect this stuff and see what happens. You don’t need to engage in higher mathematics or whip out a tape measure to do this. This is mere change management, and it’s a whole lot easier than measuring cables that are already in the wall and in use on a production network.
A Token-Ring can have several different packet sizes. They can be anything from 1KB to 16KB, with the most popular packet size I’ve seen being 4KB. The packet size of a given Token-Ring is equal to the smallest packet size specified on the network—that is, you can easily decrease the packet size on a Token-Ring simply by adding a network card that’s configured to use a smaller packet size.
If you have a wide-area, routed network or a mixed Token-Ring and Ethernet environment, beware of large packet sizes. Some (actually, more than you would think) TCP/IP applications don’t handle fragmentation properly. Fragmentation is what happens when you need to put 10 pounds of stuff in 5-pound bags—the packets get split into smaller, more manageable chunks. When a mixed environment is in use, packets will almost definitely get chopped up in order to fit through the smaller interfaces on your router. You can handle this by instructing your applications to use smaller packet sizes, or you can simply dial down the packet size on your Token-Ring. Alternatively, you can ask your vendor to fix things; it depends on how optimistic you feel that day.
| Previous | Table of Contents | Next |