12.3 Virtual Chassis Roles and Elections

Virtual Chassis Architecture & Operations

In traditional enterprise campus networks, high availability across access and distribution layers requires deploying redundant physical switches interconnected by Spanning Tree Protocol (STP) links and First Hop Redundancy Protocols (such as VRRP). While functional, this traditional architecture leaves half of the available uplink bandwidth blocked by STP, complicates management across dozens of independent IP addresses, and introduces failover delays during topology changes.

Juniper Virtual Chassis (VC) technology revolutionizes campus network design by interconnecting multiple physical EX Series switches into a single, unified logical switch. The resulting fabric operates with a centralized control plane, a single management IP address, and a distributed, line-rate forwarding plane.

---

1. Virtual Chassis Architecture & Enterprise Value

A Virtual Chassis combines up to 10 physical switches (on platforms such as the EX3400, EX4300, and EX4400) while other EX/QFX combinations have different supported member limits and role restrictions into a single managed chassis:

• Single Management IP: Network administrators manage the entire multi-switch stack through a single console connection, out-of-band management interface (me0 or em0), or virtual management IP. A single configuration file (/config/juniper.conf) controls all member switches.
• Unified Control Plane: Junos OS routing and management processes—including the Routing Protocol Daemon (rpd), Management Daemon (mgd), and Chassis Daemon (chassisd)—execute centrally on the elected Master switch.
• Distributed Line-Rate Forwarding Plane: Each member switch retains its own Packet Forwarding Engine (PFE) ASICs. Transit frames entering and exiting ports on the same physical member switch are switched locally in hardware at line rate without traversing the inter-chassis backplane.
• Elimination of STP Blocking via Multi-Chassis LAG: Because the entire Virtual Chassis behaves as a single logical bridge, downstream servers and access switches can establish standard 802.3ad Link Aggregation Groups (LAG) whose member links connect to different physical switches within the Virtual Chassis. This cross-chassis link aggregation eliminates Spanning Tree blocked ports entirely, allowing all uplinks to forward traffic simultaneously.

---

2. Member Roles: Master, Backup & Linecard

Within an operational Virtual Chassis, each physical switch is assigned a member ID (0 through 9) and assumes one of three distinct functional roles:

+-----------------------------------------------------------------------------------+
| VIRTUAL CHASSIS LOGICAL ENTITY                                                    |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | MEMBER 0: MASTER (Routing Engine 0)                                         |  |
|  |  - Active Junos OS Control Plane (rpd, mgd, chassisd)                       |  |
|  |  - Coordinates configuration commits, compiles FIB, manages chassis         |  |
|  +-----------------------------------------------------------------------------+  |
|                                        ^ Synchronized via GRES / Kernel Mirror    |
|                                        v                                          |
|  +-----------------------------------------------------------------------------+  |
|  | MEMBER 1: BACKUP (Routing Engine 1)                                         |  |
|  |  - Hot-Standby Routing Engine; monitors Master health                       |  |
|  |  - Instantaneous takeover upon Master failure (forwarding preservation subject to supported HA state)   |  |
|  +-----------------------------------------------------------------------------+  |
|                                        |                                          |
|                         Interconnected via VCP Backplane                          |
|                                        |                                          |
|  +-----------------------------------------------------------------------------+  |
|  | MEMBERS 2-9: LINECARDS                                                      |  |
|  |  - Forward transit traffic locally via hardware ASICs                       |  |
|  |  - Run no active routing protocol calculation; receive FIB updates from Master                  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

1. Master (Active Routing Engine role)

The Master switch operates as the active supervisor of the entire Virtual Chassis. It executes the FreeBSD-based Junos kernel, coordinates user authentication, parses CLI commands, manages configuration transactions, and runs rpd to maintain master routing tables (inet.0). The Master compiles the forwarding tables and synchronizes them across all member PFEs.

2. Backup (Standby Routing Engine role)

The Backup switch operates as a hot-standby supervisor. It maintains active synchronization with the Master's kernel, configuration database, and forwarding state using Graceful Routing Engine Switchover (GRES). The Backup continuously monitors the Master's health across the Virtual Chassis backplane. If the Master experiences hardware failure, power loss, or a software crash, the Backup immediately assumes the Master role with minimal disruption to user transit forwarding.

3. Linecard (Other eligible members)

All remaining switches in the Virtual Chassis operate in the Linecard role. Linecards execute no routing protocol daemons, do not parse CLI commits, and do not process management logins. Instead, their local CPUs manage local environmental hardware (fans, power supplies, interface PHYs) and program their local PFE ASICs using forwarding tables pushed down from the Master. Interface naming across all members incorporates the member ID as the FPC slot (e.g., port 12 on member 3 is named ge-3/0/12).

---

3. The 4-Step Mastership Election Algorithm

When a Virtual Chassis powers on, or when topology changes occur, the member switches execute a deterministic 4-step election sequence to determine which switch becomes Master and which becomes Backup:

$\text{1. Highest Mastership Priority} \longrightarrow \text{2. Previous Master Status} \longrightarrow \text{3. Longest System Uptime} \longrightarrow \text{4. Lowest Base MAC Address}$

Step 1: Highest Mastership Priority

The primary deciding factor is the user-configured mastership priority, ranging from 0 to 255 (the default priority is 128):

• The switch with the highest numeric priority value wins the election.
• In production, network engineers assign the same high priority (commonly 255) to the intended primary and backup for reliable GRES behavior; stage power-on to influence initial election.
• Configuring priority 0 permanently disqualifies a switch from ever assuming the Master or Backup role, locking it strictly into a Linecard role.

Step 2: Previous Mastership Status

If priorities are identical, the election evaluates operational continuity: a switch that was operating as Master in the previous state wins over a switch that was operating as Backup or Linecard. This prevents unnecessary mastership failovers when a rebooted switch with default priority rejoins the fabric.

Step 3: Longest System Uptime

If previous mastership status is tied, the election selects the switch that has been powered on and operational for the longest time. Juniper compares time in the Virtual Chassis, with a difference of more than one minute between power-up times needed for this criterion to distinguish candidates.

Step 4: Lowest Base MAC Address

If priority, previous state, and system uptime are completely tied, the final deterministic tiebreaker is the switch's hardware base MAC address. The switch with the numerically lowest base MAC address is elected Master.

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.

Provisioning distinction: In a preprovisioned chassis, assign role routing-engine to the two eligible RE members; Junos sets their priority to 129 and prevents manual priority assignment there. The priority 255/254/0 display above illustrates a separate nonprovisioned example, not the output of the preprovisioned serial-number configuration. Member ID does not intrinsically determine primary versus backup.

Official references checked 2026-10-18: VC election.