Managing Serviceguard A.11.20, March 2013

Constraints and Limitations
A subnet must be configured into the cluster in order to be monitored.
Polling targets are not detected beyond the first-level router.
Polling targets must accept and respond to ICMP (or ICMPv6) ECHO messages.
A peer IP on the same subnet should not be a polling target because a node can always ping
itself.
On an HP-UX system, an IP-level failure on the standby interface will not be detected until the
IP address fails over to the standby.
On an HP-UX system, after the IP address fails over to the standby, the IP monitor will not
detect recovery on the primary interface.
The following constraints apply to peer polling when there are only two interfaces on a subnet:
If one interface fails, both interfaces and the entire subnet will be marked down on each node,
unless Local Switching (page 71) is configured and there is a working standby.
If the node that has one of the interfaces goes down, the subnet on the other node will be
marked down.
In a 2-node cluster, there is only a single peer for polling. When POLLING_TARGET is not
defined, if one of the two nodes fail (for example, a node is rebooted or all the interfaces of
a node are down), IP monitoring fails and all the subnets are marked down on the operational
node. This results in failure of packages running on the operational node.
Therefore, peer polling is not suitable when there is only a single peer as in a 2-node cluster.
In such scenarios, you must always define a polling target so that a single LAN failure does
not affect polling of other LANs.
Reporting Link-Level and IP-Level Failures
Serviceguard detects both link-level and IP-level failures; see “Monitoring LAN Interfaces and
Detecting Failure: Link Level” (page 70) and “Monitoring LAN Interfaces and Detecting Failure: IP
Level” (page 74) for information about each level of monitoring. Any given failure may occur at
the link level or the IP level. In addition, local switching may occur, that is, a switch to a standby
NIC if one has been configured; see “Local Switching ” (page 71).
The following examples show when and how a link-level failure is differentiated from an IP-level
failure in the output of cmviewcl (1m).
As you can see, if local switching is configured, the difference is the keyword disabled, which
appears in the tabular output, and is set to true in the line output, if the IP Monitor detects the
failure. If local switching is not configured, the output is the same whether link-level or IP monitoring
detects the failure.
Example 1: If Local Switching is Configured
If local switching is configured and a failure is detected by link-level monitoring, output from
cmviewcl -v will look like something like this:
Network_Parameters:
INTERFACE STATUS PATH NAME
PRIMARY down (Link and IP) 0/3/1/0 lan2
PRIMARY up 0/5/1/0 lan3
cmviewcl -v -f line will report the same failure like this:
node:gary|interface:lan2|status=down
node:gary|interface:lan2|local_switch_peer=lan1
node:gary|interface:lan2|disabled=false
node:gary|interface:lan2|failure_type=link+ip
How the Network Manager Works 77