Network Configuration Example

Two-Member QFX Series Virtual Chassis

Upgrade Procedure

Published
2020-01-24
 ii

Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in
the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks
are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publication without notice.

Network Configuration Example Two-Member QFX Series Virtual Chassis Upgrade Procedure
Copyright © 2020 Juniper Networks, Inc. All rights reserved.

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related
limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)
Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement
(“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you
agree to the terms and conditions of that EULA.
 iii

Table of Contents
About the Documentation | v

Documentation and Release Notes | v

Documentation Conventions | v

Documentation Feedback | viii

Requesting Technical Support | viii

Self-Help Online Tools and Resources | ix

Creating a Service Request with JTAC | ix

1 Example: Two-Member QFX Series Virtual Chassis Upgrade

Upgrading Two-Member QFX Series Virtual Chassis | 13

About This Network Configuration Example | 13

Use Case Overview | 13

Technical Overview | 14

Configuration Example | 15

Conclusion | 25
 v

About the Documentation

IN THIS SECTION

Documentation and Release Notes | v

Documentation Conventions | v

Documentation Feedback | viii

Requesting Technical Support | viii

Use this network configuration example to manually upgrade a two-member QFX Series Virtual Chassis.

Documentation and Release Notes

®
To obtain the most current version of all Juniper Networks technical documentation, see the product
documentation page on the Juniper Networks website at https://www.juniper.net/documentation/.

If the information in the latest release notes differs from the information in the documentation, follow the
product Release Notes.

Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts.
These books go beyond the technical documentation to explore the nuances of network architecture,
deployment, and administration. The current list can be viewed at https://www.juniper.net/books.

Documentation Conventions

Table 1 on page vi defines notice icons used in this guide.

 vi

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or instructions.

Caution Indicates a situation that might result in loss of data or hardware

damage.

Warning Alerts you to the risk of personal injury or death.

Laser warning Alerts you to the risk of personal injury from a laser.

Tip Indicates helpful information.

Best practice Alerts you to a recommended use or implementation.

Table 2 on page vi defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Convention Description Examples

Bold text like this Represents text that you type. To enter configuration mode, type
the configure command:

user@host> configure

Fixed-width text like this Represents output that appears on user@host> show chassis alarms
the terminal screen.
No alarms currently active

Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.

• Identifies RFC and Internet draft • Junos OS CLI User Guide

titles. • RFC 1997, BGP Communities
Attribute
 vii

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Italic text like this
Represents variables (options for Configure the machine’s domain
which you substitute a value) in name:
commands or configuration
[edit]
statements.
root@# set system domain-name
domain-name

Text like this Represents names of configuration
statements, commands, files, and
directories; configuration hierarchy
levels; or labels on routing platform
components.
• To configure a stub area, include
the stub statement at the [edit
protocols ospf area area-id]
hierarchy level.
• The console port is labeled
CONSOLE.

< > (angle brackets) Encloses optional keywords or stub <default-metric metric>;
variables.

| (pipe symbol) Indicates a choice between the broadcast | multicast

mutually exclusive keywords or
(string1 | string2 | string3)
variables on either side of the symbol.
The set of choices is often enclosed
in parentheses for clarity.

# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS
same line as the configuration only
statement to which it applies.

[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]

Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
; (semicolon) Identifies a leaf statement at a route default {
configuration hierarchy level. nexthop address;
retain;
}
}
}

GUI Conventions
 viii

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Bold text like this Represents graphical user interface • In the Logical Interfaces box, select
(GUI) items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.

> (bold right angle bracket) Separates levels in a hierarchy of In the configuration editor hierarchy,
menu selections. select Protocols>Ospf.

Documentation Feedback

We encourage you to provide feedback so that we can improve our documentation. You can use either
of the following methods:

• Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the Juniper
Networks TechLibrary site, and do one of the following:

• Click the thumbs-up icon if the information on the page was helpful to you.

• Click the thumbs-down icon if the information on the page was not helpful to you or if you have
suggestions for improvement, and use the pop-up form to provide feedback.

• E-mail—Send your comments to techpubs-comments@juniper.net. Include the document or topic name,

URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC).
If you are a customer with an active Juniper Care or Partner Support Services support contract, or are
 ix

covered under warranty, and need post-sales technical support, you can access our tools and resources
online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User
Guide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Product warranties—For product warranty information, visit https://www.juniper.net/support/warranty/.

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week,
365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called
the Customer Support Center (CSC) that provides you with the following features:

• Find CSC offerings: https://www.juniper.net/customers/support/

• Search for known bugs: https://prsearch.juniper.net/

• Find product documentation: https://www.juniper.net/documentation/

• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/

• Download the latest versions of software and review release notes:

https://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

https://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

https://www.juniper.net/company/communities/

• Create a service request online: https://myjuniper.juniper.net

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:
https://entitlementsearch.juniper.net/entitlementsearch/

Creating a Service Request with JTAC

You can create a service request with JTAC on the Web or by telephone.

• Visit https://myjuniper.juniper.net.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see

https://support.juniper.net/support/requesting-support/.
1 CHAPTER

Example: Two-Member QFX Series

Virtual Chassis Upgrade

Upgrading Two-Member QFX Series Virtual Chassis | 13

 13

Upgrading Two-Member QFX Series Virtual Chassis

IN THIS SECTION

About This Network Configuration Example | 13

Use Case Overview | 13

Technical Overview | 14

Configuration Example | 15

Conclusion | 25

About This Network Configuration Example

This network configuration example (NCE) shows how to upgrade a two-member QFX Series Virtual
Chassis when the nonstop software upgrade (NSSU) process is either not available or undesirable. This
process minimizes service disruption and has minimal impact on data center workloads. The NSSU feature
for the QFX Series is supported between specific releases that can be found in the QFX Series section of
the Junos Release Notes.

SEE ALSO

Understanding QFX Series Virtual Chassis

Upgrading Software on a Virtual Chassis and Mixed Virtual Chassis Using Nonstop Software Upgrade

Use Case Overview

The Virtual Chassis capabilities are important aspects of the QFX Series portfolio. A common Virtual Chassis
use case in data centers is aggregating multiple top-of-rack switches into a single logical entity for simplicity
in management and operations of high-availability pairs. In this use case, racks of servers are multihomed
to two top-of-rack QFX Series switches. The switches are configured into a Virtual Chassis pair and provide
resiliency to the network path if one of the QFX Series devices fails.
 14

When these devices need software updates, you will generally use the NSSU capabilities of the Virtual
Chassis to upgrade the devices. The NSSU upgrade selectively upgrades the Virtual Chassis member devices
in an intelligent order to minimize service disruption to the connected servers.

However, there are certain upgrade scenarios where the “from” release and “to” release do not support
the NSSU upgrade process. When upgrading in these scenarios, we can achieve a similar result through a
series of manual operations. This use case covers the non-NSSU upgrade path between two releases.

Technical Overview

The process to manually upgrade a two-member Virtual Chassis closely mimics the steps taken by the
automated NSSU process. The sequence leverages the high-availability design to systematically remove
one device from service to perform the upgrade and reboot. When the server nodes are dual homed to
each of the devices, the network can withstand the removal of one of the Virtual Chassis members during
the upgrade window. There is a reduction of overall network bandwidth during the process, but the network
remains available.

The Virtual Chassis feature uses a master/backup concept to keep the device state synchronized between
the members of the Virtual Chassis. While one device handles the traffic, we take the other device offline
and upgrade it. To upgrade both devices, we take the following steps:

1. First, we shift all traffic to the master device.

2. Once the backup device is no longer handling server traffic, we break apart the Virtual Chassis.

3. With the backup device completely isolated, we upgrade the software on the backup device and reboot
it. The backup device will keep a copy of the original network configuration.

4. After the upgraded backup comes online, we shift server traffic from the master to the backup device.
Once the backup is handling the network load, we upgrade and reboot the master.

5. After the master comes online, we shift traffic back to the master.

6. Finally, we re-enable the Virtual Chassis links between the two devices to re-create the Virtual Chassis
pair running the new software version.
 15

Configuration Example

IN THIS SECTION

Requirements | 15

Overview | 15

Configuration | 16

This configuration example shows how to upgrade a two-member Virtual Chassis from Junos OS Release
14.1X53-D49.1 to Junos OS Release 18.1R2.6. According to the QFX NSSU supported release matrix, this
is not a supported combination for the NSSU feature, so we will use the manual process outlined below.

This example uses a basic Virtual Chassis configuration, but the process here is adaptable to a number of
different use cases.

Requirements

Use this procedure to upgrade both members of a two-member Virtual Chassis consisting of QFX5100,
QFX5110, QFX5220, or QFX5200 switches to the same Junos OS Release version. We strongly recommend
that both members of the Virtual Chassis are the same platform, like in this example.

Before you begin:

• Make sure the Virtual Chassis is comprised of two members

• Configure one member to be the master Routing Engine and one to be a backup Routing Engine

• Configure the Virtual Chassis in Virtual Chassis mode (that is, not Virtual Chassis Fabric mode)

• Make sure the Virtual Chassis is performing Layer 2 functions only (that is, no IRBs or routing protocols)

This example uses the following hardware and software components:

• Two QFX5100-48S-6Q devices running Junos OS Release 14.1X53-D49.1

• Junos OS Release 18.1R2.6

• Test server running Ubuntu Linux 16.04

Overview

The upgrade between releases requires a specific sequence of steps coordinated among the network
elements to ensure a minimum of downtime during the transition. As indicated in the diagram, the general
 16

procedure will leverage the high availability characteristics of modern servers with redundant connections
to the Virtual Chassis during the transition.

At the start of the upgrade, we begin with a functional two-member Virtual Chassis. Our goal is to upgrade
to a new Junos release with minimum traffic disruption. To achieve this, we will break apart the Virtual
Chassis and upgrade the member devices as standalone units. After the devices have been upgraded, we
will re-connect them and re-establish the Virtual Chassis.

Topology

Configuration

Step-by-Step Procedure
 17

To upgrade the devices:

1. Verify the Virtual Chassis state. Check the parameters of the Virtual Chassis and verify we are working
with a two-member Virtual Chassis that is operational.

{master:0}
user@qfx5100-a> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: 235e.5bda.52ca
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 TA3714120212 qfx5100-48s-6q 129 Master* N Virtual
Chassis 1 Virtual Chassisp-255/0/48
1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual
Chassis 0 Virtual Chassisp-255/0/48

2. Upload the new software to the Virtual Chassis members. Copy the new software to /var/tmp on the
Virtual Chassis master and the Virtual Chassis backup. This step stages software on both switches for
the upgrade procedure. The copy operation will take some time to complete while it transfers the Junos
images.

file copy
http://sspt-tools.juniper.net/volume/download/docroot/software/junos/18.1R2.6/jinstall-host-qfx-5-18.1R2.6-signed.tgz
/var/tmp/

3. Disable split detection so the master Routing Engine will maintain mastership when you disable the
backup Routing Engine. Otherwise, the master device may take on a linecard role and stop the control
and data planes.

user@qfx5100-a# set virtual-chassis no-split-detection

4. Disable server-facing ports on the backup Routing Engine to minimize disruption during switchover.
 18

user@qfx5100-b# wildcard range set interfaces ge-1/0/[0-47] disable

wildcard range set interfaces xe-1/0/[0-47] disable
commit and-quit

5. Disable VCP ports toward the backup Routing Engine. This breaks up the Virtual Chassis.
 19

user@qfx5100-b> request virtual-chassis vc-port delete pic-slot 0 port 48 member 1

request virtual-chassis vc-port delete pic-slot 0 port 48 member 0

6. Upgrade the backup Routing Engine.

{master:1}
user@qfx5100-b> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz reboot
 20

7. Swap the server-facing ports by re-enabling the server-facing ports on the backup and disabling the
server-facing ports on the master. Implement the same configuration on the backup and master devices
to modify any configuration left over from when the two devices were part of the Virtual Chassis.

On the backup QFX:

user@qfx5100-b# wildcard range set interfaces ge-0/0/[0-47] disable

wildcard range set interfaces xe-0/0/[0-47] disable
wildcard range delete interfaces ge-1/0/[0-47] disable
wildcard range delete interfaces xe-1/0/[0-47] disable
commit and-quit

On the master QFX:

user@qfx5100-a# wildcard range set interfaces ge-0/0/[0-47] disable

wildcard range set interfaces xe-0/0/[0-47] disable
wildcard range delete interfaces ge-1/0/[0-47] disable
 21

wildcard range delete interfaces xe-1/0/[0-47] disable

commit and-quit

8. Upgrade the master Routing Engine.

 22

{master:0}
user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz reboot

9. Swap the server facing ports back to the master. Re-enable the server facing ports on the master to
speed up LACP convergence when the Virtual Chassis comes back. Implement the same configuration
on the backup and master devices to modify any configuration left over from when the two devices
were part of the Virtual Chassis.

On the backup QFX:

user@qfx5100-b# wildcard range delete interfaces ge-0/0/[0-47] disable

wildcard range delete interfaces xe-0/0/[0-47] disable
wildcard range set interfaces ge-1/0/[0-47] disable
wildcard range set interfaces xe-1/0/[0-47] disable
commit and-quit

On the master QFX:

user@qfx5100-a# wildcard range delete interfaces ge-0/0/[0-47] disable

wildcard range delete interfaces xe-0/0/[0-47] disable
wildcard range set interfaces ge-1/0/[0-47] disable
 23

wildcard range set interfaces xe-1/0/[0-47] disable

commit and-quit

10. Re-enable the VCP ports on both boxes to re-establish the Virtual Chassis.
 24

user@qfx5100-a> request virtual-chassis vc-port set pic-slot 0 port 48 member 0

request virtual-chassis vc-port set pic-slot 0 port 48 member 1

11. Verify you have re-established the Virtual Chassis.

user@qfx5100-a> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: 235e.5bda.52ca
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 TA3714120212 qfx5100-48s-6q 129 Master* N Virtual
Chassis 1 Virtual Chassisp-255/0/48
1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual
Chassis 0 Virtual Chassisp-255/0/48

12. Enable access ports on both members. Now that the Virtual Chassis has been re-established, we need
to re-establish the access ports so we can use the master Routing Engine em0 address to communicate
with the newly upgraded Virtual Chassis.

On the master QFX:

 25

user@qfx5100-a# wildcard range delete interfaces ge-1/0/[0-47] disable

wildcard range delete interfaces xe-1/0/[0-47] disable
commit and-quit

You have upgraded your two-member Virtual Chassis.

Conclusion

Virtual Chassis is an important architecture design for datacenter high availability. You now know how to
manually upgrade a two-member QFX Series Virtual Chassis with minimal impact to your datacenter
workloads. Use the procedure outlined in this document to upgrade any Virtual Chassis with a similar
topology when NSSU is not available or not desirable.