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.