juniper re (Routing Engine redundancy in Junos OS) is a high-availability feature that provides automatic or manual failover between the primary and backup Routing Engines to ensure uninterrupted network operation on Juniper MX, PTX, and T-series routers.
> show chassis routing-engine
Routing Engine status:
Slot 0:
Current state Master
Slot 1:
Current state BackupOverview and Use Cases
Juniper RE (Routing Engine redundancy) is a core HA subsystem on dual-RE platforms. It works with Graceful Routing Engine Switchover (GRES) and Non-Stop Forwarding (NSF) to keep the control plane alive during RE failure or maintenance. Enable RE redundancy when the router carries mission-critical BGP/OSPF/IS-IS peering that cannot tolerate control-plane downtime. The feature is configured via the Junos CLI and is transparent to forwarding hardware as long as the Packet Forwarding Engine (PFE) retains current forwarding tables.
Tested on Junos OS 22.2R1 on MX480 with dual RE-S-1800×4 modules.
RE redundancy relies on a heartbeat between the two Routing Engines. When the primary fails (loss of heartbeat or kernel panic), the backup assumes the primary role. By default, both REs start in backup state if no primary is explicitly configured, triggering a conflict alarm. This guide covers exact CLI commands to monitor, trigger, and troubleshoot RE redundancy.
Configuration and Monitoring Commands
A production-grade setup involves three layers: GRES, NSF for routing protocols, and commit synchronization. Below is a complete configuration snippet for a dual-RE MX router:
# Enable graceful switchover
set chassis graceful-switch-over
# Persist primary role across reboots
set chassis redundancy keep-current-state
# Commit sync to both REs
set system commit synchronize
# BGP graceful restart
set protocols bgp graceful-restart
# OSPF helper disable router-state (optional)
set protocols ospf graceful-restart helper-disableMonitor mastership, uptime, and failover reasons with:
> show chassis routing-engineTo parse failover events programmatically:
show log messages | match "KERNEL|CHASSISD|RE-MASTER"
# Example:
# Aug 15 10:23:45 mx480 chassisd[1234]: CHASSISD_RE_SWITCHOVER_COMPLETE: Routing Engine switchover completedTroubleshooting Common Issues
| Error / Condition | Root Cause | Remediation Command |
|---|---|---|
Both REs in backup state |
No primary designated; default config does not persist mastership. |
|
RE failover with packet loss |
GRES not configured or BGP graceful restart not enabled. |
|
request chassis routing-engine master switch fails |
The other RE is not reachable or has a different Junos version. |
|
Alarm: Redundancy Protocol Failure |
Inter-RE link or fabric communication down. |
|
Commit fails on backup RE |
Partial configuration or commit synchronize not set. |
|
Failover Conditions and Default Behavior
| Condition | Trigger | Default Behavior | Junos CLI Check |
|---|---|---|---|
| Graceful switchover (manual) | request chassis routing-engine master switch |
In-service if GRES enabled; otherwise traffic disruption | show chassis routing-engine role change |
| RE hardware failure | Loss of heartbeat (2-13 seconds) | Backup RE takes mastership automatically | show log messages files |
| RE halt (planned) | request system halt on primary |
Backup becomes primary only if redundancy configured; otherwise router dies | show chassis routing-engine before/after |
| Both REs in backup state | No explicit primary after boot | Junos detects conflict, logs alarm; control plane may be inoperative | show configuration groups re0 re1 |
| Configuration commit | commit with default redundancy settings |
Config synced if commit synchronize set; role persists only if keep-current-state |
show chassis redundancy |
Managing Switchover
Manual Graceful Switchover
Precondition: GRES must be enabled globally.
set chassis graceful-switch-over
commit
request chassis routing-engine master switch
show chassis routing-enginePlanned Halt of a Routing Engine
Before powering off a dual-RE chassis, halt the backup first, then the primary:
# Step 1: On primary RE, halt backup
request system halt other-routing-engine
# Step 2: Halt primary
request system haltFailing to halt the backup first forces a crash-based failover that may corrupt the standby RE filesystem.
Persisting Mastership After Reboot
set chassis redundancy keep-current-state
commitWithout this, both REs come up in backup state after reboot, causing a “no-primary” alarm.
Best Practices
- Enable GRES and NSF together before any planned switchover. Without GRES, PFE stops forwarding during the switch.
- Keep both REs on the same Junos version.
request chassis routing-engine master switchfails silently if versions differ (log shows “RE version mismatch”). - Use commit synchronize with a commit script that validates both REs. Manual configuration of the standby leads to inconsistency.
- Test failover during maintenance windows with
request chassis routing-engine master switch. Validate BGP sessions remain up (show bgp summary). - Monitor RE health via SNMP using
jnxAxlRoutingEngineMasterOID. Alert if both REs are in backup state. - Never power off a chassis with dual REs without first halting the backup, then the primary. Otherwise the backup RE may not boot cleanly.
- Set keep-current-state on equipment that must retain mastership after a planned power cycle.
Platform Comparison
| Feature | Juniper (Junos) | Cisco IOS XR HA | Arista EOS MLAG+SSO |
|---|---|---|---|
| Control-plane switchover | GRES + request chassis routing-engine master switch |
redundancy force-switchover |
redundancy switchover |
| Config sync | commit synchronize |
Auto on RSP pair | configuration auto-save |
| Standby state on boot | Backup by default (unless keep-current-state) | Standby if configured | Active/standby |
| Failover on crash | Kernel watchdog triggers | RP heartbeat | In-line with supervisor |
References
Commands verified against Juniper documentation:
| Command | Source | Notes |
|---|---|---|
show chassis |
www.juniper.net | Front panel system LEDs, RE status |
show log |
www.juniper.net | List/display log file contents |
commit |
www.juniper.net | Requires apply-groups re0/re1 with commit synchronize |
show version |
www.juniper.net | Standard CLI reference |
show configuration |
www.juniper.net | Initial configuration guidance |
Frequently Asked Questions
What is the difference between request chassis routing-engine master switch and request chassis routing-engine switchover?
Answer: master switch performs a graceful control-plane failover; switchover executes immediate, non-graceful handover without waiting for protocol convergence. Use master switch for planned maintenance, switchover only when primary RE is unresponsive. Examples:
request chassis routing-engine master switch
request chassis routing-engine switchoverWhen should I use the force flag with request chassis routing-engine master switch?
Answer: Use force when the standby RE is not fully in sync but an emergency failover is required, overriding health checks. Without force, the switch aborts if the standby is inconsistent. Example:
request chassis routing-engine master switch forceHow do I fix the error “Routing Engine not in standby state: cannot switch”?
Answer: Verify the standby RE is online and synchronized with show chassis routing-engine. Check for hardware faults with show chassis hardware. If stuck in “Present” state, reboot the standby RE:
request chassis routing-engine master switch force
request system reboot routing-engine 1Does request chassis routing-engine master switch work on Juniper vMX in AWS/GCP?
Answer: Yes, vMX supports RE switchover when configured with dual REs, but requires GRES enabled and adequate host VM resources. Virtual REs may exhibit longer sync times. Confirm with:
show configuration system switchover
show chassis routing-engineHow do I force a routing-engine switchover on a Juniper PTX without waiting for BGP convergence?
Answer: Execute request chassis routing-engine switchover force to bypass all hold timers. This drops BGP sessions and requires peering restart. Example:
request chassis routing-engine switchover forceFor marginally faster execution, disable graceful restart first, then switch, then re-enable:
set system switchover no-graceful-restart
commit
request chassis routing-engine switchover force
Command Line Expert & Software Engineer
Welcome! I’m Thomas Heinrich, a software engineer and system administrator with a deep passion for the Command Line Interface (CLI). With years of experience navigating the terminal, building backend architectures, and automating server deployments, I created this space to share practical, real-world terminal knowledge.
Whether you are a beginner taking your first steps in a Linux environment or a seasoned DevOps engineer looking to optimize your deployment scripts, you will find actionable solutions here. My goal is to help you ditch the mouse, speed up your workflow, and harness the full power of the command line.