Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Configuring Nonstop Active Routing

This section includes the following topics:

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 [edit chassis redundancy] hierarchy level:

By default, nonstop active routing is disabled. To enable nonstop active routing, include the nonstop-routing statement at the [edit routing-options] hierarchy level:

To disable nonstop active routing, remove the nonstop-routing statement from the [edit routing-options] hierarchy level.


When you enable nonstop active routing, you cannot enable automatic route distinguishers for multicast VPN routing instances. Automatic route distinguishers are enabled by configuring the route-distinguisher-id statement at the [edit routing-instances instance-name] hierarchy level; for more information, see the Junos OS VPNs Library for Routing Devices.

If the routing protocol process (rpd) on the NSR primary Routing Engine crashes, the primary Routing Engine simply restarts rpd (with no Routing Engine switchover), which impacts routing protocol adjacencies and neighbors and results in traffic loss. To prevent this negative impact on traffic flow, configure the switchover-on-routing-crash statement at the [edit system] hierarchy level. This configuration forces an NSR Routing Engine switchover if rpd on the primary Routing Engine crashes.

To enable the routing platform to switch over to the backup Routing Engine when the routing protocol process (rpd) fails rapidly three times in succession, include the other-routing-engine statement at the [edit system processes routing failover] hierarchy level.

For more information about the other-routing-engine statement, see the Junos OS Administration Library for Routing Devices.

Synchronizing the Routing Engine Configuration

When you configure nonstop active routing, you must also include the commit synchronize statement at the [edit system] hierarchy level so that configuration changes are synchronized on both Routing Engines:

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

If you configure the commit synchronize statement at the [edit system] hierarchy level and issue a commit in the primary Routing Engine, the primary configuration is automatically synchronized with the backup.

However, if the backup Routing Engine is down when you issue the commit, the Junos OS displays a warning and commits the candidate configuration in the primary Routing Engine. When the backup Routing Engine comes up, its configuration will automatically be synchronized with the primary.


A newly inserted backup Routing Engine automatically synchronizes its configuration with the primary Routing Engine configuration.

When you configure nonstop active routing, you can bring the backup Routing Engine online after the primary Routing Engine is already running. There is no requirement to start the two Routing Engines simultaneously.


We recommend that you do not restart Routing Protocol Process (rpd) on primary Routing Engine after enabling nonstop active routing, as it disrupts the protocol adjacency/peering sessions, resulting in traffic loss.

Verifying Nonstop Active Routing Operation

To see whether or not nonstop active routing is enabled, issue the show task replication command. For BGP nonstop active routing, you must also issue the show bgp replication command.


If BGP is configured, before attempting nonstop active routing switchover, check the output of show bgp replication to confirm that BGP routing table synchronization has completed on the backup Routing Engine. The complete status in the output of show task replication only indicates that the socket replication has completed and the BGP synchronization is in progress. To determine whether BGP synchronization is complete, you must check the Protocol state and Synchronization state fields in the output of show bgp replication on the primary Routing Engine. The Protocol state must be idle and the Synchronization state must be complete. If you perform NSR switchover before the BGP synchronization has completed, the BGP session might flap.

For more information about these commands, see the CLI Explorer.

When you enable nonstop active routing or graceful Routing Engine switchover and issue routing-related operational mode commands on the backup Routing Engine (such as show route, show bgp neighbor, show ospf database, and so on), the output might not match the output of the same commands issued on the primary Routing Engine. For example, it is normal for the routing table on the backup Routing Engine to contain persistent phantom routes that are not present in the routing table on the primary Routing Engine.

To display BFD state replication status, issue the show bfd session command. The replicated flag appears in the output for this command when a BFD session has been replicated to the backup Routing Engine. For more information, see the CLI Explorer.