Understanding Chassis Cluster Redundancy Group IP Address Monitoring
Redundancy group IP address monitoring checks end-to-end connectivity and allows a redundancy group to fail over because of the inability of a redundant Ethernet interface (known as a reth) to reach a configured IP address. Redundancy groups on both devices in a cluster can be configured to monitor specific IP addresses to determine whether an upstream device in the network is reachable. The redundancy group can be configured such that if the monitored IP address becomes unreachable, the redundancy group will fail over to its backup to maintain service. The primary difference between this monitoring feature and interface monitoring is that IP address monitoring allows for failover when the interface is still up but the network device it is connected to is not reachable for some reason. It may be possible under those circumstances for the other node in the cluster to route traffic around the problem.
![]() | Note: If you want to dampen the failovers occurring because of IP address monitoring failures, use the hold-down-interval statement. |
IP address monitoring configuration allows you to set not only the address to monitor and its failover weight but also a global IP address monitoring threshold and weight. Only after the IP address monitoring global-threshold is reached due to cumulative monitored address reachability failure will the IP address monitoring global-weight value be deducted from the redundant group’s failover threshold. Thus, multiple addresses can be monitored simultaneously as well as monitored to reflect their importance to maintaining traffic flow. Also, the threshold value of an IP address that is unreachable and then becomes reachable again will be restored to the monitoring threshold. This will not, however, cause a failback unless the preempt option has been enabled.
When configured, the IP address monitoring failover value (global-weight) is considered along with interface monitoring—if set—and built-in failover monitoring, including SPU monitoring, cold-sync monitoring, and NPC monitoring (on supported platforms). The main IP addresses that should be monitored are router gateway addresses to ensure that valid traffic coming into the services gateway can be forwarded to the appropriate network router.
One Services Processing Unit (SPU) or Packet Forwarding Engine (PFE) per node is designated to send Internet Control Message Protocol (ICMP) ping packets for the monitored IP addresses on the cluster. The primary PFE sends ping packets using Address Resolution Protocol (ARP) requests resolved by the Routing Engine (RE). The source for these pings is the redundant Ethernet interface MAC and IP addresses. The secondary PFE resolves ARP requests for the monitored IP address itself. The source for these pings is the physical child MAC address and a secondary IP address configured on the redundant Ethernet interface (see Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring (CLI) ). For the ping reply to be received on the secondary interface, the input/output card (IOC), central PFE processor, or Flex IOC adds both the physical child MAC address and the redundant Ethernet interface MAC address to its MAC table. The secondary PFE responds with the physical child MAC address to ARP requests sent to the secondary IP address configured on the redundant Ethernet interface.
The default interval to check the reachability of a monitored IP address is once per second. The interval can be adjusted using the retry-interval command. The default number of permitted consecutive failed ping attempts is 5. The number of allowed consecutive failed ping attempts can be adjusted using the retry-count command. After failing to reach a monitored IP address for the configured number of consecutive attempts, the IP address is determined to be unreachable and its failover value is deducted from the redundancy group's global-threshold.
Once the IP address is determined to be unreachable, its weight is deducted from the global-threshold. If the recalculated global-threshold value is not 0, the IP address is marked unreachable, but the global-weight is not deducted from the redundancy group’s threshold. If the redundancy group IP monitoring global-threshold reaches 0 and there are unreachable IP addresses, the redundancy group will continuously fail over and fail back between the nodes until either an unreachable IP address becomes reachable or a configuration change removes unreachable IP addresses from monitoring. Note that both default and configured hold-down-interval failover dampening is still in effect.
Every redundancy group x has a threshold tolerance value initially set to 255. When an IP address monitored by redundancy group x becomes unavailable, its weight is subtracted from the redundancy group x's threshold. When redundancy group x's threshold reaches 0, it fails over to the other node. For example, if redundancy group 1 was primary on node 0, on the threshold-crossing event, redundancy group 1 becomes primary on node 1. In this case, all the child interfaces of redundancy group 1's redundant Ethernet interfaces begin handling traffic.
A redundancy group x failover occurs because the cumulative weight of the redundancy group x's monitored IP addresses and other monitoring has brought its threshold value to 0. When the monitored IP addresses of redundancy group x on both nodes reach their thresholds at the same time, redundancy group x is primary on the node with the lower node ID, which is typically node 0.
Monitoring can be accomplished only if the IP address is reachable on a redundant Ethernet interface (known as a reth in CLI commands and interface listings), and IP addresses cannot be monitored over a tunnel. For an IP address to be monitored via a redundant Ethernet interface on a secondary cluster node, the interface must have a secondary IP address configured. IP address monitoring cannot be used on a chassis cluster running in transparent mode. The maximum number of monitoring IPs that can be configured per cluster is 64 for the SRX5000 line and 32 for the SRX3000 line.
![]() | Note: Redundancy group IP address monitoring is not supported for IPv6 destinations in this release. |
Related Topics
- JUNOS Software Feature Support Reference for SRX Series and J Series Devices
- Understanding Chassis Cluster Redundancy Group 0: Routing Engines
- Understanding Chassis Cluster Redundancy Groups 1 Through 128
- Understanding Chassis Cluster Redundancy Group Interface Monitoring
- Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring (CLI)
- Understanding Chassis Cluster Redundancy Group Failover
- Understanding Chassis Cluster Monitoring of Global-Level Objects