Monitor IP Addresses on a Chassis Cluster

IP monitoring checks the end-to-end connectivity of configured IP addresses and allows a redundancy group to automatically fail over when a monitored IP address is not reachable through the redundant Ethernet (reth) interface. Both the primary and secondary nodes in a chassis cluster monitor specified IP addresses to determine whether an upstream device in the network is reachable.

IP monitoring allows for failover based upon end to-end reachability of a configured monitored IP address. On Firewalls, IP reachability is tested by sending ICMP echo requests (pings) to the monitored IP address from both nodes through the reth interface and verifying that a response is received. The monitored IP address can be either a directly connected host on the same subnet as the reth interface or a remote device reachable through a next-hop router.

A monitored IP address can have one of three reachability states: Reachable, Unreachable, or Unknown.

• The status is shown as Unknown when the Packet Forwarding Engines (PFEs) are not yet operational.

• Once the PFEs are up and running, they start sending status updates. Based on these updates, the IP address status changes to either Reachable or Unreachable.

We do not recommend configuring chassis cluster IP monitoring on Redundancy Group 0 (RG0) for firewalls.

Table 1 provides details of different combinations of monitored results from both the primary and secondary nodes, and the corresponding actions by the Juniper Services Redundancy Protocol (jsrpd) process.

Table 1: IP Monitoring Results and Failover Action

Primary Node Monitored Status	Secondary Node Monitored Status	Failover Action
Reachable	Reachable	No action
Unreachable	Reachable	Failover
Reachable	Unreachable	No action
Unreachable	Unreachable	No action

• The IP monitoring interval can be configured between 1 and 30 seconds, with a default value of 1 second.

• The IP monitoring threshold can be configured between 5 and 15 requests , with a default value of 5. If the monitored IP address does not respond to consecutive requests that exceed the configured threshold, IP monitoring reports the IP address as unreachable.

• IP monitoring also supports configuring monitored IP addresses on redundant Ethernet (reth) interfaces that are not associated with a Redundancy Group (RG).

Redundancy group IP address monitoring checks end-to-end connectivity and allows a redundancy group to fail over when a redundant Ethernet (reth) interface (cannot reach a configured IP address). Redundancy groups on both nodes in a cluster can be configured to monitor specific IP addresses to determine whether an upstream device in the network is reachable.

If the monitored IP address becomes unreachable, the redundancy group can fail over to its backup node to maintain service availability.

Unlike interface monitoring, IP address monitoring can trigger a failover even when the interface remains up but the connected network device is unreachable. In such scenarios, the peer node in the cluster might still be able to route traffic around the failure.

To dampen failovers caused by IP address monitoring failures, use the hold-down-interval statement.

IP address monitoring configuration allows you to define not only the IP addresses to monitor and their associated failover weights, but also a global IP monitoring threshold and global weight. Only when the cumulative reachability failures of the monitored IP addresses reach the configured global threshold is the global IP monitoring weight deducted from the redundacy group’s failover threshold.

This design allows multiple IP addresses to be monitored simultaneously and weighted according to their importance in maintaining traffic flow. If a previously unreachable monitored IP address becomes reachable again, its threshold value is restored to the monitoring threshold. However, this recovery does not trigger a failback unless the preempt option is enabled.

When configured, the IP address monitoring failover value (global-weight) is evaluated along with interface monitoring(if configured) and built-in failover mechanisms, including SPU monitoring, cold-sync monitoring, and NPC monitoring (on supported platforms). The primary IP addresses to monitor are typically router gateway addresses, ensuring that incoming traffic to the services gateway can be forwarded to the appropriate upstream network router.

In a chassis cluster, only one Services Processing Unit (SPU) or Packet Forwarding Engine (PFE) per node is responsible for sending Internet Control Message Protocol (ICMP) ping packets to monitored IP addresses. The primary PFE sends ICMP pings using Address Resolution Protocol (ARP) entries resolved by the Routing Engine (RE). These pings use the redundant Ethernet (reth) interface MAC address and primary IP address as the source. The secondary PFE, however, resolves ARP requests for the monitored IP address on its own. The ICMP pings sent by the secondary PFE use the physical child MAC address and a secondary IP address configured on the redundant Ethernet interface as the source. To ensure that ICMP replies are correctly received on the secondary interface, the I/O card (IOC), central PFE processor, or Flex IOC programs both the physical child MAC address and the redundant Ethernet interface MAC address into its MAC table.

When responding to ARP requests sent to the secondary IP address configured on the redundant Ethernet interface, the secondary PFE replies using the physical child interface MAC address.

By default, the reachability of a monitored IP address is checked once per second. This interval can be modified using the retry-interval command. The default number of allowed consecutive ping failures is five, which can be adjusted with the retry-count command. If the monitored IP address fails to respond for the configured number of consecutive attempts, it is declared unreachable, and its configured failover value is deducted from the redundancy group's global-threshold.

After an IP address is declared unreachable, its configured weight is deducted from the global-threshold. If the recalculated global-threshold value remains nonzero, the IP address is marked unreachable, but the global weight of the redundancy group is not deducted. However, if the redundancy group's IP monitoring global-threshold reaches zero while unreachable IP addresses remain configured, the redundancy group repeatedly fails over and failsback between nodes. This behavior continues until either a monitored IP address becomes reachable again or unreachable IP addresses are removed from monitoring. Default and user-configured hold-down intervals for failover dampening continue to apply throughout this process.

Each redundancy group x has a threshold tolerance value that is initially set to 255. When an IP address monitored by redundancy group x becomes unavailable, the IP address's configured weight is subtracted from the redundancy group x's threshold. When the threshold value for redundancy group xreaches 0, the redundancy group fails over to the peer node.

For example, if redundancy group 1 is primary on node 0 and its threshold reaches 0, redundancy group 1 fails over and becomes primary on node 1. At this point, all child interaces associated with redundancy group 1's redundant Ethernet interfaces begin forwarding traffic on the new primary node.

A redundancy group x failover occurs when the combined weight of monitored IP addresses and any other monitoring conditions reduces the threshold to 0. If the monitored IP addresses on both nodes reach their thresholds simultaneously, redundancy group x becomes primary on the node with the lower node ID, which is typically node 0.

Firewalls support upstream device failure detection for the chassis cluster.

The Address Resolution Protocol (ARP) feature allows you to override the previously hard-coded ARP request throttling interval, which defaults to 10 seconds per SPU for each IP address, and configure a higher value ranging from 10 to 100 seconds. Increasing the ARP throttling interval helps reduce excessive utilization of the Routing Engine (RE), allowing it to operate more efficiently under load. You can configure the ARP request throttling interval using the set forwarding-options next-hop arp-throttle <seconds> command.

IP address monitoring is supported only when the IP address is reachable through a redundant Ethernet interface (referred to as a reth in CLI commands and interface listings). IP addresses cannot be monitored across tunnel interfaces. To monitor an IP address through a redundant Ethernet interface on a secondary cluster node, the interface must be configured with a secondary IP address. IP address monitoring is not supported on chassis clusters operating in transparent mode.

Redundancy group IP address monitoring is not supported for IPv6 destinations.

This example shows how to configure redundancy group IP address monitoring for an SRX Series Firewall in a chassis cluster.

This example shows how to monitor IP address on SRX5000 line of Firewalls with chassis cluster enabled.

Use Feature Explorer to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform.

See the Additional Platform Information section for more information.

Table 2: Platform-Specific Behavior

Platform

Difference

SRX Series

You can configure up to 64 IP addresses for IP monitoring on SRX5000 line of Firewalls. On SRX300, SRX320, SRX340, SRX345, and SRX380 Firewalls, when the reth interface has more than one physical interface configured, IP monitoring for redundant groups is not supported. The Firewall uses the lowest interface in the bundle for tracking on the secondary node. If the peer forwards the reply on any other port except the one it received it on, the Firewall drops it. Following are the limitations for IP monitoring support on SRX5000 line of Firewalls IOC2 and IOC3: IP monitoring is supported through the reth or the RLAG interface. If your configuration does not specify either of these interfaces, the route lookup returns a non-reth/RLAG interface, which results in a failure report. Equal-cost multipath (ECMP) routing is not supported in IP monitoring. IP address monitoring is not supported on SRX5000 line of Firewalls when the redundant Ethernet interface is configured in a VPN routing and forwarding (VRF) instance. On SRX5600 and SRX5800 Firewalls, IP address monitoring is subject to a hardware limitation when using 40-port 1-Gigabit Ethernet I/O cards (IOCs). Only two ports per PIC can simultaneously support IP address monitoring. Because each IOC contains four PICs, a maximum of eight ports per IOC can be monitored. If more than two ports per PIC are configured for IP address monitoring on these IOCs, the configuration commit succeeds, but a log message is generated, and the accuracy and stability of IP address monitoring cannot be guaranteed. This limitation does not apply to other IOC types or platforms. The maximum number of monitoring IP addresses per cluster is 64 on the SRX5000 line of Firewalls, SRX1500, SRX1600, SRX2300, SRX4120, and SRX4000 line of Firewalls.

Additional Platforms may be supported.

Table 3: Maximum MACs Supported for IP Monitoring on IOC2 and IOC3

Cards	Interfaces	Maximum MACs Supported for IP Monitoring
IOC2 (SRX5K-MPC)	10XGE	10
	20GE	20
	2X40GE	2
	1X100GE	1
IOC3 (SRX5K-MPC3-40G10G or SRX5K-MPC3-100G10G)	24x10GE	24
	6x40GE	6
	2x100GE + 4x10GE	6