Managing Serviceguard A.11.20, March 2013

Reasons To Use IP Monitoring
Beyond the capabilities already provided by link-level monitoring, IP monitoring can:
• Monitor network status beyond the first level of switches; see “How the IP Monitor Works”
(page 75)
• Detect and handle errors such as:
IP packet corruption on the router or switch◦
◦ Link failure between switches and a first-level router
◦ Inbound failures even when the cluster configuration parameter
NETWORK_FAILURE_DETECTION is not set to INONLY_OR_INOUT
NOTE: This applies only to subnets for which the cluster configuration parameter
IP_MONITOR is set to ON. See “Cluster Configuration Parameters ” (page 114) for more
information.
◦ Errors that prevent packets from being received but do not affect the link-level health of
an interface
IMPORTANT: You should configure the IP Monitor in a cross-subnet configuration, because IP
monitoring will detect some errors that link-level monitoring will not. See also “Cross-Subnet
Configurations” (page 29).
How the IP Monitor Works
Using Internet Control Message Protocol (ICMP) and ICMPv6, the IP Monitor sends polling messages
to target IP addresses and verifies that responses are received. When the IP Monitor detects a
failure, it marks the network interface down at the IP level, as shown in the output of cmviewcl
(1m). If there is a standby, the subnet is failed over to the standby. See “Reporting Link-Level and
IP-Level Failures” (page 77) and “Failure and Recovery Detection Times” (page 76).
The monitor can perform two types of polling:
• Peer polling.
In this case the IP Monitor sends ICMP ECHO messages from each IP address on a subnet to
all other IP addresses on the same subnet on other nodes in the cluster.
• Target polling.
In this case the IP Monitor sends ICMP ECHO messages from each IP address on a subnet to
an external IP address specified in the cluster configuration file; see POLLING_TARGET under
“Cluster Configuration Parameters ” (page 114). cmquerycl (1m) will detect gateways
available for use as polling targets, as shown in the example below.
Target polling enables monitoring beyond the first level of switches, allowing you to detect if
the route is broken anywhere between each monitored IP address and the target.
NOTE: In a cross-subnet configuration, nodes can configure peer interfaces on nodes on
the other routed subnet as polling targets.
HP recommends that you configure target polling if the subnet is not private to the cluster.
The IP Monitor section of the cmquerycl output looks similar to this:
…
Route Connectivity (no probing was performed):
IPv4:
1 16.89.143.192
How the Network Manager Works 75