The following message is output and activation of an interface fails.
hanet: ERROR: 85700: polling information is not defined. Devname = sha0(0) |
In NIC switching mode, switching interfaces inside a node and between nodes is controlled using a failure monitoring function. Therefore, NIC switching mode does not work only by defining the information of a virtual interface using a hanetconfig create command. Necessary to set the monitor-to information by a hanetpoll create command. When the monitor-to information is not set, a takeover IP address is not activated either. Activation of a userApplication fails in cluster operation.
When using a logical address takeover function, and also when sharing a physical interface, necessary to have the monitor-to information in a unit of information of each virtual interface. In such a case, duplicate the information of a virtual interface and the monitor-to information that defined initially using a hanetconfig copy command and a hanetpoll copy command.
The following messages display during recovering process of standby patrol in NIC switching mode. As a result, it fails to instantly switch back from the secondary interface to the primary interface.
hanet: INFO: 88500: standby interface recovered. (sha1) hanet: INFO: 89700: immediate exchange to primary interface is canceled. (sha1) |
After switching from the primary interface to the secondary interface due to transfer path failure, if a standby patrol recovers prior to elapsed link up delay time (default is 60 sec), the switching process between the primary and secondary interface may loop infinitely. To prevent from this symptom, the above messages will display to stop the switching process for the primary interface. The main reason of covering this issue in this section is to prevent infinite loop of switching interfaces when setting routes for monitoring and instead of HUBs.
The following message is output and activation of an interface fails.
hanet: WARNING: 87500: standby interface failed. |
On the network where VLAN switch exists on the transfer path monitored via standby patrol function, this error occurs if the following two circumstances take place:
1) Connecting a redundant NIC to a port of disparate VLAN identifier.
2) Connecting one of a redundant NIC or both redundant NICs to tagged member port of the switch.
The VLAN switch cannot communicate in between the ports where VLAN identifiers are disparate. Therefore, when connecting redundant NIC to disparate VLAN identifier, transmitting the monitoring frame fails between standby NIC and operation NIC, consequentially outputting 875 message. Additionally, even if VLAN identifiers are the same port and this port is set to tag member, and in the condition where the NIC does not support tagged VLAN (IEE802.1Q compliance), it still fails to retrieve tag frame from the switch. Once again, transmitting the monitoring frame fails outputting 875 message. To rectify this problem, double check the VLAN configuration of the switch and make sure VLAN identifier is identical on the port connecting redundant NIC. If the NIC you are using does not support tagged VLAN, set the port of the switch as non-tag member.
Executing hanetconfig create/delete command, hanetpoll create/delete command, dsphanet command, and dsppoll commands output the following error message and aborts. Also, the virtual interface fails to activate during the system startup.
"hanet: 56100: internal error: daemon process does not exist."
The problem is most likely occurred due to cut off of symbolic link that was linked to initialization script for Redundant Line Control function. The user might have performed illegal operation to generate this issue. Therefore, the initialization script of Redundant Line Control function did not run during the system startup in which have caused activation failure of the virtual interface as well as startup failure of GLS daemon (hanetcltd). In such a case, the command also aborts since the GLS daemon is not running.
To resolve this issue, refer to the following recovery procedure to create the symbolic link under /etc/rc2.d and /etc/rc3.d that links to the initialization script and reboot the system.
[Recovery Procedure]
# ln -s /etc/init.d/hanet /etc/rc2.d/S32hanet # ln -s /etc/init.d/hanet99 /etc/rc3.d/S99hanet |
If the virtual interface in fast switching or physical interface in NIC switching is specified for the network setting, the following error message will be output and zone startup will fail:
# zoneadm -z zone0 boot could not verify net address=192.168.80.10 physical=sha0: No such device or address zoneadm: zone zone0 failed to verify or # zoneadm -z zone0 boot zoneadm: zone 'zone0': hme0:1: could not bring interface up: address in use by zone 'global': Cannot assign requested address zoneadm: zone 'zone0': call to zoneadmd failed |
If the specified interface does not exist in the zone network setting or the IP address same as that specified for the zone network setting, the zone cannot be started. Check if the specified interface or IP address already exists using the "ifconfig(1M)" command.
If you are using NIC switching, check if the method of deactivating the standby interface can be used in the zone. For details, see "7.6 hanetparam Command" and "F.1 Changing Methods of Activating and Inactivating Interface".
Information
If a zone is installed, and interfaces for the zone do not exist, zone installation will fail. You need to activate the interfaces specified for the zone network settings before zone installation.
When rebooting the system in the case of NIC or system board failure in the Solaris 10 or Solaris 11, the following message is output and services for Redundant Line Control function may not started.
Failed to plumb IPv4 interface(s): hme0 svc.startd[7]: svc:/network/physical:default: Method "/lib/svc/method/net-physical" failed with exit status 96. svc.startd[7]: network/physical:default misconfigured: transitioned to maintenance (see 'svcs -xv' for details) |
If rebooting the system while a failure occurs when multiple system boards exist or when NICs with multiple ports are used as shown in the following configuration, starting the network service (svc:/network/physical) fails because IP addresses cannot be assigned. In this case, network services including Redundant Line Control function (svc:/network/fjsvhanet) will not start.
Figure F.1 Configuration of NIC switching mode before change (For Solaris 10)
Figure F.2 Configuration of NIC switching mode before change (For Solaris 11)
When rebooting the system with a failure of NIC or system boards, change the configuration of the IP address set to the physical interface with a failure so that the IP address will be set to a physical interface without any failure before rebooting the system, or restore the service using the svcadm(1M) command.
Recovery procedure
Assign the IP address set to the physical interface with a failure to a physical interface without any failure.
1-1) For Solaris 10
# mv /etc/hostname.hme0 /etc/hostname.hme3 # mv /etc/hostname.hme1 /etc/hostname.hme2 |
1-1) For Solaris 11
# /usr/sbin/ipadm delete-ip hme0 # /usr/sbin/ipadm create-ip hme3 # /usr/sbin/ipadm create-addr -T static -a host11/24 hme3/v4 # /usr/sbin/ipadm delete-ip hme1 # /usr/sbin/ipadm create-ip hme2 # /usr/sbin/ipadm create-addr -T static -a host12/24 hme2/v4 |
Reboot the system or restore the network service.
# /usr/sbin/shutdown -y -i6 -g0 |
Or,
# svcadm clear svc:/network/physical:default |
See
For details on the svcadm(1M) command and ipadm(1M) command, refer to the Solaris manual.
Change process to recommended environment
If the IP address set to a physical interface is assigned only for one system board in the case of Figure F.1 Configuration of NIC switching mode before change (For Solaris 10), it is recommended to change the environment for the Primary interface for each system board as shown in Figure F.3 Configuration of NIC switching mode after change (For Solaris 10).
Figure F.3 Configuration of NIC switching mode after change (For Solaris 10)
Figure F.4 Configuration of NIC switching mode after change (For Solaris 11)
Procedure for setting up is as follows:
Stop the HUB monitoring function.
# /opt/FJSVhanet/usr/sbin/hanetpoll off |
Deactivate all virtual interfaces.
# /opt/FJSVhanet/usr/sbin/stphanet |
Change the configuration information.
Switch the redundant physical interfaces (Primary:hme1 and Secondary:hme2) in sha1 by executing the hanetconfig modify command.
# /opt/FJSVhanet/usr/sbin/hanetconfig modify -n sha1 -t hme2,hme1 |
Change the configuration so that IP addresses set to physical interfaces will be distributed for each system board. If the recovery procedure has been performed and the configuration is changed so that IP addresses set to physical interfaces will be distributed for each system board, this step is not required.
1-1) For Solaris 10
Rename the /etc/hostname.*** file.
In accordance with switch of redundant physical interfaces, rename the file from /etc/hostname.hme1 to /etc/hostname.hme2.
# mv /etc/hostname.hme1 /etc/hostname.hme2 |
1-1) For Solaris 11
# /usr/sbin/ipadm delete-ip hme1 # /usr/sbin/ipadm create-ip hme2 # /usr/sbin/ipadm create-addr -T static -a host12/24 hme2/v4 |
Reboot the system.
# /usr/sbin/shutdown -y -g0 -i6 |
When /opt cannot be mounted at system startup in the Solaris 10 OS, the following message will be output and the services for Redundant Line Control function may not start.
hanet: ERROR: 98400: file system is inconsistent. (details) |
Since the inconsistency of the /opt file system was detected at the startup of GLS service, the startup stopped.
Make sure that the inconsistency of the /opt file system is resolved and /opt is mounted. After that, perform one of the actions:
Staring the system again
Starting GLS service
# svcadm clear fjsvhanet |
If the operation is not started normally after starting GLS service, the TCP/IP application that uses Redundant Line Control function may have failed to start. Start the system again.
