12.4 Virtual Chassis Links, Splits and Provisioning

4. Virtual Chassis Ports (VCP) & Topologies

Member switches communicate across the Virtual Chassis backplane using specialized connections known as Virtual Chassis Ports (VCPs). VCP links carry all inter-switch control plane messages, internal keepalives, and transit user frames destined for ports on other member switches.

Dedicated VCPs vs. Optical Uplink VCPs

• Dedicated VCP Ports: Many EX switches incorporate dedicated high-speed VCP ports on their rear panels (e.g., dedicated or designated 40-Gbps ports on applicable EX4300 models; count and capacity depend on the model). Junos automatically recognizes these interfaces as VCPs out of the box without requiring CLI configuration.
• Configured Uplink VCP Ports: On platforms without dedicated rear-panel ports, or when members are distributed across different wiring closets or racks, standard front-panel optical ports (10GbE SFP+ or 40GbE QSFP+) can be converted into VCPs using the operational CLI command:

  user@EX4300> request virtual-chassis vc-port set pic 1 port 0
  user@EX4300> request virtual-chassis vc-port set pic 1 port 1
  

  To revert a VCP port back into a standard Ethernet interface: request virtual-chassis vc-port unset pic 1 port 0.

Cabling Topologies: Resilient Ring vs. Daisy Chain

• Ring Topology (Recommended): Members are cabled in a continuous closed loop, where Member 0 connects to Member 1, Member 1 to Member 2, and the final member connects back to Member 0. A ring tolerates one VCP-link failure: if any single VCP cable or port fails, the fabric automatically degenerates into a linear chain without losing a single member switch.
• Daisy-Chain Topology: Members are cabled in a linear sequence without closing the loop. If an intermediate cable or switch fails, the Virtual Chassis partitions into two separate isolated fragments.

---

5. Split-Brain Protection, Quorum & Two-Member Setups

The Split-Brain Condition

A catastrophic failure mode in clustered networking is the split-brain condition. If all VCP interconnections between two functional groups of member switches fail simultaneously (while all switches remain powered), both partitioned groups may believe the other group has died. If both groups elect a local Master, two independent switches will attempt to use the exact same management IP address, default gateway IP, and Virtual MAC address, triggering severe network-wide ARP conflicts and packet looping.

Split Detection Considers Stable Routing Engine Roles

Junos does not apply a universal “largest half wins” quorum rule. Split detection considers the stable primary and stable backup from before the split, together with partition size:

• A partition containing both stable Routing Engine members can remain active.
• A partition with the stable primary must be larger than half the original chassis.
• A partition with the stable backup must contain at least half.

For an equal split with stable primary and backup separated, the backup’s partition remains active. In a five-member split, a three-member group with neither stable RE is not guaranteed to win merely because it is larger. Identify roles before applying the rules.

Two-Member Chassis and no-split-detection

Juniper recommends considering no-split-detection for applicable two-member designs to improve availability when one member fails. It disables the split-detection decision; it does not elect member 0 as a predetermined surviving primary. If VCP connectivity alone is lost and both switches remain powered, both partitions can become active with duplicate addressing. This tradeoff demands resilient VCP links and a design that handles the remaining split-brain risk.

[edit virtual-chassis]
set no-split-detection

Do not extend a two-member recommendation automatically to a larger chassis. Verify the platform-specific split/merge requirements and inspect roles and VCP topology with show virtual-chassis and show virtual-chassis vc-port before maintenance.

6. Preprovisioned vs. Non-Provisioned Virtual Chassis

Junos supports two deployment methodologies for building a Virtual Chassis:

Non-Provisioned (Dynamic) Deployment

In a non-provisioned setup, switches are connected together using VCP cables without pre-assigning hardware identifiers. The switches dynamically negotiate member IDs and roles based on cable order and the 4-step election algorithm. While simple for laboratory environments, non-provisioned deployments are fragile in enterprise production: replacing a failed switch or inadvertently swapping a cable can cause member IDs to shift, renumbering interface names (e.g., ge-1/0/0 becoming ge-2/0/0) and corrupting interface policies.

Preprovisioned Deployment (Enterprise Best Practice)

In enterprise networks, administrators use preprovisioned configuration. Preprovisioning explicitly binds each member ID and role to the physical switch's hardware serial number:

[edit virtual-chassis]
user@EX4300# show
preprovisioned;
member 0 {
    role routing-engine;
    serial-number BM0214340001;
}
member 1 {
    role routing-engine;
    serial-number BM0214340002;
}
member 2 {
    role line-card;
    serial-number BM0214340003;
}
member 3 {
    role line-card;
    serial-number BM0214340004;
}

Advantages of Preprovisioning

1. Deterministic Role Assignment: Only switches with serial numbers matching Member 0 and Member 1 can ever assume the Routing Engine (Master or Backup) role. Members 2 and 3 are strictly restricted to Linecard roles.
2. Prevention of Rogue Takeovers: If a replacement switch with default settings is plugged into the stack, it cannot hijack the Master role even if it has a higher priority or longer uptime.
3. Seamless RMA Replacement: When replacing a defective switch, the engineer simply updates the serial number string in the configuration; the replacement can assume the intended member ID and configuration after compatible hardware and software join successfully. Verify VCP links, software compatibility and member status before restoring service.

---

7. Monitoring & Operational Verification

To verify member roles, priorities, and backplane health, use show virtual-chassis. The following output is schematic and illustrates the preprovisioned configuration above:

user@EX4300> show virtual-chassis

Virtual Chassis ID: 3a22.41b0.12e4
Virtual Chassis Mode: Enabled
                                            Mstr           Member
Member ID  Status   Serial No    Model      prio  Role      ID  Interface
0 (FPC 0)  Prsnt    BM0214340001 ex4300-48p 129   Master*    1  vcp-255/1/0
                                                             3  vcp-255/1/1
1 (FPC 1)  Prsnt    BM0214340002 ex4300-48p 129   Backup     0  vcp-255/1/0
                                                             2  vcp-255/1/1
2 (FPC 2)  Prsnt    BM0214340003 ex4300-48p 0     Linecard   1  vcp-255/1/0
                                                             3  vcp-255/1/1
3 (FPC 3)  Prsnt    BM0214340004 ex4300-48p 0     Linecard   2  vcp-255/1/0
                                                             0  vcp-255/1/1

In this output:

• The asterisk (*) next to Master indicates the local switch executing the current CLI session.
• In this preprovisioned example, both Routing Engine members have automatic priority 129; the election algorithm selects the primary and backup. Explicit line-card members have priority 0.
• Interconnecting vcp interfaces confirm a complete, resilient closed-ring topology.

To verify individual VCP link states and speed:

user@EX4300> show virtual-chassis vc-port
fpc0:
Interface   Type              Trunk  Status       Speed        Next-hop
0/1/0       Configured        -1     Up           40Gbps       1
0/1/1       Configured        -1     Up           40Gbps       3

Official references checked 2026-10-18: Preprovisioned roles and automatic priorities, Split/merge rules.