Nonstop Active Routing Concepts
Nonstop active routing (NSR) uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, NSR also saves routing protocol information by running the routing protocol process (rpd) on the backup Routing Engine. By saving this additional information, NSR is self-contained and does not rely on helper routers (or switches) to assist the routing platform in restoring routing protocol information. NSR is advantageous in networks in which neighbor routers (or switches) do not support graceful restart protocol extensions. As a result of this enhanced functionality, NSR is a natural replacement for graceful restart.
Starting with Junos OS Release 15.1R1, if you have NSR configured, it is never valid to issue the restart routing command in any form on the NSR master Routing Engine. Doing so results in a loss of protocol adjacencies and neighbors and a drop in traffic.
To use NSR, you must first enable GRES on your routing (or switching) platform. For more information about GRES, see Understanding Graceful Routing Engine Switchover.
Starting with Junos OS Release 12.3, because of its synchronization requirements and logic, NSR or GRES performance is limited by the slowest Routing Engine in the system.
If NSR is enabled, certain system log (syslog) messages are sent from the backup Routing Engine if the configured syslog host is reachable through the fxp0 interface.
Figure 1 shows the system architecture of nonstop active routing and the process a routing (or switching) platform follows to prepare for a switchover.
The switchover preparation process for NSR comprises the following steps:
The master Routing Engine starts.
The routing (or switching) platform processes on the master Routing Engine (such as the chassis process [chassisd] and the routing protocol process [rpd]) start.
The Packet Forwarding Engine starts and connects to the master Routing Engine.
All state information is updated in the system.
The backup Routing Engine starts, including the chassis process (chassisd) and the routing protocol process (rpd).
The system determines whether GRES and NSR have been enabled.
The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the master Routing Engine.
For supported protocols, state information is updated directly between the routing protocol processes on the master and backup Routing Engines.
Figure 2 shows the effects of a switchover on the routing platform.
The switchover process comprises the following steps:
When keepalives from the master Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.
The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new master. Because the routing protocol process (rpd) and chassis process (chassisd) are already running, these processes do not need to restart.
State information learned from the point of the switchover is updated in the system. Forwarding and routing are continued during the switchover, resulting in minimal packet loss.
Peer routers (or switches) continue to interact with the routing platform as if no change had occurred. Routing adjacencies and session state relying on underlying routing information are preserved and not reset.
We recommend that you do not restart the routing protocol process (rpd) on master Routing Engine after enabling NSR, as it disrupts the protocol adjacency/peering sessions, resulting in traffic loss.