HP Serviceguard manual Reasons To Use IP Monitoring, How the IP Monitor Works

The IP Monitor:

•Detects when a network interface fails to send or receive IP messages, even though it is still able to send and/or receive DLPI messages.

•Handles the failure, failover, recovery, and failback.

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 74)

•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 109) 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 30).

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 76) and “Failure and Recovery Detection Times” (page 75).

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 109). 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:

74 Understanding Serviceguard Software Components