Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understanding Nonstop Active Routing

Nonstop active routing (NSR) enables the transparent switchover of the Routing Engines in the event that one of the Routing Engines goes down.

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 primary Routing Engine. Doing so results in a loss of protocol adjacencies and neighbors and a drop in traffic.

Note:

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.

Note:

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.

Note:

NSR is not supported during the Routing Engine reboot process on MX Series devices with the Next-Generation Routing Engine (NG-RE) installed. NSR will still work during the Routing Engine switchover process.

Figure 1 shows the system architecture of nonstop active routing and the process a routing (or switching) platform follows to prepare for a switchover.

Figure 1: Nonstop Active Routing Switchover Preparation ProcessNonstop Active Routing Switchover Preparation Process

The switchover preparation process for NSR comprises the following steps:

  1. The primary Routing Engine starts.

  2. The routing (or switching) platform processes on the primary Routing Engine (such as the chassis process [chassisd] and the routing protocol process [rpd]) start.

  3. The Packet Forwarding Engine starts and connects to the primary Routing Engine.

  4. All state information is updated in the system.

  5. The backup Routing Engine starts, including the chassis process (chassisd) and the routing protocol process (rpd).

  6. The system determines whether GRES and NSR have been enabled.

  7. The kernel synchronization process (ksyncd) synchronizes the backup Routing Engine with the primary Routing Engine.

  8. For supported protocols, state information is updated directly between the routing protocol processes on the primary and backup Routing Engines.

Figure 2 shows the effects of a switchover on the routing platform.

Figure 2: Nonstop Active Routing During a SwitchoverNonstop Active Routing During a Switchover

The switchover process comprises the following steps:

  1. When keepalives from the primary Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.

  2. The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new primary. Because the routing protocol process (rpd) and chassis process (chassisd) are already running, these processes do not need to restart.

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

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

CAUTION:

We recommend that you do not restart the routing protocol process (rpd) on primary Routing Engine after enabling NSR, as it disrupts the protocol adjacency/peering sessions, resulting in traffic loss.

See Also

Understanding Nonstop Active Routing on EX Series Switches

You can configure nonstop active routing (NSR) on an EX Series switch with redundant Routing Engines or on an EX Series Virtual Chassis to enable the transparent switchover of the Routing Engines in the event that one of the Routing Engines goes down.

Nonstop active routing provides high availability for Routing Engines by enabling transparent switchover of the Routing Engines without requiring 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 neighbor routing devices, which do not detect that a change has occurred.

Enable nonstop active routing when neighbor routing devices are not configured to support graceful restart of protocols or when you want to ensure graceful restart of protocols for which graceful restart is not supported—such as PIM.

You do not need to start the two Routing Engines simultaneously to synchronize them for nonstop active routing. If both Routing Engines are not present or not up when you issue a commit synchronize statement, the candidate configuration is committed in the primary Routing Engine and when the backup Routing Engine is inserted or comes online, its configuration is automatically synchronized with that of the primary.

Nonstop active routing uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, nonstop active routing also saves routing protocol information by running the routing protocol process (rpd) on the backup Routing Engine. By saving this additional information, nonstop active routing does not rely on other routing devices to assist in restoring routing protocol information.

Note:

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.

If you suspect a problem with the synchronization of Routing Engines when nonstop active routing is enabled, you can gather troubleshooting information using trace options. For example, if certain protocols lose connectivity with neighbors after a graceful Routing Engine switchover with NSR enabled, you can use trace options to help isolate the problem. See Tracing Nonstop Active Routing Synchronization Events.

Note:

Graceful restart and nonstop active routing are mutually exclusive. You will receive an error message upon commit if both are configured.

Note:

Nonstop active routing provides a transparent switchover mechanism only for Layer 3 protocol sessions. Nonstop bridging (NSB) provides a similar mechanism for Layer 2 protocol sessions. See Understanding Nonstop Bridging on EX Series Switches.

See Also

Nonstop Active Routing System Requirements

This section contains the following topics:

Nonstop Active Routing Platform and Switching Platform Support

Table 1 lists the platforms that support nonstop active routing (NSR).

Table 1: Nonstop Active Routing Platform Support

Platform

Junos OS Release

M10i router

8.4 or later

M20 router

8.4 or later

M40e router

8.4 or later

M120 router

9.0 or later

M320 router

8.4 or later

MX Series routers

9.0 or later

PTX Series Packet Transport Routers

Note:

Nonstop active routing (NSR) switchover on PTX series is supported only for the following MPLS and VPN protocols and applications using chained composite next hops:

  • Labeled BGP

  • Layer 2 VPNs excluding Layer 2 interworking (Layer 2 switching)

  • Layer 3 VPNs

  • LDP

  • RSVP

12.1R4 or later

T320 router, T640 router, and TX Matrix router

8.4 or later

Standalone T1600 router

8.5 or later

Standalone T4000 router

12.1R2 or later

TX Plus Matrix router

10.0 or later

TX Plus Matrix router with 3D SIBs

13.1 or later

EX Series switch with dual Routing Engines or in a Virtual Chassis

10.4 or later for EX Series switches

EX Series or QFX Series switches in a Virtual Chassis Fabric

13.2X51-D20 or later for the EX Series and QFX Series switches
Note:

All Routing Engines configured for nonstop active routing must be running the same Junos OS release.

Nonstop Active Routing Protocol and Feature Support

Table 2 lists the protocols that are supported by nonstop active routing.

Table 2: Nonstop Active Routing Protocol and Feature Support

Protocol

Junos OS Release

Aggregated Ethernet interfaces with Link Aggregation Control Protocol (LACP)

9.4 or later

Bidirectional Forwarding Detection (BFD)

For more information, see Nonstop Active Routing BFD Support.

8.5 or later

BGP

For more information, see Nonstop Active Routing BGP Support.

8.4 or later

EVPN

  • EVPN with ingress replication for BUM traffic

  • EVPN-ETREE

  • EVPN-VPWS

  • EVPN -VXLAN

  • PBB-EVPN

  • EVPN with P2MP mLDP replication for BUM traffic

For more information, please see NSR and Unified ISSU Support for EVPN .

16.2R1 or later (for EVPN with ingress replication for BUM traffic )

17.2R1 or later (for (EVPN-ETREE, EVPN-VPWS, EVPN-VXLAN, and PBB-EVPN)

18.2R1 or later (for EVPN with P2MP mLDP replication for BUM traffic)

Labeled BGP (PTX Series Packet Transport Routers: only)

12.1R4 or later

IS-IS

8.4 or later

LDP

8.4 or later

LDP-based virtual private LAN service (VPLS)

9.3 or later

LDP OAM (operation, administration, and management) features

9.6 or later

LDP (PTX Series Packet Transport Routers only)

Nonstop active routing support for LDP includes:

  • LDP unicast transit LSPs

  • LDP egress LSPs for labeled internal BGP (IBGP) and external BGP (EBGP)

  • LDP over RSVP transit LSPs

  • LDP transit LSPs with indexed next hops

  • LDP transit LSPs with unequal cost load balancing

  • LDP Point-to-Multipoint LSPs

  • LDP ingress LSPs

12.3R4 or later

(for LDP Point-to-Multipoint LSPs) 13.3R1 or later

(for LDP ingress LSPs) 13.3R1 or later

Layer 2 circuits

(on LDP-based VPLS) 9.2 or later

(on RSVP-TE LSP) 11.1 or later

Layer 2 VPNs

9.1 or later

Layer 2 VPNs (PTX Series Packet Transport Routers only)

Note:

Nonstop active routing is not supported for Layer 2 interworking (Layer 2 stitching).

12.1R4 or later

Layer 3 VPNs (see the first Note after this table for restrictions)

Nonstop active routing support for Layer 3 VPNs include:

  • IPv4 labeled-unicast (ingress or egress)

  • IPv4-vpn unicast (ingress or egress)

  • IPv6 labeled-unicast (ingress or egress)

  • IPv6-vpn unicast (ingress or egress)

9.2 or later

Layer 3 VPNs (PTX Series Packet Transport Routers only)

12.1R4 or later

Logical System support (Nonstop active routing support for logical systems to preserve interface and kernel information).

13.3R1 or later
   

Multicast Source Discovery Protocol (MSDP)

For more information, see Nonstop Active Routing MSDP Support.

12.1 or later

OSPF/OSPFv3

8.4 or later

Protocol Independent Multicast (PIM)

For more information, see Nonstop Active Routing PIM Support.

(for IPv4) 9.3 or later

(for IPv6) 10.4 or later

RIP and RIP next generation (RIPng)

9.0 or later

RSVP (PTX Series Packet Transport Routers only)

Nonstop active routing support for RSVP includes:

  • Point-to-Multipoint LSPs

    • RSVP Point-to-Multipoint ingress, transit, and egress LSPs using existing non-chained next hop.

    • RSVP Point-to-Multipoint transit LSPs using composite next hops for Point-to-Multipoint label routes.

  • Point-to-Point LSPs

    • RSVP Point-to-Point ingress, transit, and egress LSPs using non-chained next hops.

    • RSVP Point-to-Point transit LSPs using chained composite next hops.

12.1R4 or later

RSVP-TE LSP

For more information, see Nonstop Active Routing Support for RSVP-TE LSPs.

9.5 or later

VPLS

(LDP-based) 9.1 or later

(RSVP-TE-based) 11.2 or later

VRRP

13.2 or later

VRRP

13.2 or later
Note:

In a Virtual Chassis environment configured with OSPF and NSR, any failure or restart of the backup device can lead to longer global convergence times compared to environments where NSR is not configured.
Note:

Layer 3 VPN support does not include dynamic GRE tunnels, multicast VPNs, or BGP flow routes.

Note:

If you configure a protocol that is not supported by nonstop active routing, the protocol operates as usual. When a switchover occurs, the state information for the unsupported protocol is not preserved and must be refreshed using the normal recovery mechanisms inherent in the protocol.
Note:

On routers that have logical systems configured on them, NSR is only supported in the main instance.
Note:

Starting with Junos OS Release 13.3R5, on EX9214 switches, the VRRP primary state might change during graceful Routing Engine switchover, even when nonstop active routing is enabled.

Nonstop Active Routing BFD Support

Nonstop active routing supports the Bidirectional Forwarding Detection (BFD) protocol, which uses the topology discovered by routing protocols to monitor neighbors. The BFD protocol is a simple hello mechanism that detects failures in a network. Because BFD is streamlined to be efficient at fast liveness detection, when it is used in conjunction with routing protocols, routing recovery times are improved. With nonstop active routing enabled, BFD session states are not restarted when a Routing Engine switchover occurs.

Note:

BFD session states are saved only for clients using aggregate or static routes or for BGP, IS-IS, OSPF/OSPFv3, PIM, or RSVP.

When a BFD session is distributed to the Packet Forwarding Engine, BFD packets continue to be sent during a Routing Engine switchover. If nondistributed BFD sessions are to be kept alive during a switchover, you must ensure that the session failure detection time is greater than the Routing Engine switchover time. The following BFD sessions are not distributed to the Packet Forwarding Engine: multihop sessions, tunnel-encapsulated sessions, and sessions over integrated routing and bridging (IRB) interfaces.

Note:

BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. The minimum-interval configuration statement is a BFD liveness detection parameter.

Depending on your network environment, these additional recommendations might apply:

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions, and 100 ms for distributed BFD sessions.

  • For very large-scale network deployments with a large number of BFD sessions, contact Juniper Networks customer support for more information.

  • For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing is configured, specify a minimum interval of 2.5 seconds for Routing Engine-based sessions. For distributed BFD sessions with nonstop active routing configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

Nonstop Active Routing BGP Support

Nonstop active routing BGP support is subject to the following conditions:

  • You must include the path-selection external-router-ID statement at the [edit protocols bgp] hierarchy level to ensure consistent path selection between the primary and backup Routing Engines during and after the nonstop active routing switchover.

  • Starting with Junos OS Release 14.1, you must include the advertise-from-main-vpn-tables statement at the [edit protocols bgp] hierarchy level to prevent BGP sessions from going down when route reflector (RR) or autonomous system border router (ASBR) functionality is enabled or disabled on a routing device that has VPN address families configured.

  • BGP session uptime and downtime statistics are not synchronized between the primary and backup Routing Engines during Nonstop Active Routing and ISSU. The backup Routing Engine maintains its own session uptime based on the time when the backup first becomes aware of the established sessions. For example, if the backup Routing Engine is rebooted (or if you run restart routing on the backup Routing Engine), the backup's uptime is a short duration, because the backup has just learned about the established sessions. If the backup is operating when the BGP sessions first come up on the primary, the uptime on the primary and the uptime on the backup are almost the same duration. After a Routing Engine switchover, the new primary continues from the time left on the backup Routing Engine.

  • If the BGP peer in the primary Routing Engine has negotiated address-family capabilities that are not supported for nonstop active routing, then the corresponding BGP neighbor state on the backup Routing Engine shows as idle. On switchover, the BGP session is reestablished from the new primary Routing Engine.

    Only the following address families are supported for nonstop active routing.

    Note:

    Address families are supported only on the main instance of BGP. Only unicast is supported on VRF instances.

    • evpn-signaling

    • inet labeled-unicast

    • inet-mdt

    • inet multicast

    • inet-mvpn

    • inet unicast

    • inet-vpn unicast

    • inet6 labeled-unicast

    • inet6 multicast

    • inet6-mvpn

    • inet6 unicast

    • inet6-vpn unicast

    • iso-vpn

    • l2vpn signaling

    • route-target

  • BGP route dampening does not work on the backup Routing Engine when nonstop active routing is enabled.

Nonstop Active Routing Layer 2 Circuit and VPLS Support

Nonstop active routing supports Layer 2 circuit and VPLS on both LDP-based and RSVP-TE-based networks. Nonstop active routing support enables the backup Routing Engine to track the label advertised by Layer 2 circuit and VPLS on the primary Routing Engine, and to use the same label after the Routing Engine switchover.

in Junos OS Release 9.6 and later, nonstop active routing support is extended to the Layer 2 circuit and LDP-based VPLS pseudowire redundant configurations.

Nonstop Active Routing PIM Support

Nonstop active routing supports Protocol Independent Multicast (PIM) with stateful replication on backup Routing Engines. State information replicated on the backup Routing Engine includes information about neighbor relationships, join and prune events, rendezvous point (RP) sets, synchronization between routes and next hops, multicast session states, and the forwarding state between the two Routing Engines.

Note:

Nonstop active routing for PIM is supported for IPv4 on Junos OS Release 9.3 and later, and for IPv6 on Junos OS Release 10.4 and later. Starting with Release 11.1, Junos OS also supports nonstop active routing for PIM on devices that have both IPv4 and IPv6 configured on them.

To configure nonstop active routing for PIM, include the same statements in the configuration as for other protocols: the nonstop-routing statement at the [edit routing-options] hierarchy level and the graceful-switchover statement at the [edit chassis redundancy] hierarchy level. To trace PIM nonstop active routing events, include the flag nsr-synchronization statement at the [edit protocols pim traceoptions] hierarchy level.

Note:

The clear pim join, clear pim register, and clear pim statistics operational mode commands are not supported on the backup Routing Engine when nonstop active routing is enabled.

Nonstop active routing support varies for different PIM features. The features fall into the following three categories: supported features, unsupported features, and incompatible features.

Supported features:

  • Auto-RP

    Note:

    Nonstop active routing PIM support on IPv6 does not support auto-RP because IPv6 does not support auto-RP.

  • Bootstrap router (BSR)

  • Static RPs

  • Embedded RP on non-RP IPv6 routers

  • Local RP

    Note:

    RP set information synchronization is supported for local RP and BSR (on IPv4 and IPv6), autoRP (on IPv4), and embedded RP (on IPv6).

  • BFD

  • Dense mode

  • Sparse mode

  • Source-specific multicast (SSM)

  • Draft Rosen multicast VPNs (MVPNs)

  • Anycast RP (anycast RP set information synchronization and anycast RP register state synchronization on IPv4 and IPv6 configurations)

  • Flow maps

  • Unified ISSU

  • Policy features such as neighbor policy, bootstrap router export and import policies, scope policy, flow maps, and reverse path forwarding (RPF) check policies

  • Upstream assert synchronization

  • PIM join load balancing

Starting with Release 12.2, Junos OS extends the nonstop active routing PIM support to draft Rosen MVPNs. Nonstop active routing PIM support for draft Rosen MVPNs enables nonstop active routing-enabled devices to preserve draft Rosen MPVN-related information—such as default and data multicast distribution tree (MDT) states—across switchovers. In releases earlier than 12.2, nonstop active routing PIM configuration was incompatible with draft Rosen MVPN configuration.

The backup Routing Engine sets up the default MDT based on the configuration and the information it receives from the primary Routing Engine, and keeps updating the default MDT state information.

However, for data MDTs, the backup Routing Engine relies on the primary Routing Engine to provide updates when data MDTs are created, updated, or deleted. The backup Routing Engine neither monitors data MDT flow rates nor triggers a data MDT switchover based on variations in flow rates. Similarly, the backup Routing Engine does not maintain the data MDT delay timer or timeout timer. It does not send MDT join TLV packets for the data MDTs until it takes over as the primary Routing Engine. After the switchover, the new primary Routing Engine starts sending MDT join TLV packets for each data MDT, and also resets the data MDT timers. Note that the expiration time for the timers might vary from the original values on the previous primary Routing Engine.

Starting with Release 12.3, Junos OS extends the Protocol Independent Multicast (PIM) nonstop active routing support to IGMP-only interfaces.

In Junos OS releases earlier than 12.3, the PIM joins created on IGMP-only interfaces were not replicated on the backup Routing Engine. Thus, the corresponding multicast routes were marked as pruned (meaning discarded) on the backup Routing Engine. Because of this limitation, after a switchover, the new primary Routing Engine had to wait for the IGMP module to come up and start receiving reports to create PIM joins and to install multicast routes. This caused traffic loss until the multicast joins and routes were reinstated.

However, in Junos OS Release 12.3 and later, the multicast joins on the IGMP-only interfaces are mapped to PIM states, and these states are replicated on the backup Routing Engine. If the corresponding PIM states are available on the backup, the multicast routes are marked as forwarding on the backup Routing Engine. This enables uninterrupted traffic flow after a switchover. This enhancement covers IGMPv2, IGMPv3, MLDv1, and MLDv2 reports and leaves.

Unsupported features: You can configure the following PIM features on a router along with nonstop active routing, but they function as if nonstop active routing is not enabled. In other words, during Routing Engine switchover and other outages, their state information is not preserved, and traffic loss is to be expected.

  • Internet Group Management Protocol (IGMP) exclude mode

  • IGMP snooping

Nonstop active routing is not supported for next-generation MVPNs with PIM provider tunnels. The commit operation fails if the configuration includes both nonstop active routing and next-generation MVPNs with PIM provider tunnels.

Junos OS provides a configuration statement that disables nonstop active routing for PIM only, so that you can activate incompatible PIM features and continue to use nonstop active routing for the other protocols on the router. Before activating an incompatible PIM feature, include the nonstop-routing disable statement at the [edit protocols pim] hierarchy level. Note that in this case, nonstop active routing is disabled for all PIM features, not just incompatible features.

Nonstop Active Routing MSDP Support

Starting with Release 12.1, Junos OS extends nonstop active routing support to the Multicast Source Discovery Protocol (MSDP).

Nonstop active routing support for MSDP preserves the following MSDP-related information across the switchover:

  • MSDP configuration and peer information

  • MSDP peer socket information

  • Source-active and related information

However, note that the following restrictions or limitations apply to nonstop active routing MSDP support:

  • Because the backup Routing Engine learns the active source information by processing the source-active messages from the network, synchronizing of source active information between the primary and backup Routing Engines might take up to 60 seconds. So, no planned switchover is allowed within 60 seconds of the initial replication of the sockets.

  • Similarly, Junos OS does not support two planned switchovers within 240 seconds of each other.

Junos OS enables you to trace MSDP nonstop active routing events by including the flag nsr-synchronization statement at the [edit protocols msdp traceoptions] hierarchy level.

Nonstop Active Routing Support for RSVP-TE LSPs

Junos OS extends nonstop active routing support to label-switching routers (LSRs) and Layer 2 Circuits that are part of an RSVP-TE LSP. Nonstop active routing support on LSRs ensures that the primary to backup Routing Engine switchover on an LSR remains transparent to the network neighbors and that the LSP information remains unaltered during and after the switchover.

You can use the show rsvp version command to view the nonstop active routing mode and state on an LSR. Similarly, you can use the show mpls lsp and show rsvp session commands on the backup Routing Engine to view the state recreated on the backup Routing Engine.

The Junos OS nonstop active routing feature is also supported on RSVP point-to-multipoint LSPs. Nonstop active routing support for RSVP point-to-multipoint egress and transit LSPs was added in Junos OS Release 11.4, and for ingress LSPs in Release 12.1. During the switchover, the LSP comes up on the backup Routing Engine that shares and synchronizes the state information with the primary Routing Engine before and after the switchover. Nonstop active routing support for point-to-multipoint transit and egress LSPs ensures that the switchover remains transparent to the network neighbors, and preserves the LSP information across the switchover.

Starting with Release 14.1R1, Junos OS extends nonstop active routing support to the next-generation multicast VPNs (MVPNs).

The show rsvp session detail command enables you to check the point-to-multipoint LSP remerge state information (P2MP LSP re-merge; possible values are head, member, and none).

Starting with Release 14.1R1, Junos OS extends nonstop active routing support for point-to-multipoint LSPs used by VPLS and MVPN.

However, Junos OS does not support nonstop active routing for the following features:

  • Generalized Multiprotocol Label Switching (GMPLS) and LSP hierarchy

  • Interdomain or loose-hop expansion LSPs

  • BFD liveness detection

  • Starting with Junos OS Release 14.2, Setup protection

Nonstop active routing support for RSVP-TE LSPs is subject to the following limitations and restrictions:

  • Detour LSPs are not maintained across a switchover and so, detour LSPs might fail to come back online after the switchover.

  • Control plane statistics corresponding to the show rsvp statistics and show rsvp interface detail | extensive commands are not maintained across Routing Engine switchovers.

  • Statistics from the backup Routing Engine are not reported for show mpls lsp statistics and monitor mpls label-switched-path commands. However, if a switchover occurs, the backup Routing Engine, after taking over as the primary, starts reporting statistics. Note that the clear statistics command issued on the old primary Routing Engine does not have any effect on the new primary Routing Engine, which reports statistics, including any uncleared statistics.

  • State timeouts might take additional time during nonstop active routing switchover. For example, if a switchover occurs after a neighbor has missed sending two hello messages to the primary, the new primary Routing Engine waits for another three hello periods before timing out the neighbor.

  • On the RSVP ingress router, if you configure auto-bandwidth functionality, the bandwidth adjustment timers are set in the new primary after the switchover. This causes a one-time increase in the length of time required for the bandwidth adjustment after the switchover occurs.

  • Backup LSPs —LSPs that are established between the point of local repair (PLR) and the merge point after a node or link failure—are not preserved during a Routing Engine switchover.

  • When nonstop active routing is enabled, graceful restart is not supported. However, graceful restart helper mode is supported.

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
15.1R1
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 primary Routing Engine.
14.2
Starting with Junos OS Release 14.2, Setup protection
14.1
Starting with Junos OS Release 14.1, you must include the advertise-from-main-vpn-tables statement at the [edit protocols bgp] hierarchy level to prevent BGP sessions from going down when route reflector (RR) or autonomous system border router (ASBR) functionality is enabled or disabled on a routing device that has VPN address families configured.
14.1
Starting with Release 14.1R1, Junos OS extends nonstop active routing support to the next-generation multicast VPNs (MVPNs).
14.1
Starting with Release 14.1R1, Junos OS extends nonstop active routing support for point-to-multipoint LSPs used by VPLS and MVPN.
13.3R5
Starting with Junos OS Release 13.3R5, on EX9214 switches, the VRRP primary state might change during graceful Routing Engine switchover, even when nonstop active routing is enabled.
12.3
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.