Symptom:
The following messages are output to the system log.
hanet: WARNING: 87500: standby interface failed. (sha1) |
Corrective action:
The standby patrol performs NIC switching by sending and receiving the monitoring frame via adjacent HUB from standby NIC (eth1) to active NIC (eth0). (When the primary NIC is using in communication at present) The message is output when cutting off the receiving and sending of the monitoring frame, the main output patterns are classified into the following four types.
Output the error messages that anomalies are detected by the standby patrol when the system is started, and the status of standby patrol output by the dsphanet command is in FAIL.
The following messages are output to the system log.
hanet: WARNING: 87500: standby interface failed. (sha1) |
# /opt/FJSVhanet/usr/sbin/dsphanet [IPv4,Patrol / Virtual NIC] Name Status Mode CL Device +----------+--------+----+----+------------------------------------------------+ sha0 Active d OFF eth0(ON),eth1(OFF) sha1 Active p OFF sha0(FAIL) |
In pattern 1, the monitoring frame of the standby patrol may not reach to primary NIC (eth0) due to the HUB setting errors or cable connection errors.
Output messages that indicate normal working of the standby patrol when starting the system, and output the messages that indicate error occurrence in the standby patrol during operating. The status of the standby patrol output by the dsphanet command is in FAIL.
hanet: INFO: 89600: path to standby interface is established. (sha1)
: :
hanet: WARNING: 87500: standby interface failed. (sha1) |
# /opt/FJSVhanet/usr/sbin/dsphanet [IPv4,Patrol / Virtual NIC] Name Status Mode CL Device +----------+--------+----+----+------------------------------------------------+ sha0 Active d OFF eth0(ON),eth1(OFF) sha1 Active p OFF sha0(FAIL) |
In pattern 2, network faults may occur.
Output messages that indicate the standby patrol anomalies during operation, and output messages indicating recovery after waiting for a moment, or the messages indicating anomaly and recovery are output in alternately.
hanet: INFO: 89600: path to standby interface is established. (sha1)
:
hanet: WARNING: 87500: standby interface failed. (sha1)
hanet: INFO: 88500: standby interface recovered. (sha1)
:
hanet: WARNING: 87500: standby interface failed. (sha1)
hanet: INFO: 88500: standby interface recovered. (sha1) |
In pattern 3, the monitoring frame may lose temporarily due to error settings of HUB or GLS and increased network load.
Output the messages indicating that anomalies are detected by the standby patrol every time when the system is started. Afterwards, and the message indicating recovery may be output immediately. Moreover, the status of standby patrol in operation is "ON".
hanet: WARNING: 87500: standby interface failed. (sha1) hanet: INFO: 88500: standby interface recovered. (sha1) |
# /opt/FJSVhanet/usr/sbin/dsphanet [IPv4,Patrol / Virtual NIC] Name Status Mode CL Device +----------+--------+----+----+------------------------------------------------+ sha0 Active d OFF eth0(ON),eth1(OFF) sha1 Active p OFF sha0(ON) |
There is no problem in operation for pattern 4. When the STP (Spanning Tree protocol) is valid in HUB, the monitoring frame cannot be sent and received for about 30 seconds even if the interface has been linked up because of the transmission delay timer of STP. Therefore, Communication can be performed normally after ending the transmission delay timer when temporary errors are detected by the standby patrol. In addition, the output message can be suppressed by changing the settings.
Confirm the following items based on message output patterns.
Message output patterns | Confirmation items | |
|---|---|---|
Pattern 1 | HUB settings | Ethernet frame type |
Status of the own node and the network | HUB status | |
Cable | Connection confirmation | |
Pattern 2 | Status of the own node and the network | HUB status System log |
Cable | Connection confirmation | |
Pattern 3 | GLS setting | MAC address |
HUB settings | Communication mode | |
Status of the own node and the network | Maintenance work | |
Pattern 4 | HUB settings | STP settings |
Details of each confirmation item are as follows.
Confirmation item | Contents | |
|---|---|---|
Cable | Connection confirmation | 1) Please confirm the port of HUB connected with primary NIC and secondary NIC is correct. Please confirm the cacade connection between HUBs when connecting to a HUB that the primary NIC is different from the secondary NIC. Moreover, please confirm that the cable is not disconnected, which is indicated by the LED of NIC and HUB. |
Category | 1) Confirm whether the category (straight cable, cross cable) used by cable is correct. In addition, if the communication mode is not set to auto negotiation, the function (Auto-MDIX) of automatic cable category identification will be invalid. For details, refer to the HUB manual. | |
HUB settings | Ethernet frame type | The standby patrol monitoring by receiving and sending the monitoring frame. Communications can be performed by monitoring frame in most HUBs, but the HUB that cannot support monitoring frame in default settings also exists. In this case, please reset the HUB to enable arbitrary Ethernet frame to pass. |
Communication mode | Please confirm whether the communication mode set to the port of the interface matches that of HUB. When the communication mode of the HUB is different from that of the own node, the collision might result in the packet lost frequently. (For example: When setting the own node to auto negotiation and setting HUB to fixed full duplex) In addition, the following communication modes are required among the computers connecting with the Ethernet. | |
STP settings | The communication will be disabled for about 30 seconds after the activation of the interface of GLS and the switch when STP (spanning tree protocol) becomes valid. During this period, the GLS suppresses the switch of NIC due to the failure of the HUB monitoring. Set the controlled time by the hanetpoll command as the parameter "Time of delay for Linking Up" (60 seconds in default). Incorrect switch of NIC may occur if this parameter value is small. Processing it in the following methods. | |
VLAN-ID | Please confirm that the VLAN ID of ports which connects the primary NIC is same as the one connects the secondary NIC when using the HUB that supports port VLAN. When the VLAN IDs are different, the monitoring frame cannot reach to the active NIC from the standby NIC. | |
Status of the own node and the network | Maintenance work | Please confirm neither the reactivation of the monitored targets HUB nor the maintenance work of the exchange, etc. are done during the period of detecting anomalies by the standby patrol. When changing the HUB, it is necessary to stop the standby patrol. |
HUB status | When the HUB is in trouble, the monitoring frame will be lost intermittently. Please confirm the abnormal messages are not output to the logs of HUB. | |
System log | 1) The NIC that monitors the standby patrol might have been linked down. Please confirm whether the link down messages have been output to the system log during the period of detecting anomalies. | |
Communication load | The delay and the lost of the monitoring frame might occur when traffic on the network increases and the network is in state of a high load. Please confirm whether there are conflicts and packet loss from statistical information and logs of HUB. Please confirm the amount of received and sent packets during the period of switch by the sar command in Linux. In addition, in the environment where the network with a different speed (1Gbps and 100Mbps, etc.) exists, even if the unoccupied bandwidth exists in a high-speed network, packets may still be lost when they are transported from the HUB to a low-speed network. Please confirm whether the traffic has been estimated correctly. | |
