Failover Triggers

When a failure occurs on the active Panorama and the passive Panorama takes over the task of managing the firewalls, the event is called a failover. A failover is triggered when a monitored metric on the active Panorama fails. This failure transitions the state on the primary Panorama from active-primary to passive-primary, and the secondary Panorama becomes active-secondary.
The conditions that trigger a failover are:
  • The Panorama peers cannot communicate with each other and the active peer does not respond to health and status polls; the metric used is HA Heartbeat Polling and Hello Messages.
    When the Panorama peers cannot communicate with each other, the active one monitors whether the peers are still connected before a failover is triggered. This check helps in avoiding a failover and causing a split-brain scenario, where both Panorama peers are in an active state.
  • One or more of the destinations (IP addresses) specified on the active peer cannot be reached; the metric used is HA Path Monitoring.
In addition to the failover triggers listed above, a failover also occurs when the administrator places the Panorama peer in a suspended state or when preemption occurs. Preemption is a preference for the primary Panorama to resume the active role after recovering from a failure (or user-initiated suspension). By default, preemption is enabled and when the primary Panorama recovers from a failure and becomes available, the secondary Panorama relinquishes control and returns to the passive state. When preemption occurs, the event is logged in the System log.
If you are logging to an NFS datastore, do not disable preemption because it allows the primary peer (that is mounted to the NFS) to resume the active role and write to the NFS datastore. For all other deployments, preemption is only required if you want to make sure that a specific Panorama is the preferred active peer.

Recommended For You