Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Autoprovisioning a Virtual Chassis Fabric

Autoprovisioning a Virtual Chassis Fabric (VCF) enables you to “plug and play” devices into your VCF after minimal initial configuration. See Understanding Virtual Chassis Fabric Components and Understanding Virtual Chassis Fabric Configuration for details on the supported devices that can be interconnected into a non-mixed or mixed VCF.

Before you begin:

To configure a VCF using autoprovisioning:

  1. Make a list of the serial numbers of all the spine devices in the VCF. You can configure up to four spine devices in a VCF. You can get the device’s serial number in the show virtual-chassis output or by following the instructions in Locating the Serial Number on a QFX5100 Device or Component for a QFX5100 VCF, or Locating the Serial Number on a QFX5110 Device or Component for a QFX5110 VCF.
  2. Set each device individually into fabric mode. If needed, also set the devices into mixed mode for a mixed VCF, and at the same time, request the device to reboot as part of the procedure to complete this step.
    Tip:

    This step must be done at least for the spine devices being assigned the Routing Engine role in the VCF, but for the most predictable results, we strongly recommend you also manually set fabric mode and mixed modes for all devices (with the device reboot option) before cabling them into the VCF.

    If you are configuring a non-mixed VCF:

    If you are configuring a mixed mode VCF:

    Note:

    A spine device whose fabric and mixed mode settings are improperly set will not properly join a mixed VCF. You can check the mode settings by using the show virtual-chassis mode command.

    We recommend that you set the fabric and mixed mode settings before you interconnect your spine devices into the VCF to avoid the following issues:

    • Incurring downtime during VCF formation as the devices reboot to commit the fabric or mixed mode settings.

    • Manually correcting potential issues related to VCF formation because a device did not immediately join the VCF.

    You can, however, use the request virtual-chassis mode fabric local or request virtual-chassis mode mixed local commands to set a spine device into fabric or mixed mode after interconnecting your VCF.

    The fabric and mixed mode settings are automatically updated for a leaf device when it is interconnected into an autoprovisioned or preprovisioned VCF if the device is zeroized or has the factory default configuration. If the fabric or mixed mode settings are automatically changed when a leaf device is interconnected into a VCF, the leaf device automatically reboots in order to properly join the VCF. To avoid this potentially unexpected reboot and impact on VCF operation, as mentioned earlier, for best results, set the fabric and mixed modes and manually reboot each leaf device before cabling it into the VCF.

  3. After the reboot completes, log in to one of the spine devices in your VCF.
  4. Set the configuration mode to autoprovisioned:
  5. Configure at least two spine devices into the Routing Engine role:

    For instance, to configure two spine devices with the serial numbers “SERIALNUMB00” and “SERIALNUMB01” into the Routing Engine role as members 0 and 1:

    Keep in mind that any member devices you configure into the Routing Engine role participate in the primary-role election process (see Primary Routing Engine Election Process). The VCF will elect one primary and one backup member from the devices configured into this role. Member devices that are not in Routing Engine role are not eligible for primary-role election. Those members automatically operate in linecard role, whether or not you explicitly configured them into linecard role. Members configured into Routing Engine role that were not elected as primary or backup also automatically operate in linecard role.

    You usually want spine devices acting as the primary and backup members. If you don’t have enough spine devices to do that, you can configure one or two leaf devices into the Routing Engine role to ensure the VCF can reassign the primary and backup members if a spine device Routing Engine member fails.

  6. (Recommended) Configure a virtual management Ethernet (VME) interface for management of the VCF configuration:
    Note:

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

  7. Commit the configuration:
  8. Cable your VCF.

    After you commit your autoprovisioned VCF configuration, you can cable any additional supported leaf devices (in zeroized or factory default configuration) into the VCF using supported VCPs. The autoprovisioning process automatically configures the VCPs, and if needed, automatically sets mixed mode and fabric mode and reboots the device for those changes to take effect. The devices participate in the VCF with no further user intervention.

    Note:

    Automatic VCP conversion only works when the interfaces on both ends of the link are not already configured as VCPs.

    When adding a QFX4300 leaf device to a QFX5100 VCF, the 40-Gbps QSFP+ interfaces on EX4300 switches are configured as VCPs, by default. You must, therefore, delete the VCP configuration on the 40-Gbps QSFP+ interface using the request virtual-chassis vc-port delete command before interconnecting it into the VCF. Then the automatic VCP conversion process is invoked and converts the link into a VCP.

    A device joins the VCF immediately without a reboot if you do not need to change the fabric mode or mixed mode settings.

  9. Install the VCF feature licenses.

    For a VCF deployment, we recommend having two license keys for redundancy—one for the device in the primary Routing Engine role and the other for the device in the backup Routing Engine 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.

  10. (Optional) The VCF forwards broadcast, unknown unicast, and multicast (BUM) traffic among the members of the VCF using multicast distribution trees (MDTs). By default, the VCF creates MDTs for every member of the VCF with that member as the root node of an MDT. If this default MDT creation method is not optimal for your installation, you can control which members become MDT root nodes.

    The set virtual-chassis member member-id fabric-tree-root configuration statement preempts the default method of creating MDTs, and specifies whether or not a member in a VCF can be an MDT root node. If this statement is configured for one or more members, MDTs are created only with the specified members as root nodes. See Understanding Traffic Flow Through a Virtual Chassis Fabric and fabric-tree-root for more details on why you might want to choose this MDT creation method instead of the default method. Note that if you decide to use this option, we recommend that you specify all the spine members (and only spine members) as MDT root nodes. In an autoprovisioned VCF, this option should be configured for all spine devices (independent of the member’s role) after the VCF is running and any additional spine device member IDs have been automatically assigned.

    If desired, configure the spine devices in the VCF to be fabric MDT root nodes. For example, if you have four spine members in your VCF, where you configured the first two spine devices to be members 0 and 1, and during autoprovisioning, the two additional spine members were automatically assigned to be members 4 and 5:

    Note:

    This option can also be configured anytime later during VCF operation if you observe internal VCF multicast traffic flow issues with default MDTs.

Related Documentation