|
|  以 PDF 格式下载本书 (253 KB)
Chapter 2 Using the SunFDDI Network UtilitiesThis chapter describes the network utilities of SunFDDI. While some examples show only pf or nf, unless otherwise noted, all instructions apply to both the SunFDDI PCI adapter (pf) and the SunFDDI SBus adapter (nf). Throughout this chapter, it is assumed that you have installed the SunFDDI software under the default base directory <basedir> for your operating system: The default base directory <basedir> is: /opt/SUNWconn/bin Changing the Default MAC AddressEach attachment to an FDDI network is identified by a unique 48-bit MAC address. By default, the first SunFDDI card takes the host-resident MAC address, which is stored in nonvolatile memory (NVRAM) on the motherboard of the machine. Each subsequent SunFDDI card adopts the card-resident MAC address stored in its own IDPROM. In general, this convention is sufficient to ensure that each SunFDDI card installed in the machine has a unique MAC address. However, there may be a conflict with other LAN interfaces that also take the host-resident MAC address--for example, an Ethernet (le) interface or a SunFDDI 2.0 (bf) interface. In this event, change the default MAC address assigned to the first SunFDDI card installed in the system. To Change the Default MAC Address with pf_macid or nf_macidUse the pf_macid(1M) or the nf_macid(1M) utility to recover the card-resident MAC address, and then modify the system files to override the default MAC address:
When a SunFDDI card takes the host-resident MAC address, it can be swapped to another system without affecting the existing network. However, once a station starts sending packets on the network, the Address Resolution Protocol (ARP) updates the ARP tables on other stations to include the MAC address of its interface. The ES-IS protocol performs the same function for SunFDDI OSI running over FDDI. If you swap SunFDDI cards that use the card-resident MAC address, you must wait until the ARP entries time-out, or remove the ARP entries from every active station manually before packets can be routed correctly. Displaying SunFDDI StatisticsThe pf_stat(1M)or nf_stat utility interrogates a specified SunFDDI interface and displays the accumulated statistics. This command must be executed as root and has the general form: # <basedir>/pf_stat [-m] pf<inst> [<interval>] [<count>] pf<inst> specifies the SunFDDI interface <interval> is the elapsed time (in seconds) between interrogations <count> the total number of interrogations The pf_stat utility displays information using column headings that conform to SMT revision 7.3, which differ from SMT revision 5.1 and 4.2 headings in the following cases:
Displaying Local Interface StatisticsWhen you enter the pf_stat command without the -m option, it displays statistics recovered from the local interface pf<inst>. For example, to display the accumulated statistics for the interface pf0, type: # <basedir>/pf_stat pf0 Ring ECM RMT PCMS Ring_OP XmitP RecvP UP IN RING_OP ACTIVE c 16fde 1862d You can also monitor the interface dynamically (active monitor), by specifying the interval (the elapsed time between interrogations) and count (the total number of interrogations). This displays the incremental difference between the current state and the previous state. The minimum interval is one second and the accumulated statistics are displayed after every tenth interrogation. For example, to monitor the interface pf0 once every 60 seconds for 3 minutes (a total of 3 interrogations), type: # <basedir>/pf_stat pf0 60 3 Ring ECM RMT PCMS Ring_OP XmitP RecvP UP IN RING_OP ACTIVE c 131a0 131aa UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 1 1 Interpreting Local StatisticsRunning the pf_stat utility without the -m option displays information about the various SMT state machines and the network to which the local station is attached: Ring (Ring Status)The Ring status shows the current state of the physical connection to the FDDI network. The following states may be returned by pf_stat under the Ring heading
ECM (Entity Coordination Management)ECM shows the current state of the Entity Coordination Management state machine, which controls the following features and facilities:
Table 2-1 lists the states that may be returned by pf_stat under the ECM heading. Table 2-1 pf_stat States Under the ECM Heading
RMT (Ring Management)RMT shows the current state of the Ring Management state machine, which controls the following features and facilities:
Table 2-2 lists the states that may be returned by pf_stat under the RMT heading. Table 2-2 pf_stat States Under the RMT Heading
PCM (Physical Connection Management)PCM shows the current state of the Physical Connection Management state machine that controls the following features and facilities:
This heading is modified to indicate the type of port that is being managed:
TABLE 2-3 lists the states that may be returned by pf_stat under the PCM heading. Table 2-3 pf_stat States Under the PCM Heading
The normal sequence of PCM states leading to a fully synchronized connection and incorporation of the port into the token path is shown in Figure 2-1. Note that the minimum interval between interrogations is one second and that this is not always fast enough to recover and display the complete sequence of PCM states. Figure 2-1 Normal Sequence of PCM States
Ring_OP (Ring Operational)Ring_OP shows the number of Ring_OP (Ring Operational) signals received. This signal is generated when the station is incorporated into an operational network. XmitP (Transmit Packets)Running pf_stat without an interval and count, displays the total number of packets transmitted since the interface was activated. Running pf_stat with an interval and count, displays the number of packets transmitted since the last interrogation. RecvP (Receive Packets)Running pf_stat without an interval and count displays the total number of packets received since the interface was activated. Running pf_stat with an interval and count displays the number of packets received since the last interrogation. Example Local StatisticsThe following output was recovered from a single-attached station using the command shown. A temporary fault condition was simulated by disconnecting the FDDI cable from the SunFDDI card and then reconnecting it. # <basedir>/pf_stat pf0 1 20 Ring ECM RMT PCMS Ring_OP XmitP RecvP UP IN RING_OP ACTIVE 2 26 1d UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 DOWN IN ISOLATED CONNECT 0 1 1 DOWN IN ISOLATED CONNECT 0 0 0 DOWN IN ISOLATED NEXT 0 0 0 UP IN RING_OP ACTIVE 1 0 0 UP IN RING_OP ACTIVE 0 1 1 Ring ECM RMT PCMS Ring_OP XmitP RecvP UP IN RING_OP ACTIVE 3 29 20 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 1 1 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 0 0 UP IN RING_OP ACTIVE 0 1 1 Note the following observations regarding this example:
The link status indicator mounted on the SunFDDI card displays the following sequence of events: Green (connected) -> Amber (disconnected) --> Green (connected) Displaying Statistics from Neighboring StationsWhen you use the pf_stat or nf_stat command with the -m option, it displays information about the neighboring stations attached to the local interface pf<inst> and the frames received from the network. For example, to display information about the neighboring stations attached to the interface pf0, type: # <basedir>/pf_stat --m pf0 PhyS Frame Error Lost SA UNA DNA M b43eb2 0 3 <mac_addr1> <mac_addr2> <mac_addr3> You can also monitor the neighboring stations dynamically (active monitor), by specifying the interval (the elapsed time in seconds between interrogations) and count (the total number of interrogations). The minimum interval is one second and the accumulated statistics are displayed after every tenth interrogation. For example, to monitor the stations attached to pf0 once every 10 seconds for 1 minute (a total of 6 interrogations), type: # <basedir>/pf_stat --m pf0 10 6 PhyS Frame Error Lost SA UNA DNA M c460a6d 0 3 <mac_addr1> <mac_addr2> <mac_addr3> M 27224 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27227 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27220 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 2722e 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27223 0 0 <mac_addr1> <mac_addr2> <mac_addr3> Interpreting Statistics from Neighboring StationsRunning the pf_stat utility with the -m option displays information about the neighboring stations attached to the local interface pf<inst>. Phy (Physical Connection)PHY shows the type of physical connection to the FDDI network. This heading is modified to indicate the type of port being managed:
The following states may be returned by pf_stat under the Phy heading: Table 2-4 pf_stat States Under the PHY Heading
Frame (Frames Received)Running pf_stat or nf_stat without an interval and count displays the total number of SMT frames received since the interface was activated. Running pf_stat or nf_stat with an interval and count displays the number of SMT frames received since the last interrogation. More detailed information about the SMT frames can be recovered using the pf_smtmon(1M) or nf_smtmon(1M) utility described in "Monitoring SMT Frames". Error (Error Frames)Running pf_stat or nf_stat without an interval and count displays the total number of error frames received since the interface was activated. Running pf_stat or nf_stat with an interval and count displays the number of error frames received since the last interrogation. An error frame is defined as an SMT frame whose E (error) bit is set, and whose E bit is first detected by the local station. It does not indicate the location of the cause of the error. Frequent error frames can indicate a noise problem on the network, either dirt (optical fiber) or electrical interference (UTP). Lost (Lost Frames)Running pf_stat or nf_stat without an interval and count displays the total number of lost frames since the interface was activated. Running pf_stat or nf_stat with an interval and count displays the number of lost frames since the last interrogation. A lost frame is defined as an SMT frame whose reception is aborted by the local station. It does not indicate the location of the cause of the error. A large number of lost frames can indicate a noise problem on the network, either dirt (optical fiber) or electrical interference (UTP). SA (Station Address)Displays the MAC address for the local station. UNA (Upstream Neighbor Address)Displays the MAC address for the neighboring station, connected upstream on the ring from the local station. DNA (Downstream Neighbor Address)Displays the MAC address for the neighboring station, connected downstream on the ring from the local station. Example Neighbor StatisticsThe following output was recovered from a single-attached station using the command shown. A temporary fault condition was simulated by disconnecting the FDDI cable from the SunFDDI card and then reconnecting it. # <basedir>/pf_stat --m pf0 1 20 PhyS Frame Error Lost SA UNA DNA M c45d5463 1 1b <mac_addr1> <mac_addr2> <mac_addr3> M 27437 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27427 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27435 0 0 <mac_addr1> <mac_addr2> <mac_addr3> NONE 182f1 0 0 <mac_addr1> <mac_addr2> <mac_addr3> NONE 0 0 0 <mac_addr1> <mac_addr2> <mac_addr3> NONE 0 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M d432 0 7 <mac_addr1> <mac_addr2> <mac_addr3> M 2707e 0 0 <mac_addr1> <mac_addr2> <mac_addr3> PhyS Frame Error Lost SA UNA DNA M c46e5ce7 1 22 <mac_addr1> <mac_addr2> <mac_addr3> M 27228 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27230 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27227 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 2722e 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 2722c 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27228 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27231 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 2722b 0 0 <mac_addr1> <mac_addr2> <mac_addr3> M 27227 0 0 <mac_addr1> <mac_addr2> <mac_addr3> Note the following observations regarding this example:
Monitoring SMT FramesThe pf_smtmon(1M) or nf_smtmon(1M) utility is an active monitor that displays the SMT frames received by the local station. It is particularly useful for diagnosing communication problems with the SunNet Manager proxy agent. This command must be executed as root (or superuser) and has the general form: # <basedir>/pf_smtmon [-i pf<inst>] [--x] [--h] [<frameclass>] -i pf<inst> specifies the SunFDDI interface -x displays the received SMT frames in hexadecimal -h displays help information, including a list of valid frame classes <frameclass> specifies one or more SMT frame classes (used to filter output) If you do not specify an interface, pf_smtmon(1M) or nf_smtmon(1M) returns the SMT frames received by pf0. If you do not specify a frame type, pf_smtmon displays all the SMT frames that it receives. Use Ctrl-C to stop pf_smtmon(1M) or nf_smtmon(1M). To display the encoded SMT frames received by interface pf1, type: # <basedir>/pf_smtmon -i pf1 pf1: nif_request v=0x1 t=0xfc03e781 s=10-0-4-48-6f-a5 i=0x28 pf1: nif_response v=0x1 t=0xfc03e781 s=10-0-4-8-24-5c i=0x28 pf1: nif_request v=0x1 t=0xfc00dec6 s=10-0-4-b8-6e-ab i=0x28 pf1: nif_request v=0x1 t=0xfc03e787 s=10-0-4-48-6f-a5 i=0x28 pf1: nif_response v=0x1 t=0xfc03e787 s=10-0-4-8-24-5c i=0x28 The elements of the SMT frames are defined as follows: Table 2-5 Elements of the SMT Frames
SMT Frame Classes and TypesSMT frames are used for peer-to-peer (station-to-station) management. They are divided into classes, which define the function of the frame. Each class is then divided into up to three types, which define whether the frame is an announcement (information only), a request for service, or a response to a request. Refer to the ANSI/FDDI Station Management (SMT) X3.299 R7.3 Specification for a detailed description of SMT frames and their functions. The pf_smtmon(1M) or nf_smtmon(1M) utility is used to monitor the following SMT frame classes: NIF (Neighbor Information Frames)These are the most common frames displayed when you run pf_smtmon(1M) or nf_smtmon(1M). As the name suggests, they carry information about a neighboring station (for example, address, description, state, MAC capabilities) and are used as keep-alive notifications that a station is still attached to the ring and functioning. An NIF frame can be an announcement, a request, or a response. SIF (Status Information Frames)These frames carry more detailed information about a station. SIF configuration frames describe the station configuration (for example, number of ports, number of MAC entities, connection policy). SIF operation frames describe the current status of the station. A SIF frame can be either a request or a response. ECF (Echo Frames)These frames are equivalent to ICMP ping packets and are used to test connectivity between stations. An ECF frame can be either a request or a response. RDF (Request Denied Frame)These frames are used to indicate that the request is rejected. If an SMT agent (such as the SunNet Manager proxy agent delivered with SunFDDI) receives an unsupported or unrecognized request, it issues an RDF frame to indicate that the request is rejected. An RDF frame is always a response. ESF (Extended Service Frame)These frames are implementation dependent. An ESF frame can be an announcement, a request, or a response. PMF (Parameter Management Frame)These frames are used to access remote station attributes. The Parameter Management Protocol supports both get (display) and set (modify) functions. However, the pf_smtmon(1M) or nf_smtmon(1M) utility can display only PMF_get frames. A PMF_get frame can be either a request or a response. Filtering Output from pf_smtmonBy default, pf_smtmon(1M) or nf_smtmon(1M) displays all of the SMT frames received by the local station. You can filter the output generated by pf_smtmon(1M) or nf_smtmon(1M) by specifying one or more frame classes on the command-line: nif, sif_config, sif_operat, ecf, rdf, esf, pmf_get. For example:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|