12.5 Routing Engine Redundancy: GRES, NSR, NSB and GR

High Availability: GRES, NSR, BFD & VRRP

Enterprise networks supporting critical applications cannot tolerate outages caused by single hardware failures or maintenance windows. Achieving resilient enterprise operations requires multi-layered high availability (HA): control plane redundancy within the routing supervisor, sub-second failure detection along transit links, and first-hop gateway redundancy for end-user LAN clients.

Junos OS provides a tightly integrated high-availability suite comprising Graceful Routing Engine Switchover (GRES), Nonstop Active Routing (NSR), Nonstop Bridging (NSB), Bidirectional Forwarding Detection (BFD), and the Virtual Router Redundancy Protocol (VRRP).

---

1. Dual-Routing Engine High Availability Architecture

On Juniper hardware platforms equipped with dual Routing Engines (such as high-end EX switches, MX Series routers, or multi-member Virtual Chassis fabrics), high availability depends on how control plane state is mirrored between the primary and backup REs.

+-----------------------------------------------------------------------------------+
| PRIMARY ROUTING ENGINE (RE0)                       BACKUP ROUTING ENGINE (RE1)    |
|                                                                                   |
|  +-------------------------+      GRES Kernel Mirror      +--------------------+  |
|  | Junos Kernel Forwarding |============================>| Synchronized Kernel|  |
|  +-------------------------+                              +--------------------+  |
|               |                                                     |             |
|  +-------------------------+        NSR Protocol State    +--------------------+  |
|  | rpd (OSPF, BGP, IS-IS)  |============================>| Warm Standby rpd   |  |
|  +-------------------------+       TCP Session Sync       +--------------------+  |
+-----------------------------------------------------------------------------------+
                                          |
                         Hardware PFE Forwarding (FIB ASICs)
                       Continues Uninterrupted Forwarding Traffic
                                          |
+-----------------------------------------------------------------------------------+
| PACKET FORWARDING ENGINE (PFE)                                                    |
|  - Line-rate Layer 2/3 hardware packet switching                                  |
|  - Hardware-assisted BFD liveness probes (30ms - 100ms)                           |
+-----------------------------------------------------------------------------------+

---

2. GRES, NSR, NSB & Graceful Restart Deep Dive

Junos OS differentiates between four distinct supervisor redundancy mechanisms:

1. Graceful Routing Engine Switchover (GRES)

GRES mirrors the FreeBSD kernel state and the Packet Forwarding Engine (PFE) forwarding database from the primary RE to the backup RE. When the primary RE fails, the backup RE assumes the master role immediately. Because the PFE ASICs retain their forwarding state, transit traffic continues flowing across the switch without interruption.

The GRES Limitation: Under pure GRES, the Routing Protocol Daemon (rpd) does not mirror its state. When the backup RE assumes mastership, its local rpd restarts from scratch. The newly activated rpd tears down all OSPF, BGP, and IS-IS neighbor adjacencies, relearns routes, and recalculates the master routing table (inet.0). While transit traffic forwards during the initial seconds, adjacent routers detect dropped neighbor hellos and withdraw routes, causing widespread network disruption.

[edit chassis redundancy]
user@EX4300# set graceful-switchover

2. Nonstop Active Routing (NSR)

NSR addresses the routing-state limitation of GRES for supported protocols. When NSR is enabled, the primary RE replicates supported routing protocol states, neighbor state, link-state databases and applicable TCP connections to the backup RE's standby rpd process.

When a Routing Engine switchover occurs under NSR:

• The standby rpd immediately takes over as the active protocol daemon with zero restart delay.
• Routing protocol adjacencies do not flap: OSPF, BGP, and IS-IS neighbor sessions remain continuously established.
• Zero external dependency: Adjacent peer routers have no awareness that a switchover took place.
• Prerequisite: NSR strictly requires GRES to be enabled first.

[edit routing-options]
user@EX4300# set nonstop-routing
user@EX4300# top
user@EX4300# set system commit synchronize

3. Nonstop Bridging (NSB)

While NSR protects Layer 3 routing protocols, Nonstop Bridging (NSB) protects Layer 2 control protocols on enterprise switches. NSB replicates supported Layer 2 control state, especially supported spanning-tree state, from the primary to the backup RE. Consult the device’s NSB support matrix rather than assuming LLDP, LACP and 802.1X all receive identical protection. NSB aims to preserve topology and forwarding during switchover; it is not an unconditional guarantee of zero loss.

[edit protocols layer2-control]
user@EX4300# set nonstop-bridging

4. Graceful Restart (GR) vs. Nonstop Active Routing (NSR)

Before NSR was developed, the networking industry created Graceful Restart (GR) (defined in RFC 3623 for OSPF and RFC 4724 for BGP). It is vital to understand the fundamental architectural contrast between GR and NSR for the JNCIS-ENT exam:

• Graceful Restart (Helper-Router Dependent): GR allows a restarting router to request that its adjacent neighbors (acting as helpers) continue forwarding traffic along existing paths while rpd restarts and relearns routes. GR has significant operational drawbacks: it depends on applicable peers supporting and permitting helper behavior, and risks creating transient routing loops if a topology change occurs during the restart.
• Nonstop Active Routing (Self-Contained & Peer-Independent): NSR is completely self-contained within the local dual-RE router. Neighboring routers require zero special configuration, zero helper mode support, and receive no protocol notifications during switchover.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

Configuration and Switchover Readiness

For a documented graceful-restart design, Junos provides global routing-options graceful-restart and applicable protocol-specific controls. Verify helper capability and the protocol’s supported restart interval; enabling a global statement does not prove every neighbor will retain every route. NSR is a different local-replication design and must satisfy the platform’s prerequisites, including GRES and synchronized configuration where required. Select the supported design rather than combining unrelated examples blindly.

Before a planned RE switchover, inspect show system switchover, the RE health/alarms and show task replication where supported for NSR state. Compare protocol sessions and routes before and after. GRES readiness is kernel/configuration evidence; supported routing replication and Layer 2 protocol readiness are additional evidence. Correlate switchover timestamps with show log messages to distinguish hardware failure from a protocol timeout or unsynchronized standby.