Document revision date: 15 July 2002
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Cluster Systems

Previous Contents Index

F.3.5 Monitoring LAN Adapters

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

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

F.4.1 Areas of Trouble

Sections F.5 and F.6 describe two likely areas of trouble for LAN networks: channel formation and retransmission. The discussions of these two problems often include references to the use of a LAN analyzer tool to isolate information in the NISCA protocol.

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.)
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

F.5.2 Techniques for Troubleshooting

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

You can troubleshoot cluster retransmissions using a LAN protocol analyzer for each LAN segment. If multiple segments are used for cluster communications, then the LAN analyzers need to support a distributed enable and trigger mechanism (see Section F.8). See also Section G.1 for more information about how PEDRIVER chooses channels on which to transmit datagrams.

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:

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
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
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.

Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement