Juniper EX Virtual Chassis Configuration: Step-by-Step CLI Guide

A Virtual Chassis turns up to ten Juniper EX switches into one logical device that shares a control plane, runs one configuration and gives you active/standby RE redundancy cheaply. This guide walks through the CLI that makes it happen: preprovisioning members so the configuration exists before the hardware does, designating and cabling Virtual Chassis ports, setting mastership priority and member IDs, handling mixed and non-provisioned modes, and verifying the fabric is actually formed. The examples use EX4300/EX4650 conventions but the concepts carry across the EX range.

Two ways to build one

Cabling and port budget before you configure

Virtual Chassis ports (VCPs) are dedicated on some EX models and borrowed from the uplink budget on others, so settle the cabling plan before you type configuration. On an EX4300 the two rear 40G QSFP+ ports are dedicated VCPs and cost you nothing from the front-panel uplinks. On an EX4650 the 100G uplink ports are used as VCPs, which means every port you convert is a port you can no longer use as a data uplink. On older EX4200/EX4500 hardware the dedicated VCP ports sit on the rear panel with SFP/SFP+ connectors, and on EX2300/EX3400 you convert uplink ports where the chassis allows it.

Two cabling rules keep the chassis predictable:

• Build a ring, not a chain. Connect VCP0 of member N to VCP1 of member N+1 and close the loop from the last member back to member 0. A ring tolerates one VCP or cable failure without splitting the chassis; a daisy chain fails into two islands when any middle link breaks.
• Budget the optics and label both ends. Confirm the supported DAC/AOC lengths for your port type. A VCP cabled to the wrong rear port looks exactly like a VCP that was never configured, so the label is a troubleshooting tool, not housekeeping.

Before touching a switch, write down which physical port on which member becomes which VCP. That table is what you will compare against show virtual-chassis vc-port when a member refuses to join.

Step 1: Preprovision the members

user@ex-0> configure
[edit virtual-chassis]
user@ex-0# set preprovisioned
user@ex-0# set member 0 serial-number ABC123 role routing-engine
user@ex-0# set member 1 serial-number DEF456 role routing-engine
user@ex-0# set member 2 serial-number GHI789 role line-card
user@ex-0# set member 2 no-split-detection
user@ex-0# set member 3 serial-number JKL012 role line-card
user@ex-0# set member 3 no-split-detection
user@ex-0# set mastership-priority 200
user@ex-0# commit and-quit

Roles matter. A routing-engine member can become master; a line-card member cannot, which is how you prevent a closet switch from taking over the chassis during a split. Setting no-split-detection on line-card members avoids the split-detection shutdown that triggers when a large chassis loses half its VCP links - intended for two-member edge topologies, dangerous if used blindly.

Mixed mode: members that are not identical

Not every chassis is built from identical hardware. Junos supports a mixed Virtual Chassis in which different EX models interoperate, and show virtual-chassis status reports the situation in the Mixed column. Two constraints matter in practice.

• The master must be the capable member. In a mixed chassis of EX4200/EX4500/EX4300 units the master has to be the EX4300 (or the newer platform in the combination). A mixed chassis that elects the wrong master does not form properly, which is one more reason to preprovision roles rather than trust the election.
• Not every combination is supported. Some pairings, such as EX4550 members inside an EX4300 chassis, are not on the supported list. Check the Juniper compatibility matrix for your exact models and Junos releases before you order hardware for the build.

Feature support also follows the master's software version: when a member joins with an older Junos release the master pushes its own package down to that member. That is convenient during a rollout, but it means a mixed chassis is not the place to experiment with new features. Standardise on one Junos release per chassis and upgrade members before adding them.

Step 2: Create and cable the VCPs

! Dedicated VCP ports on EX4300 (the rear 40G ports)
user@ex-0# set virtual-chassis vcp-ports vcp-0
user@ex-0# set virtual-chassis vcp-ports vcp-1

! Uplink ports converted to VCPs where needed
user@ex-0# set virtual-chassis vcp-ports vcp-2
user@ex-0# set virtual-chassis vcp-ports vcp-3
user@ex-0# set interfaces xe-0/2/0 virtual-chassis-vc-port 2
user@ex-0# set interfaces xe-0/2/1 virtual-chassis-vc-port 3

! Automatic VCP conversion for newly added members
user@ex-0# set virtual-chassis auto-sw-update

user@ex-0# commit and-quit
user@ex-0> request virtual-chassis vc-port set interface vcp-0 member 3

Converting an uplink port to a VCP means it is no longer usable as a data port - check your uplink budget before you commit. For multi-member chassis, follow a ring topology: VCP0 of member N to VCP1 of member N+1 and close the loop. Rings survive a single link failure without splitting.

Non-provisioned mode: a build order that works

Non-provisioned mode is the opposite discipline: nothing exists in the configuration ahead of time and the chassis forms itself. It is quick in a lab and easy to get wrong in a rack, because the order in which you power and cable members decides the member IDs you will live with.

1. Power the switch you intend to be master first, and give it a mastership priority high enough to win the election.
2. Configure its VCPs (set virtual-chassis vcp-ports vcp-0) and commit before cabling members together.
3. Add one member at a time and wait for show virtual-chassis status to show it as Prsnt before adding the next.
4. Renumber anything that landed on an unexpected member ID, then commit and re-check.

user@ex-0> show virtual-chassis status
user@ex-0> request virtual-chassis renumber member 1 new-member-id 4
user@ex-0> show virtual-chassis protocol adjacency

Member IDs are not cosmetic. Interface names (ge-2/0/12), filter and policy references, monitoring templates and every script you have written embed them, so decide the numbering on paper first and then make the hardware match it.

Step 3: Bring the members up and verify

user@ex-0> show virtual-chassis
user@ex-0> show virtual-chassis status
user@ex-0> show virtual-chassis vc-port
user@ex-0> show virtual-chassis protocol adjacency
user@ex-0> show virtual-chassis member 2

Virtual Chassis ID: 1a2b3c4d
Member ID  Status    Serial No    Model    Prio  Role      Mixed
0 (FPC 0)  Prsnt     ABC123       ex4300   200   Master*   No
1 (FPC 1)  Prsnt     DEF456       ex4300   128   Backup    No
2 (FPC 2)  Prsnt     GHI789       ex4300   128   Linecard  No

Every member must show Prsnt and a non-zero Role, and the VCP links must be Up in both directions. A member that appears in show virtual-chassis status but shows no VCP links is cabled to the wrong port or the port was never converted.

Mastership, split and recovery

user@ex-0> request virtual-chassis routing-engine ...            ! promotion
user@ex-0> show virtual-chassis status | match Master
user@ex-0> show chassis alarms
user@ex-0> show log messages | match -i 'vc|split'

! recover a member that lost its configuration
user@ex-1> request system zeroize
user@ex-1> request virtual-chassis renumber member 1 new-member-id 4

Priority decides the election at boot, not at runtime, so plan a controlled switchover instead of pulling a power cable. show chassis routing-engine reports which member holds mastership plus the priority and role of each routing engine, and request chassis routing-engine master switch hands mastership to the Backup RE — the supported way to move the active control plane during maintenance. Both routing engines must run the same Junos release with the same configuration for that move to be clean.

user@ex-0> show chassis routing-engine
user@ex-0> request chassis routing-engine master switch
user@ex-0> show virtual-chassis status

Unless graceful Routing Engine switchover and nonstop routing are configured, expect routing protocols to re-establish on the new master while the data plane keeps forwarding. In an EVPN-VXLAN fabric where the chassis acts as a leaf, that means the EVPN sessions come up again on the other member, so schedule the switchover rather than discovering it during an incident.

When a chassis splits, both fragments may run independently and both keep the same IP addresses - the classic split-brain. Fix it structurally: run a full VCP ring, avoid no-split-detection on members that can realistically split, and add a second management path so a broken fragment is still reachable. Maintain the same discipline on other vendors' stack technologies; our guides on ArubaOS-CX VSF, Dell OS10 VLT, Arista EOS MLAG and Huawei iStack vs CSS cover the same failure modes, and initial EX setup is the prerequisite step, and EVPN ESI-LAG multihoming is the natural companion design when the access layer needs active/active server links instead of a single logical switch.

Adding, replacing and removing members

Preprovisioning pays off exactly here: because the member's serial number, role and ID already exist in the configuration, a replacement switch boots into the correct role with no console work.

! add a member: configuration first, hardware second
user@ex-0# set virtual-chassis member 4 serial-number MNO345 role line-card
user@ex-0# set virtual-chassis member 4 no-split-detection
user@ex-0# commit and-quit
user@ex-0> show virtual-chassis status

! replace a failed member: keep the ID, change the serial number
user@ex-0# set virtual-chassis member 2 serial-number NEW987 role line-card
user@ex-0# commit and-quit

! remove a member entirely
user@ex-0# delete virtual-chassis member 4
user@ex-0# commit and-quit

A member deleted from the configuration but still cabled does not simply disappear: it keeps trying to rejoin and will appear as a Spare or inactive entry until its VCPs are unplugged. Remove the configuration, unplug the VCPs, and if the unit is being reused elsewhere run request system zeroize so it boots standalone with no trace of the chassis configuration.

Software upgrades on a live chassis

The master is the software source of truth. Copy the Junos package to the master's /var/tmp and install it there; the chassis propagates the image to every member, and members reload as their turn comes.

user@ex-0> show version invoke-on all-routing-engines
user@ex-0> request system software add /var/tmp/jinstall-ex-4300-21.4R3.tgz
user@ex-0> show version invoke-on all-routing-engines
user@ex-0> show virtual-chassis status

Do this in a maintenance window: while members reload, the Backup RE takes over and routing protocols — including any EVPN sessions the chassis terminates — are interrupted. Where nonstop software upgrade (NSSU) is supported on your platform, use that procedure instead of a plain install, because NSSU upgrades members in sequence and keeps the chassis forwarding throughout. Finish by confirming that every member reports the same release; a chassis quietly running two releases because one member failed to upgrade is a fault waiting for the next change window to expose it.

Troubleshooting: a member that does not join

• Prsnt with no VCP links. Compare cabling against your port table and run show virtual-chassis vc-port. The usual cause is a VCP that was never configured on that member, or an uplink port converted on one side only.
• NotPrsnt. The member is powered off, or its serial number does not match the preprovisioned entry — a mistyped serial is silent and looks exactly like a dead switch.
• Inactive or Spare. The chassis has decided not to use the member, typically because the configured member count or roles do not match reality.
• Chassis splits at boot. Follow the VCP ring rather than the member list: one broken or unconfigured link splits the ring into two fragments, and both fragments keep the same management addresses.
• Unsupported model. An incompatible member appears as a normal entry but never reaches a ready state. Check the compatibility matrix and the Mixed column before assuming a hardware fault.

user@ex-0> show virtual-chassis status
user@ex-0> show virtual-chassis vc-port
user@ex-0> show virtual-chassis protocol adjacency
user@ex-0> show log messages | last 100 | match "Virtual Chassis|vcp"

Acceptance test before you trust the chassis

Run this sequence every time a chassis is built or a member is replaced, and paste the output into the change ticket:

user@ex-0> show virtual-chassis
user@ex-0> show virtual-chassis status
user@ex-0> show virtual-chassis vc-port          ! every VCP Up in both directions
user@ex-0> show virtual-chassis protocol adjacency
user@ex-0> show chassis routing-engine            ! mastership and priorities as designed
user@ex-0> show chassis alarms

The chassis passes when every member is Prsnt, every VCP is up in both directions, exactly one member is Master in the intended priority order, and show chassis alarms is quiet. Then prove the failure model: pull one VCP cable and confirm the chassis stays formed, and reboot the Backup member to confirm mastership does not move. A Virtual Chassis that has never been tested for a link failure is an assumption, not a design.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/virtual-chassis/topics/concept/virtual-chassis-overview.html