Technical Documentation

Nonstop Active Routing System Requirements

This section contains the following topics:

Nonstop Active Routing Platform Support

Table 1 lists the platforms that support nonstop active routing.

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

T320 router, T640 router, and TX Matrix router

8.4 or later

T1600 router

8.5 or later

TX Plus Matrix router

10.0 or later

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 about BFD support, see Nonstop Active Routing BFD Support.

8.5 or later

BGP

For more information about nonstop active routing support for BGP, see Nonstop Active Routing BGP Support.

8.4 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

Layer 2 circuits

9.2 or later

Layer 2 VPNs

9.1 or later

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

9.2 or later

OSPF/OSPFv3

8.4 or later

Protocol Independent Multicast (PIM) (for IPv4)

For more information about nonstop active routing support for PIM, see Nonstop Active Routing PIM Support.

9.3 or later

RIP and RIP next generation (RIPng)

9.0 or later

RSVP-TE LSP

For more information about nonstop active routing support for RSVP-TE LSPs, see Nonstop Active Routing Support for RSVP-TE LSPs.

9.5 or later

VPLS

9.1 or later

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, only the master logical system supports nonstop active routing.

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, or PIM.

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: For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing is configured, the value for the minimum-interval configuration statement (a BFD liveness detection parameter) must be at least 2500 ms for Routing Engine-based sessions and at least 10 ms for distributed BFD sessions.

Nonstop Active Routing BGP Support

The 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 master and backup Routing Engines during and after the nonstop active routing switchover.
  • If the BGP peer in the master 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 master 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.

    • inet unicast
    • inet labeled-unicast
    • inet multicast
    • inet6 labeled-unicast
    • inet6 multicast
    • inet6 unicast
    • route-target
    • l2vpn signaling
    • inet6-vpn unicast
    • inet-vpn unicast

Nonstop Active Routing Layer 2 Circuit and LDP-Based VPLS Support

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

Starting with Junos OS, Release 9.6, 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, and the forwarding state between the two Routing Engines.

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-restart 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
  • BFD
  • Bootstrap router
  • Dense mode
  • Sparse mode (except for some subordinate features mentioned in the following list of unsupported features)
  • Source-specific multicast (SSM)
  • Static RPs

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
  • PIM for IPv6 and related features such as embedded RP and Multicast Listener Discovery (MLD)
  • 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

Incompatible features: Nonstop active routing does not support the following features, and you cannot configure them on a router enabled for PIM nonstop active routing. The commit operation fails if the configuration includes both nonstop active routing and one or more of these features:

  • Anycast RP
  • Draft-rosen multicast VPNs (MVPNs)
  • Local RP
  • Next-generation MVPNs with PIM provider tunnels
  • PIM join load balancing

Junos OS provides a configuration statement that disables nonstop active routing for the 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 only incompatible features.

Nonstop Active Routing Support for RSVP-TE LSPs

Junos OS extends nonstop active routing support to label-switching routers (LSR) that are part of an RSVP-TE LSP. Nonstop active routing support on LSRs ensures that the master 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 standby Routing Engine to view the state recreated on the standby Routing Engine.

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

  • Point-to-multipoint LSPs
  • Generalized Multiprotocol Label Switching (GMPLS) and LSP hierarchy
  • Interdomain or loose-hop expansion LSPs
  • Application or VPN traffic, such as circuit cross-connect (CCC), translational cross-connect (TCC), Layer 2 Circuit, or VPLS, on ingress routers
  • BFD liveness detection

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

  • 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 master, starts reporting statistics. Note that the clear statistics command issued on the old master Routing Engine does not have any effect on the new master 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 master, the new master 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 master 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.

Published: 2010-07-16

Help
|
My Account
|
Log Out