High Availability Features on Virtual-Chassis

This document provides the configuration and the explanation of the high availability features: Graceful Routing Engine Switchover (GRES), Non-Stop Routing (NSR) and Non-Stop Bridging (NSB). These features are designed to ensure minimal disruption and maintain network stability during planned and unplanned events. By leveraging these technologies, network administrators can achieve higher uptime and reliability in their network infrastructure.

Without high availability features on your Virtual-Chassis, you may encounter the following symptoms:

• Routing Engine switchover takes longer than expected.
• Temporary loss of routing information during switchover.
• Inconsistent state between primary and backup Routing Engines.
• Routing protocols not synchronizing correctly between Routing Engines.
• Loss of routing sessions during failover.
• Increased CPU utilization during synchronization.
• Bridging table inconsistencies between primary and backup Routing Engines.
• Packet loss during failover events.
• Delays in traffic forwarding after switchover.

What is Graceful Routing Engine Switchover (GRES) ?

Graceful Routing Engine switchover enables a routing platform with dual Routing Engines to switch from a master Routing Engine to a backup Routing Engine without interruption to packet forwarding. When you configure graceful Routing Engine switchover, the backup Routing Engine automatically synchronizes with the master Routing Engine to preserve kernel state information and forwarding state. 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 (GRES) must be combined with either Graceful Restart or Nonstop Active Routing (NSR), respectively.

The following image shows the system architecture of Graceful Routing Engine Switchover and the process a platform follows to prepare for a switchover.

The switchover preparation process for Graceful Routing Engine Switchover follows these steps:

1. The master Routing Engine starts.
2. The routing platform processes (such as the chassis process [chassisd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts.
6. The system determines whether graceful Routing Engine switchover has been enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the master Routing Engine.
8. All state information is updated in the system

The following image shows the effects of a switchover on the platform. 

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

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

Enabling Graceful Routing Engine Switchover (GRES)

By default, Graceful Routing Engine Switchover is disabled. To configure Graceful Routing Engine Switchover, include the "graceful-switchover" statement at the chassis redundancy hierarchy level.

user# set chassis redundancy graceful-switchover

NOTE: When you configure GRES you must also include the "commit synchronize" statement at the system hierarchy level so that, by default, when you issue the commit command, the configuration changes are synchronized on both Routing Engines.

Verifying Graceful Routing Engine Switchover Operation

To verify whether Graceful Routing Engine Switchover is enabled, on the backup Routing Engine, issue the "show system switchover" command. When the output of the command indicates that the Graceful switchover field is set to on, graceful Routing Engine switchover is operational. The status of the kernel database and configuration database synchronization between Routing Engines is also provided. For example:

user@switch > show system switchover

Graceful switchover: On

Configuration database: Ready

Kernel database: Ready

Peer state: Steady state

NOTE: You must issue the "show system switchover" command on the backup Routing Engine. This command is not supported on the master Routing Engine. 

What is Nonstop Active Routing ( NSR) ?

Nonstop Active Routing (NSR) uses the same infrastructure as Graceful Routing Engine Switchover (GRES) to preserve interface and kernel information. However, Nonstop Active Routing also saves routing protocol information by running the routing protocol process (rpd) on the backup Routing Engine. By saving this additional information, nonstop active routing is self-contained and does not rely on helper routers to assist the routing platform in restoring routing protocol information. Nonstop active routing is advantageous in networks where neighbor routers do not support graceful restart protocol extensions. As a result of this enhanced functionality, nonstop active routing is a natural replacement for graceful restart.

NOTE: To use Nonstop Active Routing, you must first enable Graceful Routing Engine Switchover on your platform.

The following image shows the system architecture of Nonstop Active Routing and the process a routing platform follows to prepare for a switchover. 

The switchover preparation process for Nonstop Active Routing follows these steps:

1. The master Routing Engine starts.
2. The routing platform processes on the master Routing Engine (such as the chassis process [chassisd] and the routing protocol process [rpd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts, including the chassis process (chassisd) and the routing protocol process (rpd).
6. The system determines whether Graceful Routing Engine Switchover and Nonstop Active Routing have been enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the master Routing Engine.
8. For supported protocols, state information is updated directly between the routing protocol processes on the master and backup Routing Engines.

The following image shows the effects of a switchover on the platform.

The switchover process follows these steps:

1. When keepalives from the master Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.
2. The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new master. Because the routing protocol process (rpd) and chassis process (chassisd) are already running, these processes do not need to restart.
3. State information learned from the point of the switchover is updated in the system. Forwarding and routing are continued during the switchover, resulting in minimal packet loss.
4. Peer routers continue to interact with the routing platform as if no change had occurred. Routing adjacencies and session state relying on underlying routing information are preserved and not reset.

Enabling Nonstop Active Routing

Nonstop active routing (NSR) requires you to configure graceful Routing Engine switchover (GRES). To enable Graceful Routing Engine Switchover, include the "graceful-switchover" statement at the chassis redundancy hierarchy level.

user# set chassis redundancy graceful-switchover

By default, Nonstop Active Routing is disabled. To enable Nonstop Active Routing, include the "nonstop-routing" statement at the routing-options hierarchy level: 

user# set routing-options nonstop-routing

NOTE: When you configure NSR you must also include the commit synchronize statement at the system hierarchy level so that, by default, when you issue the commit command, the configuration changes are synchronized on both Routing Engines.

Verifying Nonstop Active Routing Operation

To see whether or not Nonstop Active Routing is enabled, issue the "show task replication" command.

user> show task replication

     Stateful Replication: Enabled

     RE mode: Master

   Protocol        Synchronization Status

   OSPF          NotStarted

   BGP           Complete

   IS-IS          NotStarted

   LDP           Complete

   PIM           Complete

Tracing Nonstop Active Routing Synchronization Events 

To track the Progress of Nonstop Active routing synchronization between Routing Engines, you can configure Nonstop Active Routing trace options flags for each supported protocol and for BFD sessions and record these operations to a log file. To configure Nonstop Active Routing trace options for supported routing protocols, include the "nsr-synchronization" statement at the protocols protocol-name traceoptions flag hierarchy level and specify the detail, disable, receive, or send option.

Protocols

user# set protocols bgp traceoptions flag nsr-synchronization detail send receive disable

user# set protocols ospf traceoptions flag nsr-synchronization detail send receive disable

user# set protocols isis traceoptions flag nsr-synchronization detail send receive disable

user# set protocols ldp traceoptions flag nsr-synchronization detail send receive disable

BFD

user# set protocols bfd traceoptions flag nsr-synchronization

user# set protocols bfd traceoptions flag nsr-packet

Nonstop Bridging (NSB)

Nonstop Bridging uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, Nonstop Bridging also saves Layer 2 Control Protocol (L2CP) information by running the Layer 2 Control Protocol process (l2cpd) on the backup Routing Engine. 

NOTE: To use Nonstop Bridging, you must first enable Graceful Routing Engine Switchover on your platform.

Following image shows the system architecture of Nonstop Bridging and the process a routing platform follows to prepare for a switchover.

The switchover preparation process for Nonstop Bridging follows these steps:

1. The master Routing Engine starts.
2. The routing platform processes on the master Routing Engine (such as the chassis process [chassisd] and the Layer 2 Control Protocol process [l2cpd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts, including the chassis process (chassisd) and the Layer 2 Control Protocol process (l2cpd).
6. The system determines whether Graceful Routing Engine Switchover and Nonstop Bridging have been enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the master Routing Engine.
8. For supported protocols, state information is updated directly between the l2cpds on the master and backup Routing Engines

Following image shows the effects of a switchover on the platform.

The switchover process follows these steps:

1. When keepalives from the master Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.
2. The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new master. Because the Layer 2 Control Protocol process (l2cpd) and chassis process (chassisd)are already running, these processes do not need to restart.
3. State information learned from the point of the switchover is updated in the system. Forwarding and bridging are continued during the switchover, resulting in minimal packet loss.

Enabling Nonstop Bridging

Nonstop Bridging (NSB) requires you to configure Graceful Routing Engine Switchover (GRES). To enable graceful Routing Engine switchover, include the "graceful-switchover" statement at the chassis redundancy hierarchy level.

user# set chassis redundancy graceful-switchover

By default, Nonstop Bridging is disabled. To enable Nonstop Bridging, include the "nonstop-bridging" statement at the protocols layer2-control hierarchy level.

user# set protocols layer2-control nonstop-bridging

NOTE :When you configure Nonstop Bridging, you must also include the "commit synchronize" statement at the system hierarchy level so that, by default, when you issue the commit command, the configuration changes are synchronized on both Routing Engines.

Verifying Nonstop Bridging Operation 

When you enable Nonstop Bridging, you can issue Layer 2 Control Protocol-related operational mode commands on the backup Routing Engine. However, the output of the commands might not match the output of the same commands issued on the master Routing Engine.

Find more commands to ensure that the primary and backup Routing Engines are in sync on the following KB: Junos-List-of-commands-to-check-for-GRES-readiness

For more information about High Availability Features on Juniper:  https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/high-availability-features-in-junos-introducing.html