Configuring Nonstop Active Routing
SUMMARY Configure nonstop active routing on your device with the following steps and examples.
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] 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.
Configuring Nonstop Active Routing on Switches
Nonstop active routing (NSR) provides a mechanism for 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.
You can configure NSR on an on a Juniper Networks EX Series switch with multiple Routing Engines or an EX Series or QFX Series switch in a Virtual Chassis or Virtual Chassis Fabric configuration.
To configure nonstop active routing:
There is no requirement to start the two Routing Engines
simultaneously. If the backup Routing Engine is not up when you issue
the commit synchronize command , the candidate configuration
is committed in the primary Routing Engine. When the backup Routing
Engine is inserted or comes online, its configuration is automatically
synchronized with that of the primary.
After a graceful Routing Engine switchover, we
recommend that you issue the clear interface statistics (interface-name | all) command to reset the cumulative
values for local statistics on the new primary Routing Engine.
To disable nonstop active routing:
[edit routing-options] user@switch# delete nonstop-routing
See Also
Preventing Automatic Reestablishment of BGP Peer Sessions After NSR Switchovers
It is useful to prevent a BGP peer session from automatically being reestablished after a nonstop active routing (NSR) switchover when you have applied routing policies configured in the dynamic database. When NSR is enabled, the dynamic database is not synchronized with the backup Routing Engine. Therefore, when a switchover occurs, import and export policies configured in the dynamic database might no longer be available. For more information about configuring dynamic routing policies, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.
The BGP established timers are not maintained across switchovers.
You can configure the routing device not to reestablish a BGP
peer session after an NSR switchover either for a specified period
or until you manually reestablish the session. Include the idle-after-switch-over statement at the [edit protocols bgp] hierarchy level:
idle-after-switch-over (forever | seconds);
For a list of hierarchy levels at which you can configure this statement, see the configuration statement summary for this statement.
For seconds, specify a value from 1
through 4294967295. The BGP peer session is not reestablished
until after the specified period. If you specify the forever option, the BGP peer session is not reestablished until you issue
the clear bgp neighbor command.
Example: Configuring Nonstop Active Routing
The following example enables graceful Routing Engine switchover, nonstop active routing, and nonstop active routing trace options for BGP, IS-IS, and OSPF.
[edit]
system commit {
synchronize;
}
chassis {
redundancy {
graceful-switchover; # This enables graceful Routing Engine switchover on
# the routing platform.
}
}
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.1.1/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.1.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.3.1.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family iso {
address 49.0004.1921.6800.2001.00;
}
}
}
}
routing-options {
nonstop-routing; # This enables nonstop active routing on the routing platform.
router-id 192.168.2.1;
autonomous-system 65432;
}
protocols {
bgp {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing
# events for BGP.
}
advertise-from-main-vpn-tables;
local-address 192.168.2.1;
group external-group {
type external;
export BGP_export;
neighbor 192.168.1.1 {
family inet {
unicast;
}
peer-as 65103;
}
}
group internal-group {
type internal;
neighbor 192.168.10.1;
neighbor 192.168.11.1;
neighbor 192.168.12.1;
}
}
isis {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing events
# for IS-IS.
}
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop active routing events
# for OSPF.
}
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement BGP_export {
term direct {
from {
protocol direct;
}
then accept;
}
term final {
then reject;
}
}
}
See Also
Resetting Local Statistics
After a graceful Routing Engine switchover, we recommend that
you issue the clear interface statistics (interface-name | all) command to reset the cumulative values for local statistics
on the new primary Routing Engine.
See Also
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.
Requirements
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.
Configuration
CLI Quick Configuration
To quickly configure nonstop active routing, copy the following commands and paste them into the switch terminal window:
[edit] set chassis redundancy graceful-switchover set routing-options nonstop-routing set system commit synchronize
Procedure
Step-by-Step Procedure
To configure nonstop active routing on a switch:
Enable graceful Routing Engine switchover (GRES):
[edit chassis redundancy] user@switch# set graceful-switchover
Enable nonstop active routing (by default, nonstop active routing is disabled):
[edit routing-options] user@switch# set nonstop-routing
Synchronize configuration changes between the Routing Engines:
[edit system] user@switch# set commit synchronize
If you try to commit the nonstop active routing configuration without including the
commit synchronizestatement, the commit fails.Note: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.
Results
Check the results of the configuration:
[edit]
user@switch# show
chassis {
redundancy {
graceful-switchover;
}
routing-options {
nonstop-routing;
}
system {
commit synchronize;
}
Verification
To confirm that the configuration is working properly, perform these tasks:
Verifying That Nonstop Active Routing Is Working Correctly on the Switch
Purpose
Verify that nonstop active routing is enabled.
Action
Issue the show task
replication command:
user@switch# show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol Synchronization Status
OSPF Complete
RIP Complete
PIM Complete
RSVP Complete Meaning
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:
Stateful Replication: Disabled RE mode: Master
Troubleshooting
To troubleshoot nonstop active routing, perform these tasks:
Investigating Problems with Synchronization of Routing Engines When NSR Is Enabled
Problem
A protocol loses connectivity with neighbors after a graceful Routing Engine switchover (GRES) occurs with nonstop active routing (NSR) enabled.
Solution
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.