Today we’ll talk about an alternative to MCLAG from Juniper – Virtual Chassis. With Virtual Chassis, you can control multiple devices as a single device, have multiple Routing Engines in the stack, and use the graceful Routing Engine switchover (GRES) and Nonstop Active Routing (NSR).
My use case is option with two switches, both same model – QFX5100-48S. We will configure – pre-provisioned VC, where the roles of the switches are predefined and fixed.
Before starting configuration of the Virtual chassis, we need a list of serial numbers, you can check it like this:
qfx01> show virtual-chassis
Virtual Chassis ID: a1a4.efda.4891
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Prsnt TA3700000001 qfx5100-48s-6q 128 Master* N VC
Member ID for next new member: 1 (FPC 1)
The virtual-chassis stack can consist of different switch models – this is Mixed mode. In our case, the models are the same, so we need fabric mode.
Before starting the configuration, check the virtual-chassis mode:
qfx01> show virtual-chassis mode
fpc0:
--------------------------------------------------------------------------
Current mode : Virtual Chassis with similar devices
Future mode after reboot : Virtual Chassis with similar devices
If the mode is not the one we need, we should change it:
qfx01>request virtual-chassis mode fabric local reboot
Now we need to define the roles of each switch. I have identical models, so i will use them both as a Routing Engines. This will give the ability to use the GRES / NSR / NSB and the Control-plane redundancy in case one switch fails.
Defining the roles:
#qfx01 config
chassis {
redundancy {
graceful-switchover;
}
}
routing-options {
nonstop-routing;
}
protocols {
layer2-control {
nonstop-bridging;
}
}
virtual-chassis {
preprovisioned;
no-split-detection;
member 0 {
role routing-engine;
serial-number TA3700000001;
}
member 1 {
role routing-engine;
serial-number TA3700000002;
}
}
I must say a few words why no-split-detection is used:
When using split-detection in a two members stack, if one of the switches fails, the rest will go into line-card mode. In this case, no active RE will remain and all FPC ports will be disabled. BEST PRACTICE as recommended by Juniper – disable split-detection when using a stack of two switches. This functionality is needed if there are more than 2 devices in the stack.
Quote from the manual:
“We recommend that you disable split detection for a two-member Virtual Chassis configuration if you think the backup router or switch is more likely to fail than the Virtual Chassis port interfaces to the backup router or switch. Configuring redundant Virtual Chassis ports on different line cards in each member router or switch reduces the likelihood that all Virtual Chassis port interfaces to the backup router or switch can fail.”
Configuring VC ports:
qfx01>request virtual-chassis vc-port set pic-slot 0 port 48
Port conversion initiated, use show virtual-chassis vc-port to verify
qfx01>request virtual-chassis vc-port set pic-slot 0 port 49
Port conversion initiated, use show virtual-chassis vc-port to verify
Checking VC ports:
qfx01> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
0/48 Configured -1 Down 40000
0/49 Configured -1 Down 40000
Configuration of the first switch is done. Now i will repeat all the same on the second switch and see what happened:
qfx01> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID: a1a4.efda.4891
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Prsnt TA3700000001 qfx5100-48s-6q 129 Master* N VC 1 vcp-255/0/48
1 vcp-255/0/49
1 (FPC 1) Prsnt TA3700000002 qfx5100-48s-6q 129 Backup N VC 0 vcp-255/0/48
0 vcp-255/0/49
We got a chassis with a redundant RE, 96 10G ports and 8 40G ports (2 40G ports are used by VC).
To get into the console of the switch, which works as a backup RE, use this command:
qfx01>request session member 1
root@qfx01:BK:1% cli
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{backup:1}
root@qfx01>
Let’s check replication and GRES status :
{backup:1}
root@qfx01>show system switchover
fpc1:
--------------------------------------------------------------------------
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
{backup:1}
root@qfx01>show task replication
Stateful Replication: Enabled
RE mode: Backup
Everything works as it expected, Virtual Chassis is assembled, REs are synchronized.
How do I remove a switch from a Virtual Chassis?
If the switch is operating as the Master RE, then you should switch active RE to the switch that will remains in service.
qfx01> request chassis routing-engine master switch check
# Here should be "Switchover Ready", output
# but on 18.4R2-S5.4 i got just blank line??
qfx01> request chassis routing-engine master switch
Toggle mastership between routing engines ? [yes,no] (no) yes
Power down the switch you are removing from VC. Disconnect all links. You can now delete Virtual-Chassis related configuration of the disconnected switch.
{master:1}
root@qfx01> configure
Entering configuration mode
{master:1}[edit]
root@qfx01# del virtual-chassis member 1
{master:1}[edit]
root@qfx01# commit
configuration check succeeds
commit complete
Remove VC ports:
{master:0}
root@qfx01>request virtual-chassis vc-port delete pic-slot 0 local port 48
Port deletion initiated, use cmd show virtual-chassis vc-port to verify
root@qfx01>request virtual-chassis vc-port delete pic-slot 0 local port 49
Port deletion initiated, use cmd show virtual-chassis vc-port to verify
After that, the switch will be removed from the VC, and VC ports are wiped.