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.
Before You Begin |
|---|
For background information, read about enterprise-specific MIBs for JUNOS Software in the JUNOS Network Management Configuration Guide. |
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 due to any event, such as interface monitoring, SPU monitoring, failures, and manual failovers.
The trap will be 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 Software Feature Support Reference for SRX Series and J Series Devices
- Understanding Chassis Cluster Redundancy Group Manual Failover
- 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