This chapter describes how to maintain, monitor, and verify the IRIS HIPPI subsystem.
IRIS HIPPI can be monitored and maintained with the commands summarized in Table 3-1.
Table 3-1. Utilities for Monitoring and Maintaining IRIS HIPPI
Command | Purpose |
|---|---|
Adds and deletes entries from the lookup table (in memory) that maps HIPPI I-fields to IP addresses. | |
Provides a variety of control and status functions for the IRIS HIPPI subsystem. | |
Verifies IRIS HIPPI subsystem through the character device interface, without going through the IP network interface. | |
Verifies IP network interfaces. Can be used to verify that a hip# network interface is functioning. | |
All the normal IP configuration options work with IRIS HIPPI IP network interfaces (that is, hip#), except broadcast, arp, and the specification of a destination IP address for setting up a point-to-point connection. | |
All the normal network status information is available for IP interfaces to IRIS HIPPI. Non-IP interfaces are not displayed; however, if the IRIS HIPPI driver has been built with IP support, a disabled hip0 interface with no IP address is shown. |
This section describes some of procedures commonly used to monitor and maintain the IRIS HIPPI subsystem. All of the IRIS HIPPI utilities (hipmap, hipcntl, and hiptest) require the user to have superuser (root) privileges.
To shut down or disable the IRIS HIPPI board, use the command below. This resets the board; all data (incoming or outgoing) that is on the board is lost.
# hipcntl [hippi#] shutdown |
To start or enable the IRIS HIPPI board, use the command below. This command verifies that the versions of the firmware on the board and the driver in the operating system match. If they do not match, the driver loads a compatible version of firmware onto the board.
# hipcntl [hippi#] startup |
To configure the IRIS HIPPI subsystem so that the transmit channel does not generate any connection REQUEST signals and so that the receive channel does not generate any CONNECT (accept) signals, use the command below:
# hipcntl [hippi#] reject |
To configure the IRIS HIPPI subsystem so that both the transmit and receive channels open connections, use the command below. This command results in the transmit channel generating connection REQUESTs when host applications send data, and in the receive channel generating CONNECT signals in response to connection REQUESTs.
# hipcntl [hippi#] accept |
To display status information for an IRIS HIPPI board, use the command below. Each counted item is initialized to zero upon reset of the board. The counters roll over to zero upon reaching 232. The displayed information is described in Table 3-2.
# hipcntl [hippi#] status |
Table 3-2. IRIS HIPPI Status Information
Status Item | Description |
|---|---|
FLAGS: |
|
DSIC | SRC sees the INTERCONNECT input signal. |
SDIC | DST sees the INTERCONNECT input signal. |
ACCEPTING | DST is accepting connections. When this flag is not listed, the DST is rejecting connections. |
DST.PKT | DST sees that the PACKET input signal is asserted |
DST.REQ | DST sees that the REQUEST input signal is asserted |
SRC.REQ | SRC channel's REQUEST output signal is asserted |
SRC.CON | SRC sees that the CONNECT input signal is high |
SRC connections: | Count of total connection REQUEST signals issued by source. |
SRC packets: | Count of total packets sent by source. |
SRC rejects: | Count of connection attempts that were rejected by the destination. |
SRC seq errors (dm): | Count of data state machine's sequence errors. |
SRC seq errors (cd): | Count of connection state machine's sequence errors for which the destination is believed to be at fault. |
SRC seq errors (cs): | Count of connection state machine's sequence errors for which the source is believed to be at fault. |
SRC dsic lost: | Count of connections dropped due to lost DSIC signal. |
SRC time outs: | Count of connection attempts that timed out so that the source withdrew the request. |
SRC connects lost: | Count of connections that were dropped by the destination. |
SRC parity errs: | Count of source parity errors. |
DST connections: | Count of connections accepted. |
DST packets: | Count of total packets received |
DST rcv on bad ulp: | Count of packets discarded due to unknown ULP-id. |
DST hippi-le drop: | Count of HIPPI-LE packets discarded. |
DST llrc: | Count of connections dropped due to LLRC errors. |
DST parity: | Count of connections dropped due to parity errors. |
DST sequence err: | Count of connections dropped due to sequence errors. |
DST sync err: | Count of synchronization errors. |
DST illegal burst: | Count of packets with illegal burst sizes. |
DST sdic lost: | Count of connections dropped due to lost SDIC signal. |
DST null connections | Count of connections with zero packets. |
To enable/disable the IP network interface to the IRIS HIPPI board, use the standard /usr/etc/ifconfig command, as shown below.
# ifconfig [hip#] down # ifconfig [hip#] up |
Dynamic configuration of the IP network interfaces is done with the /usr/etc/ifconfig command, which is explained in detail in the man page. The command lines listed below are available for use with IRIS HIPPI:
# ifconfig [hip#] IPaddr # ifconfig [hip#] up # ifconfig [hip#] down # ifconfig [hip#] netmask ######## # ifconfig [hip#] metric # |
 | Note: Some of the standard ifconfig arguments are not supported for IRIS HIPPI. |
The /usr/etc/hipmap command makes changes to the lookup table that is currently in memory.
To add an entry to the look up table, use this command line:
# hipmap hostname I-field_value [ULA_value] |
To delete one entry from the lookup table, use this command line:
# hipmap -d hostname |
To delete all the entries from the lookup table, use this command line:
# hipmap -D |
To concatenate entries from a file onto the lookup table, use this command line:
# hipmap -f filename |
To clear the lookup table, then add entries from a file, use this command line:
# hipmap -D -f filename |
Use the command line below to display the table of IP addresses mapped to I-fields that is currently loaded into memory:
# hipmap -a |
To dynamically change the timeout value used by the IRIS HIPPI source channel, use the command line below. The source timeout is the amount of time that the source channel waits for a CONNECT or READY signal from the destination before it aborts the request.
In this command line, the timeout is expressed in milliseconds. The granularity for this timeout is a quarter of a second (that is, 250 milliseconds). A timeout value that are not divisible by 250 is rounded up to the next quarter-second.
# hipcntl [hippi#] stimeo timeout_in_milliseconds |
The most reliable method for verifying an IRIS HIPPI subsystem is to install a loopback link between the destination and source on the same system, then run the hiptest verification test described under the heading “Verify the Interface to HIPPI-FP” in this section. After the HIPPI subsystem has been verified, further upper-layer verification tests can be run (for example, the test described under the heading “Verify an IP Interface” in this section).
To install a loopback link, use any of the procedures illustrated below:
Use any standard HIPPI cable to connect the IRIS HIPPI DST and SRC ports on the system's I/O panel plate to each other, as illustrated in Figure 3-1.
Use a special loopback (female-to-female) cable to connect the other end of the HIPPI destination and source cables as illustrated in Figure 3-2.
At a switch, connect the cables coming from the IRIS HIPPI board to the same port or to two different ports. For example, the cable from the IRIS HIPPI destination could be attached to the OUT of port 1, while the cable from the IRIS HIPPI source could be attached to the IN of port 1 (or of port 2).
Note: This loopback configuration requires you to use a valid I-field during the test and assumes that the switch is functional.
To verify the IRIS HIPPI-FP subsystem (without going through the IP stack), use the /usr/etc/hiptest command. The test only works for an IRIS HIPPI board that has a loopback link installed between its source and destination channels. The command is available only to superuser (root).
This test sends randomly-sized HIPPI-FP packets that contain randomly generated data as the D2 data set. The test then reads the received packets and verifies that the received data matches the data that was sent. The following items from the received packet are compared to those items from the transmitted packet: length of the header (FP header and D1 data area), length of the D2 area, and data integrity (word-by-word comparison) for the D2 data set.
The command creates HIPPI-FP packets with the following non-configurable characteristics:
| FP header | 8 bytes of FP header where all fields contain valid values for the packet. The ULP-id used is 0x89 (hexadecimal). | |
| D1 area size | 24 bytes. | |
| D1 data set | Zero. | |
| D2 area size | Randomly generated size, up to the constraining bytecount specified by maxsize. The first words of D2 area are included in the first burst of the packet. | |
| D2 data set | Randomly generated data. |
The command allows you to specify the following packet characteristics:
| -I | The I-field value (in hexadecimal format) to use for the connection request. If not specified on the command line, the command uses 0x00000001. # /usr/etc/hiptest -I 0x07001002 | |
| -D | The IRIS HIPPI board to test: /dev/hippi0, /dev/hippi1, etc.. If not specified on the command line, the command uses /dev/hippi0. # /usr/etc/hiptest -D /dev/hippi3 | |
| maxsize | The maximum bytesize (in decimal format) for the packets. The value specified is rounded down to a number that is divisible by 8. The minimum is 32 (8 bytes of FP header and 24 bytes of D1 data). The maximum is 2 megabytes (that is, 2097152 bytes). When maxsize is specified, #packets must also be specified. If maxsize is not specified on the command line, the command uses 2 megabytes. For an example, see the command line shown for #packets. | |
| #packets | The number of packets (in decimal format) to send before dropping the connection and ending the test. The minimum is 1. There is no maximum. When #packets is specified, maxsize must also be specified.If #packets is not specified on the command line, the command uses 100. # /usr/etc/hiptest 1500 10 |
The command line usage for hiptest is summarized below. After the command is invoked, each successfully sent packet is indicated with a dot. To terminate the test at any point, press the <Ctrl> and <C> keys simultaneously.
hiptest [-I 0x<Ifieldvalue>] [-D /dev/hippi[0-3]] [maxsize [#pckts] ] |
Examples:
To run the test using the default settings, use the commands below:
% cd /usr/etc % su Password: thepassword # hiptest /dev/hippi0 sending 100 packets of size [0..2097152] to I-field 0x00000001 ...................... <up to 100 dots> |
To send one minimum-sized packet, use the command line below:
# hiptest 32 1 /dev/hippi0 sending 1 packets of size [0..32] to I-field 0x00000001 . |
To send 25 packets of up to 2 megabytes on a loopback test, use the command line below:
# hiptest 2097152 25 /dev/hippi0 sending 25 packets of size [0..2097152] to I-field 0x00000001 ......................... |
To run the test when there is a switch located along the loopback link, specify a valid I-field, as illustrated in the command below. You must replace the I-field shown in the example with one that is appropriate; however, it is recommended that the I-field (as shown in this example) have the camp-on bit set to one, the PS bits set to zero for source addressing, and the rightmost bits set to the port identification number for the IRIS HIPPI destination.
# hiptest -I 0x01000002 /dev/hippi0 sending 100 packets of size [0..2097152] to I-field 0x01000002 ...................... <up to 100 dots> # |
To test four different IRIS HIPPI boards, invoke the command in four separate shell windows or execute it four times in the background, as in the example below:
# hiptest -D/dev/hippi0 & # hiptest -D/dev/hippi1 & # hiptest -D/dev/hippi2 & # hiptest -D/dev/hippi3 & |
If the hiptest utility fails with an error message, locate the error message in the section “Alphabetical Error Message Listing” in Chapter 4 and follow the instructions.
To verify that each HIPPI IP network interface is functional, follow the instructions in this section. This test requires the local system to be attached either to another HIPPI endpoint that supports IP or to a HIPPI LAN that has functioning IP hosts. This test assumes that the HIPPI subsystem has passed the hiptest verification, as described under the heading “Verify the Interface to HIPPI-FP” in this section.
To accomplish this verification, use /usr/etc/ping -r (lower case -r, not -R) to make this station communicate with another HIPPI IP station over the HIPPI subsystem.
Obtain the IP network addresses for all the local area networks attached to IRIS HIPPI boards on this system. This information can be displayed with the command shown below. The network address is listed in the column labelled Network, as illustrated in Figure 3-3.
% /usr/etc/netstat -ina
Obtain the name or IP address of at least one station on each of these networks. Two methods for obtaining station names are described below. The hip#_networkaddress variables used are the values in the Network column of the netstat display (illustrated in Figure 3-3).
For sites with NIS, use the commands below to create a file for each network connection that contains the names and addresses of stations located on that local area network:
% ypcat hosts | grep hip0_networkaddress > hip0.s % ypcat hosts | grep hip1_networkaddress > hip1.s <do this for each HIPPI IP network address>
Example:
% ypcat hosts | grep 253.5.28 > hip0.s
For distributed (non-NIS) sites, use these commands to create a file for each network connection that contains the names and addresses of stations located on that local area network:
% grep hip0_networkaddress /etc/hosts > hip0.s % grep hip1_networkaddress /etc/hosts > hip1.s <do this for each HIPPI IP network address>
Example:
% grep 253.5.88 /etc/hosts > hip1.s
Communicate with one station on the LAN attached to the hip0 connection. For the variable hip0_station, you can use any of the names or IP addresses from the hip0.s file, except the station's own.
% ping -r hip0_station PING stationname (IPaddress): 56 data bytes 64 bytes from . . . time=x ms . . . <Ctrl><c> ----stationname PING Statistics---- # packets trans,# pckts rcvd, x% packet loss
If netstat lists other IRIS HIPPI (hip#) network interfaces, communicate with one station on each of those networks. For the variable hip#_station, you can use any of the names from the hip#.s file, except the station's own.
% ping -r hip#_station PING stationname (IPaddress): 56 data bytes 64 bytes from . . . time=x ms . . . <Ctrl><c> ----stationname PING Statistics---- # packets trans, # pckts rcvd, x% packet loss
If one ping on each network succeeds, you have completed the verification procedure. All the network connections are functioning. Use the commands below to remove the files with the lists of stations:
% rm hip0.s % rm hip1.s <do this command line for each .s file created>
If the ping on a network fails, follow the instructions in the section “Troubleshoot an IP Interface.”
If the hiptest utility fails with an error message, locate the error message in the section “Alphabetical Error Message Listing” in Chapter 4 and follow the instructions.
If the ping verification tests fail for all the HIPPI network connections, your system probably has been configured incorrectly. Verify the configure with the commands below.
Verify that IP networking is enabled with the following command line:
% /sbin/chkconfig | grep network network on
Verify that the /usr/etc/hippi.imap file has entries for the local system's network connection names (or IP addresses) and for the remote system interface names or IP addresses that failed.
For each HIPPI I/O panel, verify that the HIPPI cables connect to a LAN with a network address that matches the HIPPI network interface address for that board. You can display the local network address with the /usr/etc/netstat -ina command. The address shown for network interface hip0 belongs to board hippi0; the address for hip1 belongs to board hippi1. To verify the network address being used on the cable at the I/O panel, you have to perform the equivalent action on other systems on that LAN.
If the network address is correct, continue to the next step. If the address is wrong, either change the local system's address to match or connect the correct the cables to the I/O panel.
Refer to the IRIX Advanced Site and Server Administration Guide for information about configuring and troubleshooting IP.
If one of the ping verification tests succeeds, but one or more fails, the IP stack is functioning, but the specific interface has a problem. Follow the instructions in this section for each problematic network connection to resolve the problem.
Verify that the /usr/etc/hippi.imap file has an entry for the problematic local interface and for the remote hostnames or IP addresses that failed.
If the system is connected to a switch, verify that the switch is operational.
Verify that the other system (endpoint host) is operational. If it is, continue to the next step.
Or, as an alternate, select two different stations on the LAN for which ping failed. Try to ping -r each station using the numerical address (instead of the name). If a ping works, the network connection is functional. If the pings fail, proceed to the next step.
Check that the HIPPI cables between the I/O panel and the other system (switch or endpoint) are tightly connected at both ends.
Again try to ping a station on that network. If the ping still fails, proceed to the next step.
Verify that the network portion (leftmost digits) of the addresses you are attempting to ping match the network addresses displayed by the /usr/etc/netstat -in command.
If the network addresses do not match, repeat the steps in “Verify an IP Interface” to obtain and test a new selection of stations. Take extra precautions to ensure that you use the correct network addresses. If the network addresses match, continue.
Verify that the HIPPI cables at the I/O panel attach (at their other ends) to a system using the same network address. For example, verify that the network address for hip0 matches the network address for the system at the other end of the cables attached to the hippi0 board. (If the other system is a switch, verify the network addresses at the endpoints attached to that switch.)