Top
PRIMECLUSTERGlobal Link Services Configuration and AdministrationGuide 4.5Redundant Line Control Function
FUJITSU Software

G.3.1 Communication as expected cannot be performed (Common to IPv4 and IPv6)

G.3.1.1 A default gateway is not set valid

Phenomenon:

A default gateway defined in /etc/defaultrouter at activation of a system is not valid.

Cause and how to deal with:

The setting of a default gateway defined in /etc/defaultrouter is set in svc:/network/routing-setup service at activation of a system. At this time, when an interface of the same segment as that of the specified router, or when not activated, it is not possible to set a default gateway. In a Redundant Line Control function, a virtual interface is activated at activation of a userApplication in cluster operation. Therefore, occasionally not possible to set a default gateway.

Fast switching mode:

When using a virtual interface as a sending interface to a default gateway in cluster operation, change the timing to activate a virtual interface by a hanetparam command.

NIC switching mode:

When using a physical IP address takeover function, and also when not activating an interface in a standby node, it is not possible to use a physical interface as a sending interface to a default gateway.

GS/SURE linkage mode:

It is not possible to use a virtual interface as a sending interface to a default gateway in cluster operation.

G.3.1.2 Fails to activate a system or an interface in the NIS environment

Phenomenon:

The following message is displayed and activation of a system or an interface hangs up.

ypbind[xxxx]: [ID xxxxxx daemon.error] NIS server not responding for domain "domain_name"; still trying
Cause and how to deal with:

When a system that a Redundant Line Control function works is set as an NIS client, occasionally not possible to connect NIS server temporarily due to the process to deactivate an interface executed by a Redundant Line Control function. In such a case, if set a netmask to an interface by an ifconfig command, occasionally the process to activate a system or an interface hangs up because an ifconfig command waits for the connection with NIS server to get a subnet mask.
Be sure to set as follows when using a Redundant Line Control function in the NIS environment.

To specify "files" first in /etc/nsswitch.conf to refer "netmasks".

[Example of setting]

netmasks: files

or

netmasks: files [NOTFOUND=return] nis

As to accessing NIS server, design a network not to use an interface that is the target of control in a Redundant Line Control function (activation/deactivation) as possible.

G.3.1.3 Automatic address configuration lags behind for IPv6

Phenomenon:

Automatic stateless address configuration for IPv6 may not operate instantly when activating IPv6. As a consequence, it takes time to add site-local/global addresses.

Cause and how to deal with:

When activating an interface for IPv6, a link-local address is added to the physical interface to activate the physical interface. To instantly create site-local/global address by the automatic stateless address configuration, it transmits the "router solicitation message" to the adjacent router to request for router advertisement message from the router. However, once the interface activates, if spanning tree protocol (STP) is running on the HUB, it takes time to hold a communication. Thus it may fail to request router advertisement messages. Because IPv6 router transmits the router advertisement message periodically and automatic stateless address automatic configuration runs after certain amount of time, it is possible to hold a communication of site-local/global addresses. Nevertheless, if the time interval parameter of transmitting the router advertisement message is set for a considerably long time, it may consume a long time until the automatic stateless address configuration starts and to hold a communication. In such case, either establish a link for operation NIC and standby NIC or modify the router setting so that a router transmits the router advertisement message within a fewer minutes interval.

G.3.1.4 Fails to communicate with GS in hot standby configuration

Phenomenon:

Communication with GS in hot standby configuration fails.

Cause and how to deal with:

The cause is that the setting for hanetobserv command has an error.

If GS's IP address moves between nodes as follows, execute the "hanetobserv create" command for each GS node.

# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.20,192.168.20.20 -m on -r on
# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.30,192.168.20.30
# /opt/FJSVhanet/usr/sbin/hanetobserv print
 Destination Host Virtual Address  POLL RIP  NIC Address(:PMgroupID)
+----------------+----------------+----+----+---------------------------------+
 GS               192.168.120.20   ON   ON   192.168.10.20,192.168.20.20
                                             192.168.10.30,192.168.20.30

If you create the settings as follows, one node is set as the communication target. If you want to perform this in a cluster configuration, execute the command for each node one by one. Note that the difference between the settings mentioned above and the settings here is whether the IP addresses in the "NIC Address" field that are displayed by the "hanetobserv print" command are separated by commas. Commas indicate that a communication target is a single node with four IP addresses.
(192.168.10.20,192.168.20.20,192.168.30.20,192.168.40.20)

# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.20,192.168.20.20,192.168.30.20,192.168.40.20 -m on -r on
# /opt/FJSVhanet/usr/sbin/hanetobserv print
 Destination Host Virtual Address  POLL RIP  NIC Address(:PMgroupID)
+----------------+----------------+----+----+---------------------------------+
 GS               192.168.120.20   ON   ON   192.168.10.20,192.168.20.20,
                                             192.168.30.20,192.168.40.20