Understanding Graceful Routing Engine Switchover in the Junos OS

This topic contains the following sections:

Graceful Routing Engine Switchover Concepts

Graceful Routing Engine switchover (GRES) feature in Junos OS enables a routing or switching platform with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails. Graceful Routing Engine switchover preserves interface and kernel information. Traffic is not interrupted. However, graceful Routing Engine switchover does not preserve the control plane. Note that on T Series routers, TX Matrix routers, and TX Matrix Plus routers, the control plane is preserved in case of GRES with NSR and nearly 75% of line rate worth of traffic per Packet Forwarding Engine remains uninterrupted during GRES. Neighboring routers detect that the router or switch has experienced a restart and react to the event in a manner prescribed by individual routing protocol specifications. To preserve routing during a switchover, graceful Routing Engine switchover must be combined with either graceful restart protocol extensions or nonstop active routing. Any updates to the master Routing Engine are replicated to the backup Routing Engine as soon as they occur. If the kernel on the master Routing Engine stops operating, the master Routing Engine experiences a hardware failure, or the administrator initiates a manual switchover, mastership switches to the backup Routing Engine.

Note: To quickly restore or to preserve routing protocol state information during a switchover, graceful Routing Engine switchover must be combined with either graceful restart or nonstop active routing (NSR), respectively. For more information about graceful restart, see Graceful Restart Concepts. For more information about nonstop active routing, see Nonstop Active Routing Concepts.

If the backup Routing Engine does not receive a keepalive from the master Routing Engine after 2 seconds (4 seconds on M20 routers), it determines that the master Routing Engine has failed and takes mastership. The Packet Forwarding Engine seamlessly disconnects from the old master Routing Engine and reconnects to the new master Routing Engine. The Packet Forwarding Engine does not reboot, and traffic is not interrupted. The new master Routing Engine and the Packet Forwarding Engine then become synchronized. If the new master Routing Engine detects that the Packet Forwarding Engine state is not up to date, it resends state update messages.

Note: Successive Routing Engine switchover events must be a minimum of 240 seconds (4 minutes) apart after both Routing Engines have come up.

If the router or switch displays a warning message similar to Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset . do not attempt switchover. If you choose to proceed with switchover, only the Packet Forwarding Engines that were not ready for graceful switchover are reset. None of the FPCs should spontaneously restart. We recommend that you wait until the warning no longer appears and then proceed with the switchover.

Note that in a routing matrix with TX Matrix Plus router with 3D SIBs, for successive Routing Engine switchover, events must be a minimum of 900 seconds (15 minutes) apart after both Routing Engines have come up.

Note: We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the router or switch.

Figure 1 shows the system architecture of graceful Routing Engine switchover and the process a routing platform follows to prepare for a switchover.

Figure 1: Preparing for a Graceful Routing Engine Switchover

Note: Check Graceful Routing Engine Switchover readiness by executing the request chassis routing-engine master switch check command from Master Routing Engine and show system switchover command from Backup Routing Engine.

The switchover preparation process for graceful Routing Engine switchover follows these steps:

The master Routing Engine starts.
The routing platform processes (such as the chassis process [chassisd]) start.
The Packet Forwarding Engine starts and connects to the master Routing Engine.
All state information is updated in the system.
The backup Routing Engine starts.
The system determines whether graceful Routing Engine switchover has been enabled.
The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the master Routing Engine.
After ksyncd completes the synchronization, all state information and the forwarding table are updated.

Figure 2 shows the effects of a switchover on the routing (or switching )platform.

Figure 2: Graceful Routing Engine Switchover Process

When a switchover occurs, the switchover process follows these steps:

When keepalives from the master Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.
The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new master.
Routing platform processes that are not part of graceful Routing Engine switchover (such as the routing protocol process [rpd]) restart.
State information learned from the point of the switchover is updated in the system.
If configured, graceful restart protocol extensions collect and restore routing information from neighboring peer helper routers.

Note: On T Series and M320 routers, the Switch Interface Boards (SIBs) are taken offline and restarted one by one during a graceful Routing Engine switchover. This is done to provide the SPMB that manages the SIB enough time to populate state information for its associated SIB. However, on a fully-populated chassis where all FPCs are sending traffic at full line rate, there might be momentary packet loss during the switchover.

Note: When GRES is configured and the restart chassis-control command is executed on a TX Matrix Plus router with 3D SIBs, we cannot ascertain which Routing Engine becomes a master. This is because the chassisd process restarts with the execution of the restart chassis-control command. The chassisd process is responsible for maintaining and retaining mastership and when it is restarted, the new chassisd is processed based on the router or switch load. As a result, any one of the Routing Engines is made the master.

Effects of a Routing Engine Switchover

Table 1 describes the effects of a Routing Engine switchover when no high availability features are enabled and when graceful Routing Engine switchover, graceful restart, and nonstop active routing features are enabled.

Table 1: Effects of a Routing Engine Switchover

Feature	Benefits	Considerations
Dual Routing Engines only (no features enabled)	When the switchover to the new master Routing Engine is complete, routing convergence takes place and traffic is resumed.	All physical interfaces are taken offline, Packet Forwarding Engines restart, the standby Routing Engine restarts the routing protocol process (rpd), and all hardware and interfaces are discovered by the new master Routing Engine. The switchover takes several minutes and all of the router's (or switch's) adjacencies are aware of the physical (interface alarms) and routing (topology) change.
Graceful Routing Engine switchover enabled	During the switchover, interface and kernel information is preserved. The switchover is faster because the Packet Forwarding Engines are not restarted.	The new master Routing Engine restarts the routing protocol process (rpd). All hardware and interfaces are acquired by a process that is similar to a warm restart. All adjacencies are aware of the router's (or switch's) change in state.
Graceful Routing Engine switchover and nonstop active routing enabled	Traffic is not interrupted during the switchover. Interface, kernel, and routing protocol information is preserved.	Unsupported protocols must be refreshed using the normal recovery mechanisms inherent in each protocol.
Graceful Routing Engine switchover and graceful restart enabled	Traffic is not interrupted during the switchover. Interface and kernel information is preserved. Graceful restart protocol extensions quickly collect and restore routing information from the neighboring routers.	Neighbors are required to support graceful restart and a wait interval is required. The routing protocol process (rpd) restarts. For certain protocols, a significant change in the network can cause graceful restart to stop.

Understanding Graceful Routing Engine Switchover in the Junos OS

Graceful Routing Engine Switchover Concepts

Effects of a Routing Engine Switchover

Related Documentation