Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Configuring Nonstop Active Routing on Switches

Nonstop active routing (NSR) provides high availability for Routing Engines by enabling transparent switchover of the Routing Engines without necessitating restart of supported routing protocols. Both Routing Engines are fully active in processing protocol sessions, and so each can take over for the other. The switchover is transparent to neighbors.

This example describes how to configure nonstop active routing on switches with multiple Routing Engines or on an EX Series or a QFX series switch in a Virtual Chassis or Virtual Chassis Fabric configuration.


This example uses the following hardware and software components:

  • An EX Series with multiple Routing Engines or on an EX Series or a QFX series switch in a Virtual Chassis or Virtual Chassis Fabric configuration

  • Junos OS Release 10.4 or later for EX Series switches

  • Junos OS Release 13.2X51-D20 or later for QFX Series switches

Overview and Topology

Configure nonstop active routing on any EX Series with multiple Routing Engines or on an EX Series or a QFX series switch in a Virtual Chassis or Virtual Chassis Fabric configuration. Nonstop active routing is advantageous in networks where neighbor routing devices do not support graceful restart protocol extensions.

The topology used in this example consists of an EX8200 switch with redundant Routing Engines connected to neighbor routing devices that are not configured to support graceful restart of protocols.


CLI Quick Configuration

To quickly configure nonstop active routing, copy the following commands and paste them into the switch terminal window:


Step-by-Step Procedure

To configure nonstop active routing on a switch:

  1. Enable graceful Routing Engine switchover (GRES):

  2. Enable nonstop active routing (by default, nonstop active routing is disabled):

  3. Synchronize configuration changes between the Routing Engines:

    If you try to commit the nonstop active routing configuration without including the commit synchronize statement, the commit fails.


    If the backup Routing Engine is down when you issue the commit, a warning is displayed and the candidate configuration is committed in the primary Routing Engine. When the backup Routing Engine comes up, its configuration is automatically synchronized with that of the primary. If you subsequently insert or bring up a backup Routing Engine, it automatically synchronizes its configuration with the primary Routing Engine configuration.


Check the results of the configuration:


To confirm that the configuration is working properly, perform these tasks:

Verifying That Nonstop Active Routing Is Working Correctly on the Switch


Verify that nonstop active routing is enabled.


Issue the show task replication command:


This output shows that nonstop active routing (Stateful Replication) is enabled on primary routing engine. If nonstop routing is not enabled, instead of the output shown above:

  • On the backup routing engine the following error message is displayed: “error: the routing subsystem is not running.”

  • On the primary routing engine, the following output is displayed if nonstop routing is not enabled:


To troubleshoot nonstop active routing, perform these tasks:

Investigating Problems with Synchronization of Routing Engines When NSR Is Enabled


A protocol loses connectivity with neighbors after a graceful Routing Engine switchover (GRES) occurs with nonstop active routing (NSR) enabled.


Use trace options to help isolate the problem and gather troubleshooting information. Using the information gathered from trace options, you can confirm or eliminate the synchronization of the Routing Engines as the cause of the loss of connectivity for the protocol. See Tracing Nonstop Active Routing Synchronization Events.