Juniper Virtual Chassis Explained: Roles, Members and Benefits

2026年9月2日 LOG admin

Juniper Virtual Chassis (VC) lets you interconnect multiple EX or QFX switches so they operate as one logical chassis with a single management plane - one configuration, one set of routing tables, one IP address to manage. Unlike chassis systems with fixed hardware, VC members are ordinary switches joined by Virtual Chassis Ports (VCPs), which keeps expansion flexible. This article explains the member roles, supported models and limits, and the design guidelines Juniper publishes for resilient VC deployments.

How a Virtual Chassis Works

VC members are connected through dedicated VCPs that carry both data and control traffic between switches. The resulting logical device is configured and managed as a single chassis: VLANs, firewall filters, routing protocols and LAG uplinks are defined once and apply across all members. A VC eliminates the need for VRRP in distribution designs because the members behave as one switch, and LAG uplinks from downstream devices can span members for device-level redundancy.

Virtual Chassis Ports: Cabling and Topology Options

Virtual Chassis Ports are the cabling backbone of the whole design. On mid-range and high-end platforms - EX4300, EX4600, EX4650, QFX5100 and QFX5120 - VCPs live on dedicated rear-panel QSFP+ or QSFP28 cages that normally carry 40GE or 100GE. Those same cages can be used as ordinary uplinks instead, which is exactly why Juniper's virtual and dedicated VCP terminology exists: a dedicated VCP is factory-wired for VC traffic, while a virtual VCP is a regular network or uplink port that you convert with a CLI command. Lower-cost platforms such as the EX2300, EX2300-C and EX3400 ship with no dedicated VCP ports at all, so every VC on those models is built from converted 10-Gigabit SFP+ uplinks.

Converting a port is a single operational command, and it is not configuration - it survives in the member's own file and must be repeated per member:

user@ex2300> request virtual-chassis vc-port set pic-slot 1 port 0
user@ex2300> request virtual-chassis vc-port set pic-slot 1 port 1 member 3
user@ex2300> show virtual-chassis vc-port

Use the member keyword to convert a port on another member from the primary's session, and request virtual-chassis vc-port delete to turn the port back into a normal uplink. Two warnings are worth repeating: once a port is a VCP it cannot carry user traffic or be configured as a LAG member, and deleting a VCP that is currently carrying inter-member traffic can split the VC on the spot.

Topology matters as much as media. Juniper's guidance is a ring for any VC with three or more members: each member connects to two neighbours, so a single VCP or member failure does not partition the fabric, and every member stays at most two hops from the primary. A chain (daisy chain) is acceptable only for two-member configurations, because a single break or a single failed member in a chain cuts the VC in half. A full mesh between three or four members is electrically fine and gives the shortest paths, but it consumes two ports per member and is rarely worth the cabling in an access closet. Two or more VCPs between the same pair of members can be bundled into an aggregate link so the fabric bandwidth scales and a single cable failure is transparent.

Sizing rule of thumb: keep the aggregate VCP bandwidth at least half of the total downlink bandwidth of the members it carries. If a member uplinks 20 Gbps of user traffic into a VC fabric with a single 10GE VCP, that port becomes the bottleneck during inter-member traffic and during a primary switchover, when all control traffic funnels through the same fabric.

Member Roles: Primary, Backup and Linecard

Primary - the Routing Engine role that runs the control plane for the whole VC (master RE).
Backup - a second Routing Engine role that takes over if the primary fails; both are elected or preconfigured.
Linecard - members that only provide forwarding ports.

In mixed Virtual Chassis (for example EX4300 with EX4600), Juniper recommends - and sometimes requires - that the Routing Engine role members be the higher-capability models, because they run the control plane for everyone.

The primary member is elected, not manually "enabled". Every member carries a mastership priority whose default is 128; the switch with the highest priority becomes primary at boot, and the next-highest becomes backup. In a non-provisioned VC you raise the two Routing Engine candidates above the rest of the fabric, for example set virtual-chassis member 0 mastership-priority 200 and set virtual-chassis member 3 mastership-priority 199, leaving every linecard at the default. Equal priorities are broken by internal heuristics such as which member was already primary, how long members have been up and which platform has more forwarding capacity. That last point is why mixed VCs should always pin the Routing Engine roles to the strongest hardware rather than trusting the election to sort it out.

When the primary fails, the backup takes over and the linecard members simply keep forwarding. Startup is a short interruption unless a graceful switchover feature is in play: nonstop active routing (NSR) keeps routing protocol adjacencies alive across the RE switchover, and nonstop bridging (NSB) does the same for Layer 2 state such as the MAC table and STP roles. Both must be configured in advance on both Routing Engine members, and both add protocol state that must be synchronised, so check the platform's support matrix before you rely on them for a zero-packet-loss failover. Verify which member holds which role, and which one you are logged into, with the asterisk in the Role column of show virtual-chassis status.

Preprovisioning a Virtual Chassis

A preprovisioned VC fixes the member ID, serial number and role of every switch in advance. The configuration exists before the members are even racked, which makes role placement deterministic, stops the fabric from renumbering itself after a power event, and refuses members that are not listed. The trade-off is real: if every member you designated as a Routing Engine is down at the same time, the remaining switches have no control plane and cannot forward - a "headless" VC. Non-provisioned mode is more forgiving but less predictable, because member IDs are handed out in the order switches boot and the primary can end up on whichever model came up first.

[edit virtual-chassis]
user@switch# set preprovisioned
user@switch# set member 0 serial-number abc123 role routing-engine
user@switch# set member 1 serial-number def456 role routing-engine
user@switch# set member 2 serial-number ghi789 role line-card
user@switch# set member 3 serial-number jkl012 role line-card
user@switch# commit

Replacing a failed member is then a two-line change - delete member 2 serial-number ghi789 followed by set member 2 serial-number mno345 role line-card - and the spare inherits the same member ID, FPC slot numbering and port references. Commit that change from the primary session, then check that the new member shows as Prsnt in show virtual-chassis status. A member that is cabled into a preprovisioned VC but not listed appears as Unprvsnd, and it stays out of the forwarding fabric until you add it.

Supported Models and Member Limits

Switch Model	Maximum VC Members
EX2300 / EX4650	4
EX3400 / EX4100 / EX4100-F / EX4300 / EX4400	10
EX4000 / EX4100-H	6
QFX5120-32C / 48T / 48Y	2
QFX5120-48YM	4

Models such as EX2300 and EX4650 have no dedicated VCPs, so a VC on those platforms is formed through "virtual" VCPs configured on regular ports.

Two families are worth calling out. The EX2300 and EX2300-C can only form a VC with other EX2300/EX2300-C members, capped at four switches; the EX2300 multigigabit models require a mixed-mode setting when combined with older EX2300 members in releases before Junos 18.4R1. The EX2300, EX3400 and EX4100-F families are generally used within their own family or in the combinations Juniper lists for that platform, and the EX4300/EX4400/EX4650 families can be combined with each other in mixed Virtual Chassis. In every mixed case, the Routing Engine role should be assigned to the higher-capacity model, and the fabric should be cabled so that linecard members do not have to hairpin through a slower member to reach the primary.

Virtual Chassis vs VCF vs MC-LAG

Technology	What it joins	Control plane	Best fit
Virtual Chassis (VC)	Up to 2-10 switches of one platform family	One shared control plane, one config	Access and small distribution closets, single management point
Virtual Chassis Fabric (VCF)	Spine and leaf members in a Clos-like fabric	One shared control plane with multiple RE-capable spines	Scale-out within a rack or row while keeping one logical device
MC-LAG	Two independent switches	Two control planes, synchronised by ICCP	Keeping devices separately manageable while offering LAG-level redundancy to servers

The practical decision rule is simple: if you want one configuration file and one IP address for the whole closet, use a VC. If you need device independence for maintenance windows and per-device routing, and the servers only need a redundant LAG, a MC-LAG pair is the better architecture. VCF is the middle ground when a single access VC is not enough but a full data-centre fabric is.

Verification and Monitoring Commands

Learn four commands and most VC questions answer themselves. show virtual-chassis status lists member ID, status, serial number, model, mastership priority, role and neighbour list - the fastest way to prove all members joined and that the primary/backup pair is the pair you planned. show virtual-chassis vc-port shows which physical port is which VCP and whether the link is up. show virtual-chassis vc-port statistics reveals whether traffic is actually flowing across the fabric, and show virtual-chassis protocol adjacency style protocol counters show whether members are exchanging control messages or silently losing them.

user@switch> show virtual-chassis status
user@switch> show virtual-chassis vc-port
user@switch> show virtual-chassis vc-port statistics
user@switch> show virtual-chassis protocol interface

Sample output of show virtual-chassis status on a healthy four-member fabric looks like this - note the * marking the member you are logged into and the neighbour list mapping each VCP:

Preprovisioned Virtual Chassis
Virtual Chassis ID: 0000.e255.00e0
                     Mastership          Neighbor List
Member ID  Status    Serial No  Model   Priority Role       ID, Interface
0 (FPC 0)  Prsnt     abc123     ex4300-48p  200  Master*   1 vcp-0
                                                           2 vcp-1
1 (FPC 1)  Prsnt     def456     ex4300-48p  199  Backup    2 vcp-0
                                                           0 vcp-1
2 (FPC 2)  Prsnt     ghi789     ex4300-24t    0  Linecard  0 vcp-0
                                                           3 vcp-1
3 (FPC 3)  Prsnt     jkl012     ex4300-24t    0  Linecard  1 vcp-0
                                                           2 vcp-1

Troubleshooting Common Virtual Chassis Problems

A member never appears. Check that the VCP is actually configured on both ends - a converted uplink on one switch and an unconverted port on the other will simply not link. Then check the cable and optics, and finally the model combination: an unsupported mix reports a mixed-mode or mismatch condition instead of forming.

The VC split in two. A fabric partition turns one logical switch into two devices that both think they are primary, with duplicate SVIs, duplicate DHCP servers and possibly a bridging loop if any link still joins them. Confirm the split with show virtual-chassis status on each side. Recovery is to restore the VCP path and let the members re-merge, or to isolate and reload the smaller fragment. Design defences are a ring topology, independent power feeds for the RE members, and keeping all inter-member traffic on VCPs rather than on ordinary uplinks.

Unexpected primary. After a reboot the primary can change because the election ran again with a member missing. If the roles move around, pin mastership priority - that is what it is for. If you run preprovisioned mode, remember that the Roles are fixed and the fabric will not promote a linecard to keep itself alive.

Traffic slow across members. Look for a single VCP carrying the whole fabric, then at the VCP error counters. Copper DAC cables that pass data but drop control packets, or a VCP negotiated at a lower speed than expected, show up here first.

Virtual Chassis FAQ

Can I mix an EX4300 with an EX3400? Only in combinations Juniper lists for those platforms - check the mixed Virtual Chassis table for your release before ordering. Mixing families that are not supported produces a member that powers on but never joins.

Do I still need VRRP in a VC? No. The members share one control plane, so an SVI on the VC already has a single IP address and LAG uplinks can span members. VRRP is only needed when you deliberately keep two independent switches.

How many members should be Routing Engine capable? Two. One primary and one backup gives you a switchover target without paying for control-plane hardware on every member.

Does the VC need its own management address per member? No - the VC is managed through one address. Individual members can still be reached in-band through their FPC number if you need to reload or console one of them.

Design Guidelines for Resilient VCs

Put the primary and backup members in different physical locations or at least on independent power feeds.
Distribute members so no single power supply or switch failure takes down more than half the fabric.
Space members evenly by member hop so no single inter-member link carries an unbalanced share.
Preprovision the VC (serial number, member ID and role per member) when possible - it prevents accidental role elections and rogue members joining.

Virtual Chassis Ports are the cabling backbone: use the dedicated VCP cabling where available (each cable provides tens of Gbps of fabric bandwidth) and avoid under-sizing the VC fabric relative to the aggregate downlink traffic.

Two additions to those guidelines come from real outages. First, never let a VC depend on a single uplink for both inter-member traffic and user traffic - if the primary-side uplink is also the only path to the core, a switchover window becomes an outage window. Second, document the member ID to physical switch mapping and record each serial number in the preprovisioned configuration, because the answer to "which member is the primary" is what you need at 3 a.m., and it is not obvious from the rack.