Adding a Device to a Virtual Chassis Fabric
This topic describes how to add a device to a Virtual Chassis Fabric (VCF). 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.
All devices in a VCF must be running the same or a compatible version of Junos OS, so before you begin to add a device to an existing VCF, update your device to the same version of Junos OS running on the devices in the VCF. See Installing Software Packages on QFX Series Devices or Installing Software on an EX Series Switch with a Virtual Chassis or Single Routing Engine (CLI Procedure). Then follow the applicable procedure to add the device based on how your VCF is configured.
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 added to a QFX5110 Virtual Chassis or VCF. See Upgrading a QFX5100 Switch with a USB Device to Join a QFX5110 Virtual Chassis or Virtual Chassis Fabric.
This topic contains the following sections:
Adding a Leaf Device to an Autoprovisioned Virtual Chassis Fabric
To add a leaf device to an autoprovisioned VCF:
- Log onto the device that you are adding to the VCF.
- (Optional) Perform this step if you want to avoid the
downtime associated with an extra reboot when your device is interconnected
into your VCF. If you do not perform this step, the VCF auto-detects
the fabric and mixed mode settings and, if needed, reboots the device
as part of the process of changing these settings.
Configure the leaf device into fabric mode. Configure your device into mixed mode for a mixed VCF .
Note:If the leaf device has not previously been configured, also specify the
reboot
option to reboot the leaf device now and apply the mode settings. Otherwise, if the leaf device has been previously configured, in the next step you zeroize and reboot the device to clear prior configuration stanzas. In that step the reboot also applies the mode settings (maintained during zeroizing), so you do not need to reboot in this step and again in the next step.If you are configuring a non-mixed VCF:
user@device> request virtual-chassis mode fabric local <reboot>
If you are configuring a mixed VCF:
user@device> request virtual-chassis mode fabric mixed local <reboot>
- If the leaf device that you are adding to the VCF has
not previously been configured, proceed to the next step.
If your device has been configured previously, zeroize your device and reboot:
user@device> request system zeroize warning: System will be rebooted and may not boot without configuration Erase all data, including configuration and log files? [yes,no] (yes) yes
Note:You must zeroize your device if you have previously entered one or more configuration commands, including basic configuration commands.
Your device will not properly join the VCF as a “plug and play” device if it contains any configuration, until it has been zeroized.
You cannot use other methods to set a device into factory default mode before inserting it into a VCF if it was previously configured in another Virtual Chassis or VCF. You must use request system zeroize.
Note:The request virtual-chassis mode fabric local and request virtual-chassis mode fabric mixed local commands are entered in operational mode, so those settings are maintained when the device is zeroized.
For additional information on this procedure, see Reverting to the Factory-Default Configuration for the EX Series Switch or Reverting to the Default Factory Configuration.
- (Required only if you are adding a device that turns a
non-mixed VCF into a mixed VCF) Log in to the VCF and set all devices
in the VCF to mixed mode. Configure all devices to reboot to complete
this procedure.
user@device> request virtual-chassis mode mixed all-members reboot
The VCF experiences downtime as part of the reboot step.
- Interconnect your leaf device into the existing spine
devices, using at least one interface that can be a Virtual Chassis
port (VCP) to
connect to each spine device in the VCF.
An autoprovisioned VCF automatically adds a supported device that is zeroized or in factory default mode to the VCF when it is connected to a spine device using a supported VCP link. Both sides of the link are automatically converted into VCPs, and fabric and mixed mode settings are detected and updated automatically if necessary, as part of this process. If fabric or mixed mode settings are updated, the newly-added leaf device is automatically rebooted to complete the configuration and join the VCF.
Best Practice:When adding a leaf device to an existing 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.
No further configuration is required.
Adding a Spine Device to an Autoprovisioned Virtual Chassis Fabric
To add a spine device to an autoprovisioned VCF:
- Log in to your VCF.
- If you are replacing a spine device that is already part
of the VCF, power off the spine device in the VCF.
Follow the steps in Removing a Device From a Virtual Chassis Fabric to remove the device from the VCF.
- Modify the configuration.
If your new spine device is replacing an existing spine, modify the configuration to remove the old spine.
You can skip this step if you are not replacing an existing spine device.
[edit virtual-chassis] user@device# delete member member-id
where member-id is the member ID of the spine that is removed from this procedure.
Add the spine device to the configuration:
[edit virtual-chassis] user@device# set member member-id serial-number serial-number role [line-card | routing-engine]
For instance, to configure a spine device acting in the linecard role with the serial number OU81234567890 as member 3:
[edit virtual-chassis] user@device# set member 3 serial-number OU81234567890 role line-card
The
set virtual-chassis member member-id fabric-tree-root
configuration statement specifies that only certain devices will be root nodes in the multicast distribution trees (MDTs) created for directing traffic within the VCF. This configuration item preempts the default VCF behavior to create one MDT for every device in the VCF with that device as a root node. (See Understanding Traffic Flow Through a Virtual Chassis Fabric and fabric-tree-root for more information about this option.) If your VCF uses this option to configure the spine devices as fabric tree roots (which is the recommended usage), then configure the new spine device as a fabric tree root as well:[edit virtual-chassis] user@device# set member member-id fabric-tree-root
For instance, to configure the spine device configured as member 3 as a fabric tree root node:
[edit virtual-chassis] user@device# set member 3 fabric-tree-root
- Commit the configuration.
[edit] user@device# commit
- Log in to the device that is going to be added to the VCF.
- Configure the device into fabric mode. If needed, also
configure the device into mixed mode.
Reboot the device to complete this configuration step.
If you are configuring a non-mixed VCF:
user@device> request virtual-chassis mode fabric local reboot
If you are configuring a mixed mode VCF:
user@device> request virtual-chassis mode fabric mixed local reboot
Note: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.
You can, however, use the
request virtual-chassis mode fabric local
orrequest virtual-chassis mode mixed local
commands to set a device into fabric or mixed mode after interconnecting your VCF. - (Required only if you are adding a device that turns a
non-mixed VCF into a mixed VCF) Log in to the VCF and set all devices
in the VCF to mixed mode. Configure all devices to reboot to complete
this procedure.
user@device> request virtual-chassis mode mixed all-members reboot
The VCF experiences downtime as part of the reboot procedure.
- After the device reboots, interconnect the new device
into the VCF by cabling the device to the leaf devices in the VCF
using supported interfaces that can be VCPs.
The interconnecting links are converted into VCPs automatically.
The new spine device should be operational after the cabling is completed.
Adding a Spine or Leaf Device to a Preprovisioned Virtual Chassis Fabric
To add a spine or leaf device to a preprovisioned VCF:
- Log in to your VCF.
- If you are replacing a device that is already part of
the VCF, power off the device in the VCF.
Follow the steps in Removing a Device From a Virtual Chassis Fabric to remove the device from the VCF.
- Modify the configuration.
If your new device is replacing an existing device, modify the configuration to remove the old device.
You can skip this portion of the procedure if you are not replacing an existing device.
[edit virtual-chassis] user@device# delete member member-id
where member-id is the member ID of the device that is removed in this procedure.
Add the new device to the VCF configuration:
[edit virtual-chassis] user@device# set member member-id serial-number serial-number role [line-card | routing-engine]
For instance, to configure a device with the serial number OU81234567890 into the Routine Engine role as member 3:
[edit virtual-chassis] user@device# set member 3 serial-number OU81234567890 role routing-engine
(For spine devices only) The
set virtual-chassis member member-id fabric-tree-root
configuration statement specifies that only certain devices will be root nodes in the multicast distribution trees (MDTs) created for directing traffic within the VCF. This configuration item preempts the default VCF behavior to create one MDT for every device in the VCF with that device as a root node. (See Understanding Traffic Flow Through a Virtual Chassis Fabric and fabric-tree-root for more information about this option.) If your VCF uses this option to configure the spine devices as fabric tree roots (which is the recommended usage), then configure the new spine device as a fabric tree root as well:[edit virtual-chassis] user@device# set member member-id fabric-tree-root
For instance, to configure the spine device configured as member 3 as a fabric tree root node:
[edit virtual-chassis] user@device# set member 3 fabric-tree-root
- Commit the VCF configuration.
[edit] user@device# commit
- Log in to the device that is going to be added to the VCF.
- Configure the device into fabric mode. If needed, also
configure the device into mixed mode. Reboot the device to complete
this configuration step.
If you are configuring a non-mixed VCF:
user@device> request virtual-chassis mode fabric local reboot
If you are configuring a mixed-mode VCF:
user@device> request virtual-chassis mode fabric mixed local reboot
Note:If you are adding a device that turns a non-mixed VCF into a mixed VCF, as the next step, you must also log in to the VCF and set all of the devices in the VCF into mixed mode. This step requires a VCF reboot, which incurs some downtime.
Note:We recommend that you set the fabric and mixed mode settings, zeroize (if necessary), and reboot leaf devices before interconnecting them into the 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.
You can, however, use the
request virtual-chassis mode fabric local
orrequest virtual-chassis mode mixed local
commands to recover a device that was not set into fabric or mixed mode before you interconnect it into your VCF. - (Required only if you are adding a device that turns a
non-mixed VCF into a mixed VCF) Log in to the VCF and set all devices
in the VCF to mixed mode, also configuring all devices to reboot to
complete this step.
user@device> request virtual-chassis mode mixed all-members reboot
The VCF experiences downtime during the reboot.
- After the device reboots, interconnect the new device
into the VCF using supported interfaces that
can be VCPs. The interconnecting links are converted
into VCPs automatically.
The new device should be operational shortly after the cabling is complete.
Best Practice:When adding a leaf device to an existing 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.
Adding a Spine or Leaf Device to a Nonprovisioned Virtual Chassis Fabric
Configure your 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.
Nonprovisioned VCF configuration is highly discouraged. Nonprovisioned VCF configuration should only be used by VCF experts in specialized scenarios.
To add a spine or leaf device to a nonprovisioned VCF:
- Log in to your VCF.
- If you are replacing a device that is already part of
the VCF, power off the device in the VCF. Uncable the device once
the power off is complete.
You can skip this step if you are adding a new device without replacing an existing device. You must skip this step if there is no configuration for the device that you are removing from the VCF.
If the device is configured, delete the device from the VCF configuration:
[edit virtual-chassis] user@device# delete member member-id
where member-id is the member ID of the device that you are removing.
- Log in to the device that you are going to add to the VCF.
- Configure the device into fabric mode. If needed, also
configure the device into mixed mode.
Reboot the device to complete this configuration step.
If you are configuring a non-mixed VCF:
user@device> request virtual-chassis mode fabric local reboot
If you are configuring a mixed mode VCF:
user@device> request virtual-chassis mode fabric mixed local reboot
Note:If you are adding a device that turns a non-mixed VCF into a mixed VCF, you must also log in to the VCF and set all of the devices in the VCF into mixed mode.
Log in to the VCF and enter the request virtual-chassis mode mixed all-members reboot command to perform this task.
The VCF reboots and incurs downtime to complete this procedure.
Note:We recommend that you set the fabric and mixed mode settings before you interconnect 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.
You can, however, use the
request virtual-chassis mode fabric local
orrequest virtual-chassis mode mixed local
commands to set a device into fabric or mixed mode after interconnecting your VCF. - (Required only if you are adding a device that turns a
non-mixed VCF into a mixed VCF) Log in to the VCF and set all devices
in the VCF to mixed mode. Configure all devices to reboot to complete
this procedure.
user@device> request virtual-chassis mode mixed all-members reboot
The VCF experiences downtime as part of the reboot procedure.
- After the device reboots, interconnect it into the VCF
using supported interfaces that can be VCPs.
Configure the interconnecting 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 request virtual-chassis vc-port must be configured on the ports at both ends of the link in order for that link to be configured into a VCP.
Best Practice:When adding a leaf device to an existing 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.
- (Optional) Log in to the VCF and set the primary-role
priority of the new device:
[edit virtual-chassis] user@device# set member member-id mastership-priority number
If needed, enter the
show virtual-chassis
command to learn the member ID of the new member device in the VCF.