Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding Virtual Chassis Fabric Configuration

 

This topic describes the configuration options available for your Virtual Chassis Fabric (VCF).

This topic covers:

Virtual Chassis Fabric Setup

You must setup your VCF using one of the following options:

Autoprovisioned Virtual Chassis Fabric Configuration

Autoprovisioned configuration allows you to “plug and play” leaf devices into a VCF after minimal initial configuration.

The minimal configuration requirements for autoprovisioning a VCF include setting the configuration mode to autoprovisioned and explicitly identifying the spine devices in your VCF by serial number. After this minimal configuration is complete, all supported devices—supported devices are either devices that have been zeroized or devices in factory default mode that have never been configured into a Virtual Chassis or VCF—are automatically added to the VCF as leaf devices when they are cabled to spine devices using supported 10-Gbps SFP+ ports or 40-Gbps QSFP+ ports. During this process, the Virtual Chassis ports (VCPs) are configured automatically, and other parameters such as fabric and mixed mode are automatically detected and set.

For best results, a spine device in an autoprovisioned configuration should be configured into fabric mode and rebooted manually before being interconnected into a VCF. Otherwise, if the VCF automatically sets fabric mode for the device, the subsequent automatic device reboot might be unexpected at that point during VCF configuration and operation.

A spine device in an autoprovisioned VCF must also have the same mixed mode setting as other member devices in the VCF. Setting either fabric mode or mixed mode requires the device to be rebooted, so as a best practice, you should configure your spine device into fabric mode and at the same time, if necessary, configure mixed mode, and reboot the device manually before interconnecting it into the VCF.

Similar to the behavior for spine devices, a leaf device in an autoprovisioned configuration that is zeroized or in factory default configuration and not yet configured into fabric mode is automatically configured into fabric mode and rebooted during the automatic VCP conversion process when it is interconnected into a VCF. The leaf device is also automatically rebooted if the device needs to be configured into or out of mixed mode to participate in the VCF. You can optionally avoid the downtime that accompanies a leaf device reboot by manually setting the leaf device into fabric mode and into or out of mixed mode, zeroizing the device at that point if necessary, and manually rebooting the device before interconnecting it into the VCF.

Preprovisioned Virtual Chassis Fabric Configuration

In a preprovisioned configuration, you deterministically control the devices in your VCF by associating each device’s serial number to a member ID and role.

The advantage of configuring a VCF using a preprovisioned configuration is that you can more explicitly control which devices are added to your VCF, and in what roles. At the same time, as with an autoprovisioned VCF, preprovisioned VCFs support automatic VCP conversion. As part of the VCP conversion process, when leaf devices that have been zeroized or are in factory default mode are interconnected to configured spine devices, the VCF can automatically detect and, if needed, set fabric and mixed modes. If fabric mode or mixed mode settings are automatically updated, the devices are also rebooted automatically. Alternatively, you can avoid a potentially unexpected automatic device reboot (and associated down time) by manually configuring the fabric or mixed mode setting on the device and manually rebooting it before interconnecting it into the VCF. For best results when adding devices to a preprovisioned VCF, we recommend manually setting fabric and mixed modes, zeroizing or restoring the factory default configuration if necessary, and manually rebooting the devices being added before interconnecting them into the VCF.

The disadvantage of using a preprovisioned configuration is that the configuration process requires more manual steps than the autoprovisioned configuration process.

Nonprovisioned Virtual Chassis Fabric Configuration

Caution

We discourage nonprovisioned VCF configuration. You can configure all aspects of a VCF using autoprovisioned or preprovisioned configuration. Nonprovisioned VCF configuration should only be used by VCF experts in specialized scenarios.

A nonprovisioned VCF is the default method for creating a VCF; it is the configuration mode used when a VCF has not been configured into autoprovisioned or preprovisioned mode.

In a nonprovisioned VCF, member roles are determined by a mastership election algorithm. The first value checked by the mastership election algorithm is the mastership priority value. The switches with the highest mastership priority values assume the master and backup Routing Engine roles in a VCF.

If two or more devices have the same mastership priority value and are candidates for the Routing Engine role, the mastership election algorithm uses other parameters to determines which device is elected as the Routing Engine. See Understanding Virtual Chassis Fabric Components.

The default mastership priority value for all devices is 128. You should always configure two spine devices with the highest mastership priority to ensure the Routing Engine role is assigned to a spine device.

In a nonprovisioned VCF, you must manually configure every VCP.

Configuration File Management in a VCF

You configure a VCF by logging onto the master Routing Engine and making configuration changes. See the next section for information on logging into a VCF.

The configuration file that is modified when you are on the master Routing Engine is automatically shared with all other devices in the VCF when it is committed. Each device stores it’s own copy of the configuration file.

Logging into a Virtual Chassis Fabric

The recommended method of logging into a VCF is through the use of a Virtual Management Ethernet (VME) interface. The VME interface is a logical interface representing all of the out-of-band management ports on the member devices. When you connect to the VCF configuration using the VME interface’s IP address, the connection is always redirected to the management port on device in the master Routing Engine role. The VME interface is not tied to a device, so it can always be used to log in to the VCF even after the master Routing Engine changes. We recommend cabling the management ports—an me or em interface—on each Routing Engine in your VCF to support the VME interface.

If you log in to the console port of any member device in a VCF, your session is automatically redirected to the device acting in the master Routing Engine role.

Understanding Interface Numbering

Interfaces in Junos OS are specified as follows:

type-fpc/pic/port

A VCF applies this convention as follows:

  • type—The interface type.

  • fpc—Flexible PIC Concentrator. In a VCF, the fpc is the member ID of the switch. For instance, the fpc of member 16 in the VCF is 16.

  • pic—the number of the PIC (Physical Interface Card) on the member device.

  • port—the port number.

For more detailed information on interface numbering, see Understanding Interface Naming Conventions.