Understanding Virtual Chassis Components

This topic describes the components of an EX series or a QFX Series Virtual Chassis.

An EX Series Virtual Chassis is a supported combination of standalone EX Series switches interconnected and managed as a single chassis.

Note:
We do not recommend using EX9200 switches in a Virtual Chassis, and we phased out support for that architecture as of Junos OS Release 17.1R1. For deployments with EX9200 switches, we recommend planning or moving to MC-LAG or Junos Fusion Enterprise architectures instead of using a Virtual Chassis.
A QFX Series Virtual Chassis is a supported combination of standalone QFX5100, QFX5110, QFX5120, or QFX5200 switches interconnected and managed as a single chassis. EX4650 Virtual Chassis operate the same as QFX5120 Virtual Chassis, so most of the information in this topic about QFX Series Virtual Chassis in general also applies to an EX4650 Virtual Chassis, with a few platform-specific support differences.

Note:
EX4300 switches (excluding multigigabit models [EX4300-48MP]) can also be interconnected into a mixed Virtual Chassis with QFX5100 switches.

Maximum Switch Support

The maximum number of switches that a Virtual Chassis supports varies by Virtual Chassis and might also depend on the Junos OS release running on the Virtual Chassis.

Maximum Number of Switches in an EX Series Virtual Chassis
Maximum Number of Switches in a QFX Series Virtual Chassis (Including Mixed Virtual Chassis with EX Series Switches)

Maximum Number of Switches in an EX Series Virtual Chassis

Table 1 lists the maximum number of member switches supported in an EX Series Virtual Chassis by Junos OS release.

Table 1: Maximum Member Switch Support for EX Series Virtual Chassis by Junos OS Release
Type of EX Series Virtual Chassis	Maximum Member Switches by Junos OS Release
EX2300 Virtual Chassis	18.4R1—Starting in Junos OS Release 18.4R1, up to 4 of any model EX2300 member switches (including multigigabit models and any other EX2300 switches) can be combined in the same Virtual Chassis.
EX3400 Virtual Chassis	15.1X53-D50—Initial release. Up to 10 EX3400 member switches.
EX4100 Virtual Chassis	22.2R1—Initial release. Up to 10 EX4100 member switches.
EX4300 Virtual Chassis	18.2R1—Starting in Junos OS Release 18.2R1 with the introduction of EX4300 multigigabit model switches (EX4300-48MP), an EX4300 Virtual Chassis can contain up to 10 EX4300 multigigabit model switches as a non-mixed Virtual Chassis or a combination of EX4300 multigigabit model switches with other EX4300 switches as a mixed EX4300 Virtual Chassis.
EX4400 Virtual Chassis	21.1R1—Initial release. Up to 10 EX4400 member switches. 21.2R1—Starting in Junos OS Release 21.2R1, an EX4400 Virtual Chassis can also include EX4400 multigigabit model switches (EX4400-24MP and EX4400-48MP).
EX4650 Virtual Chassis	19.3R1—Initial release. Up to 2 EX4650 switches in Routing Engine roles only. 20.1R1—Starting in Junos OS Release 20.1R1, an EX4650 Virtual Chassis can have up to 4 members.

Maximum Number of Switches in a QFX Series Virtual Chassis (Including Mixed Virtual Chassis with EX Series Switches)

Table 2 lists the maximum number of member switches supported in a QFX Series Virtual Chassis by Junos OS release, including mixed QFX Series Virtual Chassis with EX Series switch members.

Table 2: Maximum Member Switch Support for QFX Series Virtual Chassis by Junos OS Release
Type of QFX Series Virtual Chassis	Maximum Member Switches by Junos OS Release
QFX5110 Virtual Chassis: QFX5110 switches in Routing Engine role with any combination of supported QFX5110 and QFX5100 switches in linecard role.	17.3R1—Initial release. Up to 10 member switches.
QFX5120 Virtual Chassis:	19.3R1—Initial release on QFX5120-48Y switches. Up to 2 member switches, both in Routing Engine role. 20.2R1—Initial release on QFX5120-48T switches. Up to 2 member switches, both in Routing Engine role. 20.3R1—Initial release on QFX5120-32C switches. Up to 2 member switches, both in Routing Engine role.
QFX5200 Virtual Chassis— Only QFX5200 switches.	17.3R2 and 17.4R1—Initial release. Up to 3 member switches.

Virtual Chassis Ports (VCPs)

You set up a Virtual Chassis by configuring Virtual Chassis ports (VCPs) on the member switches, and interconnecting the switches using the VCPs. VCPs are responsible for passing all data and control traffic between member switches in the Virtual Chassis.

Virtual Chassis Port Options
Automatic Virtual Chassis Port (VCP) Conversion
Virtual Chassis Port Link Aggregation Groups

Virtual Chassis Port Options

Some switches have dedicated VCPs; you can only use these ports as VCPs and you can’t reconfigure them as network ports. Dedicated VCPs allow you to interconnect switches into a Virtual Chassis without requiring any additional interface configuration.

Some switches have ports that are configured as VCPs by default. You don’t need to explicitly configure those as VCPs to use them to interconnect the switches into a Virtual Chassis.

Most switches have optical or uplink ports that you can also configure as VCPs.

You must configure VCPs to interconnect switches that do not have dedicated or default-configured VCPs or to interconnect switches across greater distances than allowed by a dedicated VCP connection. Otherwise, you can mix any of the supported VCP options among the members of a Virtual Chassis, and we recommend having redundant links between any two members for resiliency or to increase member communication bandwidth. VCPs automatically bundle into a Link Aggregation Group when two or more ports operating at the same speed are configured into VCPs between the same two member switches. See Understanding Virtual Chassis Port Link Aggregation for details.

When adding switches to an existing Virtual Chassis or adding new redundant links between existing members, if the automatic VCP conversion feature is enabled, under the right conditions the ports on both sides of the connection will convert into VCPs automatically (see Automatic Virtual Chassis Port (VCP) Conversion).

Table 3 summarizes the available VCP options on switches in an EX Series or QFX Series Virtual Chassis. For complete details on where dedicated VCPs, default-configured VCPs, or ports that can be configured as VCPs are located on a switch, and the supported transceivers and cables that you can use for VCP connections on the switch, see the hardware documentation for that type of switch.

Table 3: VCP Options by Switch Type
Switch	Dedicated VCPs	Default VCPs	Ports that can be configured and are supported as VCPs
EX2300 (including EX2300 multigigabit models)	None	None	10-Gigabit Ethernet uplink ports with SFP+ tranceivers Note: You cannot use ports with SFP transceivers as VCPs on EX2300 switches to form a Virtual Chassis.
EX4100	4 25-Gbps SFP28 ports on the front panel	4 25-Gbps SFP28 ports on the front panel	None
EX4100-F	4 10-Gbps SFP+ ports on the front panel	4 10-Gbps SFP+ ports on the front panel	None
EX4300	None	All QSFP+ ports	Any uplink ports installed with SFP+ or QSPF+ transceivers Note: On 32-port EX4300 switches, you can’t use the four built-in 10-Gigabit Ethernet SFP+ ports as VCPs.
EX4300 multigigabit models (EX4300-48MP)	4 40-Gbps QSFP+ ports on the rear panel	None	None
EX4400 (Including EX4400 multigigabit models)	None	4 logical 50-Gbps VCP interfaces using the two 100-Gbps QSFP28 ports on the rear panel (PIC slot 1)	None
EX4650	None	None	Any of the 40-Gigabit Ethernet or 100-Gigabit QSFP28 ports on the front panel (ports 48 through 55), non-channelized Note: The Junos OS doesn’t prevent you from trying to set other ports as VCPs, but they don’t operate properly as VCPs.
QFX5110	None	None	Any 40-Gigabit Ethernet or 100-Gigabit Ethernet QSFP28 ports Any non-channelized 40-Gigabit Ethernet QSFP+ interfaces Any non-channelized 10-Gigabit Ethernet SFP+ interfaces (on QFX5110 switch models that support these ports)
QFX5120	None	None	(QFX5120-48Y) Any of the eight 40-Gigabit Ethernet or 100-Gigabit Ethernet QSFP+ or QSFP28 ports on the front panel (ports 48 through 55), non-channelized (QFX5120-48T) Any of the six 40-Gigabit Ethernet or 100-Gigabit Ethernet QSFP+ or QSFP28 ports on the front panel (ports 48 through 53), non-channelized Note: Any ports other than those specified above for QFX5120-48Y and QFX5120-48T switches are not supported as VCPs. The Junos OS CLI doesn’t return an error if you try to set other ports as VCPs, but they will not work properly as VCPs. (QFX5120-32C) Any non-channelized network ports (ports 0 through 31) installed with either 40-Gbps QSFP+ or 100-Gpbs QSFP28 transceivers
QFX5200	None	None	Any 40-Gigabit Ethernet QSFP+ ports Starting in Junos OS Release 17.3R2-S4, you can also use 100-Gigabit Ethernet QSFP28 ports as VCPs on QFX5200 switches.

QSFP+ interfaces that have been channelized into SFP+ interfaces using a breakout cable cannot be configured into VCPs.

Automatic Virtual Chassis Port (VCP) Conversion

When the automatic VCP conversion feature is enabled and you cable a new link from a new switch being added into an existing Virtual Chassis, or add a redundant link between two members of a Virtual Chassis, ports that can be VCPs are automatically converted into VCPs under the following conditions:

Link Layer Discovery Protocol (LLDP) or LLDP-Media Endpoint Discovery (LLDP-MED) is enabled on the interfaces for the members on both ends of the new link. The two sides exchange LLDP packets to accomplish the port conversion.
The Virtual Chassis must be preprovisioned with the switches on both sides of the link already configured in the members list of the Virtual Chassis using the set virtual-chassis member command.
The interfaces for the ports on both ends of the link are not already configured as VCPs. Both sides of the link must be in the same state to handshake and establish the VCP link.

Using automatic VCP conversion when adding a switch to a preprovisioned Virtual Chassis is also called autoprovisioning the new member.

For ports to be eligible for automatic VCP conversion, you must convert them back into network ports using the request virtual-chassis vc-port delete command if they are default-configured VCPs or you previously configured them into VCPs. Switches do not automatically convert VCPs back into network ports when you remove them from a Virtual Chassis and disconnect the links.

Automatic VCP conversion is enabled by default on all Virtual Chassis, except in the following cases:

Automatic VCP conversion doesn't apply to EX4400 switches in a Virtual Chassis. On these switches, to convert the default VCPs into network ports or convert them from network ports back into VCP ports, you must explicitly set the port mode using the request virtual-chassis mode network-port command, and then reboot the switch.
For any EX4650 and QFX5120 Virtual Chassis (which all have the automatic VCP conversion feature enabled by default), you can choose to disable the feature by configuring no-auto-conversion at the [edit virtual-chassis] hierarchy level on the Virtual Chassis. To return to the default behavior to re-enable automatic VCP conversion, delete the no-auto-conversion statement from the configuration.

Virtual Chassis Port Link Aggregation Groups

You can increase VCP bandwidth between member switches by configuring multiple links between the same two switches into VCP links. When multiple VCPs interconnect the same two member switches, the links automatically form a Link Aggregation Group (LAG) bundle if the VCP links are the same speed. For example, if you have two 40-Gbps QSFP+ VCP links connected between member switches, the links automatically form a LAG with 80-Gbps total bandwidth. However, 10-Gigabit SFP+ and 40-Gbps QSFP+ VCP links will not become members of the same LAG.

Within a Virtual Chassis, you can also configure network interfaces located on different Virtual Chassis member switches to form a LAG, which provides load-balancing and redundancy for network traffic that the Virtual Chassis forwards. See Understanding Virtual Chassis Port Link Aggregation for details on the difference between VCP LAGs and network interface LAGs within a Virtual Chassis.

Primary Routing Engine Role

In a Virtual Chassis, each member switch operates in one of two roles, Routing Engine role or linecard role. When in Routing Engine role, a member switch acts as the primary or backup Routing Engine.

The primary Routing Engine member in the Virtual Chassis:

Manages the member switches.
Runs Junos OS for the switches as a primary Routing Engine.
Runs the chassis management processes and control protocols.
Represents all the member switches interconnected within the Virtual Chassis configuration. (The hostname and other properties that you assign to this switch during setup apply to all members of the Virtual Chassis configuration.)

In a preprovisioned configuration, the Virtual Chassis primary-role election algorithm determines which member switch in the Routing Engine role acts as the Virtual Chassis primary and which acts as the backup. See Understanding How the Primary in a Virtual Chassis Is Elected.

In a configuration that is not preprovisioned, called a nonprovisioned configuration, the Virtual Chassis selects the primary and backup using the primary-role priority value and secondary factors in the primary-role election algorithm.

The remaining switches in the Virtual Chassis that are not the primary or backup operate in the linecard role.

Use the following guidelines for assigning Routing Engine roles to the switches in a mixed Virtual Chassis:

In a QFX5110 Virtual Chassis with QFX5110 and QFX5100 switches, we recommend configuring only QFX5110 switches into the Routing Engine role.
In a two-member EX4650 or QFX5120 Virtual Chassis, configure both member switches into the Routing Engine role as primary and backup member switches only (no linecard role members).

Backup Routing Engine Role

The member that functions in the backup Routing Engine role in a Virtual Chassis:

Maintains a state of readiness to take over the primary Routing Engine role if the primary fails.
Runs Junos OS for the switches as a backup Routing Engine.
Synchronizes with the primary in terms of protocol states, forwarding tables, and other information, so that it is prepared to preserve routing information and maintain network connectivity without disruption in case the primary is unavailable.

The Virtual Chassis configuration must have at least two member switches in order to have a backup Routing Engine member.

In a nonprovisioned configuration, the Virtual Chassis selects the primary and backup member switches using the primary-role priority value and secondary factors in the primary-role election algorithm.

Use the following guidelines for assigning Routing Engine roles to the switches in a mixed Virtual Chassis:

In a mixed EX4300 Virtual Chassis composed of EX4300 multigigabit model (EX4300-48MP) and other EX4300 model switches, you should always have EX4300 multigigabit model switches in the primary and backup Routing Engine roles.
In a QFX5110 Virtual Chassis with QFX5110 and QFX5100 switches, we recommend configuring only QFX5110 switches into the Routing Engine role.
In a two-member EX4650 or QFX5120 Virtual Chassis, configure both member switches into the Routing Engine role as primary and backup member switches only (no linecard role members).

Linecard Role

A member that functions in the linecard role in a Virtual Chassis:

Runs only a subset of Junos OS.
Does not run the chassis control protocols.
Can detect certain error conditions (such as an unplugged cable) on any interfaces that have been configured on it through the primary.

The Virtual Chassis configuration must have at least three members in order to include a linecard member.

In a preprovisioned configuration, you can explicitly configure a member with the linecard role, which means it can’t be a primary or backup Routing Engine.

In a nonprovisioned configuration, the members that are not selected as primary or backup operate as linecard members of the Virtual Chassis. The Virtual Chassis selects the primary and backup member switches using the primary-role priority value and secondary factors in the primary-role election algorithm. A switch with a primary-role priority of 0 is always in the linecard role.

In any two-member Virtual Chassis, for high availability you should configure both members into the Routing Engine role, and no members in the linecard role. Otherwise, in a Virtual Chassis with more than two members, any supported switch type can operate in linecard role.

Use the following guidelines for assigning Routing Engine and linecard roles to the switches in a QFX Series Virtual Chassis:

In a QFX5110 Virtual Chassis made up of QFX5110 and QFX5100 switches, we recommend configuring only QFX5110 switches into the Routing Engine role.

Member Switch and Member ID

Each standalone switch that supports Virtual Chassis is a potential member of a Virtual Chassis configuration. When you power on one of those switches, it has a Virtual Chassis member ID that you can see on the front-panel LCD on some switches or in show virtual-chassis command output. If the switch is powered on as a standalone switch, its member ID is always 0. When you interconnect the switch into a Virtual Chassis configuration, the primary member switch assigns it a member ID based on various factors such as the order in which the switch was added to the Virtual Chassis or if you defined member IDs based on switch serial numbers in the preprovisioning process.

If the Virtual Chassis configuration previously included a member switch and you physically disconnected or removed that member from the Virtual Chassis configuration, its member ID is not automatically available for assignment as part of the primary’s standard sequential member ID assignment. For example, you might have a Virtual Chassis configuration with member 0, member 2, and member 3, because member 1 was removed. When you add another member switch and power it on, the primary assigns ID 4 to it, not ID 1. If you want to reuse a member ID from a member switch that was removed, you can recycle the member id (see the request virtual-chassis recycle command for details). .

The member ID distinguishes the member switches from each other. You use the member ID to:

assign a primary-role priority value to a member switch.
configure interfaces for a member switch, similar to specifying a juniper Networks device slot number.
apply some operational commands to a member switch.
display status or characteristics of a member switch.

Primary-role Priority

In a nonprovisioned configuration, you can designate the role (primary or backup Routing Engine role or linecard role) that a member switch assumes by configuring its primary-role priority (a number from 0 through 255). The primary-role priority value is the first consideration in the primary-role election algorithm for selecting the primary of the Virtual Chassis configuration. A switch with a primary-role priority of 0 never assumes the backup or primary Routing Engine role.

When you power on a standalone switch, it has the default primary-role priority value 128. Because it’s the only member switch in its own Virtual Chassis configuration, it’s also the primary member. When you interconnect a standalone switch to an existing Virtual Chassis configuration (which already has its own primary), we recommend that you explicitly configure the primary-role priority of the members that you want to function as the primary and backup.

Note:

Configuring the same primary-role priority value for both the primary and backup helps to ensure a smooth transition from primary to backup if the primary becomes unavailable. It prevents the original primary from preempting control from the backup when the backup has taken control of the Virtual Chassis configuration because the original primary became unavailable.

In a preprovisioned configuration, you can’t configure primary-role priority values manually. You assign the role of each member switch, and the Virtual Chassis assigns the primary-role priority automatically based on the assigned role.

Virtual Chassis Identifier (VCID)

All members of a Virtual Chassis configuration share one Virtual Chassis identifier (VCID). The Virtual Chassis derives this identifier from internal parameters. When you monitor a Virtual Chassis configuration, certain interface views and the show virtual-chassis command display the VCID.

Nonvolatile Storage in a Virtual Chassis

EX Series and QFX Series switches store Junos OS system files in internal flash memory. In Virtual Chassis configurations, both the primary and the backup switch store the configuration information for all the member switches.

Junos OS optimizes the way a Virtual Chassis stores its configuration if a member switch or the Virtual Chassis configuration shuts down improperly, as follows:

If the primary is not available, the backup switch takes on the role of the primary and its internal flash memory takes over as the alternate location for maintaining nonvolatile configuration memory.
If you take a member switch offline for repair, the primary stores the configuration of the member switch.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release

Description

20.1R1

Starting in Junos OS Release 20.1R1, an EX4650 Virtual Chassis can have up to 4 members.

18.4R1

Starting in Junos OS Release 18.4R1, up to 4 of any model EX2300 member switches (including multigigabit models and any other EX2300 switches) can be combined in the same Virtual Chassis.

18.2R1

Starting in Junos OS Release 18.2R1 with the introduction of EX4300 multigigabit model switches (EX4300-48MP), an EX4300 Virtual Chassis can contain up to 10 EX4300 multigigabit model switches as a non-mixed Virtual Chassis or a combination of EX4300 multigigabit model switches with other EX4300 switches as a mixed EX4300 Virtual Chassis.

17.3R2-S4

Starting in Junos OS Release 17.3R2-S4, you can also use 100-Gigabit Ethernet QSFP28 ports as VCPs on QFX5200 switches.

15.1R7

Starting in Junos OS Releases 15.1R7 and 14.1X53-D47, in EX2200, EX3300, EX4200, EX4500, and EX4550 Virtual Chassis, automatic VCP conversion is disabled by default.

14.1X53-D47

Starting in Junos OS Releases 14.1X53-D47, 17.4R2, 18.1R3, 18.2R2, and 18.3R1 for EX4300, EX4600, QFX Series Virtual Chassis and for any EX4650 and QFX5120 Virtual Chassis (which all have the automatic VCP conversion feature enabled by default), you can choose to disable the feature by configuring no-auto-conversion at the [edit virtual-chassis] hierarchy level on the Virtual Chassis.

13.2X53-D25

Starting in Junos OS Release 13.2X51-D25, you can include up to 10 QFX5100-96S switches in a mixed or non-mixed QFX5100 Virtual Chassis.

13.2X50-D20

Starting in Junos OS Release 13.2X50-D20, a mixed QFX Series Virtual Chassis or VCF can also contain EX4300 switches.

12.2R1

Starting in Junos OS Release 12.2R1, an EX3300 Virtual Chassis can support up to 10 EX3300 member switches.

ON THIS PAGE