Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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:

    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.

    Note: 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 master Routing Engine crashes, the master 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 master 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 master Routing Engine, the master 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 master Routing Engine. When the backup Routing Engine comes up, its configuration will automatically be synchronized with the master.

    Note: A newly inserted backup Routing Engine automatically synchronizes its configuration with the master Routing Engine configuration.

    When you configure nonstop active routing, you can bring the backup Routing Engine online after the master Routing Engine is already running. There is no requirement to start the two Routing Engines simultaneously.

    Caution: We recommend that you do not restart Routing Protocol Process (rpd) on master 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 can also issue the show bgp replication command.

    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 master 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 master 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.

    Modified: 2016-05-11