Notes on setting a configuration:
The minimum and maximum number of virtual and logical virtual interface can be defined is 1 to 64.
The number of physical interfaces can be used for redundancy on a single virtual interface is within 1 to 8 for Fast switching and GS/SURE linkage mode. For NIC switching mode, the range is within 1 to 2.
The number of logical virtual interfaces that can be defined to a single logical virtual interface is within 1 to 63.
When using the tagged VLAN interface in Solaris 11 environment, do not specify the VLAN link name to create the tagged VLAN interface. Use the automatically generated interface name.
"net" + VLAN-ID + instance number (*1)
*1: The instance number is represented by 3-digit number XXX (from 000 to 999).
Example: If VLAN-ID is 12 and the NIC name is net3, the automatically generated VLAN interface name will become "net12003".
The interface name that is bundled by the virtual interface must be specified within 11 characters.
If VLAN is not used, an interface name that can be recognized as the VLAN interface name cannot be specified for the interface bundled by the virtual interface. For example, if an integer followed by "net" is 1000 or larger such as "net12003", this interface name cannot be specified.
To use all host names and IP addresses used in a Redundant Line Control function, they must be defined in /etc/inet/ipnodes files of the local system.
The system automatically determines the length of MTU for an interface. Nonetheless, it is possible to change the length of MTU using user command execution function. For changing MTU length, refer to "3.6.10 Setting User command execution function". Note that the length of MTU cannot be modified in other redundant modes.
The IPMP virtual interface (ipmpX) cannot be made redundant.
Notes on the operation:
It is not possible to use a multicast IP address in a Redundant Line Control function.
Do not execute a DR linkage function in a machine that runs the cluster operation.
Do not operate physical interfaces that a virtual interface bundles with an ifconfig command.
GLS does not support Verified Boot.
The following warning messages may be output to the syslog. However, these messages do not disrupt the system configuration or system operation. No action is required.
WARNING: Signature verification of module /usr/kernel/drv/sparcv9/rvnet failed
WARNING: Signature verification of module /usr/kernel/drv/sparcv9/rvnetcf failed
WARNING: Signature verification of module /usr/kernel/drv/sparcv9/sha failed
Notes on applications:
When an application uses TCP, the data lost when an error occurred in a transfer route is guaranteed by resending from TCP and reaches the other system in the end. Therefore, TCP connection is not disconnected and there is no error in communication. However, it is necessary to set a timer value longer than the time to finish disconnecting/switching a transfer route when an application monitors a response by such timer. When TCP connection is disconnected by the reason such as incapability to change a timer value, reestablish the TCP connection and recover the communication.
The data lost at the time of an error in a transfer route is not guaranteed when an application uses the UDP. It is necessary to execute a recovery process such as sending the data by the application itself.
It is not possible to use DHCP (a server function and a client function) as the application in a Redundant Line Control function.
When using NTP as an application, it is necessary to activate an IP address that a Redundant Line Control function controls before activating an NTP daemon. No special operation is required when activating a system because a Redundant Line Control function is activated before an NTP daemon. However, when manually activated an IP address with an operation command or when running cluster operation, reactivate an NTP daemon after an IP address is activated.
Notes on Solaris Zones:
If a zone is activated, an interface in the shared-IP zone cannot be deactivated.
If you want to change or delete the redundant line control function settings, it is necessary to stop the zone first.
For a shared-IP zone, if a virtual interface does not exist in a zone, the zone cannot be activated.
Before starting the zone, activate the virtual interface.
If the shared-IP zone is started after NIC is switched from the primary interface to the secondary interface in NIC switching mode, it might take up to 20 seconds to enable communication in the zone.
For a shared-IP zone, if the zone is set to use the secondary interface in NIC switching mode, a network interface in the zone will automatically be switched to the primary interface when a virtual interface is activated.
An IP address specified for a shared-IP zone and that for a virtual interface must be different.
If the same IP is specified for both, zone startup or virtual interface activation will fail.
