Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

VCF Configuration Steps

This section provides a high-level overview of the VCF configuration steps and includes the following sections:

Virtual Chassis Fabric Preparation Review

Before starting to configure the VCF, the following design decisions should be made based on information in prior sections of this document:

  1. Topology. Determine which spine and leaf architecture is the right topology for your network.

  2. Type of devices in your VCF.

    • A QFX5110 VCF is a VCF with QFX5110 spine devices and any combination of supported QFX5100 and QFX5110 leaf devices. Both types of devices run the same Junos OS software image when interconnected together and configured into a QFX5110 VCF, so this is considered to be a non-mixed VCF. For best results when planning a QFX5100 VCF, use only QFX5110-32Q switches as the spine devices.

    • A QFX5100 VCF is a VCF with QFX5100 spine devices, and can have only QFX5100 leaf devices (a non-mixed QFX5100 VCF) or a combination of QFX5100, QFX3500, QFX3600, and EX4300 leaf devices running compatible Junos OS software (a mixed QFX5100 VCF).

    See Virtual Chassis Fabric Overview for details on the topology and devices that can be in a VCF.

  3. Mixed or non-mixed VCF. Determine whether your VCF is a non-mixed VCF (see the previous step and Understanding Mixed Virtual Chassis Fabric).

    The optimal QFX5110 VCF topology is to use all QFX5110 devices, and specifically QFX5110-32Q switches as the spine devices. A QFX5110 VCF composed entirely of QFX5110 devices supports the largest breadth of features at the highest scalability while also supporting the highest number of high-speed interfaces.

    The optimal QFX5100 VCF topology is to use a non-mixed VCF with QFX5100 devices only. A QFX5100 VCF composed entirely of QFX5100 devices supports the largest breadth of features at the highest scalability while also supporting the highest number of high-speed interfaces available on QFX5100 switches.

These decisions should be made before performing the VCF configuration steps for the following reasons:

  • You need to know the topology to cable and configure the switches.

  • A QFX5110 VCF can only be set up using QFX5110 and QFX5100 switches that are running the same Junos OS software, which must be a software image that includes “-qfx-5e-” in the software package filename when the Junos OS package is downloaded from the Software Center. QFX5100 switches running a Junos OS image that includes “-qfx-5-” in the software package filename must be upgraded to a package filename that includes “-qfx-5e-” before being included in a QFX5110 VCF. The upgrade requires rebooting the QFX5100 switch from USB install media and rebooting the switch. See Upgrading a QFX5100 Switch with a USB Device to Join a QFX5110 Virtual Chassis or Virtual Chassis Fabric for details.

  • All member switches in a mixed VCF have to be rebooted to change the VCF mode. In a mixed-mode VCF, we recommend changing the fabric and mixed mode on each member switch—changing the fabric mode is a mandatory step that always requires a reboot—at the same time so that you can reboot the switch once for both configuration changes to take effect.

Most other design and configuration decisions, such as adding or removing VCPs, adding or removing member switches, or switching between preprovisioned and autoprovisioned configuration processes, can usually be changed without requiring system downtime.

Once a VCF topology has been decided, the VCF configuration generally involves the following steps:

  1. Select either the preprovisioned or the autoprovisioned method of configuring the VCF.

  2. Prepare each member switch for the VCF, including upgrading the member switches to the appropriate version of Junos OS that supports VCF, and setting the member switches into fabric mode and, if applicable, mixed mode.

  3. Create the appropriate Virtual Chassis configuration.

  4. Connect the VCPs.

Selecting a Provisioning Method

You can provision a VCF in one of the following ways:

  • Autoprovision

  • Preprovision

  • Nonprovision (not recommended)

Consider the following factors when selecting a provisioning method:

  • Autoprovisioning: Autoprovisioning simplifies the configuration process, because you can plug and play leaf devices into the VCF after completing a minimal initial configuration procedure that includes specifying the spine devices.

  • Preprovisioning: Preprovisioning allows you to explicitly control the composition of the VCF, but it is more labor-intensive than autoprovisioning because you have to collect and configure the serial number of each member switch in the VCF.

  • Nonprovisioning: We discourage the use of nonprovisioned VCF configuration. Only use a nonprovisioned VCF configuration if you are an expert user and you have a clear understanding of why you are using a nonprovisioned configuration over an autoprovisioned or a preprovisioned configuration.

Autoprovisioning a VCF

To autoprovision a VCF, you must first configure the roles and serial numbers of the spine switches before the leaf devices can plug and play into the VCF.

For detailed step-by-step instructions for configuring your VCF using autoprovisioning, see Autoprovisioning a Virtual Chassis Fabric.

This section discusses the following topics:

Preparing a Leaf Device

In an autoprovisioned VCF, you can plug-and-play leaf devices into the VCF. In an autoprovisioned VCF, VCPs are created automatically as leaf devices are cabled to spines devices.

Routing Engine Preparation

When building a mixed VCF, follow these rules:

  • Select your Routing Engines from the list of eligible Routing Engine switch models. See Understanding Mixed Virtual Chassis Fabric.

  • Configure and install your Routing Engine switches before your line card switches.

    While you are not required to install the Routing Engine switches first, primary and backup synchronizations occur as part of the Routing Engine switch process and multiple switchovers can lead to unpredictable results.

  • (Recommended) Zeroize your spine device.

    All spine switches must be provisioned and are not required to be in factory-default state. However, an automatic reboot procedure is performed when the spine switch is not in the factory default state. If a switch was previously deployed in a Virtual Chassis or VCF, we recommend using the request system zeroize to erase all VCP configurations and to allow the automatic VCP conversions to happen without interference.

  • Ensure that LLDP is enabled on all switches that will become VCPs.

    LLDP is enabled by default on all EX and QFX Series switch interfaces, so you only need to perform this check if the LLDP configuration was previously modified. See Configuring LLDP (CLI Procedure).

  • Ensure the spine switches are set into the right mode before building the VCF. In the following example, a primary Routing Engine switch in a mixed VCF is set into mixed fabric mode before building the VCF:

    After the switch is rebooted, it will be set to operate in mixed fabric mode.

Leaf Device Preparation

Leaf devices must meet the following requirements before being interconnected into a VCF to be able to plug and play:

  • The switch must be in factory default mode.

    A switch received from the factory that has not been configured can be immediately installed into an autoprovisioned VCF as a leaf device.

    For switches that have previously been used in a network, set the switch into factory default mode by entering the request system zeroize command:

  • (EX4300 switches using 40-Gbps interfaces only) Delete the existing VCP configurations.

    The 40-Gbps QSFP+ interfaces on EX4300 switches are configured as VCPs, by default. Automatic VCP conversion only works when the interfaces on both ends of the link are not configured into VCPs. You must, therefore, delete the default VCP configuration on 40-Gbps QSFP+ interfaces on the EX4300 switches for AVC to work. You can delete a VCP configuration using the request virtual-chassis vc-port delete command.

Sample VCF Autoprovisioned Configuration

This section shows a sample autoprovisioned VCF configuration.

You should configure the VCF from the primary Routing Engine:

This configuration only includes the serial numbers of the spine devices. You must configure two spine devices into the Routing Engine role and, if you are using three or four spine devices, configure the non-Routing Engine spine devices into the linecard role.

Connecting the VCPs

With any autoprovisioned configuration, including the sample configuration in the previous section, VCPs form automatically as leaf devices are cabled to the spine device.

The following actions might occur to newly-cabled leaf devices after the VCPs are formed:

  • the leaf device might reboot.

  • ports are automatically converted into VCPs.

  • the leaf device joins the VCF.

  • the spine device joins the VCF.

Each of these actions is discussed in more detail in the following sections.

Understanding the Leaf Device Reboot

Leaf devices automatically reboot when cabled to spine devices in an autoprovisioned configuration when the fabric mode or mixed mode needs to be changed to match the settings in the primary spine device.

Because your leaf switch is zeroized before it is cabled into a VCF, expect your leaf device to reboot immediately after you cable it into a VCF.

The leaf device is recognized by the VCF after the reboot.

Automatic VCP Conversion

Leaf devices automatically convert ports to VCPs in an autoprovisioned configuration.

For the automatic VCP conversion procedure to work, both ends of the link must be set as network ports initially.

Note:

The 40-Gbps QSFP+ interfaces on EX4300 switches are configured as VCPs, by default. Automatic VCP conversion (AVC) only works when the interfaces on both ends of the link are not configured into VCPs. You must, therefore, delete the default VCP configuration on 40-Gbps QSFP+ interfaces on the EX4300 switches for AVC to work. You can delete a VCP configuration using the request virtual-chassis vc-port delete command.

The process to create the VCP can take up to 60 seconds. If multiple same-speed links are interconnected between the same spine and aggregation devices, the VCPs automatically form a VCP LAG.

Leaf Devices Joining the VCF

After the network ports are converted into VCPs, the leaf switches are brought into the VCF and assigned member ID numbers.

Spine Devices Joining the VCF

If you add a spine device to an autoprovisioned VCF, you must first update the configuration to specify the new spine device’s serial number and assign it a member ID.

A spine device joining an existing VCF goes through various procedures similar to a leaf switch joining a VCF, including:

  • The spine switch reboots when the fabric mode or mixed mode is updated because it is not consistent with the primary Routing Engine.

    Note:

    We recommend changing the fabric and mixed mode settings before interconnecting your new spine device into the VCF by entering the request virtual-chassis mode fabric mixed local reboot command. This action avoids a potentially unexpected automatic device reboot upon cabling the device into the VCF.

  • The joining spine switch reboots if it is in the factory-default state.

  • Network ports are automatically converted into VCPs.

Understanding VCP Link Aggregation Group Creation

After the autoprovisioned VCF is formed, parallel links—same speed links connecting the same spine device to the same leaf device—between any pair of member switches are automatically converted into a VCP LAG and the combined bandwidth is added to fabric path calculations.

Stopping Automatic VCP Conversion

Once a VCF is formed, stopping the autoprovisioning process can avoid bringing in additional chassis into the VCF by mistake, especially in cases where you want to use the uplink interfaces on the spine devices as network ports.

To stop the autoprovisioning process, you can do one of the following two things:

  • Disable LLDP on all the interfaces that are going to connect new member switches.

  • Convert the autoprovisioned VCF into a preprovisioned VCF. This is a straightforward process because all of the member switches have serial numbers that are already discovered.

Preprovisioning a VCF

This topic describes the extra steps that are required to form a mixed VCF using preprovisioning instead of autoprovisioning. For detailed step-by-step instructions for configuring your VCF using autoprovisioning, see Preprovisioning a Virtual Chassis Fabric.

Member Switch Preparation

As in an autoprovisioned VCF, each member switch in a preprovisioned VCF must be set to the correct fabric and mixed mode for it to properly join the VCF. Setting these modes should be done on Routing Engine spine devices manually before cabling the VCF. When adding other spine or leaf devices, you can set these modes manually before interconnecting the new device into the VCF to avoid requiring the device to be rebooted at that time. Otherwise, for new devices that have been zeroized or are in the factory default configuration, upon interconnecting the new device into the VCF, the automatic VCP conversion process will also detect and set fabric and mixed modes if needed, and automatically reboot the device.

Fabric and mixed modes can be enabled or disabled at the same time by using the following operational commands on the member switch that is going to be a member of the VCF:

Best Practice:

To minimize disruption to an existing VCF, change the fabric and mixed mode settings and reboot a new member switch before cabling it into the VCF.

You can, however, change the fabric and mixed mode settings and reboot your switch after cabling it into a VCF.

The current and future mode settings of the member switches can be displayed by issuing the following command:

Verify that current and future modes of all member switches are correct. If any member switch’s current and future modes are different, a reboot is required for that switch. For example, the previous display output shows that, in order for fpc0 and fpc1 to have the same fabric mode and mixed mode, fpc0 needs to be rebooted to set its mode to mixed mode.

Routing Engine Switch Preparation

The intended primary Routing Engine switch is prepared in the same way as it is for an autoprovisioned VCF.

Linecard Member Switch Preparation

Linecard member switches are prepared for a preprovisioned VCF in the same way as spine member switches are prepared for an autoprovisioned VCF.

Note that because every member switch needs to be provisioned, the member switches are not required to be in factory default state, as long as the intended linecards have LLDP enabled on any potential VCP links. However, we still recommend that you zeroize a linecard member switch before adding it to a VCF.

In addition to bringing a switch to its factory default configuration, the request system zeroize command also removes all VCPs configured on the switch. If a switch is previously used as member in a Virtual Chassis or VCF, the request system zeroize command can be used to clean up previously converted VCP ports. This is required for the automatic VCP port conversion procedure to be performed.

Preprovisioned VCF Configuration

In a preprovisioned VCF, all member switches are included in the Virtual Chassis configuration on the intended primary Routing Engine switch:

Connecting the VCPs

With the previously described preparations and configurations, the VCF will be formed as VCP links are connected.

The actions taken by the member switches automatically during VCF formation are similar to the actions in the autoprovisioned method until the VCF is fully formed.

These similar actions include:

  • Provisioned member switches might reboot if they are in the factory-default state.

  • Provisioned member switches reboot if the fabric or mixed mode needs to be changed.

  • Automatic VCP port conversions occur.

Switches can only join the VCF if they are explicitly provisioned in the configuration. Hence, there is no need to disable LLDP on any ports to stop automatically converting VCPs. Instead, additional fabric links can be added between provisioned members and they will be automatically converted to VCP links.

Nonprovisioning a VCF

CAUTION:

Configure your Virtual Chassis Fabric (VCF) using autoprovisioning or preprovisioning unless you have a compelling reason to use a nonprovisioned configuration. A nonprovisioned VCF configuration is highly discouraged.

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

See Configuring a Nonprovisioned Virtual Chassis Fabric for instructions on configuring a nonprovisioned VCF.

Adding a Leaf Device to an Operational VCF

When adding a leaf device to a VCF, be aware of the following factors:

  • Make sure the new switch is running the same version of Junos OS that is running in the VCF.

  • Set the appropriate mode—either fabric or mixed fabric—and reboot the switch before interconnecting it into the VCF.

  • Zeroize the new device using the request system zeroize command.

  • Update the VCF configuration to accommodate the new spine before cabling it into the VCF.

Interconnect the new device to the spine member that is in the primary Routing Engine role first, which is the most efficient way to synchronize the new member with the current VCF configuration and state. Interconnecting a new member only to the backup or another spine member can cause flooding of messages within the VCF as the primary tries to synchronize the new member through other leaf and spine member VCP links. After the new member is fully incorporated into the VCF, you can interconnect the remaining redundant VCP links to the backup and other spine devices without affecting traffic within the VCF.

See Adding a Device to a Virtual Chassis Fabric for detailed instructions on adding a leaf device to a VCF.