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:
[edit chassis redundancy] graceful-switchover;
By default, nonstop active routing is disabled. To enable
nonstop active routing, include the nonstop-routing
statement
at the [edit routing-options]
hierarchy level:
[edit routing-options] nonstop-routing;
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.
[edit system] user@host# set switchover-on-routing-crash
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:
[edit system] commit synchronize;
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.