I recently ran into an issue involving the routing engine on one of our Virtual Chassis stacks, clearly haunted, one of those problems that doesn't reveal itself clearly at first and takes some digging to figure out. It's a good excuse to walk through what Juniper Virtual Chassis actually is, how the routing engine works, how failover is supposed to happen, and how to troubleshoot it when something's off.

What Virtual Chassis Is

Juniper Virtual Chassis (VC) lets multiple physical switches operate as a single logical system, with one management plane, one control plane, and one configuration file. Instead of managing several individual switches with their own IPs and configs, you manage one.

Every member switch has its own CPU and control-plane hardware, but only one of them actively runs the control plane for the whole stack at a time:

  • Master – Runs the active routing engine. Owns the configuration, builds the forwarding tables, runs routing protocols, and handles management functions like SSH, SNMP, syslog, and AAA for the entire stack.
  • Backup – Maintains a synchronized copy of the Master's state so it can take over quickly if needed. It doesn't process control-plane traffic under normal conditions.
  • Linecard – Contributes ports and forwarding hardware but doesn't run the control plane. It receives forwarding instructions from the Master.

Members are interconnected by Virtual Chassis Ports (VCPs), which carry both control traffic between members (mastership negotiation, keepalives, configuration sync) and, in many topologies, transit data traffic.

Master Election: How the Routing Engine Gets Chosen

When a Virtual Chassis forms or reforms, members negotiate mastership through a priority-based election:

  1. Configured mastership priority – A value from 1–255 set per member. Higher wins, and this is the main thing you should be controlling directly rather than leaving to defaults.
  2. Current role – If a member is already Master and priorities are tied, it retains mastership rather than triggering an unnecessary switchover.
  3. Hardware/uptime tiebreakers – Used when priorities are equal.
  4. Member ID and MAC address – Final tiebreakers if everything else is identical.

Set mastership priority explicitly on every member. Leaving it to default election behavior means mastership can land on whichever switch boots first, regardless of uplink quality or physical placement.

How Failover Is Supposed to Work

When a Master fails, the Backup is promoted to take over. Whether that transition is clean or disruptive depends entirely on two features:

  • GRES (Graceful Routing Engine Switchover) keeps the Backup's kernel and interface state synchronized with the Master in real time, so it doesn't have to rebuild forwarding state from scratch on failover.
  • NSR (Non-Stop Routing) keeps routing protocol state synchronized as well, so adjacencies don't need to reconverge after a switchover.

Without these configured, a failover means every member rebuilds its forwarding and protocol state from scratch, which can turn a routine switchover into a real outage. Confirming GRES and NSR are active before you ever need them is worth doing proactively, not just when you're mid-incident.

Why Auth and Management Symptoms Trace Back to the Routing Engine

Because the Master routing engine owns SSH, SNMP, syslog, and AAA processing for the entire stack, problems that look like they belong to those individual services often trace back to routing engine health instead. A Master that's up and elected but under resource pressure, high CPU, a stalled process, excessive log volume, can produce exactly the kind of symptoms that point everywhere except the actual cause: intermittent client authentication failures, unreliable inband management, gaps in SNMP polling or syslog, all while the device still responds to a ping.

The tricky part is that a degraded Master doesn't always trigger automatic failover. Juniper's election process handles hard failures well, but a routing engine that's technically still functioning, just slow or unstable, can sit in place indefinitely without anything forcing a change. That's on you to catch and act on manually.

How to Troubleshoot This

If you're seeing symptoms like inconsistent traffic forwarding, client auth failures, or unreliable inband management on a VC stack, here's the order I'd work through it in:

  1. Rule out the surrounding infrastructure first. Confirm auth servers, upstream connectivity, and NTP are healthy elsewhere. If the problem is isolated to one stack, move to the routing engine.
  2. Check routing engine health directly with show chassis routing-engine and show system processes extensive. High CPU or stalled processes on the Master point straight at the source.
  3. Check show log messages for VCCP keepalive instability between the Master and other members, which can explain both inconsistent forwarding and management access problems.
  4. Confirm GRES and NSR status with show task replication before forcing anything, so you know a switchover will be clean rather than disruptive.
  5. Force a controlled switchover with request virtual-chassis mastership switch during a maintenance window or critical event rather than waiting for an automatic failover that may never trigger on its own.
  6. Look for root cause after the fact, not just the symptom. A degraded routing engine usually has a reason, high log volume, a runaway process, a memory leak, and fixing only the symptom means it can happen again.

Common Issues Beyond a Degraded Master

A few other failure modes worth knowing:

  • Split Virtual Chassis (Split Brain) – Severed VCP links can partition the stack into two segments that each elect their own Master. Verify VCP cabling and port status with show virtual-chassis vc-port, and prevent recurrence with redundant VCP paths.
  • Mastership Flapping – Frequent, unexpected switchovers usually trace back to unstable VCP links or priority values set too close together. Set a clear priority gap between members.
  • Configuration Sync Failures – A rejoining member fails to pick up the current configuration. Check member status with show virtual-chassis, then remove and re-add the member and confirm with show configuration | compare.
  • VCP Port Errors or Bandwidth Exhaustion – VCP links carry both control and transit traffic, which can bottleneck on larger stacks. Check show virtual-chassis vc-port statistics for errors or drops.

Summary

Virtual Chassis reduces management overhead by presenting multiple switches as one logical device, but the redundancy it promises depends entirely on correct routing engine configuration. A degraded Master can quietly break authentication, management access, and traffic consistency without ever triggering an automatic failover, which is exactly why understanding how to check routing engine health and force a controlled switchover matters. The checklist: explicit mastership priorities, GRES enabled, NSR enabled, redundant VCP paths, and periodic verification with show chassis routing-engine and show task replication that things are actually in the state you think they are.