Document revision date: 19 July 1999

Use the SDA command SHOW LAN/COUNT to display information about the LAN adapters as maintained by the LAN device driver (the command shows counters for all protocols, not just PEDRIVER [SCA] related counters). Example F-4 shows a sample display from the SHOW LAN/COUNT command.

Example F-4 SDA Command SHOW LAN/COUNTERS Display

$ ANALYZE/SYSTEM SDA> SHOW LAN/COUNTERS LAN Data Structures ------------------- -- EXA Counters Information 22-JAN-1994 11:21:19 -- Seconds since zeroed 3953329 Station failures 0 Octets received 13962888501 Octets sent 11978817384 PDUs received 121899287 PDUs sent 76872280 Mcast octets received 7494809802 Mcast octets sent 183142023 Mcast PDUs received 58046934 Mcast PDUs sent 1658028 Unrec indiv dest PDUs 0 PDUs sent, deferred 4608431 Unrec mcast dest PDUs 0 PDUs sent, one coll 3099649 Data overruns 2 PDUs sent, mul coll 2439257 Unavail station buffs(1) 0 Excessive collisions(2) 5059 Unavail user buffers 0 Carrier check failure 0 Frame check errors 483 Short circuit failure 0 Alignment errors 10215 Open circuit failure 0 Frames too long 142 Transmits too long 0 Rcv data length error 0 Late collisions 14931 802E PDUs received 28546 Coll detect chk fail 0 802 PDUs received 0 Send data length err 0 Eth PDUs received 122691742 Frame size errors 0 LAN Data Structures ------------------- -- EXA Internal Counters Information 22-JAN-1994 11:22:28 -- Internal counters address 80C58257 Internal counters size 24 Number of ports 0 Global page transmits 0 No work transmits 3303771 SVAPTE/BOFF transmits 0 Bad PTE transmits 0 Buffer_Adr transmits 0 Fatal error count 0 RDL errors 0 Transmit timeouts 0 Last fatal error None Restart failures 0 Prev fatal error None Power failures 0 Last error CSR 00000000 Hardware errors 0 Fatal error code None Control timeouts 0 Prev fatal error None Loopback sent 0 Loopback failures 0 System ID sent 0 System ID failures 0 ReqCounters sent 0 ReqCounters failures 0 -- EXA1 60-07 (SCA) Counters Information 22-JAN-1994 11:22:31 -- Last receive(3) 22-JAN 11:22:31 Last transmit(3) 22-JAN 11:22:31 Octets received 7616615830 Octets sent 2828248622 PDUs received 67375315 PDUs sent 20331888 Mcast octets received 0 Mcast octets sent 0 Mcast PDUs received 0 Mcast PDUs sent 0 Unavail user buffer 0 Last start attempt None Last start done 7-DEC 17:12:29 Last start failed None . . .

The SHOW LAN/COUNTERS display usually includes device counter information about several LAN adapters. However, for purposes of example, only one device is shown in Example F-4.

Field	Description
(1) Unavail station buffs (unavailable station buffers)	Records the number of times that fixed station buffers in the LAN driver were unavailable for incoming packets. The node receiving a message can lose packets when the node does not have enough LAN station buffers. (LAN buffers are used by a number of consumers other than PEDRIVER, such as DECnet, TCP/IP, and LAT.) Packet loss because of insufficient LAN station buffers is a symptom of either LAN adapter congestion or the system's inability to reuse the existing buffers fast enough.
(2) Excessive collisions	Indicates the number of unsuccessful attempts to transmit messages on the adapter. This problem is often caused by: A LAN loading problem resulting from heavy traffic (70% to 80% utilization) on the specific LAN segment. A component called a screamer. A screamer is an adapter whose protocol does not adhere to Ethernet or FDDI hardware protocols. A screamer does not wait for permission to transmit packets on the adapter, thereby causing collision errors to register in this field. If a significant number of transmissions with multiple collisions have occurred, then OpenVMS Cluster performance is degraded. You might be able to improve performance either by removing some nodes from the LAN segment or by adding another LAN segment to the cluster. The overall goal is to reduce traffic on the existing LAN segment, thereby making more bandwidth available to the OpenVMS Cluster system.
(3) Last receive and Last transmit	The difference in the times shown in the Last receive and Last transmit message fields should not be large. Minimally, the timestamps in these fields should reflect that HELLO datagram messages are being sent across channels every 3 seconds. Large time differences might indicate: A hardware failure Whether or not the LAN driver sees the NISCA protocol as being active on a specific LAN adapter

F.4 Troubleshooting NISCA Communications

Reference: As you read about how to diagnose NISCA problems, you may also find it helpful to refer to Section F.7, which describes the NISCA protocol packet, and Section F.8, which describes how to choose and use a LAN network failure analyzer.

F.5 Channel Formation

Channel-formation problems occur when two nodes cannot communicate properly between LAN adapters.

F.5.1 How Channels Are Formed

Table F-6 provides a step-by-step description of channel formation.

Table F-6 Channel Formation

Step	Action
1	Channels are formed when a node sends a HELLO datagram from its LAN adapter to a LAN adapter on another cluster node. If this is a new remote LAN adapter address, or if the corresponding channel is closed, the remote node receiving the HELLO datagram sends a CCSTART datagram to the originating node after a delay of up to 2 seconds.
2	Upon receiving a CCSTART datagram, the originating node verifies the cluster password and, if the password is correct, the node responds with a VERF datagram and waits for up to 5 seconds for the remote node to send a VACK datagram. (VERF, VACK, CCSTART, and HELLO datagrams are described in Section F.7.6.)
3	Upon receiving a VERF datagram, the remote node verifies the cluster password; if the password is correct, the node responds with a VACK datagram and marks the channel as open. (See Figure F-2.)
4	WHEN the local node... THEN... Does not receive the VACK datagram within 5 seconds The channel state goes back to closed and the handshake timeout counter is incremented. Receives the VACK datagram within 5 seconds and the cluster password is correct The channel is opened.
5	Once a channel has been formed, it is maintained (kept open) by the regular multicast of HELLO datagram messages. Each node multicasts a HELLO datagram message at least once every 3.0 seconds over each LAN adapter. Either of the nodes sharing a channel closes the channel with a listen timeout if it does not receive a HELLO datagram or a sequence message from the other node within 8 to 9 seconds. If you receive a "Port closed virtual circuit" message, it indicates a channel was formed but there is a problem receiving traffic on time. When this happens, look for HELLO datagram messages getting lost.

Figure F-2 shows a message exchange during a successful channel-formation handshake.

Figure F-2 Channel-Formation Handshake

When there is a break in communications between two nodes and you suspect problems with channel formation, follow these instructions:

Step	Action
1	Check the obvious: Is the remote node powered on? Is the remote node booted? Are the required network connections connected? Do the cluster multicast datagrams pass through all of the required bridges in both directions? Are the cluster group code and password values the same on all nodes?
2	Check for dead channels by using SDA. The SDA command SHOW PORT/CHANNEL/VC=VC_ remote_node can help you determine whether a channel ever existed; the command displays the channel's state. Reference: Refer to Section F.3 for examples of the SHOW PORT command. Section F.10.1 describes how to use a LAN analyzer to troubleshoot channel formation problems.
3	See also Appendix D for information about using the LAVC$FAILURE_ANALYSIS program to troubleshoot channel problems.

F.6 Retransmission Problems

Retransmissions occur when the local node does not receive acknowledgment of a message in a timely manner.

F.6.1 Why Retransmissions Occur

The first time the sending node transmits the datagram containing the sequenced message data, PEDRIVER sets the value of the REXMT flag bit in the TR header to 0. If the datagram requires retransmission, PEDRIVER sets the REXMT flag bit to 1 and resends the datagram. PEDRIVER retransmits the datagram until either the datagram is received or the virtual circuit is closed. If multiple channels are available, PEDRIVER attempts to retransmit the message on a different channel in an attempt to avoid the problem that caused the retransmission.

Retransmission typically occurs when a node runs out of a critical resource, such as large request packets (LRPs) or nonpaged pool, and a message is lost after it reaches the remote node. Other potential causes of retransmissions include overloaded LAN bridges, slow LAN adapters (such as the DELQA), and heavily loaded systems, which delay packet transmission or reception. Figure F-3 shows an unsuccessful transmission followed by a successful retransmission.

Figure F-3 Lost Messages Cause Retransmissions

Because the first message was lost, the local node does not receive acknowledgment (ACK) from the remote node. The remote node acknowledged the second (successful) transmission of the message.

Retransmission can also occur if the cables are seated improperly, if the network is too busy and the datagram cannot be sent, or if the datagram is corrupted or lost during transmission either by the originating LAN adapter or by any bridges or repeaters. Figure F-4 illustrates another type of retransmission.

Figure F-4 Lost ACKs Cause Retransmissions

In Figure F-4, the remote node receives the message and transmits an acknowledgment (ACK) to the sending node. However, because the ACK from the receiving node is lost, the sending node retransmits the message.

F.6.2 Techniques for Troubleshooting

Reference: Techniques for isolating the retransmitted datagram using a LAN analyzer are discussed in Section F.10.2. See also Appendix G for more information about congestion control and PEDRIVER message retransmission.

F.7 Understanding NISCA Datagrams

Troubleshooting NISCA protocol communication problems requires an understanding of the NISCA protocol packet that is exchanged across the OpenVMS Cluster system.

F.7.1 Packet Format

The format of packets on the NISCA protocol is defined by the $NISCADEF macro, which is located in [DRIVER.LIS] on VAX systems and in [LIB.LIS] for Alpha systems on your CD listing disk.

Figure F-5 shows the general form of NISCA datagrams. A NISCA datagram consists of the following headers, which are usually followed by user data:

• LAN headers, including an Ethernet or an FDDI header
• Datagram exchange (DX) header
• Channel control (CC) or transport (TR) header

Figure F-5 NISCA Headers

Caution: The NISCA protocol is subject to change without notice.

F.7.2 LAN Headers

The NISCA protocol is supported on LANs consisting of Ethernet and FDDI, described in Sections F.7.3 and F.7.4. These headers contain information that is useful for diagnosing problems that occur between LAN adapters.

Reference: See Section F.9.4 for methods of isolating information in LAN headers.

F.7.3 Ethernet Header

Each datagram that is transmitted or received on the Ethernet is prefixed with an Ethernet header. The Ethernet header, shown in Figure F-6 and described in Table F-7, is 16 bytes long.

Figure F-6 Ethernet Header

Table F-7 Fields in the Ethernet Header

Field	Description
Destination address	LAN address of the adapter that should receive the datagram
Source address	LAN address of the adapter sending the datagram
Protocol type	NISCA protocol (60--07) hexadecimal
Length	Number of data bytes in the datagram following the length field

F.7.4 FDDI Header

Each datagram that is transmitted or received on the FDDI is prefixed with an FDDI header. The NISCA protocol uses mapped Ethernet format datagrams on the FDDI. The FDDI header, shown in Figure F-7 and described in Table F-8, is 23 bytes long.

Figure F-7 FDDI Header

Table F-8 Fields in the FDDI Header

Field	Description
Frame control	NISCA datagrams are logical link control (LLC) frames with a priority value (5 x). The low-order 3 bits of the frame-control byte contain the priority value. All NISCA frames are transmitted with a nonzero priority field. Frames received with a zero-priority field are assumed to have traveled over an Ethernet segment because Ethernet packets do not have a priority value and because Ethernet-to-FDDI bridges generate a priority value of 0.
Destination address	LAN address of the adapter that should receive the datagram.
Source address	LAN address of the adapter sending the datagram.
SNAP SAP	Subnetwork access protocol; service access point. The value of the access point is AA--AA--03 hexadecimal.
SNAP PID	Subnetwork access protocol; protocol identifier. The value of the identifier is 00--00--00 hexadecimal.
Protocol type	NISCA protocol (60--07) hexadecimal.
Length	Number of data bytes in the datagram following the length field.

F.7.5 Datagram Exchange (DX) Header

The datagram exchange (DX) header for the OpenVMS Cluster protocol is used to address the data to the correct OpenVMS Cluster node. The DX header, shown in Figure F-8 and described in Table F-9, is 14 bytes long. It contains information that describes the OpenVMS Cluster connection between two nodes. See Section F.9.3 about methods of isolating data for the DX header.

Figure F-8 DX Header

Table F-9 Fields in the DX Header

Field	Description
Destination SCS address	Manufactured using the address AA--00--04--00-- remote-node-SCSSYSTEMID. Append the remote node's SCSSYSTEMID system parameter value for the low-order 16 bits. This address represents the destination SCS transport address or the OpenVMS Cluster multicast address.
Cluster group number	The cluster group number specified by the system manager. See Chapter 8 for more information about cluster group numbers.
Source SCS address	Represents the source SCS transport address and is manufactured using the address AA--00--04--00-- local-node-SCSSYSTEMID. Append the local node's SCSSYSTEMID system parameter value as the low-order 16 bits.

F.7.6 Channel Control (CC) Header

The channel control (CC) message is used to form and maintain working network paths between nodes in the OpenVMS Cluster system. The important fields for network troubleshooting are the datagram flags/type and the cluster password. Note that because the CC and TR headers occupy the same space, there is a TR/CC flag that identifies the type of message being transmitted over the channel. Figure F-9 shows the portions of the CC header needed for network troubleshooting, and Table F-10 describes these fields.

Figure F-9 CC Header

Table F-10 Fields in the CC Header

Field	Description
Datagram type (bits <3:0>)	Identifies the type of message on the Channel Control level. The following table shows the datagrams and their functions. Value Abbreviated Datagram Type Expanded Datagram Type Function 0 HELLO HELLO datagram message Multicast datagram that initiates the formation of a channel between cluster nodes and tests and maintains the existing channels. This datagram does not contain a valid cluster password. 1 BYE Node-stop notification Datagram that signals the departure of a cluster node. 2 CCSTART Channel start Datagram that starts the channel-formation handshake between two cluster nodes. This datagram is sent in response to receiving a HELLO datagram from an unknown LAN adapter address. 3 VERF Verify Datagram that acknowledges the CCSTART datagram and continues the channel formation handshake. The datagram is sent in response to receiving a CCSTART or SOLICIT_SRV datagram. 4 VACK Verify acknowledge Datagram that completes the channel-formation handshake. The datagram is sent in response to receiving a VERF datagram. 5 Reserved     6 SOLICIT_SERVICE Solicit Datagram sent by a booting node to form a channel to its disk server. The server responds by sending a VERF, which forms the channel. 7--15 Reserved
Datagram flags (bits <7:4>)	Provide additional information about the control datagram. The following bits are defined: Bit <4> (AUTHORIZE)---Set to 1 if the cluster password field is valid. Bit <5> (Reserved)---Set to 1. Bit <6> (Reserved)---Set to 0. Bit <7> (TR/CC flag)---Set to 1 to indicate the CC datagram.
Cluster password	Contains the cluster password.

	privacy and legal statement
4477PRO_032.HTML