Configuring Nonstop Active Routing
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]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.
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.
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
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;
}
}
}
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.
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.