007 0813 060

User Manual: 007-0813-060

Open the PDF directly: View PDF .
Page Count: 264 [warning: Documents this large are best viewed by clicking the View PDF Link!]

FDDIXPress™ Administrator’s Guide

Document Number 007-0813-060

FDDIXPress™ Administrator’s Guide

Document Number 007-0813-060

CONTRIBUTORS

Written by Carlin Otto and Susan Thomas

Illustrated by Carlin Otto

Production by Kirsten Johnson

Engineering contributions by Paul Reilly, Vernon Schryver, Premkumar Thoppae,

and Jong Kim

Special acknowledgement to Wendy Ferguson, whose FDDI documentation

provided inspiration and a starting point.

St Peter’s Basilica image courtesy of ENEL SpA and InfoByte SpA. Disk Thrower

image courtesy of Xavier Berenguer, Animatica

The contents of this document may not be copied or duplicated in any form, in whole

or in part, without the prior written permission of Silicon Graphics, Inc.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure of the technical data contained in this document by

the Government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the

Rights in Technical Data and Computer Software clause at DFARS 52.227-7013

and/or in similar or successor clauses in the FAR, or in the DOD or NASA FAR

Supplement. Unpublished rights reserved under the Copyright Laws of the United

States. Contractor/manufacturer is Silicon Graphics, Inc., 2011 N. Shoreline Blvd.,

Mountain View, CA 94043-1389.

Silicon Graphics, the Silicon Graphics logo, and IRIX are registered trademarks and

Onyx, CHALLENGE, Crimson, FDDIXPress, FDDIVisualyzer, Indigo, Indy, and

Indigo2 are trademarks of Silicon Graphics, Inc. ST is a registered trademark of AT&T.

UNIX is a registered trademark in the United States and other countries, licensed

exclusively through X/Open Company, Ltd.

iii

Table of Contents

List of Figures vii

List of Tables ix

Introduction xi

Audience xii

Typographical Conventions xii

Additional Reading xiii

IRIX Operating System Manuals xiii

Networking Manuals xiii

FDDI Station and Ring Management Manuals xiii

ANSI and ISO Documents for FDDI xiv

Product Support xv

1. Introducing FDDI 1

FDDI Features 1

FDDI Standard 2

Physical Layer Medium Dependent Protocol 5

Physical Layer Protocol 5

Media Access Control Protocol 5

Station Management Protocol 6

FDDI Ring 6

FDDI Devices 8

Dual Attach Station 9

Single Attach Station 10

Concentrators 10

Optical Bypass Switch 11

Table of Contents

How FDDI Works 12

Operational Ring 12

Fixing a Broken Ring 12

Optical Bypass Switch 14

Transmitting and Receiving on the Ring 15

Multiprotocol Networking With FDDI 15

2. Conﬁguring FDDIXPress Software 17

FDDIXPress Package 17

Installing FDDIXPress 17

Number Assignment to Interfaces 18

Overview 18

Number Assignment for CHALLENGE M 19

Number Assignment for CHALLENGE and Onyx 19

Number Assignment for Octane, Origin200, Origin 2000, and O2 21

Default Configurations 22

Quick and Easy Configuration Instructions 24

FDDI as the Primary Interface and Ethernet as Secondary 24

FDDI as the Secondary Interface and Ethernet as Primary 25

FDDI as the Only Network Interface 27

Complete and Complex Configuration Information 28

Prepare for Configuration 29

Network Connection Names and IP Addresses 31

Configure the Station’s Network Interfaces 33

Build Configuration Changes Into the System 40

Install the FDDI Board 41

Configure the Environment for User Friendliness and Safety

(Optional) 42

Verifying the FDDI Connection 47

3. Managing Your FDDI Station and Ring 51

Station Management Commands 51

Verifying the Connection to a Station 53

Listing the Stations on the Ring 54

Table of Contents

Displaying SMT Information for a Remote Station 55

Display the SMT Version 55

Display a Station’s Configuration Information 56

Recognizing Faults on the FDDI Ring 57

Monitoring a Station’s FDDI Status 60

Display Kernel and SMT Daemon Statistics 63

Display SMT Information (MIB) 65

Displaying and Configuring Network Interface Information 67

Display the Configuration 67

Change the Configuration 69

Verifying a Station’s PCM Functionality 71

Removing a Station From the FDDI Ring 72

Temporarily Disable Any Station’s FDDI Interface 73

Remove a Device Attached to a Concentrator 73

Removing a DAS That Has an Optical Bypass Switch 74

Remove a DAS Without an Optical Bypass Switch 76

Removing FDDIXPress 78

4. Troubleshooting 79

General Advice 79

Checking Physical Connections 80

Recognition of Board by Software 80

Check Cables and Connectors 83

Cable Lengths 86

Status Indicators and Symptoms 87

Link-Level Errors 87

Token Count Not Incrementing 87

Too Many Claims or Beacons 88

Ring Is Wrapped 88

High Rate of Packet Loss 90

Cannot Communicate With Other Stations 90

Current Neighbor’s Address Is Zero 93

Ring Is Not Wrapped and Token Count Increments But smtping

Does Not Work 93

System Does Not Load Miniroot or Boot From the Network 94

Table of Contents

A. Error Messages 95

How Messages Are Listed 95

SMT Error Messages 97

xpi Driver Error Messages 149

ipg Driver Error Messages 157

rns Driver Error Messages 161

B. smtstat Reports 167

MAC Status Report 169

Port Status Report 174

Ring Management Status Report 181

Configuration Information Report 185

Neighbor Information Report 189

SMT Information Report 192

C. Conﬁguring the SMT Daemon and the

FDDIXPress Driver 197

Configuring the SMT Daemon 197

Station Section 199

Board Sections 205

MAC Parameters 207

PHY Parameters 212

Configuring the FDDIXPress Driver 218

D. Man Pages 219

Index 241

vii

List of Figures

Figure 1-1 FDDI as Related to the OSI Model 3

Figure 1-2 FDDI Components of FDDIXPress and an FDDI Board 4

Figure 1-3 Simple Token Ring 7

Figure 1-4 A Basic FDDI Ring 8

Figure 1-5 Connection of DAS Ports to Primary and Secondary Rings 9

Figure 1-6 FDDI Ring With Concentrators 11

Figure 1-7 Wrapping the Ring 13

Figure 1-8 Connection of DAS Ports at Points Where Ring Is Wrapped 13

Figure 1-9 A Fragmented Ring 14

Figure 1-10 FDDI With an Ethernet Network 16

Figure 2-1 Displaying Available Interfaces With netstat -in 34

Figure 2-2 Screen Display for /usr/etc/netstat -ia Command 44

Figure 2-3 Displaying Broadcast Address 45

Figure 2-4 An Example of the hinv Display 48

Figure 3-1 smtping Display 53

Figure 3-2 smtring Display 54

Figure 3-3 Ring Created From smtring Display 55

Figure 3-4 smtinfo -c Display 56

Figure 3-5 Fault Isolation and Ring Wrap 58

Figure 3-6 Fragmented Ring 59

Figure 3-7 smtstat Display 60

Figure 3-8 smtstat -s Display: General Report Format 66

Figure 3-9 smtconfig Display 68

Figure 4-1 Cable-to-Cable Connections 84

Figure 4-2 Correct Cable Connections 84

Figure 4-3 Direction Indicators With Media Interface Connector 85

Figure A-1 Error Message Format in the /var/adm/SYSLOG File 96

viii

List of Figures

Figure A-2 Information Not Included in Alphabetized List of xpi Messages 150

Figure A-3 Information Not Included in Alphabetized List of rns Messages 161

Figure B-1 MAC Status Report 169

Figure B-2 Port Status Report (for a Dual Ring DAS) 174

Figure B-3 Ring Management Status Report 181

Figure B-4 Configuration Information Report 185

Figure B-5 Neighbor Information Report 189

Figure B-6 SMT Information Report 192

Figure C-1 Outline of smtd.conf File 198

Figure C-2 smtd.conf: Station Section 199

Figure C-3 Station ID 202

Figure C-4 smtd.conf: Board Sections 206

Figure C-5 smtd.conf: MAC Parameters 208

Figure C-6 smtd.conf: PHY Parameters 213

Figure Gl-1 Canonical Order 222

Figure Gl-2 FDDI Order 226

Figure Gl-3 FDDI Frame 227

Figure Gl-4 FDDI Token 238

Figure Gl-5 Tree Topology 239

Figure Gl-6 Wrap 240

List of Tables

Table 1-1 FDDI versus Ethernet and Token Ring 1

Table 2-1 Number Assignment for FDDIXPress Network Interfaces 18

Table 2-2 Number Assignments for Network Interfaces on CHALLENGE

and Onyx Platforms 20

Table 2-3 Default Network Interface Configuration 22

Table 2-4 Default Network Interface Parameters 23

Table 3-1 FDDIXPress (SMT) Commands 52

Table 3-2 Information Displayed by smtinfo -c 57

Table 3-3 smtstat Report Fields 61

Table 3-4 smtstat -v Kernel Statistics 63

Table A-1 Reason Codes Used in Error Messages 120

Table B-1 smtstat Report Field 168

Table B-2 MAC Status, Left Column 170

Table B-3 MAC Status, Right Column 172

Table B-4 Port Status, Left Column 175

Table B-5 Port Status, Right Column 178

Table B-6 Port Status, Bottom Section 179

Table B-7 Ring Management Status, Left Column 182

Table B-8 Ring Management Status, Right Column 183

Table B-9 Ring Management Status, Bottom Section 184

Table B-10 Configuration Information, Top Section 186

Table B-11 Configuration Information, Bottom Left Column 187

Table B-12 Configuration Information, Bottom Right Column 188

Table B-13 Neighbor Information, Top Section 190

Table B-14 Neighbor Information, Bottom Section 191

Table B-15 SMT Information Status, Left Column 193

Table B-16 SMT Information Status, Right Column 195

List of Tables

Table C-1 smtd.conf: Station Parameter Defaults 200

Table C-2 smtd.conf: MAC Parameter Defaults 209

Table C-3 smtd.conf: PHY Parameter Defaults 214

Table C-4 CMT Capability Flags 218

Table D-1 FDDIXPress Man Pages 219

Table Gl-1 Maximum Networks and Hosts Possible for IP Addresses 230

Table Gl-2 Internet Address Ranges 230

Introduction

FDDIXPress™ connects Silicon Graphics® computers to FDDI networks.

This FDDIXPress Administrator’s Guide is your guide to conﬁguring, testing, and

monitoring your FDDI network connection. This guide has been written so you can

perform all the basic FDDI station and ring administration tasks, whether you are a

newcomer to IRIX™ and networking, or a seasoned IRIX network administrator.

This guide describes the administrative user interface to a Silicon Graphics’ computer’s

FDDI connection; the guide can be used with any Silicon Graphics’ FDDI board and

driver.

This guide tells you how to

•conﬁgure your FDDI station (Chapter 2)

•verify that the FDDI connection is working (Chapter 2)

•monitor and maintain your station’s FDDI connection (Chapter 3)

•monitor and maintain your FDDI ring (Chapter 3)

•resolve problems (Chapter 4 and Appendix A)

In addition, this guide contains a chapter describing how FDDI works and a glossary

deﬁning FDDI terms.

xii

Introduction

Audience

This guide has been written for the person who keeps the FDDI network connection on

a station working. This person might be an experienced network administrator or a

novice. The format in this guide is task-oriented and assumes no prior knowledge of

FDDI or network administration. This guide provides all the information you need to

maintain a single FDDIXPress station’s connection to the FDDI ring.

Note: This guide is not an in-depth network administration guide; it does not provide

information for planning, managing, and maintaining an FDDI network. The product

FDDIVisualyzer™ is designed for this purpose.

Typographical Conventions

This guide uses the following typographical conventions:

Fixed-width type

Indicates system output, such as responses to commands that you see on

the screen. Code samples, onscreen text, error messages, and ﬁle

contents also appear in this font.

Bold fixed-width type

Indicates user input, including keyboard keys (printing and

nonprinting), and literals supplied by the user in examples.

italics Designates book titles, command and utility names, ﬁlenames, and

ﬁlename sufﬁxes. Indicates generic, place-holding variable names and

variables to be supplied by the user.

[ ] Encloses optional command arguments.

... Denotes omitted material or indicates that the preceding optional items

may appear more than once in succession.

Introduction

xiii

Additional Reading

This section lists reference material for the IRIX operating system, networking, and

FDDI.

IRIX Operating System Manuals

The following documents are available from Silicon Graphics, Inc.:

•IRIX Admin guide set

a set of guides intended for administrators of the IRIX operating system and

accessible through the online viewer IRIS Insight

•IRIX Admin: Selected Reference Pages

an item in the optional IRIX Admin guide set

•IRIS Software Installation and Licensing

an item in the optional IRIX Admin guide set

Networking Manuals

The following documents are available from Silicon Graphics, Inc.:

•IRIX Admin: Networking and Mail

an item in the optional IRIX Admin guide set

•ONC3/NFS Administration Guide

•NIS Administration Guide

•NetVisualyzer User’s Guide

FDDI Station and Ring Management Manuals

The following document is available from Silicon Graphics, Inc.:

•FDDIVisualyzer User’s Guide

xiv

Introduction

ANSI and ISO Documents for FDDI

The following documents are available from the American National Standards Institute:

•PHY:

ANSI FDDI Physical Layer (PHY)

X3.148:1988; ISO 9314-1: 1989;

Information Processing Systems—Fiber Distributed Data Interface (FDDI)—Part 1:

Token Ring Physical Layer Protocol (PHY)

•MAC:

ANSI FDDI Media Access Control (MAC)

X3.139:1987; ISO 9314-2: 1989;

Information Processing Systems—Fiber Distributed Data Interface (FDDI)—Part 2:

Token Ring Media Access Control (MAC)

•PMD:

ANSI FDDI Physical Medium Dependent (PMD)

X3.166:1990; ISO 9314-3: 1990;

Information Processing Systems—Fiber Distributed Data Interface (FDDI)—Part 3:

Token Ring Physical Layer Medium Dependent (PMD)

•SMT:

ANSI FDDI Station Management (SMT)

X3T9.5/revision 6.2 dated 18 May 1990. (The SMT version listed here is a draft that, at

the time this document went to print, had not been approved as a standard. When

you order the ANSI SMT document, a newer revision may be available. The older

version is not available once it has been replaced by a new one.)

To order ANSI documents, contact

American National Standards Institute

11 West 42nd Street

New York, NY 10036

Telephone: (212) 642-4900

Fax: (212) 302-1286

Telex: 42 42 96 ANSI UI

Introduction

Product Support

Silicon Graphics, Inc., provides a comprehensive product support and maintenance

program for its products. If you are in North America and would like support for your

Silicon Graphics supported products, contact the Technical Assistance Center at

1-800-800-4SGI. If you are outside North America, contact the Silicon Graphics

subsidiary or authorized distributor in your country.

Chapter 1

1. Introducing FDDI

This chapter introduces the basic concepts of the FDDI protocol. After reading this

chapter, you will know how FDDI works and be familiar with the most common FDDI

terms.

FDDI Features

Fiber Distributed Data Interface (FDDI) is a local area network (LAN) communications

protocol that is based on a basic token ring architecture. It is fast, reliable, and

manageable. It is emerging as the standard alternative to slower protocols like Ethernet

and 802.5 token ring. Table 1-1 compares FDDI with Ethernet (the built-in

communications medium offered on Silicon Graphics workstations and servers) and

token ring 802.5.

Table 1-1 FDDI versus Ethernet and Token Ring

Feature FDDI Ethernet Token Ring

802.5

Maximum physical

transmission speed

100 Mbps 10 Mbps 4 or 16 Mbps

Maximum packet size 4500 bytes 1518 bytes 4500 bytes for 4

18,000 for 16

Typical maximum length of

LAN cable

100 kilometers < 2.5 kilometers < 42 kilometers

(200 km wrapped)

Typical max. length between

nodes

2 kilometers 500 meters 300 meters

Maximum number of

nodes per LAN

500 1024 255

Chapter 1: Introducing FDDI

FDDI Standard

FDDI is an international standard. It has been approved and accepted by the two major

standards committees: American National Standards Institute (ANSI) and International

Standards Organization (ISO).

The FDDI components of FDDIXPress and the accompanying FDDI board conform to the

ANSI and ISO FDDI standards. The speciﬁc FDDI components (and the ANSI and ISO

standards on which they are based) are listed below:

•physical layer medium dependent sublayer (PMD)

ANSI X3.166-1990 and ISO 9314-3:1990

•physical layer protocol sublayer (PHY)

ANSI X3.148-1988 and ISO 9314-1:1989

•media access control sublayer (MAC)

ANSI X3.139-1987 and ISO 9314-2:1989

•station management module (SMT)

ANSI X3T9.5/84-49, Revision 6.2, May 18, 1990

Figure 1-1 shows how the FDDI components correspond to ISO’s seven-layer Open

Systems Interconnection (OSI) reference model.

FDDI Standard

Figure 1-1 FDDI as Related to the OSI Model

The OSI model deﬁnes a hierarchical structure for organizing the different functions

(services) of telecommunications systems. In theory, each layer is completely

independent, so changes to one layer have no effect on other layers. Standard interfaces

are deﬁned for communication between the adjacent layers. As Figure 1-1 shows, the

FDDI standard occupies the two lowest layers—the entire physical layer and a portion

of the data link layer—just as Ethernet and token ring do.

The physical layer deﬁnes the electrical, mechanical, and logical characteristics for

transmitting bits across the physical medium. Examples of physical media include

twisted pair, coaxial, and ﬁber optic cable. Dual ring FDDI speciﬁes ﬁber optic cable as

the physical medium.

The data link layer speciﬁes the way a node (for example, the FDDIXPress board)

accesses the underlying physical medium and how it formats data for transmission.

FDDI speciﬁes formatting data into frames, using a special set of symbols and following

Layer 7:

Layer 6:

Layer 5:

Layer 4:

Layer 3:

Layer 2:

Layer 1:

rcp, rlogin, ftp

network library routines

sockets

TCP, UDP

Physical

Data Link

Network

Transport

Session

Presentation

Application

logical link control (LLC)

physical layer (PHY)*

physical medium dependent (PMD)*

media access control (MAC)* station

management

(SMT)*

END-to-END SERVICES

responsible for data transfer

APPLICATION SERVICES

responsible for information

Examples from the UNIX Environment

transfer

Legend: Items marked with an asterisk are FDDI components.

Chapter 1: Introducing FDDI

a special set of rules. The MAC sublayer within the data link layer speciﬁes the physical

address (MAC address) used for uniquely identifying FDDI nodes.

Functionally, FDDI is similar to the 802.5 token ring and Ethernet standards, as

summarized below:

•Like Ethernet and 802.5 token ring, FDDI uses the interface to the logical link

control (LLC) sublayer of the data link layer, so switching from Ethernet to FDDI

does not affect the higher layers. Layer 3 and 4 software (for example,

TCP-UDP/IP) works over FDDI just as it does over Ethernet or token ring.

•Like Ethernet and 802.5 token ring, FDDI uses frames to deliver data between

stations.

•Like 802.5 token ring (but unlike Ethernet), FDDI prevents collisions on its physical

medium (cable) by passing a token; at any speciﬁc instant, only the station with the

token may transmit onto the ring.

The subsections that follow describe each of the FDDI components. Figure 1-2 illustrates

one possible conﬁguration of these FDDI components.

Figure 1-2 FDDI Components of FDDIXPress and an FDDI Board

Primary Ring

Secondary

Ring

FDDI

SMT

CPU

PHY

MAC

PMD

Board

PHY

PMD

code

Station’s address

Dual-attachment

see Figure 1-5 for

details of port and

ring attachments

FDDI Standard

Physical Layer Medium Dependent Protocol

The physical layer medium dependent protocol (PMD) deﬁnes the lowest FDDI protocol;

it occupies the lower sublayer of the physical layer. PMD speciﬁes the requirements for

the cable (for example, ﬁber optic), the transmitter and receiver, the media interface

connectors (MIC), and the optional optical bypass switch. PMD functionality is

contained within a chip on the FDDI board.

Physical Layer Protocol

The physical layer protocol (PHY) deﬁnes the upper sublayer of the physical layer. It

establishes the connection between the PMD and MAC. In addition, the PHY provides

encoding and decoding of data and control symbols. The PHY synchronizes incoming

and outgoing code-bit clocks. This functionality is contained inside a chip on the FDDI

board.

Media Access Control Protocol

The media access control protocol (MAC) schedules and performs data transfer on the

FDDI cable. The MAC is the FDDI component that contains the FDDI connection’s

identity, commonly referred to as a MAC address.

When a MAC begins to receive a block of information (a frame) from the FDDI cable, it

checks the destination address ﬁeld of the frame to see if the address is one of its own

addresses. If the address matches one of its own addresses, the MAC simultaneously

repeats the frame onto the physical medium and copies the frame into its local memory.

While repeating the frame, the MAC modiﬁes the frame’s status to indicate that the

frame has been seen and received. The modiﬁed frame continues along the ring until it

reaches the original transmitting station, which interprets the modiﬁed frame as an

acknowledgment. This functionality is handled by a chip on the FDDI board.

Chapter 1: Introducing FDDI

Station Management Protocol

The station management protocol (SMT) monitors and controls all FDDI activity on its

station. SMT manages processes in the various FDDI layers (PMD, PHY, and MAC) at the

station level and ensures the correct operation of the station on the ring. (See “FDDI

Ring” for a description of the FDDI ring.) SMT’s responsibilities include overseeing

station insertion and removal from the ring, initializing the station to conform with the

current ring status, and identifying, isolating, and recovering from faults on the ring.

An FDDIXPress station’s SMT functionality is distributed. Some of it is contained within

a software module that includes the SMT daemon (smtd) and a special database ﬁle called

the management information base (MIB); some functionality is located within chips on

the FDDI board.

The MIB resides in the local memory on each FDDI station. This database maintains

statistical and operational information used to manage the ring.

Control within an FDDI ring is distributed among the SMT entities of all the stations on

that ring; control is not handled by a master station. SMT entities communicate with each

other to manage the administration of addressing, allocation of network bandwidth, and

conﬁguration and control of the ring. Some of these SMT parameters are

site-conﬁgurable. For FDDIXPress, the SMT conﬁguration ﬁle is /etc/fddi/smtd.conf.

For more information about the SMT daemon, see the smtd(1M) man page.

FDDI Ring

An FDDI ring is a length of cable laid out in a closed loop. Current standards require that

the ring cable be ﬁber optic cable. An optical signal (light) passes through the cable

(around the ring) and returns to its point of origin. Whenever a station is connected to

the ring, it is physically inserted into the ring so that the optical signal passes through the

station (illustrated in Figure 1-3). Stations on the ring are referred to as upstream or

downstream in relation to each other. The downstream neighbor station is the ﬁrst

station to see a transmitting station’s transmission. In Figure 1-3, station A is station C’s

downstream neighbor and station B’s upstream neighbor.

FDDI Standard

Figure 1-3 Simple Token Ring

The FDDI dual ring (or trunk ring) has two separate loops (rings). One ring is called the

primary ring and the other is the secondary ring, as illustrated in Figure 1-4. Most sites

use the secondary ring as a backup ring. The light signal within each loop of a dual ring

travels in the opposite direction from the signal in the other ring; in FDDI jargon this is

referred to as counter-rotating. Because the signal travels in different directions,

upstream and downstream neighbors are opposite on each ring. In Figure 1-5, where

station 2 is station 1’s downstream neighbor on the primary ring, station 2 is the

upstream neighbor on the secondary ring.

Single Ring

Token

Station A

Station C

Station B

upstream from B

downstream from C

upstream from A

downstream from B

Chapter 1: Introducing FDDI

Figure 1-4 A Basic FDDI Ring

The cabling for FDDI is available in a number of forms. Multimode (62.5 micron) ﬁber

optic cable was the ﬁrst transmission medium (cable) deﬁned for FDDI. Recently, the use

of single-mode (50-micron) ﬁber optic cable was approved. Copper cable has also been

approved, for use only between concentrators and stations.

FDDI Devices

In addition to the FDDI components, the FDDI standard deﬁnes the types of devices that

can be connected to the ring. These devices include (but are not limited to) the following:

•stations

–DAS: dual attach station (usually attaches directly to FDDI dual ring)

–SAS: single attach station (attaches to the FDDI ring through a concentrator)

•concentrators

–DAC: dual attach concentrator (usually attaches directly to the FDDI dual ring)

–SAC: single attach concentrator (attaches to the FDDI ring through another

concentrator)

•optical bypass switch

DAS

Primary Ring

Secondary

Ring

DAS

FDDI Devices

Dual Attach Station

A dual attach station (DAS) has two ports (A and B). A DAS can be connected to the dual

ring or to a concentrator.

When connected to the dual ring, each port connects to both the primary ring and the

secondary ring (as shown in Figure 1-5). This dual connection is known in FDDI jargon

as “connecting to the dual ring.” The station’s SMT ensures that the station can continue

to transmit and receive data even when the primary ring experiences a break. (A break

in the ring occurs when the signal cannot make a complete trip around the ring; this can

be caused by a station failing or by a faulty cable.)

When connected to a concentrator, the two ports can each be connected to one of the

concentrator’s M ports. A DAS station can behave as a single attach station (SAS) if

conﬁgured to do so, in which case only one of its ports is connected to the concentrator

and the other port is not used.

Note: As illustrated in Figure 1-5, for DAS connections to the dual ring, port A must

always be connected to port B of the downstream station, while port B connects to port

A of the upstream station.

Figure 1-5 Connection of DAS Ports to Primary and Secondary Rings

Station 1

Station 2

Primary

Secondary

Ring

DAS

Ports

Chapter 1: Introducing FDDI

Single Attach Station

A single attach station (SAS) has a single slave (S) port that attaches to the ring through

a master (M) port on a concentrator. The concentrator routes the signal from the

functioning ring through every SAS connected to that concentrator.

Concentrators

A concentrator allows many single-attachment FDDI devices to obtain their connection

to the FDDI ring through one device—the concentrator. Concentrators have one or more

master ports (M), each of which accepts a connection from one single-attachment device.

The FDDI standard deﬁnes two types of concentrators: dual-attachment and

single-attachment. A dual attach concentrator (DAC) has two ports (A and B), each of

which connects to both the primary and secondary rings, just like the DAS. A single

attach concentrator (SAC) connects to an FDDI ring through another concentrator, in the

same manner as an SAS. Figure 1-6 illustrates the use of concentrators on an FDDI ring.

FDDI Devices

Figure 1-6 FDDI Ring With Concentrators

Optical Bypass Switch

An optical bypass switch (OBS) is an optional device that can be attached between a dual

ring and a DAS or DAC. The OBS allows a dual-attachment device to become

dysfunctional without wrapping the ring.

DAS

Primary Ring

Secondary

Ring

DAS

SAS

DAC

SAS

SAC

Chapter 1: Introducing FDDI

How FDDI Works

The FDDI local area network consists of two or more stations or nodes connected serially

by ﬁber optic cables to form a closed loop, the ring. Each FDDI local area network has

two rings: a primary ring and a secondary ring. Figure 1-6 and Figure 1-10 show

common FDDI ring conﬁgurations. The secondary ring is usually conﬁgured as a backup

ring.

Operational Ring

An optical signal (light), encoded to represent data, is beamed into the cable by a

transmitting station. The signal travels through the cable and is read by each station on

the ring, until it returns to the original sender. As long as the signal can make a complete

trip around the loop, the ring is operational. When a break or fault occurs in the ring, the

signal cannot complete the loop. Situations that break the ring include, among other

things, a missing or damaged cable, a loose connection, and a dysfunctional station.

Fixing a Broken Ring

The optical signal travels in opposite directions in each ring. This design makes closure

of a broken primary ring feasible. When the SMT module within a station notices that the

primary ring is broken, it connects the secondary ring to the primary one to complete the

loop. This action bypasses (cuts out) the faulty section, as illustrated in Figure 1-7. In

FDDI jargon, ﬁxing a broken primary ring in this manner is called “wrapping the ring.”

The original two rings are joined to form a single loop (ring). Notice that the ring must

wrap in two locations to complete the loop. In this condition, transmission proceeds

without interruption for all the stations on the functioning portion of the ring.

How FDDI Works

Figure 1-7 Wrapping the Ring

When a ring wraps, two stations change their internal optical signal paths. Instead of the

signal passing through both port A and port B (as illustrated in Figure 1-5), it is received

and transmitted through a single port (either A or B). Figure 1-8 illustrates the altered

optical signal paths. The two stations that make this change are located at the ends of the

functional portion of the primary ring.

Figure 1-8 Connection of DAS Ports at Points Where Ring Is Wrapped

break

Primary

Unused

Secondary

Ring

wrap

Station 1

Station X

Primary

Secondary

Ring

DAS

Ports

wrap wrap

One of these

may be

dysfunctional,

or there may be

a dysfunctional

station between

the two ports.

unused ports

Chapter 1: Introducing FDDI

If more than one fault occurs on the FDDI ring, the ring may become fragmented, as

shown in Figure 1-9. In this condition, communication continues among the stations

within each fragment, but communication is not possible with stations located on a

different fragment.

FDDI management tools such as smtstat and smtring (or the graphical product,

FDDIVisualyzer) can be used to identify problems with the ring.

Figure 1-9 A Fragmented Ring

Optical Bypass Switch

FDDI deﬁnes an optional device that allows a DAS to become dysfunctional without

wrapping the ring. This device is called an optical bypass switch (OBS). The optical

bypass switch is connected between a station’s two ports and the dual ring.

Without an optical bypass switch, when a DAS becomes dysfunctional, the signal going

around the ring cannot continue past the dysfunctional station; stations downstream

from this station do not receive any signal. The ring is broken, which causes an automatic

wrap.

When an optical bypass switch is present in this situation, it maintains an intact loop by

simply routing the signal through the switch, bypassing the dysfunctional station as if it

were not attached to the ring. The SMT modules of neighboring stations will notice that

they have acquired different neighbors, but they will continue to communicate without

the disruption caused by a wrapped ring.

break

fragment

wrap

How FDDI Works

Transmitting and Receiving on the Ring

A station on a ring gains access to transmit information onto that ring by capturing the

ring’s token. Only one token is allowed on each ring. Various controls are built into FDDI

to limit or specify the length of time the token can be held. Once a station captures the

token, it can transmit data onto the network. When the station ﬁnishes transmitting, or

its time expires, it places the token back onto the ring, thus allowing the next station the

opportunity to capture it. When a station does not have anything to transmit, it does not

capture the token.

Once a frame is transmitted onto the ring, it moves around the ring in the following

manner: Each station reads the frame and transmits it back onto the ring. If a station

makes a local copy of the frame, it indicates this action by altering various bits in the copy

that it retransmits onto the ring. As frames pass around the ring, the transmitting station

recognizes the return of its own data and determines if reception has been successful and

error free by checking the changed bits in the frame. Each station is responsible for

removing (stripping) all the data that it placed on the ring.

Multiprotocol Networking With FDDI

You can use FDDI as a standalone network, or you can incorporate it into an existing

internetwork. When incorporating FDDI with an existing network, it is standard practice

to use FDDI as the backbone and the slower networks (Ethernet or token ring) as

subnetworks. This involves using a router (for example, an FDDI-to-Ethernet router) that

is connected to both the non-FDDI network and the FDDI ring. The router allows

information (packets) to ﬂow between the two networks even though they use different

protocols. Figure 1-10 shows FDDI with an Ethernet network; the ring illustrated has ﬁve

dual-attachment nodes, one of which is a concentrator. A Silicon Graphics workstation

or server that has two network interfaces automatically and by default performs as a

router.

Chapter 1: Introducing FDDI

Figure 1-10 FDDI With an Ethernet Network

DAS

= not in use

= in use

DAC

Router/Gateway

Ethernet Network

SAS

DAS = dual−attachment station

SAS = single−attachment station

DAC = dual−attachment concentrator

Chapter 2

2. Conﬁguring FDDIXPress Software

This chapter explains how to conﬁgure your new FDDI station. You can also use these

instructions to reconﬁgure an already functioning station.

The section “Quick and Easy Conﬁguration Instructions” provides step-by-step

instructions for a basic, nonpersonalized conﬁguration.

FDDIXPress Package

FDDIXPress is a software option to accompany your Silicon Graphics computer’s FDDI

board. FDDIXPress software includes a driver for the FDDI board, an FDDI SMT module

(including software to maintain its management information database [MIB]), and some

utilities (SMT commands).

Depending on the speciﬁc release, FDDIXPress software may be shipped with the FDDI

board or with your computer’s operating system; the FDDIXPress release notes and the

FDDI Board’s Installation Guide or Installation Instructions provide details.

Installing FDDIXPress

The step-by-step instructions for installing FDDIXPress software are located in your

FDDIXPress release notes. General instructions for installing Silicon Graphics software

are included in the IRIX Admin: Software Installation and Licensing and on the inst(1M)

man page.

After installing the software, follow the steps in either “Quick and Easy Conﬁguration

Instructions” or “Complete and Complex Conﬁguration Information” to conﬁgure the

new FDDI station.

Chapter 2: Configuring FDDIXPress Software

Number Assignment to Interfaces

This section describes how identiﬁcation numbers (for example, xpi0,xpi3) are assigned

to the FDDIXPress network interfaces.

Overview

The number assignment for network interfaces varies, depending on the hardware

platform. Table 2-1 summarizes some of the implemented schemes.O

Table 2-1 Number Assignment for FDDIXPress Network Interfaces

Hardware Platform FDDIXPress

Interface Name Number Assignment Scheme

Crimson™ipg0 - ipg3 Network interface number matches a jumper

setting on each board. Jumper setting 0 has

network interface ipg0.

Indigo™xpi0 Always xpi0 for a single FDDI connection.

Indigo2™xpi0 Network interface number depends on the

order in which FDDIXPress boards are found

during startup. See “Number Assignment for

CHALLENGE M” for details.

Indy™xpi0 Always xpi0 for a single FDDI connection.

CHALLENGE™ M xpi0 Always xpi0 for a single FDDI connection.

CHALLENGE L and XL xpi0, xpi1, xpi# Network interface number depends on the

order in which FDDIXPress boards are found

during startup. See “Number Assignment for

CHALLENGE and Onyx” for details.

Onyx™xpi0, xpi1, xpi# Same scheme used for CHALLENGE L and XL.

Octane, Origin200, Origin

2000, and O2

rns0, rns1,

rns#

Network interface number is automatically

assigned at system startup. Numbering depends

on the interface numbers currently in the

ioconﬁg.conf ﬁle. See “Number Assignment for

Octane, Origin200, Origin 2000, and O2” on

page 21.

Number Assignment to Interfaces

Number Assignment for CHALLENGE M

During startup of a CHALLENGE M workstation, the operating system searches for

FDDIXPress boards starting at the topmost GIO Bus slot. The network interfaces are

subsequently assigned to the FDDI connections in the order they were located: the ﬁrst

board is assigned xpi0 and the second is assigned xpi1.

Number Assignment for CHALLENGE and Onyx

During startup of a CHALLENGE L, CHALLENGE XL, or Onyx system, the operating

system searches for FDDIXPress mezzanine boards attached to system IO4 boards in the

order shown below. When it locates a board, it adds the board to its hardware inventory.

1. Main IO4 board, lower mezzanine position (adapter 5)

2. Main IO4 board, upper mezzanine position (adapter 6)

3. Second IO4 board, lower mezzanine position (adapter 5)

4. Second IO4 board, upper mezzanine position (adapter 6)

The order continues as established above. You can display the contents of the hardware

inventory with the hinv command, as shown below. The FDDIXPress boards are listed in

the order in which they were found.

% /sbin/hinv

...

description: slot #, adapter #, xpi#-xpi#

...

The driver then uses the information summarized in Table 2-2 to assign network

interface numbers to the FDDIXPress mezzanine boards in the hardware inventory. For

each FDDIXPress mezzanine board, the operating system assigns two consecutive

numbers.

Note: Numbering for FDDIXPress boards installed in VME slots is controlled by jumpers

on the board.

Chapter 2: Configuring FDDIXPress Software

The network interface names and numbers cannot be changed or conﬁgured. The

naming/numbering scheme is embedded in the software.

The last two columns of Table 2-2 summarize how to match the labelling on the IO panel

plates to the network interfaces (that is, the connections at the daughter cards on the

FDDIXPress mezzanine boards). The bottom daughter card of each installed FDDIXPress

board is assigned the ﬁrst number within the assigned pair of numbers (for example, xpi0

or xpi2); the top daughter card, is assigned the higher number of the pair (for example,

xpi1 or xpi3).

This method of assigning numbers has the following consequences that should be

considered when FDDIXPress boards are added, removed, or moved:

•When additional FDDIXPress boards are installed, the network interfaces on

FDDIXPress boards downstream from the new board become dysfunctional. For

example, if a second FDDIXPress board is added upstream from the ﬁrst

FDDIXPress board, network interfaces xpi0 and xpi1 are assigned to the new board

during the next powerup and, unless the software has been reconﬁgured, the IP

network addresses do not match the cables that are attached to the ports.

To ﬁx this, the cables attached to the panel plates for the original board must be

moved to the panel plates for the new board. Or, alternatively, the netif.options ﬁle

must be edited so that the lines for the interfaces on the original board reﬂect the

new numbers (for example, if#name=xpi0 is changed to if#name=xpi2, and

if#name=xpi1 is changed to if#name=xpi3).

Table 2-2 Number Assignments for Network Interfaces on CHALLENGE and

Onyx Platforms

Order In Which Boards Are

Found Network Interfaces

Serviced by

FDDIXPress Board

Mapping IO Panel Plate Labels to Network

Interfaces

Daughter Card Interface

First FDDIXPress board xpi0 and xpi1 bottom

top

xpi1

xpi0

Second FDDIXPress board xpi2 and xpi3 bottom

top

xpi3

xpi2

And so on

Number Assignment to Interfaces

•When FDDIXPress boards are removed, moved, or are not found by the operating

system during startup, the interfaces that used to be serviced by the missing board

are assigned to the next downstream FDDIXPress board, so all downstream

network interfaces become dysfunctional. For example, if the ﬁrst FDDIXPress

board is not found during a powerup, its network interfaces (xpi0 and xpi1) are

assigned to the next board. This shifting of network interfaces affects all boards

downstream from the missing board. The networks physically attached to the ports

no longer match the assigned IP addresses.

To remedy this problem, the cables attached to the panel plates for each board can

be moved to the next downstream board. Or, alternatively, the netif.options ﬁle can

be edited so that the lines for the FDDIXPress interfaces reﬂect the new numbers

(for example, if#name=xpi2 is changed to if#name=xpi0, and if#name=xpi3 is

changed to if#name=xpi1).

Number Assignment for Octane, Origin200, Origin 2000, and O2

These workstations are PCI bus-based systems and their interface numbering scheme is

automatically determined at system startup by the ioconﬁg utility (see ioconﬁg(1M)).

At system startup, ioconﬁg inventories the FDDIXPress boards in the system and tries to

match them with the devices found in the /etc/ioconﬁg.conf ﬁle. If ioconﬁg detects a new

board, it assigns the next number available for that class (in this case, rns).

For example, upon initial startup after adding two FDDIXPress boards, the ﬁrst board is

labeled rns0 and the second board is rns1. These numbers remain during subsequent

system reboots and even if the boards are moved. If a board is moved, it receives the next

available number (rns2, for example) unless you edit the /etc/ioconﬁg.conf ﬁle and remove

the initial entry.

Chapter 2: Configuring FDDIXPress Software

Default Conﬁgurations

If the only conﬁguration task you perform is adding entries to the /etc/hosts ﬁle, the

system automatically conﬁgures all network interfaces with the default conﬁguration

described in this section. The defaults for ordering and naming network connections is

summarized in Table 2-3. The default settings for operational parameters are

summarized in Table 2-4.

The default conﬁguration for FDDI will not succeed if the /etc/hosts ﬁle does not contain

an entry with the station’s hostname paired with an FDDI network IP address. The name

in the /etc/hosts ﬁle must match the name displayed when the hostname command is

invoked from a shell window, as shown:

% /usr/bsd/hostname

If the line in the /etc/hosts ﬁle with the station’s hostname has an non-FDDI IP address (for

example, an IP address for an Ethernet network), the conﬁguration process will

complete, but neither the FDDI nor Ethernet connection will function.

For this station to be a router/gateway, it must have two network interfaces. For

example, if the station is to perform as an Ethernet-to-FDDI router, it must have an

Ethernet interface in addition to the FDDI interface. A station with two network

interfaces, by default, functions as a router.

Table 2-3 Default Network Interface Conﬁguration

Interface Default Conﬁguration

primary interface

interface selected FDDI (for example, ipg0 or xpi0)

network connection name assigned Same as the hostname deﬁned in the /etc/sys_id

ﬁle.

IP address The IP address in /etc/hosts ﬁle that is associated

with the station’s hostname.

secondary interface

interface selected Built-in Ethernet (for example, ec0 or et0)

network connection name assigned gate-hostname

IP address The IP address in /etc/hosts ﬁle that is associated

with the name “gate-hostname.”

Default Configurations

The network interfaces are conﬁgured with default operational parameter settings, as

summarized in Table 2-4.

If the conﬁguration described in this section ﬁts your needs, you do not need to perform

any of the conﬁguration tasks. Skip to “Install the FDDI Board” on page 41. Otherwise,

follow the instructions in one or more of the sections in this chapter to change the

conﬁguration to suite your needs.

Table 2-4 Default Network Interface Parameters

Parameter Default Description

netmask No subnet.

(That is, the bits in the standard

network portion of the Internet

address are set to 1; the bits in the

standard host portion of the

Internet address are set to 0. For

class B addresses, 0xFFFF0000. For

class C, 0xFFFFFF00.)

32-bit value used to create two or more

subnetworks from a single Internet address,

by increasing the number of bits used as the

network portion and decreasing the number

of bits used as the host portion. When

creating the mask, assign 1 to each network

bit and 0 to each host bit.

broadcast

address

For the Internet address family, the

host portion of the IP address is set

to 1s. (For class B addresses,

x.x.255.255. For class C addresses,

x.x.x.255.)

Address used by this interface for contacting

all stations on the local area network.

route

metric

0 Hop count value advertised by the routing

daemon (routed) to other routers. Higher

numbers make the route less desirable and

less likely to be selected as a route. Settings

range from 0 (most favorable) to 16 (least

favorable, inﬁnite).

arp Address Resolution Protocol is

enabled and used by the interface.

Address Resolution Protocol (ARP)

translates IP addresses to link-layer

(hardware) addresses.

When this parameter is disabled, interface

does not use ARP.

debug Disabled. When debugging is enabled, a wider variety

of error messages are displayed when errors

occur.

Chapter 2: Configuring FDDIXPress Software

Quick and Easy Conﬁguration Instructions

To conﬁgure your FDDI station quickly, follow the step-by-step instructions in the

appropriate example:

•“FDDI as the Primary Interface and Ethernet as Secondary” on page 24

•“FDDI as the Secondary Interface and Ethernet as Primary” on page 25

•“FDDI as the Only Network Interface” on page 27

FDDI as the Primary Interface and Ethernet as Secondary

The conﬁguration described here contains no special items, just the most basic

functionality.

If your site uses an NIS service, the changes described in this section must also be made

to the database on the NIS server .

1. Open a shell window.

2. Log on as superuser:

% /sbin/su

Password: thepassword

3. Determine your station’s hostname:

# /usr/bsd/hostname

4. Open the /etc/hosts ﬁle:

# /usr/sbin/jot /etc/hosts

5. Find the line containing your station’s hostname.

If the ﬁle does not contain a line for your hostname, follow the instructions in

“Complete and Complex Conﬁguration Information” on page 28,

6. Copy the line and place the copy immediately below the original.

7. Return to the original line and change the address (numbers on the left) to the IP

address for the FDDI network.

Quick and Easy Configuration Instructions

8. On the new line, change each instance of the hostname to gate-hostname.

For example, the lines for a station with a hostname of mickey, residing in a domain

of disney.com, would look like this:

x.x.x.x mickey.disney.com mickey #FDDI primary

x.x.x.x gate-mickey.disney.com gate-mickey #Ether secondary

Each x represents one, two, or three decimal digits.

9. Do not change the address on the new line. This is your original Ethernet IP address

and will continue to be used.

10. Save and close the ﬁle.

11. You are now ready to install the FDDI board. Follow the instructions in the board’s

installation guide or installation instructions.

If the board is already installed, type the following commands to build your

changes into the operating system:

# /etc/autoconfig

Automatically rebuild the operating system (y/n)? y

# /etc/reboot

FDDI as the Secondary Interface and Ethernet as Primary

The conﬁguration described here contains no special items, just the most basic

functionality. This conﬁguration makes it possible for a Silicon Graphics system to load

the miniroot over the primary Ethernet network (or boot from the network).

1. Open a shell window.

2. Log on as superuser:

% /sbin/su

Password: thepassword

3. Determine your station’s hostname:

# /usr/bsd/hostname

4. Open the /etc/hosts ﬁle:

# /usr/sbin/jot /etc/hosts

Chapter 2: Configuring FDDIXPress Software

5. Find the line containing your station’s hostname.

If the ﬁle does not contain a line for your hostname, follow the instructions in

“Complete and Complex Conﬁguration Information” on page 28.

6. Copy the line and place the copy immediately below the original.

7. On this new line, change the IP address (all the numbers on the left) to the FDDI IP

address.

8. Also on the new line, change each instance of the hostname to fddi-hostname.

For example, the lines for a station with a hostname of mickey, residing in a domain

of disney.com, would look like this:

x.x.x.x mickey.disney.com mickey #Ether primary

x.x.x.x fddi-mickey.disney.com fddi-mickey #FDDI secondary

Each x represents one, two, or three decimal digits.

9. Save and close the ﬁle.

If your site uses an NIS service, the changes described above must also be made to

the database on the NIS server.

10. Determine the name of your primary Ethernet interface with the command shown

below. Some common examples include ec0,et0,enp0,ep0.

# /usr/etc/netstat -i

11. Determine the name of your FDDI interface. This information is in the FDDIXPress

release notes. Common names include xpi0 and ipg0.

12. Open the /etc/conﬁg/netif.options ﬁle:

# /usr/sbin/jot /etc/config/netif.options

13. Find this line:

: if1name=

Change it as shown below. Be sure to remove the colon and leading space.

if1name=Ethernetinterfacename

Quick and Easy Configuration Instructions

14. Find this line:

: if2name=

Change it as shown below. Be sure to remove the colon and leading space.

if2name=FDDIinterfacename

15. Find this line:

: if2addr=gate-$HOSTNAME

Change it as shown below. Be sure to remove the colon and leading space.

if2addr=fddi-$HOSTNAME

16. Save and close the ﬁle.

17. You are now ready to install the FDDI board. Follow the instructions in the board’s

installation guide or installation instructions.

If the board is already installed, type the following commands to build your

changes into the operating system:

# /etc/autoconfig

Automatically rebuild the operating system (y/n)? y

# /etc/reboot

FDDI as the Only Network Interface

The conﬁguration described here contains no special items, just the most basic

functionality.

1. Open a shell window.

2. Log on as superuser:

% /sbin/su

Password: thepassword

3. Determine your station’s hostname:

# /usr/bsd/hostname

Chapter 2: Configuring FDDIXPress Software

4. Open the /etc/hosts ﬁle:

# /usr/sbin/jot /etc/hosts

5. Find the line containing your station’s hostname.

If the ﬁle does not contain a line for your hostname, follow the instructions in

“Complete and Complex Conﬁguration Information” on page 28.

6. Change the address (numbers on the left) to the IP address for the FDDI network.

For example, the line for a station with a hostname of mickey, residing in a domain

of disney.com, would look like this:

x.x.x.x mickey.disney.com mickey #FDDI primary

Each x represents one to three decimal digits.

7. Save and close the ﬁle.

If your site uses an NIS service, the changes described above must also be made to

the database on the NIS server.

8. You are now ready to install the FDDI board. Follow the instructions in the board’s

installation guide or installation instructions.

If the board is already installed, type the following commands to build your

changes into the operating system:

# /etc/autoconfig

Automatically rebuild the operating system (y/n)? y

# /etc/reboot

Complete and Complex Conﬁguration Information

This section describes conﬁgurations and conﬁguration issues not covered by “Quick

and Easy Conﬁguration Instructions.” The conﬁguration instructions in this section are

more complex and complete. This section explains when and why you need to conﬁgure

an FDDI station, in addition to how to do it.

The following is an overview of the procedure for installing and conﬁguring

FDDIXPress. For a new FDDI station, the tasks must be performed in the order listed.

Each task is divided into detailed steps and described in the referenced section.

Complete and Complex Configuration Information

1. Prepare for conﬁguration, as described in “Prepare for Conﬁguration” on page 29.

2. Perform the required conﬁguration tasks:

■Ensure your station’s network connection names and IP addresses are in the

/etc/hosts ﬁle, as described in “Network Connection Names and IP Addresses”

on page 31.

■Verify and, if necessary, modify the /etc/conﬁg/netif.options ﬁle as described in

“Conﬁgure the Station’s Network Interfaces” on page 33.

■If necessary, create or modify the /etc/conﬁg/ifconﬁg-#.options ﬁle, as described in

“Changing Settings for the Operational Parameters” on page 38.

3. Perform the FDDI board installation, as described in “Install the FDDI Board” on

page 41.

4. Optionally, make your environment user friendly, as described in “Conﬁgure the

Environment for User Friendliness and Safety (Optional)” on page 42.

5. Check that the FDDI connection is functional, as described in “Verifying the FDDI

Connection” on page 47.

Prepare for Conﬁguration

Before starting the installation, collect the necessary information and perform

housekeeping so the installation goes smoothly.

1. If your computer has not been networked before, follow the instructions in the

Personal System Administration Guide to set up your system as a networked

workstation. These tasks include assigning your system a hostname, a network

connection name, an IP address, as well as enabling TCP/IP.

2. If the FDDIXPress software has not been installed, do so now.

3. Determine the number of networks to which your station will be connected after

FDDIXPress is installed. For example, if your station is currently connected to an

Ethernet network, will the station continue to use the Ethernet connection in

addition to the FDDI connection?

4. If the station will have more than one network connection, decide which will be the

primary network. The primary network interface should be the one where all or

most of your station’s network services or clients reside.

Note: The network you select as primary experiences the heaviest usage. It is

recommended that FDDI be the primary network connection. However, for systems

that need to boot over the network, Ethernet must be primary.

Chapter 2: Configuring FDDIXPress Software

5. For each network connection, select a network connection name and IP address.

The network connection name of the primary network connection must be the same

as the system’s hostname. You can display your system’s hostname by using the

hostname command within a shell window:

% /usr/bsd/hostname

You can display the current IP address associated with the network connection

name hostname by typing one of the following commands in a shell window:

% /sbin/grep hostname /etc/hosts

% /usr/bin/ypmatch hostname hosts

The names you create for non-primary network interfaces can be anything you

want. To facilitate recognition, the names usually include both the hostname and an

indication of the protocol (for example, fddi-mars or fddi2-mars).

6. Determine if any of your station’s network interfaces require special conﬁguration

for any of the following items: subnetwork mask (netmask), broadcast address,

route metric, or use of Address Resolution Protocol.

The default conﬁguration settings for these operational parameters are listed in

Table 2-4, in “Default Conﬁgurations.” In most cases, the defaults are the desired

settings.

If any of these operational parameters needs special conﬁguration, the network

administrator must create an /etc/conﬁg/ifconﬁg-#.options ﬁle, where the pound sign

(#) matches the network interface’s order in the netif.options ﬁle. Once these ﬁles are

created, you can proceed with the conﬁguration.

7. For sites using an NIS server:

The network administrator needs to update the site’s hosts and ethers databases to

include the correct information about this station. The hosts database should be

updated to include all the station’s network connection names and IP addresses

before you restart the system after installing the board. The ethers database can be

updated only after the board has been installed.

8. You are ready to start conﬁguring. Follow the instructions in “Network Connection

Names and IP Addresses.”

Complete and Complex Configuration Information

Network Connection Names and IP Addresses

Your FDDI station must have a network connection name1 and IP address for each FDDI

network interface. It may also need network connection names and IP addresses for

other network interfaces (for example, Ethernet).

This section provides instructions for entering your network connection names and IP

addresses into the local /etc/hosts ﬁle.

If your site uses an NIS service, the changes described in this section must also be made

to the NIS server’s database.

1. Open a shell window.

2. Log on as superuser:

% /sbin/su

Password: thepassword

3. Use your favorite editor (for example, jot or vi) to open the /etc/hosts ﬁle. For

example, the command line below opens the /etc/hosts ﬁle for editing:

# /usr/sbin/jot /etc/hosts

4. Locate the line containing the network connection name that you selected for your

FDDI connection. If you do not ﬁnd an entry for this name, search for the FDDI IP

address. If you do not ﬁnd either, skip to step 6. If you ﬁnd the FDDI name or

address, continue.

Searching for all instances of the station’s hostname will usually identify all the

network connection names for the system. You can display the system’s hostname

with the /usr/bsd/hostname command.

5. Verify that the IP address and the name are correct for the FDDI connection. (Make

sure the IP address is not the Ethernet address.) If the name and address are correct,

skip to step 7, otherwise continue.

1The network connection name is a name entered in the /etc/hosts file. This name is paired with an IP

address. Each network interface must have one network connection name that is unique to the domain

and one globally unique IP address.

Chapter 2: Configuring FDDIXPress Software

6. If the line is not correct or is missing, edit the ﬁle so that there is a line containing the

IP address and network connection name for the FDDI network interface.

A typical format for an entry in /etc/hosts ﬁle is as shown:

IPaddress fullnetworkconnectionname aliases

For example, a portion of an /etc/hosts ﬁle might look like this, where the host goofy

has two entries and mickey has one:

198.45.91.1 mickey.mrktg.disney.com mickey

198.45.91.5 goofy.mrktg.disney.com goofy

198.45.65.1 fddi-goofy.engr.disney.com fddi-goofy

7. If your station will be using more than one network connection, for each one (in

addition to FDDI), verify that the name and IP address are the correct.

8. Save and close the ﬁle.

9. Decide if the following statements are true for your system, then choose the relevant

substep, below:

•In the /etc/hosts ﬁle, the FDDI IP address is assigned to the station’s hostname

•The Ethernet IP address to the entry gate

•FDDI is the primary network interface

•The station has no more than two network interfaces

■If all the statements are true, you do not need to perform any other

conﬁguration tasks. If the FDDI board is not installed, install it now. Otherwise,

if the board is installed, use these commands to build your changes into the

operating system:

% /sbin/su

Password: thepassword

# /etc/autoconfig

Automatically rebuild the operating system (y/n)? y

# /etc/reboot

■If any of the statements are false, you need to conﬁgure the network interface(s).

Follow the instructions in the next section, “Conﬁgure the Station’s Network

Interfaces.”

For more information about the /etc/hosts ﬁle, see the hosts(4) man page and IRIX Admin:

Networking and Mail.

Complete and Complex Configuration Information

Conﬁgure the Station’s Network Interfaces

This section explains how to conﬁgure your station’s network interface (or interfaces). If

you do not perform any of the procedures in this section, the system conﬁgures the

station with the default settings described in “Default Conﬁgurations” on page 22.

This section contains the following subsections:

•“Making FDDI the Secondary Network Interface” on page 33

•“Changing the Ethernet’s Name” on page 37

•“Conﬁguring Multiple FDDI Interfaces” on page 38

•“Changing Settings for the Operational Parameters” on page 38

•“Disabling Forwarding and Routing” on page 39

Making FDDI the Secondary Network Interface

To make FDDI the secondary network interface, edit the /etc/conﬁg/netif.options ﬁle as

explained in this procedure. This allows a Silicon Graphics workstation or server to boot

from the primary Ethernet network.

1. Determine the names of your system’s network interfaces.

■If you are installing the FDDI board for the ﬁrst time, the FDDIXPress release

notes indicate the name of the FDDI network interface for your system (for

example, ipg# or xpi#).

■Other interface names can be displayed with the netstat command.

Open a shell window and use the /usr/etc/netstat -in command to list the

currently available network interfaces, as demonstrated in Figure 2-1. If an

FDDI connection is operating, its name is listed. The names you see may be

different than those shown in Figure 2-1.

Chapter 2: Configuring FDDIXPress Software

Figure 2-1 Displaying Available Interfaces With netstat -in

2. Open the /etc/conﬁg/netif.options ﬁle with your favorite editor.

3. Change the following lines

: if1name=

: if1addr=$HOSTNAME

: if2name=

: if2addr=gate-$HOSTNAME

if1name=name of interface you want to be primary

: if1addr=$HOSTNAME

if2name=FDDIinterfacename

if2addr=fddi-$HOSTNAME

Do not alter the line containing : if1addr

4. Remove the colons and leading spaces.

For example:

if1name=ec0

: if1addr=$HOSTNAME

if2name=xpi0

if2addr=fddi-$HOSTNAME

5. If you do not want to use the network connection name shown above

(fddi-hostname), you may replace the name with one of your own choice.

Make sure the name or name format you enter corresponds to an entry in the

/etc/hosts ﬁle.

6. If this is your ﬁnal conﬁguration change, go to the subsection “Build Conﬁguration

Changes Into the System” to ﬁnish.

Name Mtu Network Address Ipkts

Ierrs Opkts Oerrs Coll

xpi0 4500 195.41.72 195.41.72.61 0

0 000

ec0 1500 195.41.75 195.41.75.61

2546732 5158 231251 0 10338

lo0 32880 127 127.0.0.1

7990697 0 7990697 0 0

an Ethernet interface

an FDDI interface

Complete and Complex Configuration Information

Example 2-1 FDDI as Primary Interface Conﬁguration

A workstation named minnie has an FDDI interface, xpi0, and an Ethernet interface, ec0.

If the netif.options ﬁle is not altered, the default conﬁguration is: xpi0 is assigned the IP

address corresponding to minnie, and ec0 is assigned the IP address for gate-minnie. If

there is no entry in /etc/hosts for gate-minnie, the secondary interface is not conﬁgured.

For example, minnie’s /etc/hosts ﬁle contains this information:

195.41.91.3 minnie.disney.com minnie

195.41.184.2 gate-minnie.disney.com gate-minnie

The unaltered /etc/conﬁg/netif.options ﬁle contains this information:

: if1name=

: if1addr=$HOSTNAME

: if2name=

: if2addr=gate-$HOSTNAME

This is the resulting conﬁguration:

•minnie (195.41.91.3) is conﬁgured as the primary FDDI interface.

•gate-minnie (195.41.184.2) is conﬁgured as the secondary Ethernet interface.

Example 2-2 FDDI as Secondary Interface Conﬁguration

To make the Ethernet (ec0) interface primary and the FDDI (xpi0) secondary for the

system described in Example 2-1, you need to change the lines in the netif.options ﬁle to

the following:

if1name=ec0

: if1addr=$HOSTNAME

if2name=xpi0

: if2addr=gate-$HOSTNAME

This is the result:

•minnie (195.41.91.3) is conﬁgured as the primary Ethernet interface.

•gate-minnie (195.41.184.2) is conﬁgured as the secondary FDDI interface.

Example 2-3 Changing the Secondary FDDI Interface Name

To change the FDDI secondary interface name to fddi-minnie for the system described in

Example 2-1 and Example 2-2, the /etc/hosts ﬁle and the /etc/conﬁg/netif.options ﬁle need to

be altered.

Chapter 2: Configuring FDDIXPress Software

The /etc/conﬁg/netif.options ﬁle must have the following entries:

if1name=ec0

: if1addr=$HOSTNAME

if2name=xpi0

if2addr=fddi-$HOSTNAME

The /etc/hosts ﬁle must have the following entries:

195.41.91.3 minnie.disney.com minnie

195.41.184.2 fddi-minnie.disney.com fddi-minnie

Explanation of Network Conﬁguration Process

During system startup and anytime it is invoked speciﬁcally, the shell command ﬁle

/etc/init.d/network conﬁgures and initializes the network interfaces and software. Some of

the script’s procedures are accomplished by calling other utilities and reading

conﬁguration ﬁles. Some of the tasks the /etc/init.d/network command ﬁle performs are:

•Determines the station’s hostname. This information is deﬁned in the /etc/sys_id ﬁle.

•Determines the network hardware and interfaces available in the operating system.

This information can be viewed with the hinv command.

•Determines the ordering for the network interfaces. This information is deﬁned in

the /etc/conﬁg/netif.options ﬁle. If the netif.options ﬁle has not been altered, the default

ordering is conﬁgured (explained in “Default Conﬁgurations” on page 22 and

deﬁned within the network script).

•Determines the network connection name for each network interface. This

information is deﬁned by the if#addr lines in the /etc/conﬁg/netif.options ﬁle. If the

netif.options ﬁle has not been altered, the default names (explained in “Default

Conﬁgurations” and deﬁned in the network script) are used.

•Determines the IP address for each interface by looking up each network connection

name in the /etc/hosts ﬁle.

•Determines the settings for each network interface’s operational parameters. This

information is deﬁned in the /etc/conﬁg/ifconﬁg-#.options. If an ifconﬁg-#.options ﬁle

does not exist for the interface, the default settings are assigned (described in

“Default Conﬁgurations”).

Complete and Complex Configuration Information

•Conﬁgures the number of network interfaces speciﬁed by the

if_ num variable in the network script.

•Starts (enables) each successfully conﬁgured interface.

The results of the network script’s conﬁguration can be viewed with the /usr/etc/netstat -i

and /usr/etc/ifconﬁg commands.

Changing the Ethernet’s Name

Ethernet is automatically conﬁgured as the secondary network interface. It is assigned a

network connection name of gate-hostname. This section provides instructions for

changing the name used for the Ethernet network connection.

If a station does not have a second entry in the /etc/hosts ﬁle, the system does not

conﬁgure a second network interface.

To conﬁgure Ethernet with a different /etc/hosts entry (for example, ether-hostname),

follow these instructions:

1. Log on as superuser and open the /etc/conﬁg/netif.options ﬁle with your favorite

editor.

2. Change the following line:

: if2addr=gate-$HOSTNAME

if2addr=newname

if2addr=newname-$HOSTNAME

3. Save and close the ﬁle.

4. Use one of the following commands to verify that the name you have entered in the

netif.options ﬁle exists in the /etc/hosts ﬁle or hosts database. If the name does not

exist, follow the instructions in “Network Connection Names and IP Addresses” on

page 31 to modify the /etc/hosts ﬁle.

% /sbin/grep name /etc/hosts

% /usr/bin/ypmatch name hosts

name is either the new name or newname-hostname.

5. If this is your ﬁnal conﬁguration change, go to the subsection “Build Conﬁguration

Changes Into the System” on page 40 to ﬁnish.

Chapter 2: Configuring FDDIXPress Software

Conﬁguring Multiple FDDI Interfaces

There is no default conﬁguration for FDDI network interfaces other than the ﬁrst one. If

a system has two or more FDDI connections, you need to add a pair of lines to the

/etc/conﬁg/netif.options ﬁle for each additional FDDI network interface and possibly

change the if_num variable in the /etc/init.d/network ﬁle.

The following lines are an example of netif.options entries for a system with three FDDI

connections and one Ethernet. The lines for the ﬁrst and second network interfaces have

not been edited, so the default conﬁguration for a primary FDDI and secondary Ethernet

are automatically conﬁgured.

: if1name=

: if1addr=

: if2name=

: if2addr=

if3name=xpi1

if3addr=fddi2-goofy

if4name=xpi2

if4addr=fddi3-goofy

The network connection names (for example, fddi3-goofy) must exist in the /etc/hosts ﬁle.

The following is a single line in a network ﬁle that has been altered to conﬁgure twelve

network interfaces:

if_num=12

Changing Settings for the Operational Parameters

To change the default settings for operational parameters (summarized in Table 2-4),

create or edit the /etc/conﬁg/ifconﬁg-#.options ﬁle for the network interface. The pound sign

(#) in the ﬁlename must match the number in the netif.options ﬁle that was used to

conﬁgure the network connection. For example, for the netif.options line if3name=xpi0,

create or edit the ﬁle /etc/conﬁg-3.options.

The following is an example of the contents of an /etc/conﬁg/ifconﬁg-#.options ﬁle. This ﬁle

enables the IP address resolution protocol, sets a route metric, and speciﬁes a subnetwork

mask for the associated network:

arp metric 9 netmask 0xFFFFFF80

Complete instructions for conﬁguring operational parameters are provided in the device

conﬁguration instructions in IRIX Admin: Networking and Mail.

Complete and Complex Configuration Information

Disabling Forwarding and Routing

By default, the routing daemon (routed) is started and IP forwarding (in the operating

system) is enabled whenever a system has two or more network interfaces. This default

conﬁguration causes the system to advertise itself as a router to other systems on the

networks, maintain tables of routes it knows, and to transfer (that is, route, forward)

packets between its networks whenever it encounters packets that need to be routed in

order to be delivered.

If your station has two (or more) network interfaces and you do not want the system to

transfer or route packets between its networks or to advertise itself as a router, follow the

steps in the examples below for the conﬁguration you want.

Example 2-4 Disable Forwarding and Route Advertising

This example disables the capability to forward data from one network to another and

advertisement of all routing information. (This conﬁguration does not disable the

routing daemon’s maintenance of routing tables, only its advertisement of the routing

information.)

1. Edit the /etc/conﬁg/routed.options ﬁle so that it contains the characters -hq. This

prevents the system from advertising its network connections (routes) or its

presence (the host route) on any of the system’s networks.

2. Edit the /var/sysgen/master.d/bsd ﬁle so that the line containing

int ipforwarding = 1 is changed to int ipforwarding = 0. This prevents the

system from passing (transferring) any messages between its networks.

3. Go to the subsection “Build Conﬁguration Changes Into the System” on page 40 to

ﬁnish.

Example 2-5 Disable Route Advertising

This example allows data to be forwarded from one network to another, but prevents the

system from advertising its network connections (thus preventing the system from

becoming known as a router).

1. Edit the /etc/conﬁg/routed.options ﬁle so that it contains the characters -hq. This

causes the system to refrain from all rout advertising; it does not advertise its

network connections (routes) and it does not advertise its own presence has a host

(host routes) on its connected networks.

2. Go to the subsection “Build Conﬁguration Changes Into the System” on page 40 to

ﬁnish.

Chapter 2: Configuring FDDIXPress Software

Example 2-6 Disable Route Advertising Except For the Primary Interface

This example allows data to be forwarded from one network to another and prevents the

system from advertising its network connections (thus preventing the system from

becoming known as a router). However, it allows the system to advertise its own

presence as a host on the network attached as its primary network interface.

1. Edit the /etc/conﬁg/routed.options ﬁle so that it contains the characters -hmq. This

causes the system to advertise (on all its connected networks) its presence as a host

(the host route) on its primary network, but prevents the system from advertising

its network connections and other host routes.

2. Go to the subsection “Build Conﬁguration Changes Into the System” on page 40 to

ﬁnish.

For more information, see the routed(1M) and chkconﬁg(1M) man pages and the

comments in the /var/sysgen/master.d/bsd ﬁle.

Build Conﬁguration Changes Into the System

To build your network interface or driver conﬁguration changes into the operating

system, follow the procedure that is appropriate:

•If the FDDI board has not been installed, do not rebuild the operating system now.

Instead, follow the instructions in the FDDI board’s installation guide or installation

instructions to install the board.

•If the FDDI board is installed, rebuild the operating system, and reboot to start

using the new operating system with these commands:

% /sbin/su

Password: thepassword

# /etc/autoconfig

Automatically rebuild the operating system (y/n)? y

# /etc/reboot

Complete and Complex Configuration Information

Install the FDDI Board

The FDDIXPress board should be installed after the FDDIXPress software has been

installed and conﬁgured. The instructions for installing an FDDI board are described in

the board’s installation guide or installation instructions.

The following is an overview of the procedure for installing the FDDIXPress product

(software and hardware). The steps must be performed in the order shown.

1. Install the FDDIXPress software.

2. Perform these required conﬁguration tasks:

■Update your station’s name(s) and IP address(es) in the /etc/hosts ﬁle.

Instructions are provided in “Network Connection Names and IP Addresses”

on page 31.

■Conﬁgure the network interface(s). Instructions are provided in “Conﬁgure the

Station’s Network Interfaces” on page 33.

3. Install the FDDI board. Follow the instructions in the board’s installation guide or

installation instructions.

Installation of the board includes the following three steps. The FDDI connection

will not function if you do not ﬁnish your installation with these steps:

■Restart the system.

■Answer yes to the prompt Automatically rebuild the operating system

(y/n)?

■Reboot the system.

4. (Optional) When you ﬁnish installing the board, continue with “Conﬁgure the

Environment for User Friendliness and Safety (Optional)” to make your station’s

environment user friendly and safe.

5. Verify the FDDI connection. Instructions are provided in “Verifying the FDDI

Connection” on page 47.

Chapter 2: Configuring FDDIXPress Software

Conﬁgure the Environment for User Friendliness and Safety

(Optional)

This section describes how to make your environment user friendly and safe. All

procedures in this section are optional.

Four actions are recommended:

•Set the path variable to include the SMT commands.

•Create backup copies of important FDDIXPress ﬁles.

•For sites without an NIS service: Create an /etc/ethers ﬁle so that names can be used

with SMT commands instead of MAC addresses.

•For sites with an NIS service: Create local copies of the ethers and hosts databases.

Setting the Path to the SMT Commands (Optional)

To invoke the SMT commands from any directory, the system must know where the

commands reside. This section shows how to conﬁgure your environment so that the

SMT commands are always available, regardless of the directory you are currently

logged into.

If you do not conﬁgure the path, you must type the complete path to the directory where

the SMT commands reside each time you invoke an SMT command.

1. Find the path to the SMT commands by reading any of the SMT command man

pages. For example, enter the command:

% /usr/bin/man smtring

In the display that appears in your shell window, the text under the heading

SYNOPSIS indicates the path. Make note of the path; it is everything up to, but not

including, the command name. In the following display, /usr/etc/ is the path:

NAME

smtring - examines the state of FDDI ring

SYNOPSIS

/usr/etc/smtring [-adn] [-i interval] . . .

Complete and Complex Configuration Information

2. Open your .login ﬁle (or .cshrc ﬁle) with your favorite editor. For example, type a

command line like this:

% /usr/sbin/jot /usr/people/yourloginname/.login

3. Locate the line that sets the path variable. The line looks like this:

set path=(. ~/bin /usr/bsd /usr/sbin /usr/lib /etc)

4. At the end of the path variable’s last line, but before the closing parenthesis, add the

new path. For example, if you were editing the example .login (or .cshrc) ﬁle, it

should look like this example:

set path=(. ~/bin /usr/bsd /usr/sbin /usr/lib /etc /usr/etc)

Setting Up the ethers File (Optional)

The FDDIXPress SMT commands use MAC (physical) addresses to contact other FDDI

stations on the ring. If you want to use the commands with names, instead of MAC

addresses, your system must have access to an ethers database. (The ethers database

maps physical addresses—MAC and Ethernet addresses—to network connection

names.) Your station can obtain ethers database information from the site’s Network

Information Service (NIS) or from a local /etc/ethers ﬁle.

Note: If any of your station’s networks uses an NIS server, this procedure must be done

at the NIS server, not on the local station.

Edit the /etc/ethers ﬁle so it lists this station’s MAC address and those of all the other

stations on the FDDI ring:

1. Open a shell window and log on as superuser.

2. Use the /usr/etc/netstat -ia command to determine the MAC address of your station’s

FDDI board and the name of the FDDI interface. Be sure to ﬁnd the MAC address

for the FDDI board (for example, the MAC address listed under xpi0 or ipg0), not

the Ethernet board (for example, ec0). In a default conﬁguration, FDDI is the ﬁrst

interface listed. The MAC address is the number displayed in hexadecimal format,

as shown in Figure 2-2.

Chapter 2: Configuring FDDIXPress Software

Figure 2-2 Screen Display for /usr/etc/netstat -ia Command

3. Open the /etc/ethers ﬁle with your favorite editor.

4. Add a line to the /etc/ethers ﬁle that speciﬁes the FDDI board’s MAC address and the

station’s FDDI network connection name. In the /etc/ethers ﬁle, use the format

displayed with the /usr/etc/netstat command for the MAC address and network

connection name:

x:x:x:x:x:x networkconnectionname # comments

x:x:x:x:x:x is the 48-bit, hexadecimal MAC address of each network interface board.

Each x represents one byte and can be a hexadecimal numeral from 0 to ff. The

networkconnectionname corresponds to the name in the /etc/hosts ﬁle that is paired

with the FDDI IP address. Comments start after the # character and are optional.

5. In another shell window, determine the broadcast address for your network by

using the following command. The broadcast address is the sequence of digits

displayed in the location illustrated in Figure 2-3.

% /usr/etc/smtconfig networkinterfacename

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

xpi0 4500 N1 mickey.disney 0 0 0 0 0

pmap-mcast

allhosts-mcast

0a:00:fc:04:a9:9

ec0 1500 N2 gate-mickey.disney 2546732 5158 231251 0 10338

pmap-mcast

allhosts-mcast

0a:00:f6:06:34:ff

lo0 32880 loopback localhost 7990697 0 7990697 0 0

allhosts-mcast

FDDI MAC address

FDDI network interface name

FDDI network

connection name

Complete and Complex Configuration Information

Figure 2-3 Displaying Broadcast Address

6. Using the broadcast address from step 5, make each station on the ring provide its

MAC address and network connection name:

% /usr/etc/ping -r -c 10 broadcastaddress

7. Display the gathered information:

% /usr/etc/arp -a

8. Copy all the displayed MAC addresses and host names into your /etc/ethers ﬁle. Be

sure to use the proper format as explained above and shown in Example 2-7.

Example 2-7 Sample ethers File

In this example, a station with a hostname of goofy, shows ﬁrst a portion of an arp display,

and second a corresponding portion of the /etc/ethers ﬁle. goofy has two network

interfaces and has been conﬁgured with the default conﬁgurations. Note that the arp

display does not list goofy’s information.

The arp display:

mickey.disney.com (187.41.75.61) at a:0:69:6:34:ff

donald.disney.com (187.41.75.1) at a:0:69:2:4:45

minnie.disney.com (187.41.75.5) at a:0:69:2:15:ff

The /etc/ethers ﬁle:

a:0:69:da:5c:f goofy# local FDDI MAC addr

2:c:1f:1:e2:88 gate-goofy# local Ethernet addr

a:0:69:6:34:ff mickey# an FDDI remote station

a:0:69:2:4:45 donald# an FDDI remote station

a:0:69:2:15:ff minnie# an FDDI remote station

The above addresses can also be in this format:

0a:00:69:da:5c:0f goofy

02:0c:1f:01:e2:88 gate-goofy

xpi0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>

inet 223.41.75.4 netmask 0xffffff00 broadcast 223.41.75.255

Broadcast address

Chapter 2: Configuring FDDIXPress Software

For more information, see the ethers(4), ping(1M), and arp(1M) man pages. For more

information about the role of the /etc/ethers ﬁle, see IRIX Admin: Networking and Mail. For

information about NIS, see the NIS Administration Guide and man pages.

Some of the FDDIXPress tools and commands (such as smtping and smtstat) depend on

the /etc/ethers ﬁle (either local or on the NIS server) to know stations by their network

connection names instead of by their MAC addresses. The /etc/ethers ﬁle maps MAC

addresses to network connection names. You need to enter each FDDI station into the

ethers database. (The ﬁle /etc/ethers is the ethers database.) If you do not update this

database, FDDIXPress commands know stations only by their MAC addresses, in

hexadecimal numerical format and Ethernet order, as deﬁned in the Glossary.

The stations listed by arp -a are stations that your station has communicated with in the

last few minutes. You can add entries to the arp display by invoking ping name or

ping IPaddress.

If your site uses a Network Information Service (NIS) server, you may want to keep local

(backup) copies of the ethers and hosts ﬁles for use when the NIS server is unavailable.

(The local copies are not used as long as NIS is available.) For example, an NIS server

could become unavailable when the FDDI ring wraps. If you decide to keep local backup

copies, remember to update them when changes are made.

Type the following command lines to make local copies of /etc/hosts and /etc/ethers ﬁles,

including the changes the network administrator has made to the database:

% /sbin/su

Password: thepassword

# /usr/bin/ypcat hosts > /etc/hosts

# /usr/bin/ypcat ethers > /etc/ethers

Do not perform this step until you are certain the network administrator has made all the

changes pertaining to your station.

Verifying the FDDI Connection

Backing Up SMT Files (Optional)

Files can become corrupted. It is a wise practice to keep backup copies of important ﬁles.

To create backup copies of two FDDIXPress ﬁles that the SMT module (daemon) uses

frequently, follow this procedure.

1. Go to the fddi directory:

% cd /etc/fddi

2. Become superuser:

% /sbin/su

Password: thepassword

3. Make backup copies of the smtd.conf and smtd.mib ﬁles:

# /sbin/cp smtd.conf smtd.conf.orig

# /sbin/cp smtd.mib smtd.mib.orig

Performing this step can save you from reinstalling the FDDIXPress software if either ﬁle

becomes corrupted or is deleted.

Verifying the FDDI Connection

To verify that the station’s FDDI connection is working, follow the steps in this section.

Many of these steps use the smtstat -s command to view key items from the SMT

information database. For details on how to use the smtstat command, see “Display SMT

Information (MIB)” on page 65. If any of the following tests fail, see Chapter 4 for

troubleshooting ideas.

1. Open a shell window.

2. Type the following command to verify that the FDDI board is recognized by the

system software:

% /sbin/hinv

The hinv display, shown in Figure 2-4, lists all the hardware known to the system.

An FDDI controller must display in the list. If an FDDI controller is not listed, refer

to “Recognition of Board by Software” on page 80.

Chapter 2: Configuring FDDIXPress Software

Figure 2-4 An Example of the hinv Display

3. List all network interfaces on the system. An FDDIXPress interface, such as ipg# or

xpi#, must be listed.

% /usr/etc/netstat -in

If the listing does not include an FDDI network interface, the FDDIXPress software

may not have been installed, may not be conﬁgured, or may not be built into the

operating system. Fix the problem before continuing.

4. Invoke the report display for the ﬁrst FDDIXPress interface:

% /usr/etc/smtstat -I FDDIinterface -s

If an error message displays, look up the error message in Appendix A for

troubleshooting instructions.

5. Verify that the FDDI board sees the ring’s token.

■Type 1 to view the MAC (#1) report.

■Type zto reset the counters and start accumulating. The accumulating total

displays every second.

■Look at the “MAC state” ﬁeld. It should display ACTIVE.

■Watch the “tokens” ﬁeld for 15 seconds. The number should increment rapidly.

If the “tokens” ﬁeld does not increment, refer to “Token Count Not

Incrementing” on page 87.

1 33 MHZ IP12 Processors

FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 4.0

CPU: MIPS R2000A/R3000 Processor Chip Revision: 3.0

On-board serial ports: 2

Data cache size:32 Kbytes

Instruction cache size:32 Kbytes

Main memory size:16 Mbytes

I/O board, slot F: IO3

Integral Ethernet: ec0, version 1

XPI FDDI controller: xpi0, firmware version 1, DAS

Disk drive: unit 1 on SCSI controller 0

Integral SCSI controller 0: Version WD33C93A, revision 9

Iris Audio Processor, rev 3

Graphics board: LG1

FDDI board Network interface name

Verifying the FDDI Connection

6. Verify that the ports are working.

■Type 2 to view the Port (#2) report.

■For a dual ring DAS, the following ﬁelds should have the statuses shown:

Port B Port A

neighbor A B

PCM state ACTIVE ACTIVE

PC withhold NONE NONE

conn state ACTIVE ACTIVE

tx line state THRU THRU

rcv line state ILS ILS

AWRAP entry indicates that the ring is wrapped at this port. This may be due to

an illegal port connection or it may indicate a fault on the ring. If the WRAP is on

port B, the fault domain starts somewhere upstream from this station; if the

WRAP is on port A, the fault is downstream.

A WRAP entry on a DAS connected to a concentrator is functioning normally. If

the ring is wrapped, refer to “Ring Is Wrapped” on page 88.

■For an SAS, the following ﬁelds should have the statuses shown:

Port S

neighbor M

PCM state ACTIVE

PC withhold NONE

conn state ACTIVE

tx line state THRU

rcv line state ILS

AQLS or HLS entry on the transmit line state indicates the connection at this

station is faulty. This may be due to an illegal port connection or it may indicate

a faulty cable or connection. Follow the instructions in “Check Cables and

Connectors” on page 83 to correct the connection.

7. Verify that the optical signal is being received without errors.

■Continue viewing the Port (#2) report.

■Type rto view the totals accumulated since the last reboot.

■Look at the “Link errors: short-term” ﬁeld. The number should be 9 or greater.

If the short-term link error value is less than 9, refer to “Link-Level Errors” on

page 87.

Chapter 2: Configuring FDDIXPress Software

8. Verify that there are no beacon or claim errors.

■Type 3 to view the Ring Mgt (#3) report.

■Type z.

■Monitor the “Claims received” and “Beacons received” areas for 1 minute. The

values should be close to zero for a ring functioning normally. If you observe an

increase of two or more beacons or claims, wait a few minutes and repeat your

observations two more times.

If you consistently see more than two additional claims or beacons during your

monitoring periods, refer to “Too Many Claims or Beacons” on page 88.

9. Verify upstream and downstream neighbors:

■Type 5 to view the Neighbors (#5) report.

■In the bottom section of the display, verify that a nonzero address is listed for

upstream and downstream neighbor stations. Ignore the “old” listings. If one or

both of the neighbors are listed with an address of zero, refer to “Current

Neighbor’s Address Is Zero” on page 93.

■Take note of the names or MAC addresses for the upstream and downstream

neighbors. You will use these in a subsequent step. If the screen display lists

MAC addresses only with no names, the /etc/ethers database has not been set up.

The /etc/ethers database is an optional conﬁguration task explained in “Setting

Up the ethers File (Optional)” on page 43.

10. Type qto quit the report display.

11. Verify that this station can communicate with other stations on the ring.

■Type one of the following commands for each of the station’s neighbors:

%/usr/etc/smtping -c 10 fddinetworkconnectionname

%/usr/etc/smtping -c 10 MACaddress

Names and MAC addresses of other stations on your FDDI ring are listed in the

/etc/ethers ﬁle or ethers database.

■Verify that the message in the next-to-last line of the smtping display indicates

less than 10 percent packet loss. If smtping does not elicit a response from a

station, see “Cannot Communicate With Other Stations” on page 90 for

troubleshooting instructions.

If the ring is losing packets at a rate over 10 percent, see “High Rate of Packet

Loss” on page 90.

Chapter 3

3. Managing Your FDDI Station and Ring

This chapter describes how to manage your station’s connection to the FDDI ring.

Speciﬁcally, the following topics are covered:

•“Verifying the Connection to a Station” on page 53

•“Listing the Stations on the Ring” on page 54

•“Displaying SMT Information for a Remote Station” on page 55

•“Recognizing Faults on the FDDI Ring” on page 57

•“Monitoring a Station’s FDDI Status” on page 60

•“Displaying and Conﬁguring Network Interface Information” on page 67

•“Verifying a Station’s PCM Functionality” on page 71

•“Removing a Station From the FDDI Ring” on page 72

If you are the FDDI ring’s network administrator, you need to devise a way to keep track

of the stations on your FDDI ring to ensure that they are operational and that the network

trafﬁc is ﬂowing freely. How do you determine whether a particular station is on the ring

or whether the ring has wrapped? How do you ﬁnd out what, if anything, is wrong with

a station? This chapter provides some of the information you need to answer these

questions.

Station Management Commands

FDDIXPress provides station management (SMT) commands (listed in Table 3-1) for

managing and monitoring both the FDDI ring and the FDDI connections at each station.

You execute these commands from a shell window.

FDDIXPress includes a graphical tool for maintaining FDDI rings: FDDIVisualyzer. This

application displays a color-coded graphical representation of the FDDI ring, thus

allowing you to see the ring status and view all the station statuses. Unlike the SMT

Chapter 3: Managing Your FDDI Station and Ring

commands that work best for monitoring a single station, FDDIVisualyzer provides

complete ring status at a single glance.

You can use the SMT commands to verify that a station is reachable on the ring, to list all

the stations on the ring, to monitor the status of a particular station’s FDDI connection,

and so forth. Table 3-1 lists the SMT commands.

Something the SMT commands do not do for you is maintain a list of all the stations that

are supposed to be on the ring. In general, SMT information is always current, so only

the currently operating stations can be listed and contacted. However, at times, it is

convenient to have a list of all the stations that should be functioning on a particular ring.

This is a task the network administrator for the FDDI ring should do.

The SMT commands are specialized versions of the IRIX networking commands. For

example, a few of the SMT commands that are similar to the networking commands

include smtstat (like netstat), smtping (like ping), and smtconﬁg (like ifconﬁg). Be sure to use

the SMT commands for the FDDI connections; use the standard network commands for

the Ethernet connections. See Appendix D for the man pages for the SMT commands.

Table 3-1 FDDIXPress (SMT) Commands

Target Utility Description

Ring smtring Lists all the functioning stations on the ring.

Remote station or

local station

smtinfo Shows SMT information for one station on the ring.

smtping Veriﬁes that a particular station on the ring can be reached.

Proves that the local station’s FDDI connection is

functional.

Local station (only) smtconﬁgConﬁgures or displays local station’s FDDI interface

parameters. Superuser access is required to (re)conﬁgure.

smtmaint Sets FDDI PCM line states for debugging local station’s

FDDI connection. Intended for use by FDDI experts only.

Superuser access required.

smtstat Shows SMT statistics and information for local station;

displays selected contents of MIB, organized into six

different reports.

Verifying the Connection to a Station

To see if a station is on the FDDI ring:

% /usr/etc/smtping –I fddiinterface -c 2 host

host is a name in the /etc/ethers ﬁle or a MAC address, and fddiinterface is the network

interface (for example, ipg0,ipg1, and so on, or xpi0,xpi1, and so on).

This command sends a request for a response (analogous to an RSVP). The previous

request is sent twice (–c 2) to a host (either a MAC address or a name deﬁned in

/etc/ethers) on the speciﬁed FDDI network connection. As the host receives each request,

it responds by sending some data. If host is not responding for any reason, smtping will

time out, and the screen display indicates the problem with the message ... 0 packets

received, 100% packet loss.

When a station is on the ring and responds, you see a display similar to Figure 3-1.

Figure 3-1 smtping Display

For additional information about smtping and its options, see smtping(1M).

SMTPING goofy -- 8 data bytes

68 bytes from 0a:00:1b:04:00:07: xid=0 time=10 ms

68 bytes from 0a:00:1b:04:00:07: xid=1 time=10 ms

---- goofy SMTPING Statistics ----

2 packets transmitted, 2 packets received, 0% packet loss

round-trip (ms) min/avg/max = 10/10/10

Chapter 3: Managing Your FDDI Station and Ring

Listing the Stations on the Ring

To list all the functioning stations on the FDDI ring, use the smtring command:

% /usr/etc/smtring

smtring broadcasts to all the stations and concentrators on the ring, waits 60 seconds to

collect all responses, and then lists the responding stations in logical order. The local

station is at the top of the list (unless a speciﬁc host has been speciﬁed in the command

line). Each line shows three items of information, described from left to right:

•the station ID for the station listed on the right (under the label MAC Address)

•the station’s upstream neighbor

•the station’s name (or, if the ethers database is not maintained, the MAC address in

canonical order)

Figure 3-2 shows an example of responses. In this example, the smtring command has

been invoked from a station named goofy whose MAC address is a:0:1b:4:0:7 and whose

upstream neighbor is mickey. From this listing you can construct a ring, as shown in

Figure 3-3.

Figure 3-2 smtring Display

In Figure 3-2, goofy’s station ID is the default one created by the FDDIXPress SMT

daemon from the MAC address.

Logical FDDI Ring Dump(4 nodes)

Station ID Upstream Nbr MAC Address

00:00:0a:00:1b:04:00:07 mickey.disney.com -> fddi-goofy.disney.com

00:00:0a:00:1b:d6:b5:10 fddi-goofy.disney.com -> donald.disney.com

00:00:0a:00:1b:04:1c:0f donald.disney.com -> gate-minnie.disney.com

00:00:0a:00:1b:05:62:c4 gate-minnie.disney.com -> mickey.disney.com

Displaying SMT Information for a Remote Station

Figure 3-3 Ring Created From smtring Display

You can use the –Ioption to smtring if you have more than one FDDI controller board

installed (for example, xpi0 and xpi1) and want to examine the state of the second board’s

ring. To do this, use:

% /usr/etc/smtring -I interfacename

Displaying SMT Information for a Remote Station

With the smtinfo command, you can see SMT information for a speciﬁed remote host,

including station conﬁguration and operation information and supported SMT versions.

Display the SMT Version

To display the SMT version for a remote host (for example, 0a:00:1b:04:00:07 or goofy), use:

% /usr/etc/smtinfo host

host is a name in the /etc/ethers ﬁle or a MAC address.

The output looks like the following line and shows the host goofy is currently using SMT

version 2, and can communicate with stations using SMT versions 1 or 2.

goofy uses SMT version 2 (supported versions: 1-2)

Unused

secondary

ring

fddi-goofy

donald

gate-minnie

mickey

Chapter 3: Managing Your FDDI Station and Ring

Display a Station’s Conﬁguration Information

To see station conﬁguration information for a remote host (for example, 0a:00:1b:04:00:07

or goofy), use:

% /usr/etc/smtinfo -c host

host is a name in the /etc/ethers ﬁle or a MAC address.

An example of smtinfo -c output is shown in Figure 3-4 and the information is explained

in Table 3-2.

Figure 3-4 smtinfo -c Display

Msg Timestamp: 659039603.045009

Station Dscrpt: 1 MAC, 0 masters, 2 nonmaster STATION

Supported Vers: v1-v1, opvers=1

Station States: topology=ROOTSTA, dupa=0

Station Policy: conf=NONE, conn=REJECT(MM)

MAC3 Nbrs: una=0a:00:1b:05:62:c4, dna=0a:00:1b:d6:b5:10

Path Descriptors: port1: pc=B state=ACTIVE pc_nbr=A remotemac=0 conn_rid=2

port2: pc=A state=ACTIVE pc_nbr=B remotemac=1 conn_rid=3

mac3: addr=0a:00:1b:04:00:07 conn_rid=1

Recognizing Faults on the FDDI Ring

If the host has an additional FDDI board installed and you want to see conﬁguration

information about that interface (for example, ipg1), use:

% /usr/etc/smtinfo -c -I interfacename host

For more information about smtinfo, see smtinfo(1).

Recognizing Faults on the FDDI Ring

The network administrator for an FDDI ring needs to monitor the ring and recognize

faults when they occur. One type of fault, for example, occurs when a station on the

network goes down. The SMT modules within the FDDI stations isolate the fault and

wrap to the secondary ring. If an optical bypass switch is installed on the dysfunctional

station, the switch causes the ring to bypass the station and no wraps occur. The network

continues to function. Figure 3-5 shows an example of wrapped ring when one station

goes down.

Table 3-2 Information Displayed by smtinfo -c

Item Description

Msg Timestamp This information is not useable.

Station Dscrpt Description of the station

Supported Vers SMT versions supported and currently used

Station States Station’s states.

dupa=0 indicates that there are no duplicate MAC addresses.

ROOTSTA indicates that the station is connected to a dual

ring, not a concentrator.

MAC3 Nbrs Upstream (una) and downstream (dna) neighbor addresses.

Path Descriptors Descriptions of the port or ports and the interface’s MAC

address in canonical order.

Chapter 3: Managing Your FDDI Station and Ring

Figure 3-5 Fault Isolation and Ring Wrap

As you can see in Figure 3-5, when one station experiences an error, only that station is

out of the loop. It is also possible for one port on one station to malfunction (as illustrated

by fault 1 in Figure 3-6), in which case the ring wraps, but no station is out of the loop.

Trafﬁc on the network continues as usual. Notice that when a station fails (both ports are

off the ring), the wraps do not occur on the faulty port, but on its two neighbor ports.

DAS

wrap on port A

wrap on port B

DAS

fault

not in use

in use

Recognizing Faults on the FDDI Ring

If two or more stations go down, the network may become fragmented into a number of

smaller loops, and users may not be able to access stations that have become isolated

onto a different loop. It is important to locate the faults and make the necessary repairs

as quickly as possible. Figure 3-6 shows a fragmented network with two stations down.

Figure 3-6 Fragmented Ring

DAS

wrap on port A

wrap on port B

DAS

fault

not in use

in use

Chapter 3: Managing Your FDDI Station and Ring

How do you know there is a fault on the ring? One way is to use smtping at each station

to verify that each one responds. Another way is to use smtring to create a complete list,

then verify that all known stations appear on the list. The easiest method is to use the

FDDIVisualyzer product, which graphically indicates faults on the ring. In all of these

instances, an up-to-date, complete list of all stations that are physically attached to the

ring is vital. The network administrator should maintain this list. In many cases, once a

station fails, it is not possible to communicate with it remotely over the ring. Its failure is

deduced from its absence or lack of response. To debug the faulty station, log on to that

station through a second network connection or at the station.

You can log on to any station and use smtstat to display status information about that

station’s FDDI interfaces. This command does not access a station remotely; rather, it

displays information about the local host, even when the host is not functioning on the

ring. A step-by-step veriﬁcation process is described in “Verifying the FDDI

Connection” on page 47.

Monitoring a Station’s FDDI Status

You can display and monitor the status of a station’s FDDI connection by logging on to

the station and entering the following command:

% /usr/etc/smtstat

The smtstat report is shown in Figure 3-7 and a listing of its columns follows. Table 3-3

explains the entries for the columns in more detail.

Figure 3-7 smtstat Display

SM_DAS: Station ID=00-00-50-00-d8-20-00-e0 SMT Version 1 (1-1)

Name Address MAC port nbr PCM tls rls flags

ipg0 0a:00:1b:04:00:07 ACT B A ACTIVE THRU ILS <LS,RC,JOIN,THRU,RNGOP>

A B ACTIVE THRU ILS <LS,RC,JOIN,THRU>

SM_SAS: Station ID=00-00-50-00-d8-20-88-40 SMT Version 1 (1-1)

Name Address MAC port nbr PCM tls rls flags

xpi0 0a:00:1b:04:11:02 ACT S M ACTIVE THRU ILS <LS,RC,JOIN,THRU,RNGOP>

For a DAS

For an SAS

Monitoring a Station’s FDDI Status

In the DAS display, the ﬁrst line contains the following information:

•the type of station (SM_DAS is a single MAC, dual-attachment station)

•the SMT station ID

•supported SMT versions

The second line contains column headings while subsequent lines display the

information:

•Name: names of FDDI interfaces (for example, ipg0,xpi0)

•Address: MAC address (in canonical order) associated with each interface

•MAC: status of the MAC (for example, ACT for active is normal)

•port: ports present for each MAC

•nbr: port on neighbor station to which each local port is connected (A-to-B, B-to-A,

and S-to-M are normal)

•PCM: status of each port’s physical connection management (PCM) where ACTIVE

is normal

•tls: transmit line state for each port (THRU is normal)

•rls: receive line state for each port (ILS is normal)

•ﬂags: ﬂags for each port (RNGOP,LS,RC,JOIN,THRU, and OBS are normal)

By monitoring SMT status, you can see the connection state, transmitting and receiving

line states, and the ﬂags indicating the ring state. In the smtstat display shown in

Figure 3-7, the primary ring is operating (RNGOP), its transmit line is working (THRU), its

receive line is idle (ILS), and the secondary ring is functional (LS,RC,JOIN) but not

operating. If the ring were wrapped at this station, you would see a WRAP indication.

Table 3-3 smtstat Report Fields

Field Possible Entries Description

MAC MAC status

ACT active

CON connect

OFF MAC could not be read by software

Chapter 3: Managing Your FDDI Station and Ring

port local port connection type

Areceive on SAS, or receive for primary ring and transmit for

secondary ring on DAS

Btransmit on SAS, or transmit for primary ring and receive

for secondary ring on DAS

Mmaster

Sslave

? no connection

nbr same as port neighbor port connection type

PCM physical connection management state

ACTIVE active

CONNECT connected

JOINED joined

tls, rls transmit and receive line states

ALS active line state

ILS idle line state

QLS quiet line state

HLS halt line state

MLS master line state

THRU through connection (the ring is working at this station)

WRAP port is wrapped, which can mean that the ring is wrapped

at this station, or (for a DAS board attached to a

concentrator) that the port is wrapped to support an SAS

connection

flags special ﬂags associated with station’s ports

LS line state desirable

Table 3-3 (continued) smtstat Report Fields

Field Possible Entries Description

Monitoring a Station’s FDDI Status

Display Kernel and SMT Daemon Statistics

By using the –v(verbose) option with smtstat, you can display additional statistics,

including the following:

•Physical connection management (PCM) status.

•A log showing line states for PHY0 (usually port B).

•Kernel statistics, described in Table 3-4. These statistics are reset to zero each time

the system is booted. Of the kernel statistics, only the following items normally

have steadily increasing values: frame_ct,A-bit,C-bit, and tok_ct.

RC ring connected; neighbor sending symbols

JOIN ring joined; neighbor handshaking ﬁnished.

RNGOP ring in operation

OBS optical bypass switch in use

CON-

Undesirable

undesirable SMT connection

CON-Illegal illegal SMT connection

WA withhold Port A as a back-up link

WAT withhold Port A in Tree mode

Table 3-4 smtstat -v Kernel Statistics

Field Description

Left column

frame_ct Frames seen

A-bit Address-recognized bits seen

rngop Times ring transitioned from nonoperational to operational

tkerr Duplicate tokens seen

Table 3-3 (continued) smtstat Report Fields

Field Possible Entries Description

Chapter 3: Managing Your FDDI Station and Ring

tvxexp Times valid-transmission-timer (TVX) expired

myclm Station’s own claims seen

mybec Station’s own beacons seen

eovf Elasticity buffer overﬂows experienced

tx_under Transmit FIFO underﬂows experienced

ﬂsh Frames ﬂushed

tot_junk Frames discarded

error Errors detected by MAC

rx_ovf Receive FIFO overﬂows experienced

Middle column

tok_ct Tokens seen

C-bit Frame-copied bits seen

rngbroke Times ring has become nonoperational.

clm Claims seen

trtexp Times token-rotation-timer (TRT) expired

loclm Claims seen that were lower than this station’s

otrbec Other stations’ beacons

noise Noise events from PMD and PHY

err_ct Frames seen with bad checksums (CRCs)

abort Frames aborted

junk_void Badly formatted void frames

shorterr Frames seen that were too short

buf_ovf Buffer overﬂows experienced

Right column

Table 3-4 (continued) smtstat -v Kernel Statistics

Field Description

Monitoring a Station’s FDDI Status

Using –vv (extra verbose) displays even more information, including SMT daemon

(smtd) statistics. The report displays

•additional station information

•physical connection management (PCM) status

•line state log for PHY0 (usually port B)

•MAC statistics and conﬁguration information (referred to as a MAC dump)

•PHY1 (usually port A) conﬁguration information

Display SMT Information (MIB)

To monitor continually the FDDI activity of a conﬁgured interface on the local system,

use:

% /usr/etc/smtstat –s -I fddiinterface

fddiinterface is the interface (for example, ipg0,ipg1,xpi0,xpi3).

E-bit Error-detected bits seen

multda Frames seen with station’s address and A bit already set

bec Beacons seen

tkiss Tokens issued

hiclm Claims seen that were higher than mine

dup_mac Times duplicate MAC addresses detected

xmtabt Transmission aborts experienced

lost_ct Badly formatted frames seen

miss Frames seen but unable to copy

junk_bec Badly formatted beacons seen

longerr Frames seen that were too long

Table 3-4 (continued) smtstat -v Kernel Statistics

Field Description

Chapter 3: Managing Your FDDI Station and Ring

The output of this command produces the following six smtstat reports.

•MAC status

•port status

•ring management status

•conﬁguration information

•neighbor information

•miscellaneous SMT information

This output requires a shell window or a terminal at least 80 columns wide by 24 lines

high. When the window is too small, the display is not usable. Make your display area at

least this size before invoking the command.

The reports are viewed one at a time. The top of each report displays the report name,

date, and time. At the bottom of each report is a menu line listing all the available reports,

as shown in Figure 3-8.

Figure 3-8 smtstat -s Display: General Report Format

5: Neighbor Information -- Mar 24 15:46:19

1:MAC 2:Port 3:Ring Mgt 4:Config Mgt 5:Neighbors 6:SMT DZR:Mode

(all the Neighbor report information)

Menu Line

Displaying and Configuring Network Interface Information

The following user interface allows you to manipulate the reports:

•To display a different report, type the report’s number. The numbers are displayed

in the menu line on the bottom of the screen. For example, to view the SMT report,

type 6.

•To quit, type qor Ctrl+c.

•To refresh the screen, type Ctrl+l.

•To change the time interval for the report statistics display, press one of the these

keys:

rEach second, shows totals accumulated since last reboot.

dResets ﬁelds to zero every second, and each second shows totals

accumulated within that last second.

zResets ﬁelds to zero when zis pressed, and every second displays

the accumulating totals.

For a description of all the ﬁelds in each report, see Appendix B, “smtstat Reports.” For

a complete deﬁnition of each ﬁeld, refer to the ANSI standard entitled ANSI FDDI Station

Management (SMT). For information about command usage, refer to the smtstat(1M) man

page.

Displaying and Conﬁguring Network Interface Information

As network administrator, you may need to display or temporarily alter a station’s

network interface parameters. The command smtconﬁg allows you to do this.

Display the Conﬁguration

To display the current conﬁguration of the FDDI interface, follow these steps:

1. Use smtstat to determine the name of the FDDI network interface(s) on your station.

The FDDI interface name is listed under the column heading Name. Examples: ipg0,

xpi0.

2. Use smtconﬁg with the name of the interface discovered in the ﬁrst step:

% /usr/etc/smtconfig interfacename

Chapter 3: Managing Your FDDI Station and Ring

Sample output from smtconﬁg is shown in Figure 3-9. A description of the ﬁelds follows,

starting with the ﬁrst item on the left of the top line and moving right.

Figure 3-9 smtconﬁg Display

•First line:

–The interface name.

–Flags that are enabled, with the following meanings:

•Second line:

–The address family conﬁgured for this interface: inet is the default.

–The address assigned to this network interface: The default is the IP address

associated with the hostname in the /etc/hosts ﬁle.

–The network mask (netmask) used for the IP subnetwork: The default is a value

that, when applied, implements no mask.

–The address used for broadcasting to all stations on the ring: The default is an IP

address where the host portion is all ones.

UP The network interface is enabled and should be functioning. When UP is

displayed, RUNNING should also be displayed.

BROADCAST A broadcast address is set.

DEBUG Debugging is enabled.

NOTRAILERS The link layer encapsulation does not use trailers.

RUNNING The driver is running and should be functional. This ﬂag and UP should

always appear together.

NOARP The Address Resolution Protocol is not enabled.

MULTICAST A multicast address is set.

CKSUM The driver is generating checksums for transmitted packets.

OBS An optical bypass switch is present.

xpi0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,OBS>

inet 187.51.80.4 netmask 0xffffff00 broadcast 187.51.80.255

Displaying and Configuring Network Interface Information

Change the Conﬁguration

As superuser, you can enable and disable the FDDI interface or (re)conﬁgure the FDDI

interface parameters manually using the smtconﬁg(1M) command. Most of the time, it is

not necessary to set interface parameters manually using smtconﬁg because FDDI is

conﬁgured automatically with default settings (as described in Table 2-3) when the

system is started or rebooted.

Note: Changes made with smtconﬁg are not saved; at reboot they return to their default

settings (or the /etc/conﬁg/ifconﬁg-#.options and /etc/conﬁg/netif.options ﬁles). To change the

conﬁguration so the changes survive rebooting, follow the instructions in Chapter 2 or in

IRIX Admin: Networking and Mail.

To change the conﬁguration of a network interface, perform the following steps:

1. Become superuser:

% /sbin/su

Password: thepassword

2. Use smtstat to determine the name of the FDDI network interface(s) on your station.

The FDDI interface name is listed under the column heading Name. Examples of

FDDI interfaces include ipg0,ipg1,xpi0,xpi3.

3. Use smtconﬁgwith one of the following formats.

Superuser can use the smtconﬁg command to change the FDDI operational

parameters listed below, in much the same manner as ifconﬁg. For information

about the creation and purpose of these parameters, refer to IRIX Admin: Networking

and Mail.

•Enable or disable the interface:

# /usr/etc/smtconfig interfacename up

# /usr/etc/smtconfig interfacename down

•Set a network mask value for an IP subnetwork:

# /usr/etc/smtconfig interfacename netmask value_or_name

•Change the address used for broadcasting:

# /usr/etc/smtconfig interfacename broadcast address

Chapter 3: Managing Your FDDI Station and Ring

•Enable or disable driver debugging messages:

# /usr/etc/smtconfig interfacename debug

# /usr/etc/smtconfig interfacename -debug

•Enable or disable Address Resolution Protocol. ARP is enabled when there is no

ﬂag about ARP:

# /usr/etc/smtconfig interfacename arp

# /usr/etc/smtconfig interfacename -arp

•Set the routing metric used by the route daemon (routed):

# /usr/etc/smtconfig interfacename metric digit

•Change the IP address for this interface:

# /usr/etc/smtconfig interfacename IPaddress

•Select a different interface to be the primary network interface for this station:

# /usr/etc/smtconfig interfacename primary

Examples

This section describes some scenarios in which the different smtconﬁg command options

can be used.

•Before performing computer maintenance work that will require rebooting a

station, disable the FDDI network interface, xpi0, with the command:

# /usr/etc/smtconfig xpi0 down

•On a router with an FDDI interface named ipg0, you want to decrease the number of

packets going through the station enroute to other networks. One way to do this is

by advertising the route as less favorable. Use this command:

# /usr/etc/smtconfig ipg0 metric 5

For information about creating netmasks, route metrics, broadcast addresses, and IP

addresses, or about altering network interface conﬁgurations, see “Changing Settings for

the Operational Parameters” in Chapter 2, the smtconﬁg(1M) man page, or IRIX Admin:

Networking and Mail.

Verifying a Station’s PCM Functionality

The smtmaint command allows you, as superuser, to set the Physical Connection

Management (PCM) line state for each PHY on a station’s FDDI board. An SAS has one

PHY (PHY0); a DAS has two PHYs (in most cases, PHY0 for port B and PHY1 for port A).

Use smtmaint judiciously and only if you are an FDDI expert. Setting a line state can make

the ring nonfunctional.

You can set these six line states:

QLS PHY sends a continuous stream of Quiet symbols so the transceiver

emits no signal.

ILS PHY sends a continuous stream of Idle symbols; this is a normal

condition between transmissions.

HLS PHY sends a continuous stream of Halt symbols; this forces a break in

the ring.

MLS PHY sends a continuous stream of alternating Halt and Quiet symbols;

this is used to propagate a trace along the ring.

ALS PHY functions normally; it is Active and incorporated into the ring.

-t PHY enters PC_TRACE state (trace function) attempting to recover the

ring from a stuck beacon condition.

To change a line state, follow these steps:

1. Become superuser:

% /sbin/su

Password: thepassword

2. Use smtstat to discover the name of the FDDI network interface on your station. The

FDDI interface name is listed under the column heading Name. Examples of FDDI

interfaces include ipg0,ipg1,xpi0.

3. Use this command to change the line state:

# /usr/etc/smtmaint interfacename 0or1 linestate

0or1 identiﬁes the PHY (port) and linestate is one of the line states listed above (for

example, ALS, -t, or ILS).

Chapter 3: Managing Your FDDI Station and Ring

Removing a Station From the FDDI Ring

When an FDDI station is removed from the ring, the SMT modules reconﬁgure the ring.

If the removal is done in a way that makes it impossible for the optical signal to complete

its loop around the ring, the ring wraps. Generally, it is best to avoid wrapped rings for

long periods. The procedures described in this section describe how to avoid or minimize

a wrapped ring when removing a station from the ring.

The situations listed below constitute taking an FDDI station off the ring; any of these has

the potential to cause the FDDI ring to wrap (sometimes for a very short period of time).

•Rebooting a system, which includes any of the following: invoking the reboot or init

commands, pressing the station’s reboot button, and crashing the station’s system.

A crash usually results in an automatic reboot.

•Hanging the station’s system (usually due to software failures).

•Shutting down the station’s system, which includes using any of the following

commands: shutdown,reboot,halt,init 0.

•Removing power from the station by pressing the power switch or disconnecting

the power cable.

•Disconnecting the station’s FDDI cables.

•Disabling the FDDI network interface, which includes invoking any of the

following commands with the down or stop option: smtconﬁg,ifconﬁg,

/etc/init.d/network.

•Removing an optical bypass switch from a station.

The procedure for safely removing a station from the ring differs, depending on three

factors:

•whether the removal is temporary or permanent

•whether the station is directly attached to the dual ring (DAS) or is attached to a

concentrator (SAS or dual-homed DAS)

•whether an optical bypass switch is present or not (applies only to a DAS attached

directly to the dual ring)

Removing a Station From the FDDI Ring

Temporarily Disable Any Station’s FDDI Interface

To temporarily disable any FDDI interface for a short period of time, use the smtconﬁg

command described in “Change the Conﬁguration” on page 69.

If the station is a DAS, is not attached to a concentrator, and does not have an optical

bypass switch, the ring will wrap when the FDDI network interface is disabled.

However, this is usually not a problem for a short period of time.

Remove a Device Attached to a Concentrator

Four types of devices can be attached to concentrators: single-attachment stations and

concentrators (SAS and SAC) and dual-homed, dual-attachment devices (DAS and

DAC). It is simple to remove any of these from the ring. Because the concentrator

maintains the integrity of the ring, it is not important whether the station will be out of

the ring for a long or short period of time. You need only decide whether the removal is

temporary or permanent.

Temporarily Removing a Device

To temporarily remove a device attached to the ring through a concentrator, perform the

following steps:

1. Become superuser and shut down the system. As soon as you do this, the station is

out of the ring. The command lines below are one way of doing this:

%/sbin/su

Password: thepassword

#/etc/shutdown

2. You can now perform system maintenance or physically disconnect the station from

ring (actually, from the concentrator). The concentrator will maintain the integrity

of the ring. However, since the station’s identity as an FDDI station remains in the

system ﬁles, the station should be returned to the ring at some point. When

reinserted into the ring, the station does not have to be reconnected at the same

location.

Chapter 3: Managing Your FDDI Station and Ring

Permanently Removing a Device

To permanently remove a concentrator-attached device from the ring, do the following:

1. Become superuser and disable the FDDI interface using these commands:

% /sbin/su

Password: thepassword

# /usr/etc/smtconfig interfacename down

2. Edit the ﬁles described in “Complete and Complex Conﬁguration Information” on

page 28 to remove or comment out the lines referring to this station. One or more of

the following ﬁles may need to be edited: /etc/hosts,/etc/ethers,/etc/conﬁg/netif.options.

3. Shut down the system using the shutdown or halt command.

4. Power off the station by pressing its power switch.

5. Disconnect the FDDI cable(s).

6. At this point, you can move the workstation or server. If you ever decide to reinsert

this station into this ring, you will need to reconﬁgure it.

Removing a DAS That Has an Optical Bypass Switch

Removing a DAS that has an optical bypass switch is simple. Because the optical bypass

switch maintains the integrity of the ring, it is not important whether the station is out of

the ring for a long or short period of time. You need only decide whether the removal is

temporary or permanent.

As long as you leave the optical bypass switch in place and move only the station, the

ring will not wrap.

Removing a Station From the FDDI Ring

Temporarily Removing a DAS

To temporarily take a DAS with an optical bypass switch out of its ring follow these steps.

1. Become superuser and shut down the system. For example:

% /sbin/su

Password: thepassword

# /etc/shutdown

2. Disconnect the optical bypass switch’s DC power cable from the FDDI board.

3. If you need to, power off the station by pressing the station’s power switch, and

disconnect the station’s FDDI cable(s). Do not disconnect the connections between

the ring and the optical bypass switch.

4. You can now perform system maintenance or physically disconnect the station from

ring. The optical bypass switch maintains the integrity of the ring. However, since

the station’s identity as an FDDI station remains in the system ﬁles, the station

should be returned to the ring at some point. When reinserted into the ring, the

station does not have to be reconnected at the same location.

Permanently Removing a DAS

To permanently remove a DAS with an optical bypass switch from the ring, perform the

steps below:

1. Become superuser and disable the FDDI interface with these commands:

% /sbin/su

Password: thepassword

# /usr/etc/smtconfig interfacename down

2. Edit the conﬁguration ﬁles to remove or comment out the lines referring to this

station. One or more of the following ﬁles may need to be edited: /etc/hosts,

/etc/ethers,/etc/conﬁg/netif.options.

3. Shut down the system using the shutdown or halt command.

4. Power off the station by pressing its power switch.

5. Disconnect the optical bypass switch’s DC power cable from the FDDI board.

6. Disconnect the FDDI board’s cables from the optical bypass switch.

7. At this point, you can move the workstation or server. If you ever want to insert this

station into this ring, you need to reconﬁgure the station. Another station can be

attached to the optical bypass switch at any time.

Chapter 3: Managing Your FDDI Station and Ring

Remove a DAS Without an Optical Bypass Switch

Removing a DAS that does not have an optical bypass switch always disrupts the ring;

removal of a station causes the ring to wrap in conﬁgurations where the secondary ring

is a backup. There is no way to avoid this; hence, your primary concern is the length of

time the ring will be disrupted. After you remove the station, you need to do one of the

following as soon as possible to reestablish the integrity of the ring:

•Insert the same or another station at the location.

•Insert an optical bypass switch at the location.

•Patch the ring (for example, by inserting a barrel connector or section of ﬁber optic

cable at the location).

Temporarily Removing a DAS

To temporarily remove a DAS without an optical bypass switch from its ring, follow the

instructions below.

Note: This procedure causes the ring to wrap.

1. Become superuser and shut down the system. For example:

% /sbin/su

Password: thepassword

# /etc/shutdown

2. Power off the station by pressing the station’s power switch, and disconnect the

station’s FDDI cable(s).

3. As soon as possible, do something to reestablish the ring’s integrity. A list of

possible actions is provided at the beginning of this section.

4. You can now perform system maintenance or physically move the station. Since the

removed station’s identity as an FDDI station remains in the system ﬁles, the station

should be returned to the ring at some point. When reinserted into the ring, the

station does not have to be reconnected at the same location.

Removing a Station From the FDDI Ring

Permanently Removing a DAS

To permanently remove a DAS station without an optical bypass switch from the ring,

follow the instructions below.

Note: The ring will wrap as soon as you disable the FDDI interface.

1. Become superuser:

% /sbin/su

Password: thepassword

2. Edit the conﬁguration ﬁles to remove or comment out the lines referring to this

station. One or more of the following ﬁles may need to be edited: /etc/hosts,

/etc/ethers,/etc/conﬁg/netif.options.

3. Disable the FDDI interface:

# /usr/etc/smtconfig interfacename down

4. Shut down the system using the shutdown or halt command.

5. Power off the station by pressing its power switch.

6. Disconnect the station’s FDDI cable(s).

7. As soon as possible, do something to reestablish the ring’s integrity. A list of

possible actions is provided in the beginning of this section.

8. At this point, you can move the workstation or server. If you want to reinsert this

station into this ring, you will need to reconﬁgure the station.

For more information, see the smtconﬁg(1M), halt(1M), and shutdown(1M) man pages

or ”Change the Conﬁguration” in this chapter.

Chapter 3: Managing Your FDDI Station and Ring

Removing FDDIXPress

To permanently remove an FDDIXPress board and software from a station, follow the

steps below:

1. Use inst to remove the FDDIXPress software:

# /usr/sbin/inst

...

Inst> remove FDDIXPress

...

Inst> quit

2. Follow the set of instructions in “Removing a Station From the FDDI Ring” on

page 72 that is appropriate for your conﬁguration.

3. Once the power is off, remove the board.

The board’s installation guide or installation instructions provides hardware details

that are useful for removing the board.

4. When the FDDI board has been removed, press the power switch to turn the system

on.

5. Answer the questions on the terminal to restart the system.

6. Answer yes to the prompt to rebuild the operating system. This step removes the

FDDI driver from the operating system (kernel).

Automatically reconfigure the operating system (y or n)? y

7. Reboot the system to start using the new operating system.

Chapter 4

4. Troubleshooting

This chapter describes what to do when your FDDI network connection has problems.

The chapter describes the following topics:

•“General Advice” on page 79

•“Checking Physical Connections” on page 80

•“Status Indicators and Symptoms” on page 87

General Advice

When you experience difﬁculty with the FDDI network connection at a particular

station, you can:

1. Check the physical connections at the station as detailed in “Checking Physical

Connections.”

2. Search or read the /var/adm/SYSLOG ﬁle and console window for error messages. If

you ﬁnd any FDDI driver or SMT messages, read about them in Appendix A.

3. Use the SMT commands (or FDDIVisualyzer) to identify problematic status

indicators, and if you ﬁnd any, read about them in “Status Indicators and

Symptoms” on page 87.

The following sections will help you with each of these suggested steps.

Chapter 4: Troubleshooting

Checking Physical Connections

Check each of the following, using the step-by-step instructions:

•“Recognition of Board by Software” on page 80

•“Check Cables and Connectors” on page 83

•“Cable Lengths” on page 86

Recognition of Board by Software

Complete inability to access the FDDI ring may indicate that the board and software are

not communicating. Follow the instructions below to ﬁgure out why.

1. In a shell window, type this command:

% /sbin/hinv

When a board is listed by hinv,, this does not mean that the board and driver are

functional; it means that the operating system was able to recognize the board. For

an explanation of the hinv screen display, see “Verifying the FDDI Connection” on

page 47 or the hinv(1M) man page.

2. If hinv displays an entry for the FDDI hardware, the operating system is recognizing

the board. The problem may be bad cable connections or improperly conﬁgured

software. First, follow one of the sets of instructions below, then (if necessary)

follow the instructions in “Check Cables and Connectors.”

If hinv does not display an entry for the FDDI hardware, the operating system did

not ﬁnd the FDDI board the last time the station was booted. The problem may be

an incompatible operating system, or a loose or dysfunctional board. First, follow

the instructions below to verify the board, then follow the instructions in “FDDI

Connection Has Not Been Functional Since Last Boot” on page 81.

Verify the Board

Verify that the LEDs on the FDDI board indicate that the board is receiving power. If the

LEDs indicate that there is no power to the FDDI board or that the board is not

operational, follow the instructions in the board’s hardware manual to troubleshoot the

problem. It is possible that the board is not seated ﬁrmly into its connection to the system,

or that the board is dysfunctional.

If you reinstall the board, take extra precautions to seat the FDDI board ﬁrmly.

Checking Physical Connections

FDDI Connection Has Not Been Functional Since Last Boot

If the FDDI connection has not been working since the last time the station was booted

or if this is an initial installation of an FDDI product, one or more of the following could

be occurring:

•The operating system installed on the station is not compatible with the FDDI board

installed.

•The operating system has not been rebuilt to include the driver for the board.

•The network interface for the board has not been conﬁgured properly.

Follow the instructions below to determine the cause of the problem:

1. Verify that the installed IRIX operating system (oeo1) and FDDIXPress software are

the correct versions by doing the following:

■Determine the correct versions. The FDDIXPress release notes indicate the

correct IRIX and FDDIXPress versions for your FDDI board.

■Use the versions command (shown below) to display the installed release

identiﬁcations (versions). If the version is not correct, install the correct version.

Then invoke hinv.

% /usr/sbin/versions eoe1

eoe1 date Execution Only Environment 1, version

% /usr/sbin/versions FDDIXPress

FDDIXPress date FDDIXPress release Option

2. Use the netstat command, as shown below, to display the currently conﬁgured

network interfaces. If the FDDI interface is not displayed, continue to the next step.

If the interface is displayed, but the conﬁguration is incorrect, follow the

instructions in “Conﬁgure the Station’s Network Interfaces” on page 33 to

reconﬁgure it.

% /usr/etc/netstat -ina

3. Verify the FDDI entries in the /etc/conﬁg/netif.options ﬁle. For example, the network

interface may be misspelled.

4. Use /etc/autoconﬁg to rebuild the operating system to include the FDDIXPress driver.

Then, reboot the system to start using the new operating system. Finally, invoke

netstat -ina again. If the FDDI interface is still missing, contact the Silicon Graphics

Technical Assistance Center.

Chapter 4: Troubleshooting

FDDI Connection Has Been Functional In the Recent Past

If new software (operating system, FDDIXPress, or another network communications

software) has been installed since the FDDI connection was last functional, the problem

is probably incompatible software. Verify that the software you last installed supports

the FDDI board installed in the station.

If the FDDI connection has been functional after the last new software was installed, the

problem is probably the board. The board may have become loosened from its

connection to the system or it may be dysfunctional.

Follow these steps to resolve the problem:

1. Verify that the LEDs on the FDDI board indicate that the board is receiving power. If

the LEDs indicate that there is no power to the FDDI board or that the board is

dysfunctional, follow the instructions in the board’s hardware manual to

troubleshoot the problem. Otherwise, continue.

2. Ensure that the system is using the operating system that was built most recently.

Use the /etc/autoconﬁg command to rebuild the operating system, then reboot to start

using it. During the reboot, begin step 3.

3. Watch the messages on the terminal during restart to verify that each network

interface is conﬁgured correctly. The messages should look similar to these

examples:

Configuring xpi0 as mickey

Configuring ec0 as gate-mickey

If the FDDI driver is not mentioned on the terminal during startup, there is a

problem with the software. Continue to step 4.

If a startup terminal message indicates that the hardware is missing, as in the

following example, start again at the beginning of “Recognition of Board by

Software” on page 80.

xpi0: missing

Checking Physical Connections

4. Use the netstat command to display the currently conﬁgured network interfaces. If

the interface is displayed, but the conﬁguration is incorrect, follow the instructions

in section “Conﬁgure the Station’s Network Interfaces” on page 33 to reconﬁgure it.

% /usr/etc/netstat -in

The /etc/conﬁg/netif.options ﬁle may have an incorrect entry (for example, a

misspelled network interface); verify all ﬁle contents carefully.

If the FDDI interface does not display, it is possible the board or software is

dysfunctional. Contact the Silicon Graphics Technical Assistance Center.

Check Cables and Connectors

A wrap on an A or B port, a high level of link-layer errors, or a stagnant token count can

indicate a faulty cable, a loose or damaged connection, or a dirty cable end. The

problematic cable or connection can be found at or near the station where the error is

occurring.

Connections

At each cable connection, along the entire length of the ring where there is a problem,

verify two things:

•Each connection is tight. Many connectors must snap or click together to be tight.

(Remember to verify the connections at each station’s I/O panel.)

•Each connection is correct.

–For cable-to-cable connections, the labels on the two cable connections must

pair as a valid (V) connection, as summarized in Figure 4-1, where U indicates

that the connection is undesirable, invalid indicates that it is invalid, and V

indicates it is valid. Figure 4-2 illustrates valid connections for a typical ring.

Chapter 4: Troubleshooting

Figure 4-1 Cable-to-Cable Connections

–For cable-to-station connections, the labels on the connectors must match (for

example, A-to-A or red-to-red, not B-to-A or red-to-blue). (Remember to verify

the connections at each station’s I/O panel. The cable’s label must match the

port where it is connected.)

Figure 4-2 Correct Cable Connections

ABS M

AUVU V

BVUU V

SUUV V

MV V V invalid

DAS

Cable-to-cable

Cable-to-

station

Verify

Checking Physical Connections

Dirty Fiber End

The ends of ﬁber optic cable can become dirty and interfere with the transmission of the

optical signal. Common pollutants are oil (from being touched by human ﬁngers) and

dust (from being left uncapped).

Note: Do not touch the ends of ﬁber optic cable. Do not leave the ﬁber optic cable

uncapped when it is not connected. The cap prevents dust and other pollutants from

collecting on the exposed ﬁber optic material.

•Gently clean cable ends with 96% isopropyl alcohol and a non-lint producing soft

material, or an alcohol-wipe product.

Faulty Cable

Fiber optic cable can become damaged if excessively bent (or coiled), twisted, or sharply

struck. Replace suspect cables with functional cables.

When no replacement cable is available, use a small, powerful ﬂashlight (as described in

the bulleted steps below) to verify that the light signal passes through the cable. This test

identiﬁes broken or incorrectly built cables, but cannot identify borderline conditions.

1. Identify the direction that light travels within each optical ﬁber line of the suspect

cable. (FDDI MIC connectors and cable contain two optical ﬁbers.)

Fiber optic material is designed somewhat like a funnel. Light travels in only one

direction: from the wide end to the narrow end. Some cable manufacturers label

each ﬁber with arrows. Some cables have connectors constructed so that the input

end of each ﬁber is indicated by the connector’s cover; the wider portion of the

cover (the funnel’s mouth) indicates the input end, as shown in Figure 4-3.

Figure 4-3 Direction Indicators With Media Interface Connector

Cable Output

Input

Connector with two ﬁbers

Output

Input

Chapter 4: Troubleshooting

2. Shine the ﬂashlight into one of the inputs. Verify that the light is visible and bright at

the output end of that line. If the light is not visible or is dim, the cable is faulty.

Replace it.

If the light is visible when shone in the opposite direction, the cable has been built

improperly. Replace it.

3. Repeat step 2 for the other input line.

Note: Special equipment is needed to accurately measure whether the optical signal is

full strength. The ﬂashlight test cannot tell if the signal is partially obstructed.Visible

light at the other end of the cable does not guarantee that the cable is fully functional.

Cable Lengths

An increasing bit-error rate may indicate that power is being lost because the cable is too

long.

Cable Between Stations

A typical manufacturer’s maximum length of cable between DAS stations is 2 kilometers

(approximately 1.24 miles) for regular ﬁber optic cable, but can be much longer (for

example, 10 km) for newer low-loss ﬁber optic cable. Length is measured from the FDDI

connector on the I/O panel of one station to the FDDI connection on the I/O panel of a

neighbor station. This length is not the distance between the two stations; it is the length

of the cable lying between two stations. Coils of cable lying in the closets, ﬂoors, or

ceilings of buildings can quickly add up to this maximum, so beware.

Total Length of Ring Cable

A typical manufacturer’s maximum length of cable allowed for one ring is 100 kilometers

(approximately 62 miles). The total ring cable length is calculated by summing all the

between-station lengths (as described in the paragraph above).

Note: Special equipment is needed to measure the amount of power loss on a ﬁber optic

cable.

Status Indicators and Symptoms

This section contains some common symptoms and smtstat status indicators

accompanied by descriptions of what they may indicate and what you can do to remedy

the problem.

Link-Level Errors

A high rate of link-layer errors can indicate a cable problem very close to or on the local

station. Follow the instructions for verifying and cleaning cable connections.

Token Count Not Incrementing

When the token count is not incrementing, the FDDI board is not seeing the light signals

on the ring (neither port is functioning or there may be a problem with the ring).

1. This symptom may indicate that the FDDI network interface has been turned off.

When this is the case, the Port Status report indicates that the MAC is OFF. Verify

that the FDDI cables are connected, then use smtconﬁg to stop and restart the FDDI

network interface.

If the problem persists, proceed to step 2.

2. Use the smtstat -s Port Status report to check the status of the receive line states.

■If the report shows HLS, the problem is probably one of the neighbor stations or

the ring. Verify that each neighbor station is functioning properly.

■If the report indicates QLS, the problem is probably local to this station. The

problem may be loose or damaged connectors, faulty cabling, or incorrectly

connected ports. Follow the instructions in “Checking Physical Connections”

on page 80 for all cabling between the station’s I/O panel and the ring.

Be especially careful to verify that the ends of the ﬁber optic cable at the I/O panel

have not been damaged.

Chapter 4: Troubleshooting

Too Many Claims or Beacons

When claims or beacons increment rapidly for more than a few seconds, a station on the

ring is malfunctioning or inserting itself. When the symptom persists for more than 5

minutes or is observed on three consecutive occasions (when you are certain no new

stations are being added), follow these steps to locate the dysfunctional station, then

remove it from the ring. This procedure can be very time consuming. A malfunctioning

station is sometimes difﬁcult to locate.

1. Locate a patch for the ring. The following items can be used to patch a ring: an

optical bypass switch, a ﬁber optic barrel connector, or an extra length of your ring’s

ﬁber optic cabling with appropriate connectors.

2. Physically disconnect one station from the ring.

3. Insert the patch into the ring (to ﬁll the gap where the station was).

4. Wait two or three minutes. During this time, the stations remaining on the ring

rearrange themselves.

5. Go to another station. Check if the problem has been remedied.

6. If the problem no longer manifests, you know that all the remaining stations are

functioning properly. Do not return the dysfunctional station to the ring until it has

been ﬁxed.

If the problem still exists, go to step 7.

7. Reinsert the disconnected station. Repeat steps 2–6.

Ring Is Wrapped

When the ring is wrapped, follow these instructions:

1. At each dual ring DAS, use the smtstat -s Port Status report to verify that neither

port’s transmit line state is in WRAP.

The transmit lines for a two-port FDDI board that is connected to a concentrator

normally indicate WRAP. This is normal and not a problem.

Status Indicators and Symptoms

2. When you locate a WRAP, look at the Port Status report’s ﬂags to verify that the WRAP

is not caused by an undesirable (CON_undesirable) or illegal connection

(C_illegal). If you identify a problematic connection, follow the instructions in

“Check Cables and Connectors” on page 83 to remedy the problem. Otherwise,

proceed to step 3.

3. When you locate two dual ring DASes, each with one of its ports in WRAP, you have

identiﬁed the boundaries of the functioning and nonfunctioning sections of the

ring. The fault can be found somewhere between the two stations: downstream

from the station whose port A is wrapped and upstream from the station whose

port B is wrapped.

4. Follow the instructions in “Checking Physical Connections” on page 80 for the

connectors and cables within the identiﬁed fault domain. If the problem persists,

proceed to step 5.

5. Starting with either of the boundary stations, perform these steps to determine

whether the fault is caused by the operating system or SMT module within one of

the stations located along the fault domain.

■Locate a patch for the ring. The following items can be used to patch a ring: an

optical bypass switch, a ﬁber optic barrel connector, or an extra length of your

ring’s ﬁber optic cabling with appropriate connectors.

■Disconnect the station from the ring.

■Patch the ring.

■Connect the station’s A connector (port) to its B connector (port) with a length

of ﬁber optic cable.

■Use the smtstat -s MAC Status report to verify that the station’s token count

increments rapidly. An incrementing token indicates that the station is

functioning properly.

■If the token increments rapidly, reconnect the station to the ring and repeat this

procedure on the next station within the fault domain.

■If you locate a dysfunctional station, do not reinsert it into the ring until it is

ﬁxed.

Chapter 4: Troubleshooting

High Rate of Packet Loss

If the packet loss is 100%, go to “Cannot Communicate With Other Stations” on page 90.

Otherwise, perform these steps:

1. If the high packet loss is displayed by the ping command, not by smtping , check any

routers connected to the ring for overloading.

Use /usr/etc/netstat -ina (or FDDIVisualyzer) at each station to identify all the

stations on the ring that are routers. A router has two or more MAC addresses, two

or more network addresses, and the routing daemon (routed) is running and is not

conﬁgured with the -qand -h options. (The routing daemon is conﬁgured by the

/etc/conﬁg/routed and /etc/conﬁg/routed.options ﬁles.)

2. If the high packet loss is indicated by both ping and smtping, use smtstat -s (or

FDDIVisualyzer) to locate additional symptoms.

High packet loss when using the -f option or the -i option with a short interval does

not necessarily indicate a problem. It is normal for ping and smtping to place echo

request packets onto the send queue faster than they can be processed, resulting in a

perceived loss of packets. In these instances, the packets are lost within the initiating

host, not on the network.

Cannot Communicate With Other Stations

If smtping or ping do not elicit a response, identify the appropriate subsection below and

follow the instructions.

Neither ping Nor smtping Works

1. If neither smtping nor ping elicits responses from any station, the /etc/hosts and

/etc/conﬁg/netif.options ﬁles may not have been set up properly. For example, the ﬁles

may be conﬁguring the FDDI network interface with the Ethernet IP address. Verify

that the IP (inet) addresses for all network interfaces are correct. To display the

currently conﬁgured IP addresses for FDDI and Ethernet network interfaces:

% /usr/etc/netstat -in

If the IP addresses are correct, proceed to step 2. If the addresses are not correct,

follow the instructions in Chapter 2 to reconﬁgure FDDIXPress.

Status Indicators and Symptoms

2. If the IP addresses are correct, the station may not be connected to any of its

networks. At each of the station’s neighbors, use smtstat -s to ﬁnd a wrapped FDDI

ring. If both neighbors indicate a WRAP, follow the instructions in “Checking

Physical Connections” on page 80 to reconnect this station to the ring.

3. If the problem persists, identify other problems, as described in “Verifying the

FDDI Connection” on page 47.

ping Works But smtping Does Not

If smtping does not elicit a response from a particular station but ping does, any of the

following may be the problem:

•The MAC address for the station may be incorrect.

•The station may be off the FDDI ring.

•The ring may be wrapped so that the two stations are on different fragments.

In the last two cases, the ping response is arriving over another connection, not the FDDI

connection in question, and the success of the ping indicates that the station is reachable

through a router.

The smtping command uses physical (MAC) addresses, not IP addresses, so it can

communicate only with stations on the same physical medium (that is, local area

network). For example, a station with an IP address of 223.62.4.51 (where the network

portion is 223.62.4) cannot smtping a station residing on a network with the address

223.62.5; however, it can contact address 223.62.4.11 (assuming that no subnetworks have

been created). You can verify the IP address of the other station with one of these

command lines:

% /usr/bin/ypmatch name hosts

% /sbin/grep name /etc/hosts

1. Use ping with the -roption and the IP address (not the host name) to verify that the

station is being reached over the FDDI network (not through a router or another

network connection). Make sure that the network portion of the IP address matches

the FDDI network (not that of another network). If the station answers, continue. If

the station does not answer, follow the instructions in “Neither ping Nor smtping

Works” on page 90.

%/usr/etc/ping -r IPaddress

Chapter 4: Troubleshooting

2. Verify the MAC address for the station you are trying to contact. You can obtain a

station’s MAC address with smtstat at that station’s terminal. Then, use smtping

with the MAC address (not the hostname) and specify the FDDI interface. If the

station answers, the station’s MAC address in the /etc/ethers ﬁle may be incorrect. If

the problem persists, continue with step 3.

%/usr/etc/smtping -I fddiinterface ##:##:##:##:##:##

3. Use smtstat -s at each station on the ring to verify the ports that indicate a WRAP.

ping Does Not Work But smtping Does

If smtping works but ping does not, it is possible that the /etc/hosts ﬁle has not been set up

properly. For example, the station may have both an FDDI and an Ethernet cable

connected but the network connection names and IP addresses in the /etc/hosts or

/etc/conﬁg/netif.options ﬁles are mismatched.

1. Display the currently conﬁgured IP (inet) address for each network interface:

% /usr/etc/netstat -ina

Verify that the displayed addresses correctly match the connected networks. If

everything is correct, proceed to step 2. If any IP addresses is not correct, follow the

instructions in “Network Connection Names and IP Addresses” on page 31 to

reconﬁgure FDDIXPress.

2. Again invoke smtping using the MAC address for the station (not the hostname) and

specify the FDDI interface. If the station answers, continue. If the station does not

answer, follow the instructions in “Neither ping Nor smtping Works” on page 90.

%/usr/etc/smtping -I fddiinterface ##:##:##:##:##:##

3. Use ping with the -roption and the station’s IP address (not the hostname) to verify

that the station is being reached over the FDDI network in question (not through a

router or another network connection). Make sure that the network portion of the IP

address matches the network address (from the netstat display) for the fddiinterface

used in the smtping command above. If the station answers, all is well. If the station

does not answer, go to step 4.

%/usr/etc/ping -r IPaddress

4. Disable then re-enable the FDDI interface, then repeat steps 1-3:

%/usr/etc/smtconfig fddiinterface down

%/usr/etc/smtconfig fddiinterface up

Status Indicators and Symptoms

Current Neighbor’s Address Is Zero

When both current neighbor addresses are zero, the station is not seeing a signal from

any other station on the ring. This condition is normal if the station is the only station on

the ring. This condition is not normal and indicates a wrapped ring when the site’s

conﬁguration is a multistation dual ring with one ring as a backup. The zero addresses

indicate that the station is located within a fault domain (a nonfunctional section of the

ring). Follow the instructions in “Ring Is Wrapped” on page 88.

When one of the current neighbor addresses is zero, the station is not seeing any signal

from that neighbor’s direction (which is either upstream or downstream). A dual ring

conﬁguration with one ring as a backup wraps when this occurs. You can see this wrap

by using the smtstat -s reports at this station. Follow the instructions in “Ring Is

Wrapped” on page 88. The zero address indicates the direction you should start looking

for the fault. Be sure to start your search at the nonwrapped port on this station’s I/O

panel. The wrapped port is a functional port.

Ring Is Not Wrapped and Token Count Increments But smtping Does

Not Work

If the ring is not wrapped, smtping does not work with any station, and smtstat -s

indicates that the token count increments normally, there is probably something wrong

with the station’s software.

To resolve this problem, follow this procedure:

1. Verify that the problem is not caused by your station’s conﬁguration.

■Use smtping with a valid MAC address. To determine all valid MAC addresses,

use smtring.

■If smtping works with the MAC addresses, but does not work with station

names, the ethers database (the /etc/ethers ﬁle, local or on an NIS server) is

incorrectly set up. Follow the instructions in “Setting Up the ethers File

(Optional)” on page 43 to set up an ethers database.

2. If smtping does not work with MAC addresses, use these commands to disable and

reenable the software and board:

% /sbin/su

Password: thepassword

# /usr/etc/smtconfig interfacename down up

Chapter 4: Troubleshooting

3. Verify the FDDI connection again.

4. If the problem is still present, reinstall your station’s software (following the

instructions in the release notes) and reconﬁgure it (following the instructions in

Chapter 2, “Conﬁguring FDDIXPress Software” of this manual).

5. If the problem is still present, contact the Silicon Graphics Technical Assistance

Center.

System Does Not Load Miniroot or Boot From the Network

Silicon Graphics workstations and servers are capable of loading a small-sized version of

the operating system (the miniroot) and booting themselves over the network; however,

they are capable of doing this only over Ethernet local area networks (they cannot boot

over FDDI networks) that are conﬁgured as the primary network interface.

If your system is unable to load the miniroot (or boot over the network), verify that its

primary network interface is an Ethernet connection by following these instructions:

1. Restart the system from the System Maintenance menu. Do not rebuild the

operating system during this restart.

2. Log on and open a shell window.

3. Use these commands to display the ordering of the network interfaces:

%/usr/etc/netstat -i

...

4. If the primary interface is an Ethernet (for example, ec0,et0,enp#), the Ethernet

network connection may be dysfunctional. See IRIX Admin: Networking and Mail for

information about Ethernet network connections.

If the primary interface is not an Ethernet, go to step 5.

5. Conﬁgure an Ethernet connection as the primary interface, following the

instructions in “FDDI as the Secondary Interface and Ethernet as Primary” on

page 25.

6. Reboot the system. When the system is up and running, it should be capable of

loading the miniroot over the network and booting from it.

Appendix A

A. Error Messages

This appendix contains an alphabetical list of all the error messages that can be displayed

by FDDIXPress drivers, SMT commands, and the SMT module. The error messages are

divided into three sections:

•“SMT Error Messages” on page 97

•“xpi Driver Error Messages” on page 149

•“ipg Driver Error Messages” on page 157

•“rns Driver Error Messages” on page 161

The error messages in this appendix are those that are unique to FDDIXPress. Standard

system error messages, even when caused by the FDDIXPress code, are not included.

How Messages Are Listed

With each error message is a discussion of the problems that may cause the message. The

list contains only messages that indicate an error or problem; it does not contain

informational messages that occur during normal operation.

Messages are alphabetized according to the following rules:

•Each message is alphabetized by the numerals (0–9) and letters (a–z) of the

message’s text. Numerals precede letters. Capitalization makes no difference.

(Figure A-1 illustrates the text of an error message.)

Appendix A: Error Messages

•Nonletters (for example, - or %) and blank spaces are shown in the text of the

message, but are ignored in alphabetization. For example, the message sm_open

appears between smnet and smp.

•When an error message includes an item that the software speciﬁes differently for

each instance of the message (a variable), this item is displayed in italic font and

labeled with a generic name (for example, ﬁlename). The generic names are skipped

for alphabetization purposes. For example, the error message goofy not

responding is located among the “n” listings as hostname not responding.

Common generic names used in this listing include hostname,interfacename,phyID,

version#, userentry, systemmessage,digit,ﬁlename, and hexnumeral.

Note: If you cannot ﬁnd an error message in the listing, identify potential ﬁll-in

words, then look up the message without those words.

•The creator of each message is listed, in angled brackets, below the text of the

message: (<creator>).

FDDIXPress error messages created by the SMT daemon (smtd) and the SMT commands

are written into the ﬁle /var/adm/SYSLOG or displayed at the terminal; some messages

appear in both places. Within the SYSLOG ﬁle, each message is preceded by the date,

time, hostname, the name of the process that created the message, and its process ID

number, as illustrated in Figure A-1. Only the text of the error message is included in the

alphabetic list that follows.

Figure A-1 Error Message Format in the /var/adm/SYSLOG File

May 10 05:12:03 goofy smtd[58]: Unknown Frame, FC=2

Date and time Host Creator Text of error message

SMT Error Messages

A<->A twist detected

<smtd>

A twist in the ﬁber was detected. The software was expecting an A-to-B

connection. Follow the instructions in the section “Checking Physical

Connections” in Chapter 4 to ﬁx the cable or connection problem.

A general error occurred

<smtd>

The SMT daemon has encountered a problem with its MIB information.

This may indicate that the MIB ﬁle (/etc/fddi/smtd.mib) is corrupted. Make

a new copy from the backup, then use smtconﬁg to stop and restart the

network interface. This also can indicate that the requesting SMT

module has requested invalid MIB information.

ANNOUNCE: Illegal FC=hexnumeral

<smtd>

The SMT daemon was attempting to send an announce frame, but found

that the frame control (FC) value, which was created by another module

of the software, is not supported.

interfacename.#: arm failed

<smtd>

While attempting to conﬁgure and bring up the SMT daemon, the

software was unable to set a new interrupt level in the operating system

for the network interface indicated.

Bad access type (token): On line digit

<smtd>

An ACCESS entry in the MIB ﬁle (/etc/fddi/smtd.mib) contains a type of

access (token) not recognized by the software. The problem is on the line

of the ﬁle indicated. Make a new copy of the ﬁle from a backup copy,

then use smtconﬁg to stop and restart the network interface.

Bad CONF_SIF frame type(digit) received

<smtd>

An illegal Conﬁguration SIF frame was received; the frame was not of a

known type (for example, REQUEST and RESPONSE).

Appendix A: Error Messages

Bad echo frame type(digit) received

<smtd>

An illegal ECF (ECHO) frame was received; the frame was not of a

known type (for example, REQUEST and RESPONSE).

Bad FC=hexnumeral recv

<smtd>

An FDDI frame was received with an illegal FC (frame control) value in

the header. The illegal two-symbol (2-byte) FC value is indicated in the

message as a hexadecimal number.

Bad format for OBJECT TYPE (token): On line digit

<smtd>

An object (token) in the MIB ﬁle (/etc/fddi/smtd.mib) was an unrecognized

type. The problem is on the line of the ﬁle indicated. Make a new copy

of the ﬁle from a backup copy, then use smtconﬁg to stop and restart the

network interface.

Bad format (token): On line digit

<smtd>

When reading the MIB ﬁle (/etc/fddi/smtd.mib), a formatting entry was

not found when expected. Instead, token was encountered. The problem

is on the line of the ﬁle indicated. Make a new copy of the ﬁle from a

backup copy, then use smtconﬁg to stop and restart the network interface.

bad header

<smtd>

This is a minor internal error not requiring any action on your part. An

invalid packet header was detected.

remotehost -- BAD type len=digits

<smtd>

The SMT software could not parse an entry in a frame received from the

station indicated (remotehost). The illegal entry was of the type and

length indicated. This indicates an incompatibility between the two

stations. You may want to report this problem to the Silicon Graphics

Technical Assistance Center.

SMT Error Messages

Bad object identifier: On line digit

<smtd>

When reading the MIB ﬁle (/etc/fddi/smtd.mib), an entry (object) on the

line of the ﬁle indicated could not be properly identiﬁed. Make a new

copy of the ﬁle from a backup copy, then use smtconﬁg to stop and restart

the network interface.

Bad operator: On line digit

<smtd>

An unrecognized entry was found in the MIB ﬁle (/etc/fddi/smtd.mib) on

the line indicated. Make a new copy of the ﬁle from a backup copy, then

use smtconﬁg to stop and restart the network interface.

Bad OP SIF frame type(digit) received

<smtd>

An illegal Operation SIF frame was received; the frame was not of a

known type (for example, REQUEST and RESPONSE).

BAD parameter type=hexnumeral len=digit

<smtd>

As the SMT daemon was processing a packet, it encountered an

unknown parameter of the type and length indicated. The invalid

parameter was skipped; the rest of the packet was processed.

bad parse of community

<smtd>

This is a minor internal error not requiring any intervention. An invalid

ﬁeld was found in the header of a received packet.

Bad parse of object id: On line digit

<smtd>

A NULL object identiﬁer was encountered unexpectedly in the MIB ﬁle

(/etc/fddi/smtd.mib) on the line of the ﬁle indicated. Make a new copy of

the ﬁle from a backup copy, then use smtconﬁg to stop and restart the

network interface.

100

Appendix A: Error Messages

Bad parse of object type: On line digit

<smtd>

A NULL object type was encountered unexpectedly in the MIB ﬁle

(/etc/fddi/smtd.mib). The problem is on the line of the ﬁle indicated. Make

a new copy of the ﬁle from a backup copy, then use smtconﬁg to stop and

restart the network interface.

bad parse of version

<smtd>

This is a minor internal error not requiring any intervention. An invalid

version was found in the header of a received packet.

bad phy/mac count

The number of PHYs and MACs deﬁned in the ﬁle /etc/fddi/smtd.conf is

invalid. For example, four PHYs cannot be deﬁned for one MAC. See

Appendix B for descriptions of valid entries for this ﬁle.

Bad status (token): On line digit

<smtd>

An unrecognized type of status (token) was encountered in the MIB ﬁle

(/etc/fddi/smtd.mib) on the line of the ﬁle indicated. Make a new copy of

the ﬁle from a backup copy, then use smtconﬁg to stop and restart the

network interface.

Bad syntax (token): On line digit

<smtd>

An entry (token) in the MIB ﬁle (/etc/fddi/smtd.mib) could not be parsed

(understood) and is probably improperly put together. The problem is

on the line of the ﬁle indicated. Make a new copy of the ﬁle from a

backup copy, then use smtconﬁg to stop and restart the network interface.

bad una

A received packet contained a missing or malformed upstream neighbor

address ﬁeld. If the message occurs frequently, check the stations

upstream.

SMT Error Messages

101

bad una purged

A received packet contained a missing or malformed ﬁeld and was

discarded. The problematic ﬁeld contained the address of the upstream

neighbor (una). The frame has been discarded.

userentry: bad value

The netmask option of the smtconﬁg command failed. The entry is not a

legal IP address represented in standard format (decimal, dot notation).

See dotted decimal notation in the Glossary. A zero address (0.0.0.0) is not

legal.

B<->B twist detected

<smtd>

A twist in the ﬁber was detected. The software was expecting an A-to-B

connection. Follow the instructions in the section “Checking Physical

Connections” in Chapter 4 to ﬁx the cable or connection problem.

bind

When attempting to set up a reception socket, the bind system or library

call failed. During a boot or restart of the network interface, this

condition is common and does not indicate a malfunction. However, if

the message occurs frequently during normal operation, it indicates a

problem with the operating system. For example, it may be overloaded.

bind port(interfacename)

When attempting to set up a transmission socket to the indicated

network interface, the bind system call failed. During a boot or restart of

the network interface, this condition is common and does not indicate a

malfunction. However, if the message occurs frequently during normal

operation, it indicates a problem with the operating system. For

example, it may be overloaded.

102

Appendix A: Error Messages

buildheader

<smtd>

This is a minor internal error not requiring any intervention. An error

was detected when attempting to create a packet header.

buildint

<smtd>

This is a minor internal error not requiring any intervention. An error

was detected when attempting to create an SMT packet.

buildstring

<smtd>

This is a minor internal error not requiring any intervention. An error

was detected when attempting to build an SMT packet.

build una failed

The SMT software was unable to build the upstream neighbor’s address

from the response frame received. This error probably indicates an

incompatibility between the two machines. This error is not serious;

however, you may want to report the problem to the Silicon Graphics

Technical Assistance Center.

Can't find variable name in this MIB

<smtd>

The SMT daemon has encountered a problem with the MIB. This

message probably indicates an incompatibility within the different

FDDIXPress software ﬁles and modules. For example, the SMT daemon

and the FDDI driver were started at different times. Use the smtconﬁg

command to stop then restart the FDDI network interface (which also

starts the SMT daemon).

This can also indicate that the MIB ﬁle (/etc/fddi/smtd.mib) is corrupted.

Make a new copy from the backup, then use smtconﬁg to stop and restart

the network interface. In rare circumstances, this can indicate that the

requesting SMT has requested invalid MIB information.

SMT Error Messages

103

Can't get response from daemon

When attempting to start, the command could not contact the SMT

daemon (smtd), indicating that the SMT daemon probably is not

running. Use smtconﬁg to stop and restart the network interface (which

restarts the SMT daemon).

Can’t get smtd version

The version of the SMT daemon cannot be determined. This may

indicate that the FDDI interface is disabled or that the SMT daemon was

stopped then restarted manually. Use smtconﬁg to stop and restart the

network interface.

can't open conﬁgurationﬁlename

<smtd>

While conﬁguring itself, the SMT daemon was unable to open the ﬁle

/etc/fddi/smtd.conf. This may indicate that the ﬁle is missing. Verify its

presence in the /etc/fddi directory. If the ﬁle does exist, it may be

corrupted. Make a new copy of it from your backup copy.

conf: bad entry: ﬁeldname

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The ﬁeld name displayed in the message

was found in the ﬁle /etc/fddi/smtd.conf, but is not recognized by the

conﬁguration software. See Appendix B for descriptions of proper

formatting for this ﬁle.

conf: bad format: linenumber

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. An entry in the ﬁle /etc/fddi/smtd.conf is

formatted improperly or the ﬁle is missing a required entry at the line

indicated. See Appendix B for descriptions of proper formatting for this

ﬁle.

104

Appendix A: Error Messages

Examples of formatting errors include the following:

•forgetting to terminate each station section with ENDSTATION

•forgetting to terminate each MAC section with ENDMAC

•forgetting to terminate each PHY section with ENDPHY

•allowing an uncommented entry to contain less than three items:

the ﬁeld’s name, an equal sign (=), and a value

conf: bad mac addr: badaddress

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The value entered for the MAC address

(addr) in the ﬁle /etc/fddi/smtd.conf is not a valid entry. See Appendix B

for descriptions of valid entries for this ﬁle.

conf: bad MAC entry: name not set

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The line containing the name of the

network interface was missing from one of the MAC sections in the ﬁle

/etc/fddi/smtd.conf. See Appendix B for descriptions of required entries

for this ﬁle.

conf: bad phy_ct=: illegalentry

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The number of PHYs speciﬁed (phy_ct

ﬁeld) in the ﬁle /etc/fddi/smtd.conf is not a valid entry. See Appendix B for

descriptions of valid entries for this ﬁle.

conf: bad sid: stationID

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The value entered in the ﬁle

/etc/fddi/smtd.conf for StationID is not a valid entry. See Appendix B for

descriptions of valid entries for this ﬁle.

SMT Error Messages

105

conf: bad SRF address: address

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The value entered for the SRF multicast

address (sr_mid) in the ﬁle /etc/fddi/smtd.conf is not a valid entry. See

Appendix B for descriptions of valid entries for this ﬁle.

conf: bad station entry: text

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. Some undeﬁned problem has been

encountered within a station section in the ﬁle /etc/fddi/smtd.conf. The

text indicated in the message identiﬁes the item in the ﬁle that could not

be processed. See Appendix B for descriptions of valid entries for this

ﬁle.

interfacename: config missing

<smtd>

While conﬁguring itself with the ﬁle /usr/etc/smtd.conf, the SMT daemon

did not ﬁnd a required conﬁguration parameter for the MAC speciﬁed

in the message. See Appendix B for details about this conﬁguration ﬁle.

conf: ignored 3rd phy for interfacename

<smtd>

During conﬁguration of the SMT daemon and FDDI network interface,

a value for a nonexistent third PHY was detected in the ﬁle

/etc/fddi/smtd.conf. The entry has been ignored. Processing has

continued.

conf: primary missing for interfacename

<smtd>

During conﬁguration of the SMT daemon and FDDI network interface,

a problem was encountered. The primary path for the MAC (network

interface) indicated was not found. This could indicate that the PHY

sections for that MAC and/or the phy_ct ﬁeld have been set improperly

in the ﬁle /etc/fddi/smtd.conf. See Appendix B for descriptions of valid

entries for this ﬁle.

106

Appendix A: Error Messages

conf: secondary missing for interfacename

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The secondary path for the MAC (network

interface) indicated was not found. This could indicate that the PHY

sections for this MAC and/or the phy_ct ﬁeld have been set improperly

in the ﬁle /etc/fddi/smtd.conf. See Appendix B for descriptions of valid

entries for this ﬁle.

conf: user data too long

<smtd>

A problem was encountered during conﬁguration of the SMT daemon

and FDDI network interface. The value entered as user data

(user_data) in the ﬁle /etc/fddi/smtd.conf contains too many characters.

See Appendix B for descriptions of valid entries for this ﬁle.

couldn't bind remotesocket

<smtd>

Abind system call failed. This indicates a problem with the operating

system.

couldn't get fdditree

<smtd>

The SMT daemon could not read the MIB ﬁle (/etc/fddi/smtd.mib). This

could indicate that the ﬁle is missing. Verify its presence. This message

could also indicate that the ﬁle is corrupted. Make a new copy of it from

a backup, then use smtconﬁg to stop and restart the network interface.

couldn't get hostent

<smtd>

The gethostbyname system call failed for localhost. This could indicate

that the localhost information about the local station (the station

where smtd was invoked) is missing from the local /etc/hosts ﬁle. Verify

that the following line exists in the /etc/hosts ﬁle:

127.0.0.1 localhost localhost.x.x.x loghost

The alternate format is this:

127.1 localhost localhost.x.x.x loghost

x.x.x contains the station’s domain information.

SMT Error Messages

107

couldn't get hostname

When attempting to set up a reception socket, the gethostname system

call failed. This may indicate a problem with the operating system. For

example, it may be overloaded. This may indicate that the station

speciﬁed on the smtring command line was not found in the hosts

database (either the local /etc/hosts ﬁle or the NIS server).

couldn't get localport

<smtd>

The SMT daemon was unable to obtain a local communication port. This

indicates a problem with the operating system.

couldn't get remotesocket

<smtd>

Asocket system call failed. This indicates a problem with the operating

system.

couldn't get socket name

<smtd>

Agetsockname system call failed. This indicates a problem with the

operating system.

couldn't open remote SNMP session

<smtd>

The SMT daemon could not open a session with an SNMP module. This

may indicate that the SNMP daemon is not running. This may also

indicate that the ﬁle descriptor obtained for the port is invalid.

couldn't open SNMP session

<smtd>

The SMT daemon could not obtain a communication channel (session).

This indicates a problem with FDDIXPress software. Reboot the system.

If the problem persists, reinstall the software shipped with your FDDI

board.

108

Appendix A: Error Messages

Denied REQUEST: bad version digit

<smtd>

The SMT daemon was attempting to respond to an FDDI request frame;

however, it discovered that the received frame was encoded in an

unsupported version of the SMT protocol. Use the “SMT Information”

report of the smtstat -s command to discover the range of supported

versions on this station.

DUP!

The number of duplicate response frames was excessive. This indicates

a problem at the remote station, except when the smtping command has

been invoked with a broadcast address (ff:ff:ff:ff:ff:ff), in which case

duplicate frames are normal.

Encapsulation Routing

Asetsockopt system or library call failed. This indicates a problem with

the operating system. For example, it may be overloaded.

Error: interfacename PHYindex: actionname errormessage

<smtd>

The speciﬁed action (actionname) caused an error as detailed in the text

of errormessage for the interface and PHY indicated. This indicates

something wrong with the SMT software. Reboot the system. If the

problem continues, reinstall the software that was shipped with the

FDDI board. If the problem persists, call the Silicon Graphics Technical

Assistance Center.

Error building packet

The SNMP daemon could not build an SMT packet as requested (for

example, the size may be too large). The requested packet was not sent.

Error in config file: can't decode section delimiter: delimiter

<smtd>

While conﬁguring itself, the SMT daemon could not parse (understand)

the section delimiter (as indicated in the message) in the ﬁle

/usr/etc/smtd.conf. See Appendix B for details about this conﬁguration

ﬁle.

SMT Error Messages

109

Error in config file: too many stations defined: max=digit

<smtd>

While conﬁguring itself, the SMT daemon found too many stations

deﬁned in the ﬁle /usr/etc/smtd.conf. The maximum number of stations

allowed is deﬁned in the message. See Appendix B for details about this

conﬁguration ﬁle.

Error in config file: unknown section delimiter: delimiter

<smtd>

While conﬁguring itself, the SMT daemon could not parse (understand)

the section delimiter (as indicated in the message) in the ﬁle

/usr/etc/smtd.conf. See Appendix B for details about this conﬁguration

ﬁle.

Error: smt phyID: actionname errormessage

<smtd>

The speciﬁed action (actionname) caused an error as detailed in the text

of errormessage for the interface and PHY indicated. This indicates

something wrong with the SMT software. Reboot the system. If the

problem continues, reinstall the software that was shipped with the

FDDI board. If the problem persists, call the Silicon Graphics Technical

Assistance Center.

event 0xhexnumeral tlvget failed

<smtd>

It was not possible to parse and build the SMT event identiﬁed by the

hexadecimal numeral.

fatal path rid mismatch

<smtd>

The SMT daemon found an inconsistency in the MAC, PHY, and path

conﬁgurations (rid = resource identiﬁcation, a software variable). Use

smtconﬁg to stop, then restart the network interface (and the SMT

daemon) so that it can rebuild its information. If the problem persists,

the MIB ﬁle may be corrupted; create a new /etc/fddi/smtd.mib ﬁle from a

backup copy, then use smtconﬁg to stop and restart the network interface.

110

Appendix A: Error Messages

frame too large: len = digits

<smtd>

An illegal FDDI frame was received. The frame had too many bits.

fs_reg: socket

<smtd>

Asocket system or library call failed. This may indicate a problem with

the operating system.

gethostbyname

The gethostbyname system or library call failed for one of the stations.

This could indicate that the station’s network connection name has not

been added to the hosts database (NIS service or local /etc/hosts ﬁle), or

that the station’s IP address is invalid. This error could indicate a

problem with the NIS server. For example, it may be overloaded or not

currently functional.

get localhost failed

When attempting to set up a reception socket, the gethostbyname system

call failed for localhost. This could indicate that localhost

information about the local station (the station where smtping was

invoked) is missing from the local /etc/hosts ﬁle. Verify that one of the

following lines exists in the /etc/hosts ﬁle:

127.0.0.1 localhost localhost.x.x.x loghost

The alternate format is as follows:

127.1 localhost localhost.x.x.x loghost

x.x.x contains the station’s domain information.

getsockname

Agetsockname system or library call failed. This indicates a problem with

the operating system. For example, it may be overloaded.

SMT Error Messages

111

getsockname failed(errornumber)

When attempting to set up a reception socket on the local host, the

getsockname system call failed. This indicates a problem with the

operating system. For example, it may be overloaded.

gettimeofday failed

<smtd>

The gettimeofday system or library call failed. This indicates a problem

with the operating system. For example, it may be overloaded.

init_mib: mibfile = NULL

<smtd>

An internal error was detected when the SMT daemon attempted to

initialize the MIB ﬁle (/etc/fddi/smtd.mib). This may indicate that the ﬁle

is corrupted or missing. Create a new MIB ﬁle using the command lines

below. If you do not have a backup copy (/etc/fddi/smtd.mib.orig) of the

MIB ﬁle, reinstall your FDDIXPress software.

% /sbin/su

# cd /etc/fddi

# /bin/cp smtd.mib.orig smtd.mib

# /usr/etc/smtconfig FDDIinterfacename down up

interfacename:phy info missing

<smtd>

While reading the ﬁle /usr/etc/smtd.conf to conﬁgure itself, the SMT

daemon did not ﬁnd a required conﬁguration parameter for the MAC

(network interface) and PHY indicated in the message. The phy variable

will be replaced by the word primary or secondary, where primary

usually identiﬁes port B and secondary port A. See Appendix B for

details about this conﬁguration ﬁle.

Invalid device name: interfacename

The interface name speciﬁed for the SMT command using the -I option

was not recognized as an FDDI interface at that station. Verify (with the

netstat -ina command) that the interface name you speciﬁed exists on

that station and is correctly typed on the command line. You also can use

the hinv command to identify the station’s FDDI hardware and its

associated network interface.

112

Appendix A: Error Messages

invalid event 0xhexnumeral ignored

<smtd>

The SMT event identiﬁed by the hexadecimal numeral is not recognized,

so it has been ignored.

characters: invalid PCM line state

The characters indicated are not valid. They do not correspond to any

physical connection (PCM) line state recognizable by smtmaint. Valid

line states are limited to the values speciﬁed in “Verifying a Station’s

PCM Functionality” on page 71 and on the smtmaint man page.

digit: invalid PHY index

The decimal number indicated is not a valid entry. The number was

entered as the second parameter in the smtmaint command line,

corresponding to a PHY. The entry must be a decimal digit of 0 or 1.

characters is a reserved word: On line digit

<smtd>

The entry indicated by characters has been improperly used in the MIB

ﬁle (/etc/fddi/smtd.mib). The problem is on the line of the ﬁle indicated.

Make a new copy of the ﬁle from a backup copy, then use smtconﬁg to

stop and restart the network interface.

invalid response type: type

The responding SMT module sent information of an invalid type. The

type, which must be RESPONSE, is speciﬁed within one of the ﬁelds of

the response. This indicates that the responding station is either

dysfunctional or not behaving in conformance with the FDDI SMT

protocol.

SMT Error Messages

113

ioctl (requestparameter)

During conﬁguration of the SMT daemon and network interface, an ioctl

system or library call failed for the indicated requestparameter. This may

indicate an invalid conﬁguration parameter (user entry) on the smtconﬁg

command line. The conﬁguration has failed; the parameter has not been

changed.

The following requestparameters indicate the invalid user entry:

SIOCGIFFLAGS network interface name

SIOCSIFADDR inet (IP or internet) address

SIOCSIFNETMASK netmask

SIOCSIFBRDADDR broadcast address

SIOCSIFHEAD make network interface primary

SIOCSIFDSTADDR destination address

set metric route metric

This error message may also indicate a problem with the operating

system. When the requestparameter is not listed above, this message

usually indicates a problem with the operating system.

interfacename,phyID: ioctl(requestparameter)

<smtd>

An ioctl system or library call with the requestparameter indicated failed.

The call was made for the network interface and PHY indicated. This

indicates a problem with the operating system.

interfacename, phyID: LEM_FAIL

<smtd>

This is a serious error condition. The SMT daemon has detected too

many link errors occurring at the network interface and PHY indicated.

When this message is displayed, the SMT daemon is not able to

reestablish the ring, so the indicated port is not functioning. The

problem lies between this station and the upstream neighbor. Follow the

instructions in sections “Checking Physical Connections” on page 80

and “Link-Level Errors” on page 87.

114

Appendix A: Error Messages

interfacename.digit: LER alarm = currentLER

<smtd>

The Link Error Alarm was activated for the network interface (MAC

address) and PHY (digit) speciﬁed in the message, indicating that the

link error rate (LER) exceeded the alarm threshold. Follow the

instructions in the section “Checking Physical Connections” in

Chapter 4 to ﬁx the cable problem.

localhost

Agethostbyname system or library call failed when using the localhost

parameter. This could indicate that the localhost information about

the local station (the station where smtinfo was invoked) is missing from

the local /etc/hosts ﬁle. Verify that the one of the following lines exists in

the /etc/hosts ﬁle:

127.0.0.1 localhost localhost.x.x.x loghost

An alternate format is this:

127.1 localhost localhost.x.x.x loghost

x.x.x completes the address.

local port

<smtd>

Agetsockname system call failed. This indicates a problem with the

operating system.

mac dump for station failed

An attempt to obtain information from another station failed. This may

indicate the SMT daemon on the local machine has failed or the interface

is disabled. Use the smtconﬁg command to stop and restart the FDDI

network interface.

Malloc failed

<smtd>

Amalloc system or library call failed. This indicates a problem with the

operating system when attempting to allocate memory.

SMT Error Messages

115

map_open: mktemp failed

<smtd>

In attempting to update the MIB, a mktemp system or library call failed

to create a unique, temporary ﬁle. This may indicate that the operating

system is overloaded.

map_smt: BAD command action

<smtd>

The action (internal software command) speciﬁed when this routine was

called is not a valid one. Another error message will provide more detail

about the problem, including the name of the process that provided the

invalid command. This indicates a problem with the SMT software.

Reboot the system. If the problem continues, reinstall the software that

was shipped with the FDDI board. If the problem persists, call the

Silicon Graphics Technical Assistance Center.

map_smt: variable doesn't exist

<smtd>

The speciﬁed variable caused an error. This indicates a problem with the

SMT software. The MIB ﬁle may be corrupted. Make a new copy of

/etc/fddi/smtd.mib from your backup copy. Reboot the system. If the

problem continues, reinstall the software that was shipped with the

FDDI board. If the problem persists, call the Silicon Graphics Technical

Assistance Center.

map_smt: FDDI interface interfacename not found

<smtd>

The indicated FDDI network interface is not known to the system.

Another error message will provide more detail about the problem,

including the name of the process that provided the invalid name. (The

map_smt routine is an internal SMT routine called by many FDDIXPress

processes.)

116

Appendix A: Error Messages

map_smt: Invalid action: action

<smtd>

The speciﬁed action (internal software command) is not a valid one. This

indicates something wrong with the SMT software. Reboot the system.

If the problem continues, reinstall the software that was shipped with

the FDDI board. If the problem persists, call the Silicon Graphics

Technical Assistance Center.

Mib not initialized. Exiting

<smtd>

An operating system error was detected. The MIB ﬁle (/etc/fddi/smtd.mib)

could not be initialized. This may indicate that the ﬁle is corrupted or

missing. Create a new MIB ﬁle using the command line below. If you do

not have a backup copy (for example, /etc/fddi/smtd.mib.orig) of the MIB

ﬁle, reinstall your FDDIXPress software.

% /sbin/su

# cd /etc/fddi

# /bin/cp smtd.mib.orig smtd.mib

# /usr/etc/smtconfig FDDIinterface down up

Mib table is bad. Exiting

<smtd>

The MIB ﬁle (/etc/fddi/smtd.mib) could not be parsed. Make a new copy

of the ﬁle from a backup copy, then use smtconﬁg to stop and restart the

network interface.

Missing end of oid: On line digit

<smtd>

The end of an entry (object) in the MIB ﬁle (/etc/fddi/smtd.mib) was

missing. The problem was encountered on the line of the ﬁle indicated.

Make a new copy of the ﬁle from a backup copy, then use smtconﬁg to

stop and restart the network interface.

SMT Error Messages

117

newiphase for interfacename failed

<smtd>

The SMT daemon failed to conﬁgure and bring up (get running) the

software for the network interface indicated in the message. This

indicates that the network interface name is not known to the system.

Use the command below to verify that the driver has been built into the

operating system:

% /sbin/grep FDDIinterface /var/sysgen/master.c

FDDIinterface is ipg or xpi (without the ﬁnal digit). If there are no entries

for the FDDI interface (for example, if_ipgintr), use the /etc/autoconﬁg

command to rebuild the operating system, then reboot to start using the

new operating system.

If the problem persists, reinstall the software that was shipped with the

installed FDDI board, rebuild the operating system, and reboot. If the

message continues to be displayed, contact the Silicon Graphics

Technical Assistance Center.

No end to oid: On line numeral

<smtd>

The ﬁnal entry in a series of an entries for an object in the MIB ﬁle

(/etc/fddi/smtd.mib) was missing. The problem was encountered on the

line of the ﬁle indicated. Make a new copy of the ﬁle from a backup copy,

then use smtconﬁg to stop and restart the network interface.

No frame sent successfully during last # seconds

<smtd>

Asend system or library call has failed to complete successfully during

the indicated period of time. This indicates a problem with the operating

system.

No response from daemon: timed-out

<smtd>

The SMT daemon has halted or quit. This indicates a problem with the

FDDIXPress software ﬁles. Use smtconﬁg to stop and restart the FDDI

network interface. If the problem persists, reboot the system to restart

everything. If this does not solve the problem, reinstall the software

shipped with your FDDI board. If the message continues to display,

contact the Silicon Graphics Technical Assistance Center.

118

Appendix A: Error Messages

No SMT frames received for numeral seconds

<smtd>

The SMT daemon has not received any SMT protocol frames within the

number of seconds indicated, so the SMT daemon has reset the driver.

This message can indicate the ring is totally quiet, which would be

normal only when the station was the only one on the ring. It could

indicate the station has been isolated onto a ring fragment. Check if any

of this station’s ports are wrapped. This message might indicate a

problem with the board. Error messages created by the driver will help

you identify this condition.

Not a sequence: On line digit

<smtd>

When reading the MIB ﬁle (/etc/fddi/smtd.mib), an ASN.1 entry (object)

was encountered, on the line of the ﬁle indicated, that was not a

SEQUENCE type. Make a new copy of the ﬁle from a backup copy, then

use smtconﬁg to stop and restart the network interface.

No terminating parenthesis (token): On line digit

<smtd>

When reading the MIB ﬁle (/etc/fddi/smtd.mib), the SMT daemon found

that a required parenthesis was missing on the line of the ﬁle indicated.

Make a new copy of the ﬁle from a backup copy, then use smtconﬁg to

stop and restart the network interface.

nt_send: rc=digit

<smtd>

An attempt to send an NIF request frame failed. The reason for the

failure is indicated by the reason code (rc). See the rc entry in this

listing for the reasons associated with each code. The SMT daemon

software is not functioning correctly. Reboot the system. If this error

message continues to be displayed, reinstall the software. If the problem

still persists, contact the Silicon Graphics Technical Assistance Center.

SMT Error Messages

119

object identifier too long

<smtd>

An invalid entry was found in the MIB ﬁle /etc/fddi/smtd.mib. This may

indicate that the ﬁle is corrupted. Create a new MIB ﬁle and restart the

network interface using the command lines below. If you do not have a

backup copy (/etc/fddi/smtd.mib.orig) of the MIB ﬁle, reinstall your

FDDIXPress software.

% /bin/su

Password: thepassword

# cd /etc/fddi

# /bin/cp smtd.mib.orig smtd.mib

# /usr/etc/smtconfig FDDIinterface down up

-p pattern ???:

The smtping -p command speciﬁed characters that are not hexadecimal.

Use only hexadecimal characters: 0 to 9 and a to f.

digits% packet loss

The number of response ECHO packets received is less than the number

of request ECHO packets sent. The loss is expressed as a percentage: the

number of received packets divided by the number sent. Low

percentages of packet loss are not usually a problem. The number that

constitutes “low” is somewhat subjective. However, when the

percentage of lost packets is greater than ten (10%) and when this

symptom persists for over an hour, it is a good idea to investigate what

is causing the loss. Follow the instructions in “Status Indicators and

Symptoms” on page 87.

packet too short (number bytes)

As smtping attempted to display the response packet, it discovered that

the packet was shorter than the one it had sent. This may indicate that

the responding station is creating malformed packets.

120

Appendix A: Error Messages

patterns must be specified as hex digits

The pattern speciﬁed on the smtping -p command line contained

characters that are not valid hexadecimal characters. The following

characters are valid: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, A, b, B, c, C, d, D, e, E, f, F,

and blank spaces.

Premature end of file: On line digit

<smtd>

When reading the MIB ﬁle (/etc/fddi/smtd.mib), the SMT daemon found

that an end-of-ﬁle indicator was encountered unexpectedly on the line

of the ﬁle indicated. Make a new copy of the ﬁle from a backup copy,

then use smtconﬁg to stop and restart the network interface.

interfacename.#: primary PC_UNKNOWN

<smtd>

When attempting to conﬁgure and bring up a new network interface

and SMT daemon, the software could not locate a primary PHY for the

MAC. This can indicate a problem with the conﬁguration ﬁle

(/etc/fddi/smtd.conf) or with the board. See Appendix B for details about

this conﬁguration ﬁle. If the problem persists, contact the Silicon

Graphics Technical Assistance Center.

The reason codes (rc) are listed in Table A-1 with their hexadecimal and

decimal (digit) representations.

Table A-1 Reason Codes Used in Error Messages

Reason Name Hex

Code

Decimal

Code

Description

RC_NOCLASS 0x1 1 Frame class not supported. Supported classes

are NIF, SIF, ECF, RAF, ESF, and PMF.

RC_NOVERS 0x2 2 Frame version not supported.

RC_SUCCESS 0x3 3 Success.

RC_BADSETCOUNT 0x4 4 Bad SETCOUNT.

SMT Error Messages

121

READ_MIB FAILED

<smtd>

An internal error was detected when attempting to initialize the MIB ﬁle

(/etc/fddi/smtd.mib). This may indicate that the ﬁle is corrupted or

missing. Create a new MIB ﬁle using the command lines below. If you

do not have a backup copy of the MIB ﬁle (/etc/fddi/smtd.mib.orig),

reinstall your FDDIXPress software.

% /sbin/su

# cd /etc/fddi

# /bin/cp smtd.mib.orig smtd.mib

# /usr/etc/smtconfig FDDInetworkinterface down up

Recv Frame error

<smtd>

An recv system or library call failed during reception of a request frame.

This indicates a problem with the operating system.

recvfrom

<smtd>

Arecvfrom system or library call failed. This indicates a problem with the

operating system.

RC_READONLY 0x5 5 Attempt to change read-only parameter.

RC_NOPARM 0x6 6 Requested parameter is not supported.

RC_NOMORE 0x7 7 No more room or parameter for add or

remove.

RC_RANGE 0x8 8 Out of range.

RC_AUTH 0x9 9 Authentication failed.

RC_PARSE 0xa 10 Parameter parsing failed.

RC_TOOLONG 0xb 11 Frame too long.

RC_INVALID 0xc 12 Unrecognized parameter.

Table A-1 (continued) Reason Codes Used in Error Messages

Reason Name Hex

Code

Decimal

Code

Description

122

Appendix A: Error Messages

REQUEST: Illegal FC=hexnumeral

<smtd>

The SMT daemon was attempting to send a request frame, but found

that the frame control (FC) value was for a class that does not allow

request frames (for example, RDF).

REQUEST: Unsupported FC=hexnumeral

<smtd>

The SMT daemon was attempting to send a request frame, but found

that the frame control (FC) value, which was created by another module

of the software, is not supported. For example, RDF requests were not

supported in early versions of FDDIXPress.

Reset interfacename

<smtd>

There is a problem with the FDDI board associated with the network

interface indicated. An automatic reset is in progress. If this message

appears infrequently, it does not indicate a problem. However, if it

occurs frequently, follow the instructions in the section “Checking

Physical Connections” on page 80. If the message continues to display

frequently, contact the Silicon Graphics Technical Assistance Center.

resp_map: sendto

<smtd>

The sendto system or library call failed. This may indicate a problem with

the operating system.

response from station1 instead of station2

The host speciﬁed in the smtinfo command line did not respond. Instead,

information was obtained from a different host. This may indicate that

there are duplicate or switched IP addresses in the hosts database. Verify

the IP addresses for station1 and station2 in the /etc/hosts ﬁle (either local

or on the NIS server).

SMT Error Messages

123

Response message would have been too large

<smtd>

The SMT daemon has encountered a problem. This probably indicates

that the MIB ﬁle (/etc/fddi/smtd.mib) is corrupted. Make a new copy from

the backup. This can indicate that the requesting SMT module has

requested invalid MIB information.

sanity check for interfacename board# failed

<smtd>

An invalid value was detected in the ﬁle /etc/fddi/smtd.conf. In most

cases, another error message will identify the speciﬁc problem. See

Appendix B for details about this conﬁguration ﬁle.

sanity: unsupported MACtype=type

The ﬁle /etc/fddi/smtd.conf has an entry in a type ﬁeld (PHY section) that

is not supported by the network interface being conﬁgured by this entry.

The entry may be incorrect, or the network interface being conﬁgured

with this section of the ﬁle may not be the target (intended) interface.

The conﬁguration ﬁle must be corrected before the station can function.

See Appendix B for details about this conﬁguration ﬁle.

sanity: interfacename unsupported mac type = type

The ﬁle /etc/fddi/smtd.conf has a StationType entry that is not supported

by the indicated network interface, which is being conﬁgured with this

entry. The entry may simply be incorrect, or the network interface being

conﬁgured with this section of the ﬁle may not be the intended one. See

Appendix B for details about this conﬁguration ﬁle.

sanity: unsupported station type=type

The ﬁle /etc/fddi/smtd.conf has an entry in the StationType ﬁeld that is

not supported by the network interface conﬁgured with that station

entry. The entry may be incorrect, or the network interface being

conﬁgured with this section of the ﬁle may not be the target (intended)

interface. The conﬁguration ﬁle must be corrected before the station can

function. See Appendix B for details about this conﬁguration ﬁle.

124

Appendix A: Error Messages

interfacename.#: secondary PC_UNKNOWN

<smtd>

When attempting to conﬁgure and bring up a new network interface

and SMT daemon, the software could not locate a secondary PHY for the

MAC. This can indicate a problem with the conﬁguration ﬁle

(/etc/fddi/smtd.conf) or with the board. See Appendix B for details about

this conﬁguration ﬁle. If the problem persists, contact the Silicon

Graphics Technical Assistance Center.

select

<smtd>

The select system or library call failed. This indicates something wrong

with the operating system. For example, it may be overloaded.

select: systemmessage

When attempting to read the status information ﬁles, the select system or

library call failed. The system error message will provide more details

about the reason for the failure.

send

Asend system call failed. This indicates a problem with the operating

system. For example, it may be overloaded.

sendto

<smtd>

Asendto system call failed. This indicates a problem with the operating

system. For example, it may be overloaded.

send_frame: # bytes not sent

<smtd>

Asend system or library call failed. This indicates a problem with the

operating system.

SMT Error Messages

125

Should be ACCESS (token): On line digit

<smtd>

An expected ACCESS entry was not found in the MIB ﬁle

(/etc/fddi/smtd.mib). Instead, the software encountered token. The

problem is on the line of the ﬁle indicated. Make a new copy of the ﬁle

from a backup copy, then use smtconﬁg to disable and reenable the

network interface.

Should be STATUS (token): On line digit

<smtd>

An expected STATUS entry was not found in the MIB ﬁle

(/etc/fddi/smtd.mib) on the line of the ﬁle indicated. Make a new copy of

the ﬁle from a backup copy, then use smtconﬁg to stop and restart the

network interface.

sm_conf: oport failed

<smtd>

During SMT startup, a system call to set up (open and bind) a raw socket

failed. An additional error message generated by sm_open provides

more detail about the reason for the failure.

sm_multi: SIOCADDMULTI

sm_multi: SIOCDELMULTI

<smtd>

When the SMT daemon was attempting to add or delete a multicast

address, an ioctl system or library call with the SIOCADDMULTI or

SIOCDELMULTI request parameter failed.

sm_open: bind port(portID,portname)

<smtd>

The bind system or library call failed to bind the socket (identiﬁcation

number and name) indicated. This indicates a problem with the

operating system. For example, it may be overloaded.

sm_open: socket

<smtd>

The socket system or library call failed to open (obtain) a socket. This

indicates a problem with the operating system. For example, it may be

overloaded.

126

Appendix A: Error Messages

sm_open: setsockopt (portID)

<smtd>

The setsockopt system or library call failed to set the options for the socket

indicated by portID. This indicates a problem with the operating system.

For example, it may be overloaded.

sm_reset: ioctl(~IFF_UP)

sm_reset: ioctl(IFF_UP)

<smtd>

During an FDDI board reset, the SMT daemon’s attempt to contact the

network interface’s driver failed. Speciﬁcally, the ioctl call to the driver

with the ~IFF_UP or IFF_UP request parameter failed. If this message

occurs infrequently and if the network interface is functioning within a

few minutes of the message appearing, it does not indicate a problem. If

this message is displayed frequently or if the network interface does not

work, there is probably a problem with the driver.

Try manually restarting all the network interfaces on this station with

the command below:

% /bin/su

Password: thepassword

# /etc/init.d/network stop

# /etc/init.d/network start

Then check if the FDDI connection is working. If it is not working, halt

or shut down the system, turn the power off, wait a few minutes, turn

the power back on, and restart the system. If this same error message

occurs, or if the FDDI connection is not working, reinstall the

FDDIXPress software that was shipped with the installed FDDI board.

If the problem persists, contact the Silicon Graphics Technical Assistance

Center.

sm_reset: ioctl(SIOCGIFFLAGS)

<smtd>

During an FDDI board reset, the SMT daemon’s attempt to enable the

network interface driver and verify or save the network interface’s ﬂag

settings, failed. In other words, the ioctl call with the SIOCGIFFLAGS

request parameter failed. Follow the instructions detailed under the

error message sm_reset: ioctl(IFF_UP).

SMT Error Messages

127

sm_reset: socket

<smtd>

While the SMT daemon was attempting to reset itself during an FDDI

board reset, a socket system or library call failed. This indicates a problem

with the operating system. For example, it may be overloaded. This

message does not indicate a problem unless it occurs frequently.

sm_set_macaddr: socket

<smtd>

While the SMT daemon was attempting to associate the network

interface with the FDDI board’s MAC address, a socket system call failed.

This indicates a problem with the operating system.

sm_set_macaddr: ioctl(SIOCSIFADDR)

<smtd>

While the SMT daemon was attempting to associate the FDDI board’s

MAC address with a network interface, an ioctl system call with the

SIOCSIFADDR request parameter failed. This indicates a problem with

the operating system.

smtconfig bind

A bind system or library call failed. This indicates a problem with the

operating system. For example, it may be overloaded.

smtconfig: bind

<smtd>

Abind system or library call failed. This indicates a problem with the

operating system. For example, it may be overloaded.

smtconfig: cannot turn on interfacename except as root

The effective user ID of the calling process (value returned by the geteuid

system call) does not include superuser (root) privileges. Only a

superuser can enable a network interface. Become superuser (su) and

try again.

128

Appendix A: Error Messages

smtconfig: can't exec smtd

An execl system or library call failed to make a new process for the SMT

daemon. This indicates a problem with the operating system.

smtconfig: Command not found.

The path to the directory containing the SMT command has not been

deﬁned in the logged-on user’s environment PATH variable. See

“Conﬁgure the Environment for User Friendliness and Safety

(Optional)” on page 42 for details on how to solve this problem. You can

also type the full path to the command, as follows:

% /usr/etc/smtconfig interfacename

If this command line does not invoke the command, the FDDIXPress

software or the command is not installed. Reinstall the FDDIXPress

software.

smtconfig: interfacename failed to start: systemmessage

The software was unable to start the indicated network interface for the

reasons provided in the standard system message.

smtconfig: entry: no such interface

The indicated network interface that was entered on the smtconﬁg

command line is not known to the system. Follow the instructions below

to resolve the problem:

•Use /usr/etc/netstat -i to list the known, running interfaces.

If the interface you want is listed, try smtconﬁg again.

If the interface you want is not listed, this indicates that the FDDI

driver is not running. It may not be built into the operating system

or the board may not be recognized. Proceed to the next step.

SMT Error Messages

129

•Use the command /usr/sbin/versions FDDIXPress to verify that the

software is installed.

If versions does not ﬁnd FDDIXPress, install the FDDIXPress

software, following the instructions in the FDDIXPress release

notes, and conﬁgure it, following the instructions in Chapter 2.

If FDDIXPress is listed, proceed to the next step.

•Type the /bin/hinv command to verify that the board is installed and

recognized.

If the FDDI controller is not listed, follow the instructions in the

section “Recognition of Board by Software” on page 80.

smtconfig: entry: permission denied

The requested smtconﬁg change (entry) requires that the user have

superuser (root) access privileges. Become superuser (enter su). Then

try again.

smtconfig: smtd failed: systemmessage\numeral

A process could not be created for starting the SMT daemon. This

indicates a problem with the operating system, as detailed in the

systemmessage.

smtconfig SIOC_XPI_EXEC

While loading new ﬁrmware into the FDDI board’s memory, an ioctl

system or library call with the SIOC_XPI_EXEC request parameter failed.

This probably indicates a mismatch between the hardware (FDDI board)

and software. Reinstall the software shipped with the installed board. If

the problem persists, contact the Silicon Graphics Technical Assistance

Center.

smtconfig SIOC_XPI_SIGNAL

While loading new ﬁrmware into the FDDI board’s memory, an ioctl

system or library call with the SIOC_XPI_SIGNAL request parameter

failed. This indicates a problem with the operating system, but not the

I/O system. The software was unable to load the newer ﬁrmware.

130

Appendix A: Error Messages

smtconfig SIOC_XPI_STO

The ioctl system or library call with the SIOC_XPI_STO request

parameter failed while the SMT daemon was attempting to load

ﬁrmware onto an FDDI board. This indicates an incompatibility

between the operating system and smtconﬁg. Use /usr/sbin/versions eoe1

to display the operating system’s version (release). Use

/usr/sbin/relnotes FDDIXPress to display the FDDIXPress release notes.

Verify that your operating system is the correct version, as indicated in

the release notes.

smtconfig SIOC_XPI_VERS

The ioctl system or library call with the SIOC_XPI_VERS request

parameter failed while the SMT daemon was attempting to verify the

ﬁrmware on an FDDI board. This probably indicates a mismatch

between the hardware (FDDI board) and software. Reinstall the

software shipped with the installed board. If the problem persists,

contact the Silicon Graphics Technical Assistance Center.

smtconfig socket

smtconfig: socket

Asocket system or library call failed. This indicates a problem with the

operating system. For example, it may be overloaded.

smtconfig: unrecognized interface: systemmessage

The network interface entered on the smtconﬁg command line is not

known to the system as an FDDI interface. Use /usr/etc/netstat -ina to list

the known interfaces or use /bin/hinv to identify the FDDI hardware and

its associated FDDI interface, then try again. If the network interface you

want to conﬁgure is not listed, verify that the board and software are

installed, then rebuild the operating system with /etc/autoconﬁg, and

reboot to start using the new operating system.

SMT Error Messages

131

smtconfig: WARNING: Writing interfacename EEPROM

Do not reset the machine

This is not an error message. It is included here because it is an extremely

important informational message. When this message is displayed, the

software is in the process of loading (writing) new ﬁrmware into one of

the FDDI board’s chips. Nothing is wrong; however, the computer must

not be interrupted until another smtconﬁg message has been displayed.

smtd: can't fork

<smtd>

The fork system or library call failed. This indicates something wrong

with the operating system. For example, it may be overloaded.

smtd dump

An attempt to obtain status from the remote SMT module failed. This

may indicate that the SMT daemon on the local system has failed. Use

the smtconﬁg command to stop and restart the network interface. If the

problem persists, contact the Silicon Graphics Technical Assistance

Center

smtd_fs: frame too large (len=digits)

<smtd>

An illegal FDDI frame was received; the frame had too many bits.

smtd_fs: frame too small (len=digits)

<smtd>

A received FDDI frame was illegally small.

smtdfs: digit of digit bytes written

<smtd>

Asendto system or library call successfully sent only some of the

requested data. The number of bytes sent and the number requested are

indicated. This may indicate a problem with the operating system.

132

Appendix A: Error Messages

SMT_DOWN

An attempt by smtconﬁg to disable the SMT daemon has failed. Use

/usr/etc/smtconﬁginterfacename down to manually disable the interface. If

this fails, reinstall the software shipped with the board.

SMT_FS_NIF: unknown type(digit)

<smtd>

An illegal NIF frame was received; the frame was not of a known type

(that is, ANNOUNCE,REQUEST, or RESPONSE). Another FDDI station is

transmitting invalid NIF packets.

SMT_FS_RDF: bad length

<smtd>

An RDF response frame was received with an invalid length. Another

FDDI station is transmitting invalid RDF packets.

SMT_FS_RDF: req denied by stationID, rc=hexnumeral

<smtd>

A response RDF frame was received indicating that one of this station’s

request frames has been denied. The station denying the request is

indicated with the reason (rc) indicated. See the rc entry in this listing

for the reasons associated with each code.

smtinfo: can’t find MAC address for station

No MAC address was found for the station speciﬁed on the SMT

command line. (Verify that the name for the speciﬁed station has been

typed correctly on the command line.) This error message usually

indicates that the station has not been added to the ethers or hosts

databases.Verify that the station’s name appears in the local or NIS

server’s/etc/hosts and /etc/ethers ﬁles. If the name is missing from either

ﬁle, add it (as explained in “Setting Up the ethers File (Optional)” on

page 43). Or, if your network uses the NIS service, have your network

administrator add it to the network’s databases.

SMT Error Messages

133

If you maintain local (backup) copies, be sure to copy the NIS server’s

ﬁles to the local machine using the command lines below:

% /bin/su

Password: thepassword

# /usr/bin/ypcat ethers > /etc/ethers

# /usr/bin/ypcat hosts > /etc/hosts

smtinfo: Command not found.

The path to the directory containing the SMT command has not been

deﬁned in the logged on user’s environment PATH variable. See

“Conﬁgure the Environment for User Friendliness and Safety

(Optional)” on page 42 for details on how to solve this problem. You can

also type the full path to the command:

% /usr/etc/smtinfo station

station can be the network connection name or the MAC address.

If this command line does not invoke the command, the FDDIXPress

software or the command is not installed. Reinstall the FDDIXPress

software.

smtinfo: invalid timeout: userinput

The user entered an invalid time-out value. The time-out parameter

entered on the smtinfo -t command line must be a value greater than

zero. Zero and negative values are not legal.

smtinfo: recv

Arecv system or library call failed. This indicates a problem with the

operating system. For example, it may be overloaded. This message

indicates a problem only if it occurs frequently.

smtinfo: recv socket

Asocket system or library call failed. This indicates a problem with the

operating system. For example, it may be overloaded. This message

indicates a problem only if it occurs frequently.

134

Appendix A: Error Messages

smtinfo register failed

An attempt to obtain information from another station failed. This may

indicate an overloaded network or individual station.

smtinfo: sendframe failed

Asendframe system or library call failed. This indicates a problem with

the operating system. For example, it may be overloaded. This is a

problem only if it occurs frequently.

smtinfo version version# doesn’t match daemon’s (version#)

The smtinfo code is a different version from the SMT daemon’s code.

SMT commands must be the same release as the SMT daemon. If the

SMT daemon’s version number has been altered in the /etc/fddi/smtd.conf

or /etc/fddi/smtd.mib ﬁle, the discrepancy could cause this problem. If you

are sure that this is the cause, edit the altered ﬁle’sversion setting back

to the original.

This message may indicate that different versions of smtd and the SMT

command have been installed. To remedy this problem, reinstall the

FDDIXPress software, use /etc/autoconﬁg to rebuild the operating system

with the new driver, then reboot the system.

smtmaint: Command not found

The path to the directory containing the SMT command has not been

deﬁned in the logged on user’s environment PATH variable. See

“Conﬁgure the Environment for User Friendliness and Safety

(Optional)” on page 42 for details on how to solve this problem. You can

also type the full path to the command:

# /usr/etc/smtmaint # linestate

If this command does not invoke the command, the FDDIXPress

software or the command is not installed. Reinstall the FDDIXPress

software.

SMT Error Messages

135

SMT_MAINT: oport failed

<smtd>

When the SMT daemon was called by the smtmaint command, a system

call to setup (open and bind) a raw socket failed. An additional error

message generated by sm_open provides more detail about the reason for

the failure.

smtping: bad preload value

The value entered for the number of preloaded frames on the smtping -l

command line is not valid. The preloaded frames must be zero or greater

than zero. Negative values are not valid.

smtping: bad timing interval

The value entered for a timing interval on the smtping -i command line

is not valid. The timing interval must be greater than zero. Zero and

negative values are not valid.

smtping: can’t find MAC address for station

No MAC address was found for the station speciﬁed on the SMT

command line. (Verify that the name has been typed correctly on the

command line.) This error message usually indicates that the station has

not been added to the ethers or hosts databases.Verify that the station’s

network connection name appears in the local or NIS server’s/etc/hosts

and /etc/ethers ﬁles. If the name is missing from either ﬁle, add it (as

explained in Chapter 2). Or, if your network uses the NIS service, have

your network administrator add it to the network’s databases.

If you maintain local (backup) copies, be sure to copy the NIS server’s

ﬁles to the local machine using the command lines below:

% /bin/su

Password: thepassword

# /usr/bin/ypcat ethers > /etc/ethers

# /usr/bin/ypcat hosts > /etc/hosts

136

Appendix A: Error Messages

smtping: Command not found.

The path to the directory containing the SMT command has not been

deﬁned in the logged on user’s environment PATH variable. See

“Conﬁgure the Environment for User Friendliness and Safety

(Optional)” on page 42 for details on how to solve this problem. You can

also type the full path to the command, as shown in the example below:

% /usr/etc/smtping station

station can be the network connection name or the MAC address.

If this command line does not invoke the command, the FDDIXPress

software or the command is not installed. Reinstall the FDDIXPress

software.

smtping: -d is meaningful only with -x

The smtping command has been invoked with an invalid -d option.

smtping: -f and -i incompatible options

The two smtping command line options -f and -i cannot be used together.

smtping: illegal packet size.

The value entered for setting packet size (in bytes) on the smtping -s

command line is not valid. Packet size must be greater than zero. Zero

and negative values are illegal.

smtping: packet size too large.

The value entered for setting packet size (in bytes) on the smtping -s

command line is not valid. The maximum packet size allowed may vary

from release to release, but is generally less than 4436 bytes.

smtping: recv

Arecv system call failed. This indicates a problem with the operating

system. For example, it may be overloaded. This message indicates a

problem only if it occurs frequently.

SMT Error Messages

137

smtping: recv socket

Arecvsock system call failed. This indicates a problem with the operating

system. For example, it may be overloaded. This message indicates a

problem only if it occurs frequently.

smtping register failed

An attempt to obtain information from (open the connection to) another

station failed. This may indicate an overloaded network or individual

station.

smtping: send socket

Asendsock system call failed. This indicates a problem with the

operating system. For example, it may be overloaded. This message

indicates a problem only if it occurs frequently.

smtping unregister failed

An attempt to obtain information from (close the connection to) another

station failed. This may indicate an overloaded network or individual

station.

smtping version %d doesn’t match daemon’s (version#)

The smtping code is a different version from the SMT daemon’s code.

SMT commands must be the same release as the SMT daemon. If the

SMT daemon’s version number has been altered in the /etc/fddi/smtd.conf

or /etc/fddi/smtd.mib ﬁle, the discrepancy could cause this problem. If you

are sure that this is the cause, edit the altered ﬁle’sversion setting back

to the original. This message may indicate that different versions of smtd

and the SMT command have been installed. To remedy this problem,

reinstall the FDDIXPress software and reboot the system (to rebuild the

operating system with the new driver).

138

Appendix A: Error Messages

smtring bind

The bind system or library call failed when the SMT daemon attempted

to set up a reception socket. This indicates a problem with the operating

system. For example, it may be overloaded. This message indicates a

problem only if it occurs frequently.

smtring: can’t find MAC address for station