Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover

Chassis clustering supports SNMP traps, which are triggered whenever there is a redundancy group failover.

The trap message can help you troubleshoot failovers. It contains the following information:

• The cluster ID and node ID
• The reason for the failover
• The redundancy group that is involved in the failover
• The redundancy group’s previous state and current state

These are the different states that a cluster can be in at any given instant: hold, primary, secondary-hold, secondary, ineligible, and disabled. Traps are generated for the following state transitions (only a transition from a hold state does not trigger a trap):

• primary <–> secondary
• primary –> secondary-hold
• secondary-hold –> secondary
• secondary –> ineligible
• ineligible –> disabled
• ineligible –> primary
• secondary –> disabled

A transition can be triggered because of any event, such as interface monitoring, SPU monitoring, failures, and manual failovers.

The trap is forwarded over the control link if the outgoing interface is on a node different from the node on the Routing Engine that generates the trap.

You can specify that a trace log be generated by setting the traceoptions flag snmp statement.

Related Topics

• Junos OS Feature Support Reference for SRX Series and J Series Devices
• Understanding Chassis Cluster Redundancy Group Manual Failover
• Initiating a Chassis Cluster Manual Redundancy Group Failover
• Example: Configuring Chassis Cluster with a Dampening Time Between Back-to-Back Redundancy Group Failovers (CLI)
• Understanding Chassis Cluster Redundant Ethernet Interfaces
• Understanding Chassis Cluster Monitoring of Global-Level Objects