Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

Configuring a Nonprovisioned Virtual Chassis Fabric

Caution: Configure your Virtual Chassis Fabric (VCF) using autoprovisioning or preprovisioning unless you have a compelling reason to use nonprovisioned configuration. You can configure all aspects of a VCF using autoprovisioned or preprovisioned configuration. The process for autoprovisioning your VCF is described in Autoprovisioning a Virtual Chassis Fabric and the process for preprovisioning your VCF is described in Preprovisioning a Virtual Chassis Fabric.

Nonprovisioned VCF configuration is highly discouraged. Nonprovisioned VCF configuration should only be used by VCF experts in specialized scenarios.

A nonprovisioned VCF is the configuration mode used when a VCF has not been configured into autoprovisioned or preprovisioned mode.

In a nonprovisioned VCF, you configure the device roles by setting the mastership priority value of each device. If no mastership priority values are set, a master election algorithm process runs and selects the role for each device.

You must manually configure all Virtual Chassis ports (VCPs) in a nonprovisioned VCF. The automatic VCP conversion feature, which automatically configures supported 10-Gbps SFP+ links and 40-Gbps QSFP+ links into VCPs on autoprovisioned and preprovisioned VCFs, is not supported on nonprovisioned VCFs.

Update all devices to the same version of Junos OS that supports VCF. See Upgrading Software or Installing Software on an EX Series Switch with a Single Routing Engine (CLI Procedure).

To configure a nonprovisioned VCF:

  1. Power on the devices.
  2. Configure each individual device into fabric mode. If needed, configure the devices into mixed mode.

    Reboot each device to complete this configuration step.

    A VCF must have QFX5100 devices in the spine role, and operates most efficiently when the leaf nodes are also QFX5100 devices. Mixed mode must be configured if your VCF also includes at least one QFX3600, QFX3500, or EX4300 device in the leaf role.

    If you are configuring a VCF composed entirely of QFX5100 devices:

    user@device> request virtual-chassis mode fabric local reboot

    If you are configuring a VCF using at least one QFX3600, QFX3500, or EX4300 device as a leaf device:

    user@device> request virtual-chassis mode fabric mixed local reboot

    Note: A device whose fabric or mixed mode setting is improperly set cannot join a VCF. You can check the mode settings using the show virtual-chassis mode command.

    We recommend setting the fabric and mixed mode settings before interconnecting your devices into a VCF to avoid the following issues:

    • Incurring downtime as the devices reboot to commit the mixed mode or fabric settings.
    • Manually correcting potential issues related to VCF formation because the device did not immediately join the VCF.

    We strongly recommend configuring the mixed and fabric settings before you interconnect a device into a VCF. You can, however, use the request virtual-chassis mode fabric local or request virtual-chassis mode mixed local commands to set a device into fabric or mixed mode after you have interconnected your VCF.

  3. After the device reboots are complete, cable your spine devices to your leaf devices using supported SFP+ and QSFP+ interfaces.
  4. (Recommended) Configure a virtual management Ethernet (VME) interface for management of the VCF configuration:
    [edit]
    user@device# set interfaces vme unit 0 family inet address /ip-address/mask/

    Note: A VME accesses the device in the master Routing Engine role using a management port, so cable management port em0 or em1 on each spine device in your VCF so the VME is available regardless of which spine device assumes the master Routing Engine role. See Connecting a QFX Series Device to a Management Console

  5. Configure the desired SFP+ and QSFP+ interfaces into Virtual Chassis ports (VCPs):
    user@device> request virtual-chassis vc-port set pic-slot pic-slot-number port port-number
    user@device> request virtual-chassis vc-port set pic-slot pic-slot-number port port-number

    The show virtual-chassis vc-port must be issued on the ports at both ends of the link in order for that link to be configured into a VCP.

  6. Enter the show virtual-chassis command to confirm that the VCPs are operational and to learn the member ID of each member device in your VCF.

    If you want to change the member ID that has been assigned to a member device, use the request virtual-chassis renumber command.

  7. (Optional) Configure the mastership priority for each member device:
    [edit virtual-chassis]
    user@device# set member member-id mastership-priority number

    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 two QFX5100 devices with the highest mastership priority values assume the master and backup Routing Engine role, which must be used by the spine devices in a VCF. All other devices assume the linecard role.

    QFX5100 devices assume the Routing Engine role, regardless of mastership priority settings. QFX5100 devices can also assume the linecard role.

    QFX3600, QFX3500, and EX4300 devices always assume the linecard role in a VCF, regardless of the mastership priority settings.

    Note: A spine device that isn’t selected as master or backup Routing Engine assumes the linecard role. The spine devices should still be configured with a higher mastership priority value than the leaf devices to assure a spine device assumes the Routing Engine role when the master or backup Routing Engine fails.

    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 into the Routing Engine role. See Understanding How the Master in a Virtual Chassis Is Elected.

    A device with a mastership priority of 0 never assumes the master or backup role.

    For instance, to configure the mastership priority for member devices 0 through 19 in your VCF.

    [edit virtual-chassis]
    user@device# set member 0 mastership-priority 255
    user@device# set member 1 mastership-priority 255
    user@device# set member 2 mastership-priority 100
    user@device# set member 3 mastership-priority 100
    user@device# set member 4 mastership-priority 95
    user@device# set member 5 mastership-priority 95
    user@device# set member 6 mastership-priority 95
    user@device# set member 7 mastership-priority 95
    user@device# set member 8 mastership-priority 95
    user@device# set member 9 mastership-priority 95
    user@device# set member 10 mastership-priority 95
    user@device# set member 11 mastership-priority 95
    user@device# set member 12 mastership-priority 95
    user@device# set member 13 mastership-priority 95
    user@device# set member 14 mastership-priority 95
    user@device# set member 15 mastership-priority 95
    user@device# set member 16 mastership-priority 95
    user@device# set member 17 mastership-priority 95
    user@device# set member 18 mastership-priority 95
    user@device# set member 19 mastership-priority 95
  8. Install the VCF feature licenses.

    For a VCF deployment, two license keys are recommended for redundancy—one for the device in the master role and the other for the device in the backup role.

    To purchase a feature license for VCF, contact your Juniper Networks sales representative (https://www.juniper.net/us/en/contact-us/sales-offices). The Juniper sales representative will provide you with the feature license files and license keys. You will be asked to supply the chassis serial number of your switch; you can obtain the serial number by running the show virtual-chassis command.

    After obtaining the licenses, follow the instructions in Generating License Keys.

Modified: 2016-03-01