Managing Serviceguard Nineteenth Edition, Reprinted June 2011

Local network switching will work with a cluster containing one or more nodes. You may wish to
design a single-node cluster in order to take advantage of this local network switching feature in
situations where you need only one node and do not wish to set up a more complex cluster.
Switching Back to Primary LAN Interfaces after Local Switching
If a primary interface fails, the IP address will be switched to a standby. You can use the
NETWORK_AUTO_FAILBACK parameter in the cluster configuration file to configure what
Serviceguard does if the primary interface is later restored.
• Default behavior: NETWORK_AUTO_FAILBACK = YES. Serviceguard will detect and log the
recovery of the interface, and will switch the IP address back to its primary interface.
In addition, when a node is halted, the cluster daemon (cmcld) will attempt to switch any
Serviceguard-configured IP addresses on standby interfaces back to their primary interfaces,
regardless of the link state of the primary interfaces. The intent of this switchback is to preserve
the original network configuration as it was before the cluster started. Switching back occurs
on the specified node if a cmhaltnode command is issued or on all nodes in the cluster if a
cmhaltcl command is issued.
• Configurable behavior: NETWORK_AUTO_FAILBACK = NO. Serviceguard will detect and log
the recovery of the interface, but will not switch the IP address back from the standby to the
primary interface.
You can tell Serviceguard to switch the IP address back to the primary interface by means of
the cmmodnet command:
cmmodnet -e <interface>
where <interface> is the primary interface.
The purpose of the NETWORK_AUTO_FAILBACK parameter is to allow you control Serviceguard's
behavior if you find network interfaces are experiencing a “ping-pong” effect, switching back and
forth unduly between primary and standby interfaces. If you are not seeing any such problem,
leave NETWORK_AUTO_FAILBACK set to YES. You can track switching behavior in the syslog
file.
NOTE: The NETWORK_AUTO_FAILBACK setting applies only to link-level failures, not to failures
at the IP level; see “Monitoring LAN Interfaces and Detecting Failure: IP Level” (page 70) for more
information about such failures. For more information about the cluster configuration file, see
“Cluster Configuration Parameters ” (page 105).
Remote Switching
A remote switch (that is, a package switch) involves moving packages to a new system. In the most
common configuration, in which all nodes are on the same subnet(s), the package IP (relocatable
IP; see “Stationary and Relocatable IP Addresses ” (page 64)) moves as well, and the new system
must already have the subnet configured and working properly, otherwise the packages will not
be started.
NOTE: It is possible to configure a cluster that spans subnets joined by a router, with some nodes
using one subnet and some another. This is called a cross-subnet configuration. In this context, you
can configure packages to fail over from a node on one subnet to a node on another, and you
will need to configure a relocatable address for each subnet the package is configured to start on;
see “About Cross-Subnet Failover” (page 145), and in particular the subsection “Implications for
Application Deployment” (page 146).
When a remote switch occurs, TCP connections are lost. TCP applications must reconnect to regain
connectivity; this is not handled automatically. Note that if the package is dependent on multiple
subnets (specified as monitored_subnets in the package configuration file), all those subnets
must normally be available on the target node before the package will be started. (In a cross-subnet
How the Network Manager Works 69