Error Terror: When a NAUN Is Not a Person, Place, or Thing

Token-Ring’s pecking order is wonderful when it works. It’s also pretty good when it doesn’t, because Token-Ring provides a lot of rules for error handling. In the way that a parliamentarian can deal with certain rule infractions without adjourning the meeting, the active monitor of the ring also can deal with certain situations. However, just like any democratic society, each citizen is also left to do his or her part.

For a packet to make it all the way around the ring, each station must transmit the packet to its neighboring station; in the process, each station gleans the location of its neighbors. That is, each station knows the address of its nearest address upstream neighbor (its NAUN, pronounced noun). Is this important? You bet!

First of all, what’s upstream? Well, because a Token-Ring passes packets around the ring in sequence, upstream refers to the direction in which packets are not flowing.

Let’s talk briefly about what constitutes downstream. Toss out theory, for the moment, and consider this from a purely pragmatic standpoint. You plug a bunch of workstations into a Token-Ring hub, plug in a server, and you’re ready to rock and roll, right? Downstream, in this case, is the direction from first port to the last port.

Plugging in another hub means that you have some means in which to extend the ring. Each Token-Ring hub (MAU) has a ring in and a ring out, which are the means for extending the ring. It’s simple: Packets flow downstream through the out and then flow into the next hub through the in, which, by definition, is upstream of its ports. This may sound crazy, but when you look at Figure 10.2, it’ll make more sense.

Figure 10.2  Downstream is always toward the out and upstream is always toward the in of a Token-Ring MAU. The direction of upstream and downstream changes as you move on the ring.

Back to NAUNs. The reason why it’s so cool that a station knows its NAUN is because when errors are detected by a particular station, it reports them two seconds later to the active monitor—the Chairman of the Ring. If you’re running a network analyzer, you’ll see the error report, plus the address of the NAUN. If you see the NAUN reported in the error log, you have a good idea where the error originated.

Think about this for a moment. In a game of telephone, if the guy to my left is responsible for giving me the correct message, and I’m responsible for giving the guy to my right the correct message, when I find out that the message I have is not the correct one, I naturally suspect the guy to my left. If these messages are packets and I’m a Token-Ring card, when I see an error, I naturally suspect the Token-Ring card upstream of me.

Error Types

The types of errors discussed thus far are called isolating soft errors. They’re isolating because they’re typically caused by a lone station rather than a generic ring problem, plus they’re reasonably easy to track. They’re soft because getting a few of them is not terribly bad for the ring. Unless you’re going to be a Token-Ring geek, it’s not worth dealing with the specifics of these errors; however, it’s good to know which Token-Ring errors are isolating errors. If you look at an analyzer and it tells you that the NAUN for an error is a certain MAC address, all you need to do is find that MAC address and turn the machine off. No divide-and-conquer techniques required.

Here are the isolating errors:

•  Abort delimiter

•  A/C error

•  Burst error

•  Internal error

•  Line error

All these errors pretty much mean the machine is ill and needs help. Because you’re not interested in being a Token-Ring physician, the best thing to do is to remove the NAUN from the network and see if the problems clear up. After all, you probably haven’t put a network analyzer on a segment unless you’re experiencing problems—in other words, you probably have to take action after sizing up the situation. Be aware, however, that if you put an analyzer on what is ostensibly a healthy Token-Ring, you’ll see a limited number of errors, so don’t panic.

Any station that comes into the conversation or leaves the conversation breaks the ring momentarily. This causes a burst error. A neighboring station notices this and reports it to the active monitor. This is as normal to Token-Ring as collisions are to Ethernet. Having a couple burst errors on a healthy Token-Ring is not a big deal; it’s just an indication that someone has turned his or her PC on or off. If you have hundreds of these in a short period, then you have a problem. Don’t worry about a couple, though.

Receiver congestion errors are also okay in small amounts—they simply indicate that the workstation is having a hard time keeping up. You’ll want to investigate large numbers of these, because they can slow down your entire network. In general, though, a few of these just indicate that some workstation is having trouble keeping pace with the ’90s.

Token Analyzers

Finding a NAUN is really easy if you have the right Token-Ring analyzer program. I’ll go into this in further detail in Hour 20, “Tell Me About Your Network: Network Analyzers & Bits & Bytes,” 135 but for the moment, consider that the right analyzer can give you a NAUN list showing all the MAC addresses on the ring, in the correct order! This is much better than Ethernet because you immediately know which port a given MAC address lives on. As a matter of fact, certain Token-Ring vendors will give you a program that collects this information for you—for free. For simplicity’s sake, let’s say you have two hubs on a given Token-Ring segment (see Figure 10.3).

Figure 10.3  A NAUN list depends on which stations are in the ring at the moment.

Your PC with the NAUN-listing program (which, fortunately, deals with the workstation name as well as the MAC address) is plugged into hub 2, port number 3. Your NAUN list is shown in Table 10.1.