How to configure Virtual chassis on Juniper QFX5100

By | 24.11.2020

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.

Subscribe
Notify of

0 комментариев
Inline Feedbacks
View all comments