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

    Understanding Virtual Chassis Fabric Components

    This topic describes the components of a Virtual Chassis Fabric (VCF).

    This topic covers:

    Spine-and-Leaf Topology

    The VCF uses a spine-and-leaf architecture where each device in the fabric is either a spine device or a leaf device.

    A VCF can have up to four spine devices, and up to twenty total devices. Each spine device has at least one direct Virtual Chassis port (VCP) connection to each leaf device in the VCF.

    All traffic entering a leaf device can, therefore, be forwarded to any directly connected spine device and is always two hops away from any other leaf device—leaf device to leaf device traffic travels from the source leaf device to a spine device to the destination leaf device—within the VCF.

    See Figure 1 for an illustration of the VCF spine-and-leaf architecture:

    Figure 1: VCF Spine-and-Leaf Architecture

    VCF Spine-and-Leaf
Architecture

    Note: A VCF topology should include at least four members—two spine devices and at least two leaf devices. For topologies with three or fewer members, use a Virtual Chassis configuration instead.

    Traffic is forwarded through a VCF using a weighted algorithm designed to avoid congestion. Traffic travelling across the VCF from one leaf device to another leaf device is forwarded using the best path available at the time, so any connection to a spine device can be used to transport traffic from one leaf device to another leaf device.

    Spine Devices

    A spine device:

    • Must be a QFX5100 device.
    • Can be configured into the Routing Engine or linecard role. In a VCF, two spine devices must be configured into the Routing Engine role. The remaining spine devices must be configured into the linecard role.
    • Has a direct connection to each leaf device.
    • Typically connects a router, firewall, or other data center networking device to the VCF.

    A VCF should always have at least two active spine devices interconnected with at least two leaf devices. A VCF supports up to four spine devices.

    Best Practice: We recommend using the following QFX5100 switches as spine devices:

    • QFX5100-24Q switches, in deployments where devices are connecting to the VCF using the 10-Gbps Ethernet interfaces on the leaf devices, or using a mix of 10-Gbps and 1-Gbps Ethernet interfaces on the leaf devices.
    • QFX5100-96S or QFX5100-48S, in deployments where devices are connecting to the VCF using 1-Gbps Ethernet interfaces only on the leaf devices.

    QFX5100-48T switches are not supported as spine devices.

    Leaf Devices

    A leaf device:

    • Is optimally a QFX5100 device, but can also be a QFX3500, QFX3600, or EX4300 device.
    • Has a direct connection to each spine device.
    • Always operates in the linecard role.
    • Typically connects an endpoint device—for instance, a server or other storage device in a data center—to the VCF.

    A VCF can have up to twenty total devices and up to four devices can be configured as spine devices. The devices that are not spine devices in a VCF operate as leaf devices.

    Note: A VCF should include at least four members—two spine devices and at least two leaf devices. For topologies with three or fewer members, use a Virtual Chassis configuration instead.

    Routing Engine Role

    A VCF has two devices operating in the Routing Engine role—a master Routing Engine and a backup Routing Engine.

    The device that functions as the master Routing Engine:

    • Is a spine device.
    • Manages the member devices.
    • Runs the chassis management processes and control protocols.
    • Represents all the member devices interconnected within the VCF configuration. (The hostname and other parameters that you assign to this device during setup apply to all members of the VCF.)

    The device that functions as the backup Routing Engine:

    • Is a spine device.
    • Maintains a state of readiness to take over the master role if the master fails.
    • Synchronizes with the master in terms of protocol states, forwarding tables, and so forth, so that it preserves routing information and maintains network connectivity without disruption when the master is unavailable.

    In a VCF, two spine devices are configured into the Routing Engine role. The remaining spine devices are configured into the linecard role.

    A spine device operating in the linecard role can complete all spine-related functions with no limitations within a VCF.

    Linecard Role

    A spine or a leaf device can be configured into the linecard role in a VCF.

    In a VCF, two spine devices are configured into the Routing Engine role. The remaining spine devices are configured into the linecard role. A spine device operating in the linecard role can complete all spine-related functions with no limitations within a VCF. A spine device operating in the linecard role does not become a Routing Engine when the master or backup Routing Engine fails.

    All leaf devices in a VCF operate in the linecard role. In autoprovisioned configurations, leaf devices are assigned the linecard role when they are cabled into the VCF. In preprovisioned configurations, leaf devices are manually configured into the linecard role. In nonprovisioned configurations, leaf devices are assigned the linecard role according to the master election algorithm, which uses the mastership priority values to set the roles of each device in the VCF.

    A member that functions in the linecard role in a VCF:

    • Runs only a subset of Junos OS.
    • Detects certain error conditions (such as an unplugged cable) on any interfaces that have been configured on it through the device functioning as the master Routing Engine.

    Master Routing Engine Election Process

    The device in the master Routing Engine role in a VCF is always a spine device.

    In a preprovisioned or autoprovisioned VCF, two spine devices are assigned the Routing Engine role during the configuration process. The spine device that has been powered on the longest assumes the master Routing Engine role; the spine device that has been powered on the second longest assumes the backup Routing Engine role.

    In a nonprovisioned VCF, the master and backup Routing Engines are selected using the following algorithm:

    1. Choose the QFX5100 device with the highest user-configured mastership priority (255 is the highest possible value) as the master Routing Engine, and the QFX5100 switch with the second highest mastership priority value as the backup Routing Engine.

      A QFX5100 switch with a mastership priority of 0 will always stay in the linecard role.

    2. Choose the QFX5100 device that was master the last time the VCF booted.
    3. Choose the QFX5100 device that has been included in the VCF configuration for the longest period of time.
    4. Choose the QFX5100 device with the lowest MAC address.

    QFX3500, QFX3600, and EX4300 devices never assume the master or backup Routing Engine role in a VCF.

    We strongly recommend that you configure the mastership priority of the QFX5100 devices in your VCF to ensure that the correct devices assume their intended roles when you configure your VCF using a nonprovisioned configuration.

    Virtual Chassis Ports (VCPs)

    Virtual Chassis ports (VCPs) are used in a VCF to interconnect leaf devices to spine devices. All control and data traffic in a VCF is transported over VCPs.

    VCPs in a VCF are either SFP+ connections that support 10-Gbps or QSFP+ connections that support 40-Gbps.

    10-Gbps SFP+ and 40-Gbps QSFP+ links are automatically converted into VCPs in most scenarios when a device is added to an autoprovisioned or preprovisioned VCF. Automatic VCP conversion is discussed in more detail in the following section.

    You can manually configure a 10-Gbps SFP+ and 40-Gbps QSFP+ link into a VCP.

    Channelized interfaces cannot be configured into VCPs.

    Automatic Virtual Chassis Port (VCP) Conversion

    10-Gbps SFP+ and 40-Gbps QSFP+ links are not configured into VCPs, by default.

    10-Gbps SFP+ and 40-Gbps QSFP+ links are automatically converted into VCPs when:

    • Link Layer Discovery Protocol (LLDP) is enabled on the interfaces on both ends of the link. LLDP is enabled by default.
    • the device being added to the VCF is configured into fabric mode.
    • The interfaces on both ends of the link are not configured as VCPs. The following interfaces are configured as VCPs:
      • The 40-Gbps QSFP+ port on an EX4300 switch, by default.
      • Any interface in the VCF that has been a VCP. If a device is removed from a VCF, the interface that was interconnected to the removed device remains configured as a VCP until it is configured into a network port using the using the request virtual-chassis vc-port delete command.
      • Any interface that has been configured into a VCP using the request virtual-chassis vc-port set command.

      To change any of the above interfaces into a network interface so that the interface can become eligible for automatic VCP conversion, use the request virtual-chassis vc-port delete command.

    • one of the devices is already part of a VCF that was autoprovisioned or preprovisioned.

    Automatic VCP conversion does not work in nonprovisioned VCFs.

    Automatic VCP conversion does not convert a VCP interface into a network interface when a device is removed from a VCF. If automatic VCP conversion has converted an interface into a VCP and you want the interface to function as a network interface, you must manually disable the VCP interface.

    VCF Configuration Options

    You can configure a VCF using autoprovisioned, preprovisioned, or nonprovisioned configuration.

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

    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.

    Nonprovisioned configuration is possible, but not recommended for most VCF installations. Nonprovisioned configuration is a highly manual procedure that should only be performed by expert users.

    See Understanding Virtual Chassis Fabric Configuration for additional information on the VCF configuration options.

    Fabric Mode

    Devices must be configured in fabric mode to properly participate as a member of a VCF. As a best practice, you should configure a device into fabric mode before interconnecting it into the VCF.

    Devices are not in fabric mode by default. A device that is in a Virtual Chassis or a standalone device that is not part of a VCF should never be configured into fabric mode.

    In autoprovisioned or preprovisioned VCF configurations, you can manually configure a spine device into fabric mode first and then interconnect it into a VCF. Alternatively, a spine device that has been zeroized or has the factory default configuration is automatically configured into fabric mode when it is interconnected into a VCF, during the automatic VCP conversion process. In either case, the process of configuring the device into fabric mode requires a device reboot as the final step for the spine device to join the VCF. If configured into fabric mode automatically, the VCF reboots the device automatically; if configured into fabric mode manually, you must manually reboot the device.

    In an autoprovisioned or preprovisioned VCF, when adding a leaf device that has been zeroized or has the factory default configuration, the VCF automatically sets fabric mode and reboots the leaf device when it is interconnected into the VCF, during the automatic VCP conversion process. You can avoid the downtime that accompanies the automatic reboot by setting the device into fabric mode and rebooting the leaf device before interconnecting it into the VCF.

    Best Practice: For best results, we strongly recommend manually configuring a spine or leaf device into fabric mode and then manually rebooting the device before interconnecting it into the VCF, rather than having the reboot happen automatically, which can be perceived as an unexpected action during VCF configuration and operation.

    Mixed Mode

    The optimal method of configuring a VCF is to use QFX5100 devices only. A 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.

    You can, however, configure other devices as leaf devices in your VCF. Spine devices must be QFX5100 devices. QFX5100, QFX3600, QFX3500, or EX4300 devices can be used as leaf devices.

    If you use QFX3600, QFX3500, or EX4300 devices as leaf devices in your VCF, you must configure all devices in your VCF into mixed mode.

    Devices are not configured into mixed mode by default. A device that is not part of a Virtual Chassis or a VCF with other devices should never be configured into mixed mode.

    Virtual Management Ethernet Interface

    VCF configuration can be managed remotely using a global management interface called the 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 using the VME interface’s IP address, the connection is always redirected to the device acting in the master Routing Engine role.

    A VME interface should always be used to configure a VCF. 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 strongly recommend cabling the management port on all devices acting as Routing Engines to the network to ensure that you always have a direct connection to the master Routing Engine through the VME interface, regardless of which device assumes the master Routing Engine role. The management ports on leaf devices can also be used by the VME interface to access the VCF, so you can also cable leaf device management ports to the network, if desired.

    Virtual Chassis Fabric Port Link Aggregation Group Bundles

    You can increase the bandwidth on links configured as VCPs within a VCF between two devices by configuring multiple same-speed links between two devices into VCPs. If, for instance, you configure two 40-Gbps QSFP+ links that are connecting the same devices in a VCF into VCPs , the two VCP links form one LAG bundle with two member links and 80-Gbps of total available bandwidth.

    A VCP LAG bundle provides more bandwidth than a single VCP link can provide. A VCP LAG bundle also improves performance by load-sharing traffic across links within the bundle, and provides redundancy because traffic can be forwarded across another member link in the VCP LAG bundle when one VCP link fails.

    VCP LAG bundling occurs automatically when same-speed VCP links are configured between two devices. No user configuration is required. VCP LAG bundling works only on same-speed VCP links; 10-Gbps and 40-Gbps links cannot be in the same VCP LAG bundle.

    Virtual Chassis Fabric License Requirements

    A feature license is required to configure a VCF. The VCF feature license is an independent feature license; the enhanced feature licenses (EFLs) or advanced feature licenses (AFLs) that must be purchased to enable some features on some Juniper switches cannot be purchased to enable VCF.

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

    Feature licenses are also required to configure advanced features on a Virtual Chassis Fabric. For a Virtual Chassis Fabric deployment, two license keys are recommended for redundancy—one for the device in the master Routing Engine role and the other for the device in the backup Routing Engine role. See Software Features That Require Licenses on the QFX Series.

    To purchase feature licenses for VCF, contact your Juniper Networks sales representative (http://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.

    Hardware Requirements for a Virtual Chassis Fabric

    A VCF can contain up to four devices configured as spines and up to twenty total devices. A VCF should contain a minimum of four members—two spine devices and at least two leaf devices interconnected in a spine-and-leaf topology.

    Note: For topologies with three or fewer members, use a Virtual Chassis configuration instead.

    All spine devices must be QFX5100 devices. We recommend optimizing the performance of your VCF by also configuring QFX5100 devices as your leaf devices. A non-mixed VCF has the highest port density and feature support for a VCF in addition to supporting more spine devices. Nevertheless, you can configure any combination of QFX5100, QFX3600, QFX3500, or EX4300 devices into leaf devices within your VCF.

    Best Practice: We recommend using the following QFX5100 switches as spine devices:

    • QFX5100-24Q switches, in deployments where devices are connecting to the VCF using the 10-Gbps Ethernet interfaces on the leaf devices, or using a mix of 10-Gbps and 1-Gbps Ethernet interfaces on the leaf devices.
    • QFX5100-96S or QFX5100-48S, in deployments where devices are connecting to the VCF using 1-Gbps Ethernet interfaces only on the leaf devices.

    QFX5100-48T switches are not supported as spine devices.

    Software Requirements in a Virtual Chassis Fabric

    All devices in a VCF must be running the same version of Junos OS software that supports VCF.

    The devices in the VCF must be using the version of software for standalone switches.

    The flex software bundle is supported on non-mixed VCFs using QFX5100 member switches only. You cannot use the flex software bundle in mixed VCFs. The flex software bundle is the software that includes “jinstall-qfx-5-flex” text in the filename when it is downloaded from the Software Center.

    We recommend configuring a device to the Junos OS release running on the VCF before interconnecting it into the VCF. For additional information on VCF software upgrades, see Understanding Software Upgrades in a Virtual Chassis Fabric.

    For information on software upgrade options for an operational VCF, see Understanding Software Upgrades in a Virtual Chassis Fabric.

    Modified: 2017-02-17