Attaching a Protocol analyzer to the FDDI Ring

Let’s see what kind of challenge you’re going to have when you study an FDDI network using your protocol analyzer. The purpose here is to simply lay the groundwork for our discussion of the technology. One end-product of your understanding will be your expert analysis of protocol analyzer traces. This means you’re going to need to know how the pieces work and how they fit together.

In this first trace file you see the conclusion of a ring failure. The SynOptics 000163 station was sending Beacon frames, notifying the world that a failure had occurred. In Frame #4 evidently the failure resolved itself and now the ring is going to need a new token. The Claim frames are sent to decide who is going to make the new token. As the SynOptics station prepares to do normal work it sends some VOID frames, and so does the Cabletron (Ctron) station. Finally the Cabletron station makes an SMT NIF (Network Information Frame) request from a DAS (Dual Attachment Station). In Frame #12 the request is answered.

SUMMARY Destination Source Summary 1 000000000000 SynOpt000163 MAC Beacon frame 2 000000000000 SynOpt000163 MAC Beacon frame 3 000000000000 SynOpt000163 MAC Beacon frame 4 SynOpt000163 SynOpt000163 MAC Claim frame 5 SynOpt000163 SynOpt000163 MAC Claim frame 6 SynOpt000163 SynOpt000163 VOID frame 7 SynOpt000163 SynOpt000163 VOID frame 8 SynOpt000163 SynOpt000163 VOID frame 9 Ctron 0A0007 Ctron 0A0007 VOID frame 10 Ctron 0A000E Ctron 0A000E VOID frame 11 Broadcast Ctron 0A0007 SMT NIF Request from DAS 12 Ctron 0A0007 SynOpt000163 SMT NIF Response from DAS

A study of the detail inside the SMT NIF Request and the associated reply will serve to expand your awareness of the importance of understanding the details of the technology.

In the next trace file printout you see the detail in Frame #11, the SMT NIF Request. You see, in the DLC header, the Frame Status (FS) indicators: the Error Detected (‘Error’) bit, the Address recognized indicator and the Frame copied indicators. A destination has already recognized this address (Addr recognized: 1) and it copied the frame from the ring into its internal buffer (Frame copied: 1). No error was detected in the transmission of this frame (Error: 0).

The Frame Control byte (FC) indicates that this is an SMT Next Station Addressing Frame. The sender is trying to find out information about the address of the next station in the ring; his downstream neighbor. You see, everyone knows about their upstream neighbor, that’s the station sending directly to you. You have to ask specifically to find out about your downstream neighbor; and that’s what’s going on here.

SUMMARY Destination Source Summary 11 Broadcast Ctron 0A0007 DLC FC = 4F (SMT Frame) SMT NIF Request from DAS DLC: ----- DLC Header ----- DLC: DLC: Frame 11 arrived at 12:20:03.15594 ; frame size is 73 DLC: FS indicators - Error: 0, Addr recognized: 1, Frame copied: 1 DLC: FC: SMT Next Station Addressing Frame DLC: Destination = BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source = Station Ctron 0A0007 DLC: SMT: ----- FDDI Station Management ----- SMT: SMT: Frame class = 1 (Neighbor info) Frame type = 2 (Request) SMT: Version ID = 1, transaction ID = 55120000 SMT: This Station ID = 0000 Ctron 0A0007 , length = 40 SMT: Upstream neighbor address = Ctron 0A000E SMT: Station descriptor: SMT: Node class = Station SMT: MAC count = 1 SMT: Non-master count = 2 SMT: Master count = 0 SMT: Station state descriptor SMT: Pad = 00 00 SMT: Topology = 10 SMT: ...1 .... = Rooted station SMT: Duplicate Address = 00 SMT: .... .... = (none) SMT: Frame status capabilities for MAC 1 SMT: .... .... .... ...1 = FSC-Type 0 (repeats A/C indicators on copy with intent to forward)

You see, in the above detail decode, that the Station descriptor fields include the class ("Station"), and some counters indicating how many MACs, Masters, and Non-Masters are currently active in this device. The station is declared to be a rooted station (..remember that term? We defined it earlier!)

The next trace file printout shows the response to the previous request. You can see that the "transaction ID" field in the SMT header has a number (55120000) that correlates the response with the preceding request (you’ll see the same transaction ID number in the request frame). A request is given a transaction ID by the sending station and the reply comes back with the same transaction ID. In this case, the protocol analyzer must have been ‘beyond’ the Ctron 0A0007 station in the ordering on the ring. Why? Because, as you see, "Addr recognized: 0" and "Frame copied: 0" indicating that the destination station has not yet seen its address in the destination address field of this frame and it has not copied it from the ring. Consequently, this frame circulated past the protocol analyzer before it circulated past the destination station.

- - - - - - - - - - - - - - Frame 12 - - - - - - - - - - - - - SUMMARY Destination Source Summary 12 Ctron 0A0007 SynOpt000163 DLC FC = 41 (SMT Frame) SMT NIF Response from DAS DLC: ----- DLC Header ----- DLC: DLC: Frame 12 arrived at 12:20:03.15673 ; frame size is 73 DLC: FS indicators - Error: 0, Addr recognized: 0, Frame copied: 0 DLC: FC: SMT Info Frame DLC: Destination = Station Ctron 0A0007 DLC: Source = Station SynOpt000163 DLC: SMT: ----- FDDI Station Management ----- SMT: SMT: Frame class = 1 (Neighbor info) Frame type = 3 (Response) SMT: Version ID = 1, transaction ID = 55120000 SMT: This Station ID = 0000 SynOpt000163 , length = 40 SMT: Upstream neighbor address = Ctron 0A0007 SMT: Station descriptor: SMT: Node class = Station SMT: MAC count = 1 SMT: Non-master count = 2 SMT: Master count = 0 SMT: Station state descriptor SMT: Pad = 00 00 SMT: Topology = 10 SMT: ...1 .... = Rooted station SMT: Duplicate Address = 00 SMT: .... .... = (none) SMT: Frame status capabilities for MAC 1 SMT: .... .... .... ...1 = FSC-Type 0 (repeats A/C indicators on copy with intent to forward)

Applying the Analysis of the AR and FC Indicators

This is how the address recognized and frame copied indicators are applied to network analysis. Consider the implication of seeing a frame that came from a file server and was addressed to a client and the analyzer was downstream from the client. The ring would look like the diagram below.

Here you see that there must be something wrong with the client machine. If the address recognized and frame copied indicators aren’t set by the time the frame arrives at the analyzer - why weren’t they? The server sent the frame, the frame circulated past the client machine; but the client machine didn’t see the frame! (Perhaps the client machine is broken!) This is how you’re going to apply protocol analysis to troubleshooting on a FDDI ring.

When you understand the expected behaviors and the capabilities of the communicating processes in the FDDI environment you'll know when something isn't working. This is why we're studying the myriad "layers" and "processes" that make up the FDDI standards.