Recovering a Physical Interface That Was Not Present at System Boot
Note - The following procedure pertains only to IP layers that are configured by using the ifconfig command. Layers before or after the IP layer, such as ATM or other services, require specific manual steps if the layers are not automated. The specific steps in the next procedure are used to unconfigure interfaces during predetachment and to configure interfaces after postattachment.
Recovery after dynamic reconfiguration is automatic for an interface that is part of the I/O board on a Sun Fire™ platform. If the NIC is a Sun Crypto Accelerator I - cPCI board, the recovery is also automatic. Consequently, the following steps are not required for an interface that is coming back as part of a DR operation. For more information on the Sun Fire x800 and Sun Fire 15000 systems, see the cfgadm_sbd(1M) man page. The physical interface fails back to the configuration that is specified in the /etc/hostname.interface file. See Configuring IPMP Groups for details on how to configure interfaces to preserve the configuration across reboots.
Note - On Sun Fire legacy (Exx00) systems, DR detachments are still subject to manual procedures. However, DR attachments are automated.
How to Recover a Physical Interface That Was Not Present at System Boot
You must complete the following procedure before you recover a physical interface that was not present at system boot. The example in this procedure has the following configuration:
Physical interfaces hme0 and hme1 are the interfaces.
Both interfaces are in the same IPMP group.
hme0 was not installed at system boot.
Note - The failback of IP addresses during the recovery of a failed physical interface takes up to three minutes. This time might vary, depending on network traffic. The time also depends on the stability of the incoming interface to fail back the failed-over interfaces by the in.mpathd daemon.
On the system with the IPMP group configuration, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.
Retrieve the failed network information from the failure error message of the console log.
See the syslog(3C)man page. The error message might be similar to the following:
moving addresses from failed IPv4 interfaces: hme1 (moved to hme0)
This message indicates that the IPv4 addresses on the failed interface hme1 have failed over to the hme0 interface.
Alternatively, you might receive the following similar message:
moving addresses from failed IPv4 interfaces: hme1 (couldn't move, no alternative interface)
This message indicates that no active interface could be found in the same group as failed interface hme1. Therefore, the IPv4 addresses on hme1 could not fail over.
Attach the physical interface to the system.
Refer to the following for instructions on how to replace the physical interface:
cfgadm(1M) man page
Sun Enterprise 10000 DR Configuration Guide
Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide
Refer to the message content from Step 2. If the addresses could not be moved, go to Step 6. If the addresses were moved, continue to Step 5.
Unplumb the logical interfaces that were configured as part of the failover process.
Review the contents of the /etc/hostname.moved-from-interface file to determine what logical interfaces were configured as part of the failover process.
Unplumb each failover IP address.
# ifconfig moved-to-interface removeif moved-ip-address
Note - Failover addresses are marked with the failover parameter, or are not marked with the -failover parameter. You do not need to unplumb IP addresses that are marked -failover.
For example, assume that the contents of the /etc/hostname.hme0 file contains the following lines:
inet 10.0.0.4 -failover up group one addif 10.0.0.5 failover up addif 10.0.0.6 failover up
To unplumb each failover IP address, you would type the following commands:
# ifconfig hme0 removeif 10.0.0.5 # ifconfig hme0 removeif 10.0.0.6
Reconfigure the IPv4 information for the replaced physical interface by typing the following command for each interface that was removed:
# ifconfig removed-from-NIC <parameters>
For example, you would type the following commands:
# ifconfig hme1 inet plumb # ifconfig hme1 inet 10.0.0.4 -failover up group one # ifconfig hme1 addif 10.0.0.5 failover up # ifconfig hme1 addif 10.0.0.6 failover up
Modifying the /etc/default/mpathd IPMP Configuration File
Use the IPMP configuration file /etc/default/mpathd to configure the following system-wide parameters for IPMP groups.
FAILURE_DETECTION_TIME
FAILBACK
TRACK_INTERFACES_ONLY_WITH_GROUPS
These parameters apply to all IPMP groups that are created on an individual system.
How to Configure the /etc/default/mpathd File
On the system with the IPMP group configuration, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.
Edit the /etc/default/mpathd file.
(Optional) Type the new value for the FAILURE_DETECTION_TIME parameter.
FAILURE_DETECTION_TIME=n
where n is the amount of time in seconds for ICMP probes to detect whether an interface failure has occurred. The default is 10 seconds.
(Optional) Type the new value for the TRACK_INTERFACES_ONLY_WITH_GROUPS parameter.
TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]
yes- The yes value is the default behavior of IPMP. This parameter causes IPMP to ignore network interfaces that are not configured into an IPMP group.
no - The no value sets failure and repair detection for all network interfaces, regardless of whether they are configured into an IPMP group. However, when a failure or repair is detected on an interface that is not configured into an IPMP group, no failover or failback occurs. Therefore, theno value is only useful for reporting failures and does not directly improve network availability.
(Optional) Type the new value for the FAILBACK parameter.
FAILBACK=[yes | no]
yes- The yes value is the default failback behavior of IPMP. When the repair of a failed interface is detected, network access fails back to the repaired interface, as described in IPMP Failure Detection and Recovery Features.
no - The no indicates that data traffic does not move back to a repaired interface. When a failed interfaces is detected as repaired, the INACTIVE flag of ifconfig is set. This flag indicates that the interface is currently not to be used for data traffic. The interface can still be used for probe traffic.
For example, suppose an IPMP group consists of two interfaces, ce0 and ce1. Then assume that the value FAILBACK=no is set in the mpathd file. If ce0 fails, its traffic fails over to ce1, as is the expected behavior of IPMP. However, when IPMP detects that ce0 is repaired, traffic does not fail back from ce1, due to the FAILBACK=no parameter in the mpathd file. ce0 retains its INACTIVE status and is not used for traffic unless the ce1 interface fails.
Restart the in.mpathd daemon.
# pkill -HUP in.mpathd