Vcs Nos Upgrade DP

53-1003479-01
September 2014
Brocade VCS Network OS

Upgrade
Deployment Guide
2014, Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the B-wing symbol, Brocade Assurance, ADX, AnyIO, DCX, Fabric OS, FastIron, HyperEdge, ICX, MLX, MyBrocade, NetIron,
OpenScript, VCS, VDX, and Vyatta are registered trademarks, and The Effortless Network and the On-Demand Data Center are trademarks
of Brocade Communications Systems, Inc., in the United States and in other countries. Other brands and product names mentioned may be
trademarks of others.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any
equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document
at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be
currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in
this document may require an export license from the United States government.
The authors and Brocade Communications Systems, Inc. assume no liability or responsibility to any person or entity with respect to the
accuracy of this document or any loss, cost, liability, or damages arising from the information contained herein or the computer programs that
accompany it.
The product described by this document may contain open source software covered by the GNU General Public License or other open
source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to
the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.
Contents
Preface..................................................................................................................................... 5
Chapter 1: Upgrade Planning.................................................................................................... 7
Hardware Requirements................................................................................... 7
NOS Versions................................................................................................... 7
Upgrade Paths and Methods............................................................................ 8
Upgrade Using HA Topology.......................................................................... 11
Chapter 2: Upgrade Procedure Summaries.............................................................................. 13

Preparing for the Upgrade...............................................................................13
In-Service Software Upgrade Overview.......................................................... 15
ISSU Hardware and Version Requirements........................................16
ISSU Features and Limitations........................................................... 16
ISSU Procedure.................................................................................. 16
Upgrading Odd/Even Nodes (Fabric Mode)....................................................18
Upgrading Odd/Even Nodes (Logical Chassis Mode).....................................19
Upgrading One Node at a Time...................................................................... 20
Verifying the Upgrade..................................................................................... 22
Example A: Release 4.1.1 to 5.0.0 (Logical Chassis)................................................................25

Task 1: Prepare for the Upgrade.....................................................................25
Task 2: Perform the Upgrade..........................................................................28
Task 3: Verify the Upgrade............................................................................. 33
Example B: Release 4.0.1 to 4.0.1c (Logical Chassis)..............................................................37

Example C: Release 3.0.1 to 4.0.1 (Fabric Mode).................................................................... 59

Example D: Release 2.11a to 3.01c........................................................................................ 75

Example Topology.......................................................................................... 75
Task 2: Route Traffic Away from the Upgrade Group..................................... 76
Task 3: Isolate the Upgrade Group from the Fabric........................................79
Task 5: Rejoin Upgrade Group to the Fabric.................................................. 86
Task 6: Enable Edge Interfaces In the Upgrade Group.................................. 87
Task 8: Upgrade the Remaining Groups.........................................................90
Brocade VCS Network OS Upgrade Deployment Guide

53-1003479-01

53-1003479-01
Preface
This document is a deployment guide for performing firmware upgrades of Brocade VCS fabrics. It is
written for technology decision-makers, architects, systems engineers, NOC engineers and other
experts responsible for network upgrades and migration.
This document provides step-by-step examples to prepare, perform, and verify a NOS upgrade. Design
considerations and troubleshooting are beyond the scope of this document.
It is assumed that the reader is familiar with establishing console access and entering commands using
the Brocade CLI. For information about the Brocade CLI, refer to the Network OS Administration Guide.
Document History
Date
Version
Description
September 2014
Initial version

53-1003479-01
Preface

53-1003479-01
Chapter 1: Upgrade Planning

Hardware Requirements................................................................................................... 7
NOS Versions................................................................................................................... 7
Upgrade Paths and Methods............................................................................................ 8
Upgrade Using HA Topology.......................................................................................... 11
This chapter summarizes considerations and background information to help you plan your upgrade.
Hardware Requirements
The NOS upgrade procedures described in this document apply to the following Brocade hardware
products:
Brocade VDX 6710-54

Brocade VDX 6720: 6720-24 and 6720-60
Brocade VDX 6730: 6730-32 and 6730-76
Brocade VDX 6740: 6740-48, 6740-64, 6740T, 6740T-48, 6740T-64, and 6740T-1G
Brocade VDX 8770: 8770-4 and 8770-8
NOS Versions
The Brocade Network OS (NOS) is released in different firmware versions that run on Brocade VDX
switches. As shown in Figure 1 , the firmware version is indicated by a series of numbers separated by
periods, with an optional patch release letter appended.
FIGURE 1 Brocade NOS Firmware Version Numbers
The upgrade path and method largely depends on the starting version number and the ending version
number.

53-1003479-01
Upgrade Paths and Methods
Upgrade Paths and Methods

The goal of every upgrade method is to minimize traffic loss during the firmware upgrade. The key
considerations for determining the upgrade method include the following:
Current version loaded on the nodes

Fabric topology
Dual-management module (MM) or single-MM node
End device connectivity
Effect of Version Changes on Configuration

A NOS upgrade without loss of configuration is possible only between the following specific releases:
2.1 to 3.0
3.0 to 4.0
4.0 to 4.1
4.1 to 5.0
A NOS upgrade without loss of configuration is possible only between the following specific releases:
Upgrade from 2.1.1.a to 3.0.1
Upgrade from 3.0.1 to 4.x
Skipping a release requires a disruptive upgrade, requires the configuration to be re-applied.
Rolling back to a previous release (downgrading) is also a disruptive change. It is recommended to to
remove all configuration (using the default-config option) to make sure the running-config does not
contain features from a later release that are not supported by an earlier release.
Upgrade Options
In general, three upgrade options are available:
Coldboot, introduced with Release 4.0.2, which simplifies upgrading dual-MM systems that do not
qualify for ISSU.
ISSU, In-Service Software Upgrade (ISSU) for dual-MM nodes, is a non-disruptive upgrade option
introduced with Release 4.0, for upgrading to a patch or maintenance release within the same major
and minor release. ISSU provides the only upgrade option that is nondisruptive for active FC/FCoE
sessions. FC/FCoE sessions are affected by other upgrade options. Use ISSU for qualifying nodes
in combination with the Procedure for Upgrading Odd/Even Nodes, which is still required for singleMM and other nodes that do not qualify for ISSU.
Manual, using noactivate and nocommit options for staging software to the Secondary partition
before the actual upgrade maintenance window begins.
Default-config, which removes all configuration and is similar to initial installation and
configuration.
Upgrade Paths without Configuration Loss

The following are the recommended upgrade methods, which preserve existing configuration and
minimize the impact of the upgrade on network traffic.

53-1003479-01
Upgrading Odd/Even Nodes. With this upgrade method, nodes are upgraded without prior isolation
of nodes from end devices or VDX fabric nodes and rejoin the fabric automatically after upgrade
completion.
Upgrading one node at a time. With this upgrade method, nodes are isolated from end devices and
other nodes in the fabric during the upgrade and re-added to the VCS after the upgrade is complete.
Table 1 summarizes the upgrade methods and options that preserve the existing configuration for
different starting and ending firmware versions.
NOTE
A single VCS fabric can contain nodes running Release 5 along with VDX 6710, 6720, and 6730 nodes
running 4.1.3.
TABLE 1 Version Changes that Preserve Existing Connfiguration
Starting Version
Ending Version
Recommended Upgrade Method

and Options
5.0.x
4.1.0
Procedure for Upgrading Odd/Even

Nodes (without node isolation) using
coldboot option. The coldboot option
restarts both MMs in any dual-MM
node at the same time (used for nonISSU upgrades).
4.1.x
4.1.0
5.0.0
4.1.x
5.0.x
4.1.x
4.1.0

4.0.x
4.1.x


53-1003479-01

Nodes (without node isolation) with
the coldboot option. The coldboot
option restarts both MMs in any dualMM node at the same time (used for
non-ISSU upgrades).
TABLE 1 Version Changes that Preserve Existing Connfiguration (Continued)

Starting Version
Ending Version
Recommended Upgrade Method

and Options
4.0.x
4.0.y
4.1.0
4.1.x

Nodes (without node isolation)
In-Service Software Upgrade (ISSU)
for qualifying nodes:
Release 4 ISSU hardware

requirements: Chassis-style
switches with redundant
management modules
Release 4 ISSU firmware version

requirements: Starting and ending
versions are part of the same
major and minor release. ISSU is
supported between maintenance
releases or patch releases.
NOTE
Release 4 ISSU firmware version
requirements: Starting and ending
versions are part of the same
major and minor release. ISSU is
supported between maintenance
releases or patch.
3.0.x
4.0.x or
Upgrading Odd/Even Nodes (without

node isolation)
4.1.x
2.0.x or
3.0.x
Upgrading One Node at a Time (with

node isolation)
2.1.x
Upgrade Paths with Configuration Loss

Other version changes are possible, however these changes require the configuration to be re-applied
once the upgrade is completed. To perform these version changes, the running-config should be
copied to a file on a remote server or external USB storage, and then copied back to the runningconfig after the version change is completed. Table 2 lists the option to use for different starting and
ending versions.
TABLE 2 Version Changes Resulting in Loss of Configuration
10
Starting Version
Ending Version
Option Used
5.0.x
4.0.x

default-config option.

53-1003479-01
Upgrade Using HA Topology
TABLE 2 Version Changes Resulting in Loss of Configuration (Continued)

Starting Version
Ending Version
Option Used
4.1.x
4.0.x

default-config option.
4.0.x
5.0.0
Disruptive upgrade using coldboot

option (introduced with 4.0.2).
NOTE
Upgrading to version 5.0.0 without
configuration loss is possible by first
upgrading to 4.1.x.
Upgrade Using HA Topology

A well-designed VCS fabric is designed for high availability (HA). The recommended HA topology helps
minimize traffic disruption during the upgrade process. Figure 2 illustrates an example of an HA
deployment using VDX 8770, 6740, and 6730 nodes.
FIGURE 2 HA Topology Helps Maintain Traffic Forwarding During Upgrade
HA Topology Helps Maintain Traffic Forwarding During Upgrade:

1. Spine nodes connected to core network with vLAGs. In Figure 2 , two spine nodes (RB1 and RB2)
are connected to the core network using a vLAG, which is a port channel that spans multiple nodes.

53-1003479-01
11
From the Core network and from VCS fabric perspective, the spine node vLAG is treated as a
single interface.
2. Dual-homed VDX leaf nodes. Each VDX leaf node (RB3 to RB8) is dual-homed with a minimum of
two inter-switch links (ISLs) to the spine nodes (RB1 and RB2).
3. Edge devices connected with vLAGs. Each end device (Server 1 to 3) has a physical connection to
at least two different leaf nodes. The physical device connections are configured as a LAG from the
device side and vLAG from VCS. In other words, both the server and VCS treat the physical
connections as a single logical interface.
With this type of HA topology, the upgrade process has a minimal impact on traffic forwarding. The
upgrade of ISSU-compatible nodes is non-disruptive for Layer 2 traffic.
NOTE
ISSU will also be non-disruptive for Layer 3 (IP) traffic when upgrading to patch and maintenance
versions of Release 5 within the same minor version.
Figure 3 illustrates how this HA topology maintains connectivity for Server 1 during the simultaneous
upgrade (non-ISSU) of RB1 and RB 3. Note that in in this upgrade, fabric capacity is still reduced, so it
is recommended that the upgrade is assigned to a maintenance window when demands on the fabric
(and configuration changes) are minimized.
FIGURE 3 Server Connectivity During Upgrade with HA Topology
As shown in this example, before the upgrade begins, Server 1 is connected to the fabric via a vLAG
to RB3 and RB4. These nodes are dual homed to the edge aggregation nodes RB1 and RB2. In this
topology, both RB1 and RB3 can be upgraded at the same time because Server 1 still has connectivity
via RB2 and RB4, even when RB1 and RB3 are reloaded as part of the upgrade procedure.
12

53-1003479-01
Chapter 2: Upgrade Procedure Summaries

Preparing for the Upgrade...............................................................................................13
In-Service Software Upgrade Overview.......................................................................... 15
Upgrading Odd/Even Nodes (Fabric Mode)....................................................................18
Upgrading Odd/Even Nodes (Logical Chassis Mode).....................................................19
Upgrading One Node at a Time...................................................................................... 20
Verifying the Upgrade..................................................................................................... 22
This chapter provides summaries of the general procedures required for each upgrade method.
Preparing for the Upgrade

This section summarizes the general procedures for preparing for the upgrade. See the subsequent
chapters in this document for examples of applying these procedures to specific upgrade
examples.Network upgrades are typically performed during allocated fixed duration maintenance
windows. Regardless of the upgrade procedure selected, the following non-disruptive steps are
common to all methods and should be performed prior to the maintenance window.
NOTE
To save time during the upgrade maintenance window, the firmware can also be pre-loaded onto the
Standby partition of single-MM nodes without any effect on traffic forwarding.
To maximize the available time within the maintenance window the following steps can be performed
before the maintenance window begins.
NOTE
As a best practice, the key information gathered in this section should be recorded into a file , such as
an Excel spreadsheet, for quick reference during the upgrade.
Step 1: Download the Firmware
Download the firmware package for your upgrade and uncompress the file using the appropriate utility.
For example, use gunzip on UNIX hosts to uncompress .gz files.
The Brocade website (www.mybrocade.com) lets customers with support service contracts and partners
download any released NOS version.
Starting Version 4.0.: Use the no-activate option with the firmware download command to copy the
new version to the Secondary partition on all nodes (both single-MM and dual-MM) at the same time.
The no-activate option for the firmware download command was introduced in Release 4.0.0.
Starting Version 4.0.2 or later: Use the coldboot option, which causes the switch to reboot after the
download is completed. The coldboot option reboots both MMs in any dual-MM node at the same time
(without ISSU). When using the coldboot option, the download is followed immediately by activation,
and so is not part of the preparation task.

53-1003479-01
13
NOTE
Use the coldboot option carefully because it does not allow backing out the upgrade once the
command is entered.
Starting Version 3: Use the no reboot and no commit options with the firmware download command
to copy the new version to the Secondary partition on single-MM nodes. The following are the
available options:
no reboot: Use the no reboot and no commit options with the firmware download command to copy
the new version to the Secondary partition on single-MM nodes. The following are the available
options.
no commit: [for ToR switches] If this option is not specified, after the new firmware is activated on
the switch it is copied to the Standby partition overwriting the previous version. The no commit
option allows you to revert the firmware to the previous version after an upgrade is completed.
Step 2: Choose the firmware download method
You can copy the firmware to one or more Brocade-branded USB drives or to a network location that
can be accessed by the nodes using FTP, SFTP, or SCP. Copy the uncompressed firmware package
to the appropriate directory, such as an FTP directory on a server accessible by all VDX nodes or to a
directory on the USB drive. The network option is highly recommended for simplicity and the efficiency
of concurrent downloads to all nodes.
Step 3: Verify console access to all nodes, including both active and standby MMs for dual-MM
nodes
Step 4: Copy the running configuration to a USB drive or external server
This should be done again immediately before the upgrade if changes occur before the actual upgrade
occurs.
Step 5: Identify the VCS principal switch and the rbridge ID of each node
Step 6: Verify topology and fabric information
show vcsshow vcs and show fabric all: Verify that all of the required nodes have joined the VCS
and identify the principal switch in the fabric and determine if the fabric is in Fabric Cluster mode or
Logical-chassis mode.
show version: Verify that the same version is committed on all nodes in the fabric (present on both
Primary and Secondary partitions).
show fabric islports: Verify ISL connectivity between fabric nodes and determine if single or multihomed, brocade trunks, or individual interfaces are used.
show port-channel summary: Verify that all port channels have two or more active members and
are vLAGs connected to two or more physical nodes and that the ignore-split option is enabled on
all port channels.
NOTE
Service interruption occurs on port channels (LAGs) if all physical links terminate on a single node for
all upgrade methods, except ISSU.
Step 7: Group the nodes by rbridge ID to minimize network distruption
An HA topology, as shown in Figure 3 on page 12, allows traffic to be forwarded even when one or
more nodes are taken offline for upgrading.
14

53-1003479-01
In-Service Software Upgrade Overview
After confirming ISL connectivity, assign nodes to groups so that no connected edge device becomes
isolated during the upgrade. The upgrade of the principal switch is delayed until the end of the upgrade
process, so it should be included in Group B.
As shown in the illustration, redundant paths interconnect the servers and Core network, so that a path
remains even when some of the nodes are being upgraded. Server 1 has one path that depends on
RB3 and another that depends on RB4. Similarly, RB1 and RB2 both provide paths from the edge
nodes to the Core network. Taking advantage of this redundancy, you can upgrade RB4 and RB2, and
traffic is still forwarded by RB3 and RB1.
FIGURE 4 Node Upgrade Groups
In the example illustrated in Figure 4 , the nodes can be put into the following upgrade groups to help
maintain traffic forwarding during the upgrade:
Group A: Rbridges 1, 3, 5, 7
Group B: Rbridges 2, 4, 6, 8 (Rbridge 6 is the principal switch)
In-Service Software Upgrade Overview

You can use ISSU for upgrading a version of Release 4 to a later maintenance release within the same
major version. For example, ISSU is supported for upgrading from Release 4.0.0 to 4.0.1c. ISSU is not
supported between minor or major releases. For example, upgrading from Release 4.0.1 to 4.1.2 is not
supported for ISSU.
NOTE
Upgrading from Release 4 to Release 5 will not be supported for ISSU because that will be a major
release upgrade.

53-1003479-01
15
ISSU Hardware and Version Requirements
ISSU Hardware and Version Requirements

The switch and NOS version requirements for ISSU are as follows:
Release 4 ISSU hardware requirements: Chassis-style switches with redundant management
modules
Release 4 ISSU firmware version requirements: Starting and ending versions must be within the
same major and minor release. ISSU is supported only between maintenance releases or patch
releases.
NOTE
ISSU is a VDX node upgrade method for qualifying nodes that can be run as part of the Procedure for
Upgrading Odd/Even Nodes.
With NOS Release 4, ISSU is supported only on chassis based systems (8770) with dual MMs.
Support for ISSU on 6740 compact switches is planned for NOS Release 5.
NOTE
ISSU is the only upgrade method that is nondisruptive for active FC/FCoE sessions. FC/FCoE
sessions are impacted when other upgrade methods are used.
ISSU Features and Limitations

ISSU is used automatically by the system for firmware upgrades when hardware and version
requirements are met. ISSU is an advanced firmware upgrade method that is designed to be hitless.
ISSU includes the following characteristics and limitations:
No data path disruption occurs for Layer 2 and FCoE traffic.

All Layer 2 control protocol states are retained.
Topology state and interface state are retained.
Last accepted user configuration is retained.
For Release 4.0.x and 4.1.x, data path and control path disruption occurs for IP (IP configuration is
replayed post failover).
For Release 5 and later no Layer 3 (IP) disruption will occur when upgrading to a later patch or
maintenance release of Release 5).
NOTE
Refer to the release notes for the starting and ending firmware versions to identify the ISSU
functionality and limitation for a specific upgrade.
ISSU Procedure
This section summarizes the general procedures for ISSU, that can be used as part of the Procedure
for Upgrading Odd/Even Nodes that applies for qualifying nodes.
ISSU is node specific and is not dependent on the fabric type. ISSU is supported with both Fabric
Cluster and Logical Chassis modes provided that the hardware and version requirements are met.
16

53-1003479-01
NOTE
Configuration actions are blocked during ISSU upgrade on a given node.
For greater control over the upgrade process, use separate commands for firmware download and
activation, although the entire ISSU can be completed with a single command that handles both
firmware download and activation.
NOTE
As a best practice, a backup copy of the running configuration from all nodes in the fabric should be
made to the onboard local node flash, and to an external device, such as an FTP server or Brocadebranded USB drive.
Task 1: Prepare for the Upgrade

See the Preparing for the Upgrade on page 13 section for detailed instructions.
NOTE
UDLD multiplier must be set to 10 or greater during ISSU upgrade.
Download the firmware:
For NOS versions earlier than 4.0.2: Execute the firmware download with the no-activate option. The
no-activate option downloads the firmware onto the Secondary partition of both Active and Standby
MMs and all line cards in the chassis.
For NOS versions 4.0.2. and later: Use the coldboot option, which activates the firmware after
download and restarts the node. When using the coldboot option, the download and activation are
both included in Task 2: Perform the Upgrade.
NOTE
The console logs confirm when the upgrade is non-disruptive for the nodes that qualify for ISSU.
Task 2: Perform the Upgrade

NOTE
Refer to the release notes for the starting and ending firmware versions to identify the ISSU functionality
and limitation for a specific upgrade.
Step 1: Verify the firmware download.
After downloading the firmware, enter the show version command to confirm that the new firmware
version is present in the Secondary partition of all the nodes to be upgraded and that the same starting
firmware version is present in the Primary partition.
Step 2: Activate the firmware.
Activate the firmware using the firmware activate command.
Although ISSU is non-disruptive to Layer 2 traffic, it is a best practice to include ISSU-eligible nodes in
an upgrade group. Upgrade groups leverage the HA topology to minimize the effect on Layer 3 traffic
when upgrading nodes within Release 4, and in general in case an issue with ISSU occurs
unexpectedly

53-1003479-01
17
Upgrading Odd/Even Nodes (Fabric Mode)
Task 3: Verify the Upgrade with Post-Upgrade checks

See the Verifying the Upgrade on page 22 section.
Upgrading Odd/Even Nodes (Fabric Mode)

This section summarizes the general procedures for the Procedure for Upgrading Odd/Even Nodes
with a fabric in Fabric Cluster mode. See Example C: Release 3.0.1 to 4.0.1 (Fabric Mode) on page
59 for an example of applying these procedures during a specific upgrade.
The high level steps outlined in this section are recommended for upgrading a VCS fabric in Fabric
Cluster mode for the following starting and ending versions:
Starting Release 4 to Ending Release 5
NOTE
Although ISSU is non-disruptive to Layer 2 traffic, it is a best practice to include ISSUeligible nodes in
an upgrade group and think of ISSU as a part of the Procedure for Upgrading Odd/Even Nodes.
Upgrade groups leverage the HA topology to minimize the effect on Layer 3 traffic when upgrading
nodes within Release 4.
See the subsequent chapters in this document for examples of applying the general procedures to
specific upgrade examples.

For NOS versions earlier than 4.0.2: Stage the firmware to the Secondary partition, using the
firmware download command with the no-activate option.
For NOS versions 4.0.2. and later: Use the coldboot option, which activates the firmware after
download and restarts the node. When using the coldboot option, the download and activation are
both included in "Task 2: Perform the Upgrade."

Step 1: Verify the firmware download if the firmware has been staged to the Secondary
partitions (for NOS versions before Release 4.0.2).
NOTE
It is assumed that all server connections are dual or triple-homed to VDX nodes so that connectivity is
maintained when one of the interfaces is brought down during firmware reload and activation.
Starting Version 4.x.x: The downloaded firmware is activated on nodes belonging to the current
upgrade group.
Starting Version 3.x.x: The downloaded firmware on single-MM nodes is activated for the current
upgrade group. For dual MM systems the firmware download command with the default options
includes automatic activation.
18

53-1003479-01
Upgrading Odd/Even Nodes (Logical Chassis Mode)
Single-MM Firmware Activation: Enter the reload command on the rbridges in the current
upgrade group.
Dual-MM Download and Activation: For chassis-based switches with dual MMs that are
part of a fabric cluster, use the default firmware download option because that installs the
firmware on both MMs and all line cards with a single command. Using the no reboot and no
commit options would require entering the commands multiple times.
Step 3: Wait until all nodes reload before proceeding.

As part of firmware activation, the associated nodes reload (with the exception of ISSU).Before
proceeding to the next upgrade group, wait for all nodes to come up and do not proceed until post boot
processing is completed.
Task 3: Verify the Upgrade

Task 4: Upgrade and Verify Nodes in Remaining Upgrade Groups

Repeat Task 2, Step 1 (Activate the firmware) and Task 3 (Verify the Upgrade) for nodes in the
remaining upgrade groups, including the principal switch, which is assigned to the last upgrade group.
Upgrading Odd/Even Nodes (Logical Chassis Mode)

This section summarizes the general tasks and steps in the Procedure for Upgrading Odd/Even Nodes
with a fabric in Logical Chassis mode. See Example B: Release 4.0.1 to 4.0.1c (Logical Chassis) on
page 37 for an example of applying these procedures during a specific upgrade.
The high-level steps outlined in the following section are recommended for use when upgrading a VCS
fabric configured for Logical Chassis mode, starting from Release 4 and ending in Release 4 or Release
5.

Downloading the firmware: For efficiency, the recommendation for this step is to download the new
version to the Standby partition on all nodes (both single MM and dual MM systems) in parallel with the
no-activate option. The no-activate option for the firmware download command was introduced in
Release 4.0.0.
For NOS versions starting with Release 4.0.2, use the coldboot option to download and activate the
firmware in a single step.
NOTE
When upgrading nodes in Logical Chassis mode, you can complete the firmware download for all nodes
with a single command from the principal switch.

53-1003479-01
19
Upgrading One Node at a Time

NOTE
It is very important that while nodes are being upgraded that no configuration changes are made on
any nodes within the fabric because that would create a configuration mismatch when nodes that are
being upgraded attempt to rejoin the fabric.
Step 1: Verify the firmware download.
The downloaded firmware is activated on nodes belonging to the current upgrade group.
NOTE
All server connections are assumed at a minimum to be physically dual homed to VDX nodes such
that connectivity is maintained when one of the interfaces are brought down during reload and
activation of FW on one of the associated VDX nodes.
Step 3: Wait until all nodes reload before proceeding.
As part of firmware activation the associated nodes reload (with the exception of ISSU).Before
proceeding, wait for all nodes to come up after reload and do not proceed until post boot processing is
completed for the nodes that have been upgraded.


Repeat Task 2, Step 3 (Activate the firmware) and Task 3 (Verify the Upgrade) for nodes in the
remaining upgrade groups, including the principal switch, which is assigned to the last upgrade group.
Upgrading One Node at a Time

This section summarizes the general tasks and steps in the procedure for Upgrading One Node at a
Time with a fabric in Fabric Cluster mode. See Example D: Release 2.11a to 3.01c on page 75 for
an example of applying these procedures during a specific upgrade.
Task 1: Prepare for the Upgrade.

Task 2: Route Traffic Away from the Current Upgrade Group

Perform the steps in this task and in Task 3 and 4 for the nodes in the first upgrade group. All steps
are to be repeated for remaining upgrade groups.
Step 1: Administratively disable physical non-ISL interfaces on spine nodes.
This applies to interfaces that connect to external devices for uplink.
20

53-1003479-01
Step 2: Administratively shut down port channels that connect to external devices for uplink.
Step 3: Shut down all non-ISL physical interfaces on all edge nodes within the upgrade group
that connect to edge devices (except for management ethernet).
NOTE
All server connections are physically dual or triple homed to VDX nodes so that connectivity is
maintained when interfaces on one of the VDX nodes are disabled.
After each port is shut down, a log is generated indicating that the interface is administratively down,
that the rbridge has left the port channel, and identifying the rbridges that remain in the port channel.
Step 4: Shut down port channels on all edge nodes within the node group.
After each port channel is shut down, a log is generated indicating that the interface is administratively
down.
Task 3: Isolate the Upgrade Group from the Fabric

Step 1: Shut down ISLs from adjacent edge aggregation nodes to isolate the upgrade group
from the VCS fabric.
NOTE
At this point, Group A forms a separate VCS while the remainder of the VDX nodes remain in the
original VCS.
After the ISLs on the adjacent edge aggregation nodes are shut down as well as the ISL to the fabric
principal switch, the node group becomes completely isolated from the remainder of the fabric.
Step 2: Shut down the ISLs on each of the ToR nodes that connect to edge aggregation nodes.
Shut down the ISLs from ToR nodes within the upgrade group to isolate each node prior to upgrading
the firmware version. This allows for re-joining the fabric sequentially and more gracefully compared to
the entire node group at once.

Step 1: Copy the running configuration on each switch in the upgrade node group to the start
configuration on each node.
Write configuration changes to the startup configuration lets the node come up in isolation so they can
be added back to the fabric when appropriate.
Step 2: Reload each node in the upgrade group to activate the new firmware.
Step 3: Wait for all nodes to come up after reload and wait until post-boot processing is
completed.
Switches are fully up once the logs noted in the example are shown on the console.
Task 5: Re-join the Upgrade Group to the Fabric

Step 1: From an adjacent node that is not part of the upgrade group, enable one ISL to one node
in the upgrade group.
A spine node within the upgrade group is preferable for this step.
Step 2: Enable ISLs sequentially within the upgrade group.

53-1003479-01
21
Verifying the Upgrade
Step 3: Enable remaining disabled ISLs from adjacent nodes to the nodes in the upgrade
group.
At this point, all nodes in the upgrade group should have rejoined the fabric (show fabric all).
Task 6: Enable Edge Interfaces in the Upgrade Group

Step 1: Enable edge-facing interfaces on ToR nodes for the upgrade group.
In this example, the physical (server-facing) interfaces shutdown in task 2 are brought up
administratively.
NOTE
L2 protocol will remain down since the port-channels are still shutdown.
Step 2: Enable port-channels on the ToR nodes for the upgrade group.
Step 3: Enable port channels on edge VCS that connects to the core.


Repeat Task 2-5 for nodes in the remaining upgrade groups, including the principal switch, which is
assigned to the last upgrade group.

This section summarizes the general procedures for verifying the upgrade. See the subsequent
chapters in this document for examples of applying these procedures to specific upgrade examples.
Step 1: Wait until all nodes come up and have completed post-boot processing.
View the console logs carefully and make sure that post-boot processing has completed.
Step 2: Verify fabric and topology.
Enter the show vcs and show fabric all commands to confirm that all of the nodes in the current
upgrade group have joined a new fabric containing the upgraded nodes. The nodes that have been
upgraded will be in a different VCS than those that are not yet upgraded because versions must be the
same to join the same fabric. However, the data plane of the fabric continues to function, even with
mixed versions.
After upgrading the last group, confirm that the new VCS has the same nodes as the original fabric by
comparing the output to the output of the show vcs and show fabric all commands that were entered
before the upgrade.
Step 3: Verify the version in the Primary and Secondary partitions.
Enter the show version command to confirm that the correct firmware version is committed on both
partitions of the upgraded nodes. The output from the show version command should show the new
version in both Primary and Secondary partitions of the upgraded switches.
22

53-1003479-01
Any nodes that have not been upgraded should still show the older firmware in the Primary partition and
the new firmware version in the Secondary partition.
Step 4: Confirm ISL connectivity.
Enter the show fabric islports command and compare the output to the results of entering this command
before the upgrade. After upgrading the last group of nodes, the ISL connectivity should be the same as
before the upgrade.
Step 5: Confirm port channels.
Enter the show port-channel summary command and compare the output to the results of entering this
command before the upgrade. After upgrading the last group of nodes, the port channels should be the
same as before the upgrade.

53-1003479-01
23
24

53-1003479-01
Example A: Release 4.1.1 to 5.0.0 (Logical Chassis)

Task 1: Prepare for the Upgrade.....................................................................................25
Task 2: Perform the Upgrade..........................................................................................28
Task 3: Verify the Upgrade............................................................................................. 33
This example demonstrates using the Procedure for Upgrading Odd/Even Nodes for upgrading a single
pair of nodes in a fabric in Logical Chassis mode.
NOTE
This example is for just two nodes: RB_6740_1 and the principal switch, RB_6740_2. The steps to
identify the upgrade groups for leveraging a HA topology and reducing the effect of the upgrade on
fabric traffic are not shown. For an example of those steps, refer to Example B.

The example in this section demonstrates the procedures for getting ready to upgrade between Release
4.1.1 and 5.0.0 with a fabric in Logical Chassis mode.
NOTE
It is very important that while nodes are being upgraded, no configuration changes are made on any
nodes within the fabric because that would a trigger a configuration mismatch when nodes that are
Step 1: Back up the running configuration.

53-1003479-01
25
NOTE
6740_1# copy running-config ?
Possible completions:
flash://
copy running-config to local flash. path syntax
flash://<filename>
ftp://
copy running-config to FTP server. URL syntax for IPv4
ftp://<username>:<password>@hostname/<filepath>. URL syntax
for IPv6 ftp://<username>:<password>@[hostname]/<filepath>.
scp://
copy running-config to SCP server. URL syntax for IPv4
scp://<username>:<password>@hostname/<filepath>. URL syntax
for IPv6 scp://<username>:<password>@[hostname]/<filepath>.
sftp://
copy running-config to SFTP server. URL syntax for IPv4
sftp://<username>:<password>@hostname/<filepath>. URL
syntax for IPv6
sftp://<username>:<password>@[hostname]/<filepath>.
startup-config
copy from running-config to startup-config
tftp://
copy running-config to TFTP server. URL syntax for IPv4
tftp://@hostname/<filepath>.
usb://
copy running-config to USB. path syntax usb://<filename>
6740_1# copy running-config flash://RB1_CONFIG
2014/09/02-22:28:49, [DCM-1112], 2619, SW/0 | Active, INFO, VDX6740_1, Running
configuration file has been uploaded successfully to flash.
Step 2: Verify the fabric and topology.

Enter the show vcs, and show fabric all commands to confirm that all of the
required nodes are included in the VCS and identify the principal switch in the
fabric.
RB_6740_2# show vcs
Config Mode
: Distributed
VCS Mode
: Logical Chassis
VCS ID
: 1
VCS GUID
: c52ca44e-249f-4d05-89ab-68c0156340e6
Total Number of Nodes
: 2
Rbridge-Id
WWN
Management IP
VCS Status
Fabric
Status
HostName
------------------------------------------------------------------------------------------------------------1
10:00:50:EB:1A:02:DA:18
10.18.125.65
Online
Online
RB_6740_1
2
>10:00:00:27:F8:81:6D:A5*
10.18.125.64
Online
Online
RB_6740_2
In this example, the configuration mode is Distributed, which indicates that the
fabric is in Logical Chassis mode. In this mode, fabric configuration for all nodes
is done from the principal switch.
The fabric principal switch is identified by the > symbol (6740_2).
Step 3: Enter the show version command to identify the firmware version
on Primary and Secondary partitions.
Confirm that the correct version is committed on all nodes in the fabric, that is,
present on both Primary and Secondary partitions. This is a prerequisite before
starting the upgrade.
RB_6740_2# show version rbridge-id all
rbridge-id 1
Network Operating System Software
Network Operating System Version: 4.1.1
Copyright (c) 1995-2014 Brocade Communications Systems, Inc.
26

53-1003479-01
Firmware name:
Build Time:
Install Time:
Kernel:
4.1.1
01:01:46 Mar 20, 2014
18:50:02 Aug 27, 2014
2.6.34.6
BootProm:
Control Processor:
1.0.1
e500mc with 4096 MB of memory
Appl
Primary/Secondary Versions
-----------------------------------------NOS
4.1.1
4.1.1
rbridge-id 2
Firmware name:
4.1.1
Build Time:
01:01:46 Mar 20, 2014
Install Time:
18:23:53 Aug 27, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Appl
-----------------------------------------NOS
4.1.1
4.1.1
In this example, the NOS Firmware version 4.1.1, is installed on both Primary
and Secondary partitions on both MMs and all line cards for Rbridge 1 and 2.
Step 4: Determine network topology and identify upgrade groups.
In a production VCS fabric, you need to manage the ISLs and port groups (LAGs/
vLAGs) to divert traffic away from the group of nodes that are being upgraded
(Group A).
Use the following commands to display the topology so that you can leverage
redundant links and reduce the impact of the upgrade on traffic:
show fabric islports command to identify ISL connectivity - in the example
below there are two 10G links that have formed a 20G ISL trunk between
Rbridge 1 and Rbridge 2
show port-channel summary command to identify port channels. - in the
example below there are three port channels that are vLAGs spanning
Rbridge 1 and Rbridge 2
6740_2# show fabric islports
Name:
6740_2
Type:
131.7
State:
Online
Role:
Fabric Principal
VCS Id:
1
Config Mode:Distributed
Rbridge-id:
2
WWN:
10:00:00:27:f8:81:6d:a5
FCF MAC:
00:27:f8:81:6e:29
Index
Interface
State
Operational State
===================================================================
0
Fo 2/0/49
Down
1
Fo 2/0/50
Down
2
Fo 2/0/51
Down
3
Fo 2/0/52
Down
4
Te 2/0/1
Down
5
Te 2/0/2
Down
6
Te 2/0/3
Up
ISL 10:00:50:eb:1a:02:da:18 "6740_1" (downstream)
(Trunk Primary)
7
Te 2/0/4
Up
ISL (Trunk port, Primary is 2/0/3 )
8
Te 2/0/5
Down
9
Te 2/0/6
Down
.

53-1003479-01
27
6740_2# show port-channel summary

Static Aggregator: Po 23 (vLAG)
Aggregator type: Standard
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Member ports on rbridge-id 1
Te 1/0/23
Te 2/0/23
*
LACP Aggregator: Po 12 (vLAG)
Ignore-split is enabled
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Admin Key: 0012 - Oper Key 0012
Member ports on rbridge-id 1:
Link: Te 1/0/1 (0x118008000) sync: 1
Link: Te 1/0/2 (0x118010001) sync: 0
Link: Te 2/0/1 (0x218008000) sync: 1
Link: Te 2/0/2 (0x218010001) sync: 0

Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Fo 1/0/49 (0x10C0620C0) sync: 1
Link: Fo 1/0/50 (0x10C0640C0) sync: 0
Link: Fo 2/0/49 (0x20C0620C0) sync: 1
Link: Fo 2/0/50 (0x20C0640C0) sync: 0

After completing the preparation, perform the actual upgrade. The example in this section
demonstrates how to upgrade from Release 4.1.1 to 5.0.0 for a fabric in Logical Chassis mode. ISSU
does not apply for upgrading to a new major or minor release.
NOTE
As a best practice, before proceeding, verify that a backup copy of the running configuration has been
made to an external device, such as an FTP server or Brocade-branded USB, as well as on the
internal flash storage.
Step 5: Perform the Upgrade.
This example uses the coldboot option, which is the recommended method for upgrading from version
4.1.x to version 5.0.0. The option applies to both Top of Rack switches and Chassis based switches.
The key difference will be most apparent on chassis based switches as the coldboot option downloads
and activates the new version on both MMs simultaneously , and restarts both MM's at the same
time. . This option preserves configuration but interrupts service on the upgrading nodes. In a
28

53-1003479-01
production network with the recommended HA topology, leverage the redundant nodes and links to
allow traffic to continue forwarding while the nodes in each group are being upgraded.
Before beginning the firmware download, the system performs a sanity test to gauge the impact of the
upgrade based on the current version, the upgrade version, and the configuration of each node. Actual
traffic loss with an HA fabric design (using vLAGs and dual-homed ISLs) is minimal.
The following example shows the command and console logs for upgrading Rbridge 1, entered from the
principal switch (Rbridge 2).
The key information below is as follows:
Coldboot option is given as part of the firmware download command
Sanity result: Disruptive indicating that the upgrade requested will not be performed using ISSU
Confirmation message given stating that firmware download with the coldboot option will trigger a
cold reboot after it has downloaded the firmware
6740_2# firmware download logical-chassis ftp rbridge-id 1 coldboot directory /
buildsjc/sre/SQA/nos/nos5.0.0/nos5.0.0 user releaseuser password releaseuser host
10.31.2.25
Following is the result of the sanity check on the specified nodes.
Rbridge-id
Sanity Result
Current Version
-------------------------------------------------------------1
Disruptive
4.1.1
You are invoking firmware download with the coldboot option. This command will
download the
new firmware to the specified nodes, and cause cold reboot.
Do you want to continue? [y/n]:y
2014/09/02-19:36:14, [SULB-1111], 2213, VCS RID2, WARNING, VDX6740, Logical chassis
firmware download begins on rbridge-id 1.
For each rbridge, a log entry indicates when the firmware copy starts and another entry indicates when
the copy is completed as shown in the console output given below. As described above with the
coldboot option, the switch resets upon firmware download completion and there is an additional log
shown below shortly after the firmware download completes
6740_1# 2014/09/02-20:05:22, [SULB-1111], 2374, VCS RID2, WARNING, VDX6740, Logical
chassis
2014/09/02-20:05:23, [HASM-1120], 2375, VCS RID1, INFO, VDX6740_1, Current version
4.1.1.
2014/09/02-20:05:24, [SULB-1105], 2376, VCS RID1, WARNING, VDX6740_1, Firmware
upgrade
session (0: single MM upgrade) starts.
2014/09/02-20:05:24, [SULB-1100], 2377,, INFO, VDX6740_1, Firmware install begins on
SWITCH/0.
..
6740_1# Finished removing unneeded files.
Tue Sep
2 20:09:14 UTC 2014 - Initializing the Dcmd database...
6740_1# Tue Sep
2 20:09:24 UTC 2014 - Completed intializing the Dcmd database.
..
2014/09/02-20:14:08, [SULB-1101], 2378,, INFO, VDX6740_1, Firmware install ends on

SWITCH/0.
Swap Begin 0
6740_1# Please avoid powering off the system during prom update.
6740_1# Finished writing prom image.
Firmware 5 exit status 0
2014/09/02-20:14:21, [SULB-1100], 2379,, INFO, VDX6740_1, Firmware reboot begins on
SWITCH/0.
Shutting Down Database ...... (New)

53-1003479-01
29
On adjacent switches in the same VCS logs will be generated indicating:

VLAGs have detected a split condition. The example below shows that Rbridge 2 reports that
Rbridge 1 has left vLAGs 12 / 23 / 49.
Associated ISL interfaces have gone down. The example below shows that ISL 2/0/3 and 2/0/4
between Rbridge 2 and Rbridge 1 have gone down.
2014/09/02-19:45:17, [NSM-1002], 2216, DCE, INFO, 6740_2,
TenGigabitEthernet
2/0/3 is protocol down.
2014/09/02-19:45:17, [NSM-1003], 2217, DCE, INFO, 6740_2,
TenGigabitEthernet
2/0/3 is link down.
2014/09/02-19:45:18, [NSM-1002], 2218, DCE, INFO, 6740_2,
TenGigabitEthernet
2014/09/02-19:45:18, [NSM-1003], 2219, DCE, INFO, 6740_2,
TenGigabitEthernet
2/0/4 is link down.
2014/09/02-19:45:18, [FVCS-1003], 2220,, WARNING, 6740_2,
Detected vLAG
- ifindex (2800000c), split RBridge(1).
2014/09/02-19:45:18, [FVCS-1003], 2221,, WARNING, 6740_2,
Detected vLAG
- ifindex (28000017), split RBridge(1).
2014/09/02-19:45:18, [FVCS-1003], 2222,, WARNING, 6740_2,
Detected vLAG
- ifindex (28000031), split RBridge(1).
2014/09/02-19:45:18, [NSM-1025], 2223, DCE, INFO, 6740_2,
Portchannel 49. Port-channel has only RBridge ID 2 and is no
2014/09/02-19:45:18, [NSM-1025], 2224, DCE, INFO, 6740_2,
2014/09/02-19:45:18, [NSM-1025], 2225, DCE, INFO, 6740_2,
Interface
Interface
Interface
Interface
Possible vLAG Split
Possible vLAG Split
Possible vLAG Split
RBridge ID 1 has left
longer a vLAG.
longer a vLAG.
longer a vLAG.
After the upgrade is completed, the upgraded node (rbridge-1) restarts, but is unable to rejoin the VCS
because it is now running a different version and schema mismatch (as shown in error log below)
compared to remaining nodes in the cluster (in this example, the single node Rbridge 2).
The logs below show that even though Rbridge 1 does not rejoin the VCS, the vLAGs spanning
Rbridge 1 and 2 are reformed and the data plane is intact, allowing for upgrade of Rbridge 2.
6740_2# 2014/09/02-19:50:42, [NSM-1003], 2227, DCE, INFO, 6740_2, Interface
TenGigabitEthernet 2/0/4 is link down.
2014/09/02-19:50:42, [NSM-1003], 2228, DCE, INFO, 6740_2, Interface
TenGigabitEthernet
2/0/3 is link down.
TenGigabitEthernet
2/0/3 is online.
TenGigabitEthernet
TenGigabitEthernet
2/0/3 is online.
TenGigabitEthernet
2/0/4 is online.
TenGigabitEthernet
TenGigabitEthernet
2/0/4 is online.
2014/09/02-19:51:02, [NSM-1023], 2235, DCE, INFO, 6740_2, RBridge ID 1 has joined
Portchannel 23. Port-channel is a vLAG with RBridge IDs 2 1.
Portchannel 49. Port-channel is a vLAG with RBridge IDs 2 1.
Port-
30

53-1003479-01
channel 12. Port-channel is a vLAG with RBridge IDs 2 1.

2014/09/02-19:51:37, [VCS-1006], 2238, VCS RID2, ERROR, VDX6740, Event: VCS node
rejoin,
Coordinator IP: 10.18.125.64, VCS ID: 1, Status: rBridge ID 1 (10.115.44.136) failed
to
rejoin VCS cluster, Reason: There is schema mismatch.
The show vcs command shows that Rbridge 1 is offline, which is correct from the viewpoint of the
principal switch, running Release 4.1.1:
RB_6740_2# show vcs
Config Mode
: Distributed
VCS Mode
: Logical Chassis
VCS ID
: 1
VCS GUID
: c52ca44e-249f-4d05-89ab-68c0156340e6
: 2
Rbridge-Id
WWN
Management IP
VCS Status
Fabric
Status
HostName
-----------------------------------------------------------------------------------------------------------1
10:00:50:EB:1A:02:DA:18
10.115.44.136
Offline
Online
sw0
2
>10:00:00:27:F8:81:6D:A5*
10.18.125.64
Online
Online
RB_6740_2
The show fabric all command indicates that both Rbridge 1 and 2 are members of the fabric after the
upgrade on Rbridge 1
RB_6740_2# show fabric all
VCS Id: 1
Config Mode: Distributed
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:50:EB:1A:02:DA:18
10.18.125.65
"RB_6740_1"
2
10:00:00:27:F8:81:6D:A5
10.18.125.64
>"RB_6740_2"*
The Fabric has 2 Rbridge(s)
After upgrading Rbridge-1 to version 5.0.0 using the coldboot option, the key final
logs show tha that the firmware is committed automatically and two logical management
modules are being referenced SW/0 and SW/1 in an HA pair
2014/09/02-20:29:24, [HASM-1100], 2607, SW/0 | Active, INFO, VDX6740_1, HA State is
in sync.
2014/09/02-20:29:24, [LOG-1000], 2608, SW/1 | Standby, INFO, VDX6740_1, Previous
message has repeated 1 times.
2014/09/02-20:29:24, [SULB-1101], 2609, SW/0 | Active, INFO, VDX6740_1, Firmware
reboot ends on SW/1.
commit begins on SW/1.
reboot ends on SW/0.
commit begins on SW/0.
Tue Sep 2 20:29:27 2014: Committing firmware now.
Please wait ...
commit
ends on SW/1.
download
completed successfully on SW/1.
2014/09/02-20:29:41, [SULB-1106], 2615, SW/0 | Active | VCS RID1, WARNING, VDX6740_1,
Firmware upgrade session (0: single-MM commit) completes.
Tue Sep 2 20:30:56 2014: Firmware commit completed successfully.
commit
ends on SW/0.
download
completed successfully on SW/0.
2014/09/02-20:31:00, [SULB-1106], 2618, SW/0 | Active | VCS RID1, WARNING, VDX6740_1,

53-1003479-01
31
The output of the show version command indicates the following:

SW/0 and SW/1 represent two logical management modules on a single 6740 switch.
Four partitions are now present (two partitions each for SW/0 and SW/1).
Version 5.0.0 is installed and committed on all partitions.
6740_1# show ver
Firmware name:
5.0.0
Build Time:
00:16:40 Aug 29, 2014
Install Time:
20:08:59 Sep 2, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------SW/0
NOS
5.0.0
ACTIVE*
5.0.0
SW/1
NOS
5.0.0
STANDBY
5.0.0
Step 6: Upgrade the nodes in Group B, including the principal switch.

This example shows the upgrade for only two nodes. The command for upgrading the principal switch
(Rbridge 2) and the abridged console logs are shown below:
6740_2# firmware download logical-chassis ftp coldboot rbridge-id 2 directory
/buildsjc/sre/SQA/nos/nos5.0.0/nos5.0.0 user releaseuser password releaseuser host
10.31.2.40
2014/09/02-21:49:40, [LOG-1000], 2408,, INFO, VDX6740, Previous message has repeated
2
times.
Following is the result of the sanity check on the specified nodes.
Rbridge-id
Sanity Result
Current Version
-------------------------------------------------------------2
Disruptive
4.1.1
You are invoking firmware download with the coldboot option. This command will
download the
new firmware to the specified nodes, and cause cold reboot.
2014/09/02-21:49:46, [SULB-1111], 2409, VCS RID2, WARNING, VDX6740, Logical chassis
2014/09/02-21:49:48, [HASM-1120], 2410, VCS RID2, INFO, VDX6740, Current version
4.1.1.
2014/09/02-21:49:48, [SULB-1105], 2411, VCS RID2, WARNING, VDX6740, Firmware upgrade
2014/09/02-21:49:48, [SULB-1100], 2412,, INFO, VDX6740, Firmware install begins on
SWITCH/0.
Removing unneeded files, please wait ...
Finished removing unneeded files.
<<. . . snip . . . >>
.
2014/09/02-22:02:06, [LOG-1000], 2429,, INFO, VDX6740, Previous message has repeated

16 times.
2014/09/02-22:02:06, [SULB-1101], 2430,, INFO, VDX6740, Firmware install ends on
SWITCH/0.
Swap Begin 0
Please avoid powering off the system during prom update.
Finished writing prom image.
2014/09/02-22:02:18, [SULB-1100], 2431,, INFO, VDX6740, Firmware reboot begins on
SWITCH/0.
<<. . . snip . . . >>
32

53-1003479-01
2014/09/02-22:14:04, [HASM-1100], 2661, SW/0 | Active, INFO, VDX6740, HA State is in

sync.
2014/09/02-22:14:04, [LOG-1000], 2662, SW/1 | Standby, INFO, VDX6740, Previous
message has repeated 1 times.
2014/09/02-22:14:04, [SULB-1101], 2663, SW/0 | Active, INFO, VDX6740, Firmware reboot
ends on SW/1.
2014/09/02-22:14:04, [SULB-1100], 2664, SW/0 | Active, INFO, VDX6740, Firmware commit
begins on SW/1.
2014/09/02-22:14:05, [SULB-1101], 2665, SW/0 | Active, INFO, VDX6740, Firmware reboot
ends on SW/0.
begins on SW/0.
Tue Sep 2 22:14:07 2014: Committing firmware now.
Please wait ...
ends on SW/1.
2014/09/02-22:14:37, [SULB-1103], 2668, SW/0 | Active, INFO, VDX6740, Firmware
download completed successfully on SW/1.
2014/09/02-22:14:37, [SULB-1106], 2669, SW/0 | Active | VCS RID2, WARNING, VDX6740,
Tue Sep 2 22:16:56 2014: Firmware commit completed successfully.
ends on SW/0.
2014/09/02-22:16:59, [SULB-1103], 2671, SW/0 | Active, INFO, VDX6740, Firmware
download completed successfully on SW/0.
2014/09/02-22:16:59, [SULB-1106], 2672, SW/0 | Active | VCS RID2, WARNING, VDX6740,
Firmware upgrade session (1: single-MM

After the upgrade, perform post-upgrade checks and compare the results to the pre-upgrade checks.
Step 8: Enter the show vcs to verify the fabric status.
Confirm that all of the required nodes have joined the VCS and identify the principal switch in the fabric.
In a production VCS fabric, use the show fabric all command to verify the topology.

53-1003479-01
33
After the upgrade Rbridge 1 is the new principal switch

Both Rbridge 1 and Rbridge 2 are shown as part of the VCS
6740_2# show vcs
Config Mode
: Distributed
VCS Mode
: Logical Chassis
VCS ID
: 1
VCS GUID
: c52ca44e-249f-4d05-89ab-68c0156340e6
: 2
Rbridge-Id
WWN
Management IP
VCS Status
Fabric
Status
HostName
-----------------------------------------------------------------------------------------------------------1
>10:00:50:EB:1A:02:DA:18
10.18.125.65
Online
Online
6740_1
2
10:00:00:27:F8:81:6D:A5*
10.18.125.64
Online
Online
6740_2
The following example shows the output of the show version command after the
upgrade is completed.
The show version command indicates the following:
SW/0 and SW/1 represent two logical management modules on each 6740
switch.
Four partitions are present. There are two partitions (SW/0 and SW/1) on
each 6740 switch.
6740_2# show version rbridge-id all
rbridge-id 1
Firmware name:
5.0.0
Build Time:
00:16:40 Aug 29, 2014
Install Time:
20:08:59 Sep 2, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------SW/0
NOS
5.0.0
ACTIVE*
5.0.0
SW/1
NOS
5.0.0
STANDBY
5.0.0
rbridge-id 2
Firmware name:
5.0.0
Build Time:
00:16:40 Aug 29, 2014
Install Time:
21:54:39 Sep 2, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------SW/0
NOS
5.0.0
ACTIVE*
5.0.0
SW/1
NOS
5.0.0
STANDBY
5.0.0
The show port-channel summary command indicates that all port-channels are
up and vLAGs spanning Rbridge 1 and Rbridge 2 are formed.
6740_2# show port-channel summary
Static Aggregator: Po 23 (vLAG)
34

53-1003479-01
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Te 1/0/23
*
Te 2/0/23
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 1/0/1 (0x118008000) sync: 1
Link: Te 1/0/2 (0x118010001) sync: 0

Link: Te 2/0/1 (0x218008000) sync: 1
Link: Te 2/0/2 (0x218010001) sync: 0
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Fo 1/0/49 (0x10C0620C0) sync: 1
Link: Fo 1/0/50 (0x10C0640C0) sync: 0

Link: Fo 2/0/49 (0x20C0620C0) sync: 1
Link: Fo 2/0/50 (0x20C0640C0) sync: 0
The show fabric islports command indicates that two 10 Gb interfaces have
formed an ISL trunk spanning Rbridge 1 and Rbridge 2.
6740_2# show fabric islports
Name:
6740_2
Type:
131.7
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Config Mode:
Distributed
Rbridge-id:
2
WWN:
10:00:00:27:f8:81:6d:a5
FCF MAC:
00:27:f8:81:6e:2b
Index
Interface
State
Operational State
===================================================================
64
Te 2/0/1
Down
65
Te 2/0/2
Down
66
Te 2/0/3
Up
ISL 10:00:50:eb:1a:02:da:18 "6740_1" (upstream)(Trunk
Primary)
67
Te 2/0/4
Up
ISL (Trunk port, Primary is 2/0/3 )
68
Te 2/0/5
Down
69
Te 2/0/6
Down
70
Te 2/0/7
Down
71
Te 2/0/8
Down
72
Te 2/0/9
Down
73
Te 2/0/10
Down
.

53-1003479-01
35
36

53-1003479-01
Example B: Release 4.0.1 to 4.0.1c (Logical Chassis)

This chapter provides an example of using the Procedure for Upgrading Odd/Even Nodes for upgrading
the nodes in a fabric in Logical Chassis mode. The topology of the VCS fabric used in this example is
illustrated in Figure 4 on page 15.

The example in this section demonstrates the procedures for getting ready to upgrade between Release
4.0.1 and 4.0.1c with a fabric in Logical Chassis mode.
NOTE
It is very important that while nodes are being upgraded, no configuration changes are made on any
nodes within the fabric because that would a trigger a configuration mismatch when nodes that are
In the following upgrade example, a VCS fabric configured as a Logical Chassis is upgraded from
Release 4.0.1 to 4.0.1c. The nodes in this VCS are as follows:
Two aggregation nodes: RB1_8770, RB2_8770
Six edge nodes: RB3_8770, RB4_8770; RB5_6720, RB6_6720; RB7_6740, RB8_6740

53-1003479-01
37
NOTE
RB1_8770# copy running-config ?
flash://
flash://<filename>
ftp://
scp://
sftp://
syntax for IPv6
startup-config
usb://
RB1_8770# copy running-config flash://RB1_8770_Running_Config
2014/05/14-11:57:03, [DCM-1112], 82711, M2 | Active, INFO, VDX8770-8, Running
configuration
file has been uploaded successfully to flash.
RB1_8770#
Step 2: Verify the fabric and topology.

Enter the show vcs and show fabric all commands to confirm that all of the
required nodes have joined the VCS and identify the principal switch in the
fabric.
RB1_8770# show vcs
Config Mode
: Distributed
VCS ID
: 1
VCS GUID
: 11a1ad9b-0d8f-4766-b7fe-dbde2e7fb510
: 8
Rbridge-Id
WWN
Management IP
Status
HostName
---------------------------------------------------------------------------------------1
>10:00:00:27:F8:A1:E7:D8*
10.18.125.112
Online
RB1_8770
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
Online
RB2_8770
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
Online
RB3_8770
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
Online
RB4_8770
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
Online
RB5_6720
6
10:00:00:05:33:5E:F7:83
10.18.124.106
Online
RB6_6720
7
10:00:00:27:F8:DD:0D:E8
10.17.1.42
Online
RB7_6740
8
10:00:00:27:F8:DC:FD:9B
10.17.1.45
Online
RB8_6740
In this example, the configuration mode is Distributed, which indicates that the
fabric is in Logical Chassis mode. In this mode, fabric configuration for all nodes
is done from the principal switch.
The output shows a total of eight nodes in the fabric, with the fabric principal
switch identified by the > symbol (RB1_8770).
The following is the output from the show fabric all command.
RB1_8770# show fabric all
VCS Id: 1
38

53-1003479-01
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:A1:E7:D8
10.18.125.112
>"RB1_8770"*
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
"RB2_8770"
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
"RB3_8770"
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
"RB4_8770"
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
"RB5_6720"
6
10:00:00:05:33:5E:F7:83
10.18.124.106
"RB6_6720"
7
10:00:00:27:F8:DD:0D:E8
10.17.1.42
"RB7_6740"
8
10:00:00:27:F8:DC:FD:9B
10.17.1.45
"RB8_6740"
Step 3 Enter the show version command to identify the firmware version on
Primary and Secondary partitions.
Confirm that the correct version is committed on all nodes in the fabric, that is,
present on both Primary and Secondary partitions. This is a prerequisite before
starting the upgrade.
RB1_8770# show version
Firmware name:
4.0.1
Build Time:
10:37:32 Oct 25, 2013
Install Time:
14:10:01 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1
ACTIVE*
4.0.1
M2
NOS
4.0.1
STANDBY
4.0.1
L1
NOS
4.0.1
4.0.1
L2
NOS
4.0.1
4.0.1
L3
NOS
4.0.1
4.0.1
L5
NOS
4.0.1
4.0.1
L6
NOS
4.0.1
4.0.1
In this example, the NOS Firmware version 4.0.1, is installed on both Primary
and Secondary partitions on both MMs and all line cards for Rbridge 1.
NOTE
: The show version rbridge-id all command can be used to show the version on
all nodes in a fabric in Logical Chassis mode.
Step 4: Enter the show fabric islports command to confirm ISL
connectivity.
Confirm ISL connectivity between nodes in the fabric (using single or multihomed, brocade trunks, or individual interfaces).
RB1_8770# show fabric islports
Name:
RB1_8770
Type:
1001.0
State:
Online
Role:
Fabric Principal
VCS Id:
1
Rbridge-id: 1
WWN:
10:00:00:27:f8:a1:e7:d8
FCF MAC:
00:27:f8:a1:e7:d8

53-1003479-01
39
Index
Interface
State
Operational State
===================================================================
0
Te 1/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720"
(Trunk Primary)
1
Te 1/1/2
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720"
(Trunk Primary)
2
Te 1/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770"
(Trunk Primary)
3
Te 1/1/4
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770"
(Trunk Primary)
4
Te 1/1/5
Up
ISL 10:00:00:27:f8:dd:0d:e8 "RB7_6740"
(Trunk Primary)
5
Te 1/1/6
Up
ISL 10:00:00:27:f8:dc:fd:9b "RB8_6740"
(Trunk Primary)
(downstream)
(downstream)
(downstream)
(downstream)
(downstream)
(downstream)
The output example show the following:

RB1_8770 has a 10-Gb ISLs to each of the six edge VDX nodes (RB3_8770,
RB4_8770, RB5_6720, RB6_6720, RB7_6740, RB8_6740).
RB2_8770 has a 10-Gb ISL to each of the six edge VDX nodes (RB3_8770,
RB4_8770, RB5_6720, RB6_6720, RB7_6740, RB8_6740).
All edge nodes in the fabric are dual homed to RB1_8770 and RB2_8770.
The following output is from the show fabric islports command issued on
RB2_8770:
Name:
RB2_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 2
WWN:
10:00:00:27:f8:a5:6d:54
FCF MAC:
00:27:f8:a5:6d:54
Index
Interface
State
Operational State
===================================================================
.
12
Te 2/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720"
(Trunk Primary)
13
Te 2/1/2
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720"
(Trunk Primary)
14
Te 2/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770"
(Trunk Primary)
15
Te 2/1/4
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770"
Primary)
16
Te 2/1/5
Up
ISL 10:00:00:27:f8:dd:0d:e8 "RB7_6740"
(Trunk Primary)
17
Te 2/1/6
Up
ISL 10:00:00:27:f8:dc:fd:9b "RB8_6740"
Primary)
(downstream)
(upstream)
(downstream)
(Trunk
(downstream)
(Trunk
Step 5: Enter the show port-channel summary command to confirm port

channels.
Confirm that all port channels have two or more active members and are vLAGs
(spanning two or more physical nodes).
RB1_8770# show port-channel summary
Member rbridges:
rbridge-id: 5 (1)
rbridge-id: 6 (1)
Link: Te 5/0/3 (0x518018002) sync: 1
Link: Te 6/0/3 (0x618018002) sync: 1
Transmits BUM traffic
<- Indicates Primary LAG member:
40

53-1003479-01

Member rbridges:
rbridge-id: 3 (1)
rbridge-id: 4 (1)
Link: Te 3/2/3 (0x318818003) sync: 1
Link: Te 4/2/3 (0x418818003) sync: 1

Member rbridges:
rbridge-id: 7 (1)
rbridge-id: 8 (1)
Link: Te 7/0/3 (0x718018002) sync: 1
Link: Te 8/0/3 (0x818018002) sync: 1

Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 1/2/1 (0x118808001) sync: 1

Link: Te 2/2/1 (0x218808001) sync: 1
The example shows the following vLAG configuration:
vLAG 91 has one 10-Gb member from RB5_6720 and one from RB6_6720.
NOTE
Service interruption occurs on port channels (LAGs) that have all physical links
terminated on a single node (with the exception of ISSU) while the associated
node is being activated (reload, configuration replay, and so forth).
Step 6: Divide the nodes in the fabric into upgrade groups to minimize
traffic disruption.
FIGURE 5 Upgrade Groups for Example B

53-1003479-01
41
In the example shown in Figure 5 , the following groups can be used to take
advantage of the HA topology:
Upgrade Group A includes the following nodes: Rbridge 2, 4, 6, 8
Upgrade Group B includes the following nodes: Rbridge 3, 5, 7, 1 (Rbridge 1
is principal switch)

After completing the preparation, perform the actual upgrade. The example in this section
demonstrates how to upgrade from Release 4.0.1 to 4.0.1c for a fabric in Logical Chassis mode.
This example is for a patch release for single-MM and compact switches, but a similar procedure is
used for upgrading between any maintenance releases or patch releases within Release 4 with
switches that do not qualify for ISSU. A similar procedure is also used for minor releases within
Release 4, such as from Release 4.0 to 4.1, for which ISSU is not supported.
NOTE
As a best practice, before proceeding, verify that a backup copy of the running configuration has been
made to an external device, such as an FTP server or Brocade-branded USB, as well as on the
internal flash storage.
Step 1: Download the firmware.
In this example, the firmware is downloaded to the Secondary partition on all nodes in the fabric
through FTP, but is not activated after download. In this example, when prompted to activate firmware
on all nodes after download, the response given is "N." As a result, this step is non-disruptive because
the firmware is not yet activated.
Before beginning the firmware download, the system performs a sanity test to gauge the impact of the
upgrade based on the current version, the upgrade version, and the configuration of each node. In this
example, the upgrade of RB1_8770 and RB4_8770 is performed by ISSU and is non-disruptive for
Layer 2 traffic.
The remaining rbridges are either single-MM or compact switches and minor Layer 2 disruption is
expected during activation and reload of the new firmware version. Actual traffic loss with an HA fabric
42

53-1003479-01
design (using vLAGs and dual-homed ISLs) during the reload of single-MM or compact switches is
minimal.
RB1_8770# firmware download interactive
Do you want to download to multiple nodes in the cluster? [y/n]: y
Server name or IP address: 10.31.2.25
File name: /buildsjc/sre/SQA/nos/nos4.0.1/nos4.0.1c
Protocol (ftp, scp, sftp): ftp
User: Releaseuser
Password: ***********
Enter 'all' for all nodes or range of rbridgeIds: all
Activate firmware on all nodes afterdownload? [y/n]:n <Following is the result of the sanity check on the specified nodes.
Rbridge-id
Sanity Result
Current Version
-------------------------------------------------------------8
Disruptive
4.0.1
7
Disruptive
4.0.1
3
Disruptive
4.0.1
4
Non-disruptive(ISSU)
4.0.1
6
Disruptive
4.0.1
2
Disruptive
4.0.1
5
Disruptive
4.0.1
1
Non-disruptive(ISSU)
4.0.1
This command will download firmware to the nodes. Please run "firmware activate"
after the
completion of installation.
For each rbridge, a log entry indicates when the firmware copy starts and another
entry indicates when the copy is completed.
In this example, the sanity check indicates firmware compatibility and success of
the download request and completion for all nodes. The sanity check indicates a
non-disruptive ISSU for Rbridges 1 and 4 and a disruptive upgrade for all other
nodes in the VCS because these are not dual-MM systems.
Console logs from the firmware download command are shown below. These
key logs are highlighted in yellow for reference on Rbridge 8 (single-MM
upgrade) and Rbridge 1 (ISSU dual-MM upgrade).
4.0.1.
4.0.1.
2014/05/14-15:49:49, [HASM-1120], 83875, M1 | Active | VCS RID3, INFO, VDX8770-4,
Current
version 4.0.1.
2014/05/14-15:49:50, [SULB-1105], 83876, M1 | Active | VCS RID3, WARNING, VDX8770-4,
Firmware upgrade session (0: single MM upgrade) starts.
Current
version 4.0.1.
Logical chassis firmware download begins on rbridge-id 8, 7, 3, 4, 6, 2, 5, 1.
Firmware upgrade session (0: ISSU firmware upgrade) starts.
2014/05/14-15:50:35, [HASM-1120], 83880, VCS RID5, INFO, chassis, Current version
4.0.1.
2014/05/14-15:50:35, [SULB-1105], 83881, VCS RID5, WARNING, chassis, Firmware upgrade
Current
version 4.0.1.
Firmware upgrade session (0: single MM upgrade) starts.
2014/05/14-15:50:39, [HASM-1120], 83884, VCS RID6, INFO, VDX6720-60, Current version
4.0.1.

53-1003479-01
43
2014/05/14-15:50:39, [SULB-1105], 83885, VCS RID6, WARNING, VDX6720-60, Firmware

upgrade
Current
version 4.0.1.
Firmware upgrade session (0: ISSU firmware upgrade) starts.
2014/05/14-15:50:42, [SULB-1100], 83888, M1 | Active, INFO, VDX8770-8, Firmware
install
begins on M2.
2014/05/14-15:52:26, [SULB-1110], 83889, VCS RID8, WARNING, VDX6740, Firmware
upgrade
session (0: single MM upgrade) has completed the installation successfully.
2014/05/14-15:52:27, [SULB-1114], 83890, VCS RID8, INFO, VDX6740, Firmware
installation has completed successfully on rbridge-id 8. Please run 'firmware
activate' for firmware
activation.
.
2014/05/14-15:52:43, [SULB-1110], 83892, VCS RID7, WARNING, VDX6740, Firmware
upgrade
2014/05/14-15:52:44, [SULB-1114], 83893, VCS RID7, INFO, VDX6740, Firmware
installation has
completed successfully on rbridge-id 7. Please run 'firmware activate' for firmware
activation.
Logical chassis firmware download has completed installation on rbridge-id 7.
Firmware upgrade session (0: single MM upgrade) has completed the installation
successfully.
2014/05/14-15:53:18, [SULB-1114], 83896, M1 | Active | VCS RID3, INFO, VDX8770-4,
Firmware
activate' for
firmware activation.
Firmware upgrade session (0: ISSU firmware upgrade) has completed the installation
successfully.
Firmware
activate' for
Firmware upgrade session (0: single MM upgrade) has completed the installation
successfully.
Firmware
activate' for firmware activation.
install
ends on M2.
install
begins on M1.
install
begins on L1/1.
install
begins on L2/1.
install
begins on L3/1.
install
begins on L5/1.
install
44

53-1003479-01
begins on L6/1.
install
begins on L1/0.
install
begins on L2/0.
install
begins on L3/0.
install
begins on L5/0.
install
begins on L6/0.
2014/05/14-16:00:26, [SULB-1110], 83916, VCS RID5, WARNING, chassis, Firmware upgrade
2014/05/14-16:00:27, [SULB-1114], 83917, VCS RID5, INFO, chassis, Firmware
installation has
completed successfully on rbridge-id 5. Please run 'firmware activate' for firmware
activation.
2014/05/14-16:00:42, [SULB-1110], 83919, VCS RID6, WARNING, VDX6720-60, Firmware
upgrade session (0: single MM upgrade) has completed the installation successfully.
2014/05/14-16:00:44, [SULB-1114], 83920, VCS RID6, INFO, VDX6720-60, Firmware
activate' for firmware activation.
install
ends on L1/1.
install
ends on L5/1.
install
ends on L6/1.
install
ends on L1/0.
install
ends on L2/1.
install
ends on L6/0.
install
ends on L2/0.
install
ends on L5/0.
install
ends on L3/1.
install
ends on L3/0.
Wed May 14 23:02:19 UTC 2014 - Initializing the Dcmd and Ccmd database...
Wed May 14 23:02:45 UTC 2014 - Completed intializing the Dcmd and Ccmd database.
install
ends on M1.
Firmware upgrade session (0: ISSU firmware upgrade) has completed the installation
successfully.
Firmware
activate' for

53-1003479-01
45

Downloading firmware to all nodes completed. You can use "show
firmwaredownloadstatus
summary" to get the complete log or use "firmware activate" to activate the firmware.
Step 2: Verify the download.

Upon completion, the success of the firmware download can be verified by
entering the show firmwaredownloadstatus logical-chassis summary command.
The following example shows the output.
RB1_8770# show firmwaredownloadstatus logical-chassis summary
1. Wed May 14 15:48:47 2014
[rbridge-id 1] : Status of Sanity request to the node 6 : Success.
2. Wed May 14 15:48:47 2014
3. Wed May 14 15:48:47 2014
4. Wed May 14 15:48:47 2014
5. Wed May 14 15:48:48 2014
6. Wed May 14 15:48:48 2014
7. Wed May 14 15:48:48 2014
8. Wed May 14 15:48:48 2014
9. Wed May 14 15:48:49 2014
[rbridge-id 1] : Status of Sanity reply from the node 8 : disruptive.
10. Wed May 14 15:48:50 2014
11. Wed May 14 15:48:50 2014
12. Wed May 14 15:48:51 2014
[rbridge-id 1] : Status of Sanity reply from the node 4 : uses ISSU protocol, nondisruptive.
13. Wed May 14 15:49:35 2014
14. Wed May 14 15:49:35 2014
15. Wed May 14 15:49:39 2014
16. Wed May 14 15:49:40 2014
[rbridge-id 1] : Status of Sanity reply from the node 1 : uses ISSU protocol, nondisruptive.
17. Wed May 14 15:49:47 2014
[rbridge-id 1] : Status of Install request to the node 8 : Success.
18. Wed May 14 15:49:47 2014
19. Wed May 14 15:49:47 2014
20. Wed May 14 15:49:48 2014
21. Wed May 14 15:49:48 2014
22. Wed May 14 15:49:48 2014
23. Wed May 14 15:49:49 2014
24. Wed May 14 15:49:50 2014
25. Wed May 14 15:52:27 2014
[rbridge-id 1] : Status of Install reply from the node 8 : Success.
26. Wed May 14 15:52:46 2014
27. Wed May 14 15:53:19 2014
28. Wed May 14 15:56:19 2014
29. Wed May 14 15:59:48 2014
30. Wed May 14 16:00:29 2014
31. Wed May 14 16:00:52 2014
46

53-1003479-01
32. Wed May 14 16:03:03 2014

Firmware installation has completed successfully on rbridge-id 1. Please run
'firmware activate' for firmware activation.
Downloading firmware to all nodes completed.
The output of the command indicated the following for each node:
The result of the sanity check request, which determines firmware
compatability and the nature of the upgrade (disruptive or non-disruptive). The
example indicates success for all nodes.
The sanity check reply from each node (disruptive or non-disruptive). The
example indicates non-disruptive ISSU for Rbridges 1, 4 and disruptive
upgrade for all other nodes in the VCS because these are not dual MM
systems.
The status of the firmware installation request. Success indicates that each
node received the request to download the new firmware. The example
indicates success for all nodes.
The result of the firmware download request. Success indicates that each
node has successfully downloaded the requested firmware. The example
indicates success for all nodes and is highlighted in yellow.
NOTE
Before proceeding to the next step in the firmware upgrade, the firmware
download must be successful on all nodes and any issues indicated should be
resolved.
Step 3: Activate the new firmware for all of the nodes in upgrade Group A
simultaneously.
This example divides the fabric into the following three groups to minimize traffic
disruption:
Upgrade group A includes the following nodes: Rbridge 2, 4, 6, 8
Upgrade group B includes the following nodes: Rbridge 3, 5, 7, 1 (Rbridge 1 is
principal switch)
To activate the downloaded firmware on the nodes in a given upgrade group, use
the firmware activate command on the principal switch, followed by the specific
rbridge IDs belonging to the current upgrade group. Nodes in upgrade Group A
(Rbridges 2, 4, 6, 8) have their firmware activated from the principal switch.
RB1_8770# firmware activate rbridge-id 2,4,6,8
This command
rbridge-id 2
rbridge-id 4
rbridge-id 6
rbridge-id 8
will activate the firmware on the following nodes.

: disruptive.
: uses ISSU protocol, non-disruptive.
: disruptive.
: disruptive.
NOTE
While the nodes in a given upgrade group are reloading, no configuration
changes should be made on the cluster until the reloaded nodes have recovered.
Before a node can rejoin a logical-chassis cluster, its configuration database
must be an exact match. Changes made from the principal switch while a

53-1003479-01
47
member node is reloading would create a configuration mismatch and the

reloaded node would fail to rejoin the cluster.
The following example shows the logs from RB1_8770:
2014/05/14-16:06:07, [NSM-1002], 83936, M1 | Active | DCE, INFO, RB1_8770,
Interface
TenGigabitEthernet 1/1/6 is protocol down.
Interface
2014/05/14-16:06:20, [FVCS-1003], 83938, M1 | Active, WARNING, RB1_8770, Possible
vLAG
Split Detected vLAG - ifindex (28000064), split RBridge(2).
2014/05/14-16:06:20, [NSM-1025], 83939, M1 | Active | DCE, INFO, RB1_8770, RBridge
ID 2
has left Port-channel 100. Port-channel has only RBridge ID 1 and is no longer a
vLAG.
RB1_8770# 2014/05/14-16:06:39, [NSM-1002], 83940, M1 | Active | DCE, INFO,
RB1_8770,
Interface TenGigabitEthernet 1/1/2 is protocol down.
Interface
2014/05/14-16:07:09, [VCS-1009], 83942, M1 | Active | VCS RID1, INFO, VDX8770-8,
Event: VCS
node disconnect, Coordinator IP: 10.18.125.54, VCS ID: 1, Status: rBridge ID 2
(10.18.125.51) disconnected from VCS cluster.
Event: VCS
(10.17.1.45)
disconnected from VCS cluster.
Event: VCS
(10.18.124.106) disconnected from VCS cluster.
Interface
Interface
TenGigabitEthernet 1/1/6 is online.
Interface
Interface
Event: VCS
(10.17.1.27)
disconnected from VCS cluster.
Interface
Interface
Interface
Interface
2014/05/14-16:19:50, [NSM-1023], 83954, M1 | Active | DCE, INFO, RB1_8770, RBridge
ID 2
has joined Port-channel 100. Port-channel is a vLAG with RBridge IDs 1 2.
When RB2_8770 (a single-MM system) is being reloaded and activated, portchannel 100 (spanning RB1_8770 and RB2_8770), changes from a vLAG to a
LAG with a single member remaining in service on RB1_8770. At that time,
48

53-1003479-01
ingress and egress traffic is through RB1_8770. After RB2_8770 comes back up,
an additional log is generated indicating that the vLAG has been reformed.
Logs also indicate when the nodes in upgrade Group A (Rbridges 2, 4, 6, 8) have
disconnected from the VCS cluster. However, no log indicates that they have
rejoined the VCS cluster because the firmware version on upgrade Group A is
4.0.1c after activation, but the remaining nodes are running version 4.0.1.
NOTE
Nodes must be running the same firmware version to join the fabric, but they can
still forward traffic even when versions do not match.

The following highlighted log entries for single-MM (RB2_8770) and dual-MM (RB4_8770) nodes
indicate the following:

53-1003479-01
49
Post-boot configuration replay is completed.

Firmware upgrade is completed.
2014/05/14-16:20:25, [SEC-1197], 96470, M1 | Active, INFO, VDX8770-8, Changed
account
admin.
2014/05/14-16:20:25, [HASM-1110], 96471, M1 | Active, INFO, VDX8770-8, Configuration
replay
has completed on the system.
account user.
account
admin.
account user.
commit fpga image LC_SYS
commit fpga image MM_SYS
commit fpga image SFM_SYS
Wed May 14 16:20:29 2014: Committing firmware now.
..
.
Wed May 14 16:22:04 2014: Firmware commit completed successfully.
recover
ends on M1.
download
completed successfully on M1.
Firmware upgrade session (5: single-MM repair) completes.
The following example shows the log entries for RB4_8770, a dual-MM node:
replay
.
Wed May 14 16:18:06 2014: Committing firmware now.
Please wait ...
Interface
Interface
Interface
Interface
Wed May 14 16:19:55 2014: Firmware commit completed successfully.
commit ends
on M1.
commit ends on M2.
download completed successfully
on M2.
download
completed successfully on M1.
Firmware upgrade session (0: dual-MM
upgrade continue) completes.
After the upgrade, perform post-upgrade checks and compare the results to the
pre-upgrade checks.
Step 2: Enter the show vcs command and show fabric all commands to
verify fabric and topology.
50

53-1003479-01
Confirm that all of the required nodes have joined the VCS and identify the
principal switch in the fabric. The following example shows eight nodes are
configured in the VCS, with four online and four offline.
RB1_8770# show vcs
Config Mode
: Distributed
VCS ID
: 1
VCS GUID
: 8
Rbridge-Id
WWN
Management IP
Status
HostName
---------------------------------------------------------------------------------------1
>10:00:00:27:F8:A1:E7:D8*
10.18.125.112
Online
RB1_8770
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
Offline
RB2_8770
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
Online
RB3_8770
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
Offline
RB4_8770
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
Online
RB5_6720
6
10:00:00:05:33:5E:F7:83
10.18.124.106
Offline
RB6_6720
7
10:00:00:27:F8:DD:0D:E8
10.17.1.42
Online
RB7_6740
8
10:00:00:27:F8:DC:FD:9B
10.17.1.45
Offline
RB8_6740
The following is the output from the show fabric all command.
VCS Id: 1
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:A1:E7:D8
10.18.125.112
>"RB1_8770"*
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
"RB2_8770"
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
"RB3_8770"
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
"RB4_8770"
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
"RB5_6720"
6
10:00:00:05:33:5E:F7:83
10.18.124.106
"RB6_6720"
7
10:00:00:27:F8:DD:0D:E8
10.17.1.42
"RB7_6740"
8
10:00:00:27:F8:DC:FD:9B
10.17.1.45
"RB8_6740"
This example shows the following:

Configuration mode is Distributed indicating that the cluster is in Logical
Chassis mode, with configuration controlled by the principal switch.
Show VCS only shows that there are eight nodes configured in the VCS, with
four online and four offline. Upgrade Group A (nodes 2, 4, 6, 8) show as offline
because they are running version 4.0.1c while nodes 1, 3, 5, 7 are running
version 4.0.1.
NOTE
The fabric data plane continues to function with mixed versions; no sustained
traffic loss is expected due to the current state of the fabric.
A total of eight nodes are in the fabric are indicated by the show fabric all
output.
The fabric principal switch is identified by the > symbol, (RB1_8770, as seen
from both the show vcs and show fabric all commands).

53-1003479-01
51
The following example shows the output of the show version command after the
upgrade of the Group A nodes is completed.
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:58:44 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
ACTIVE*
4.0.1c
L1
NOS
4.0.1c
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L3
NOS
4.0.1c
4.0.1c
L5
NOS
4.0.1c
4.0.1c
L6
NOS
4.0.1c
4.0.1c
For each of the nodes in upgrade Group A, the firmware version is now 4.0.1c.
The 4.0.1c version has been committed on all nodes and is therefore present
on both Primary and Secondary partitions.
The following shows the output from the show version command on RB4:
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:52:28 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
ACTIVE*
4.0.1c
M2
NOS
4.0.1c
STANDBY
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L4
NOS
4.0.1c
4.0.1c
Firmware name:
4.0.1c
Build Time:
10:34:32 Apr 3, 2014
Install Time:
15:58:04 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
2.2.0
e500v2 with 2048 MB of memory
Appl
------------------------------------------
52

53-1003479-01
NOS
4.0.1c
4.0.1c
Firmware name:
4.0.1c
Build Time:
17:38:55 Apr 3, 2014
Install Time:
22:51:35 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Appl
-----------------------------------------NOS
4.0.1c
4.0.1c
Step 3: Enter the show version rbridge all command for nodes in Group B.
After the upgrade of Group A, (2, 4, 6, 8), the show version rbridge all command
indicates the version information for the nodes remaining in the VCS: upgrade
Group B (3, 5, 7. 1). The following example shows the output.
RB1_8770# show version rbridge all
rbridge-id 7
Firmware name:
4.0.1
Build Time:
10:48:35 Oct 25, 2013
Install Time:
14:02:16 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Appl
-----------------------------------------NOS
4.0.1 <-Primary partition version (active)
4.0.1c
<- Secondary partition version (to be activated)
rbridge-id 3
Firmware name:
4.0.1
Build Time:
10:37:32 Oct 25, 2013
Install Time:
14:03:43 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1
ACTIVE*
4.0.1c
L2
NOS
4.0.1
4.0.1
L3
NOS
4.0.1
4.0.1
rbridge-id 5
Firmware name:
4.0.1
Build Time:
10:44:16 Oct 25, 2013
Install Time:
14:09:36 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
Appl
2.2.0

53-1003479-01
53
-----------------------------------------NOS
4.0.1
4.0.1c
rbridge-id 1
Firmware name:
4.0.1
Build Time:
10:37:32 Oct 25, 2013
Install Time:
14:10:01 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1
ACTIVE*
4.0.1c
M2
NOS
4.0.1
STANDBY
4.0.1c
L1
NOS
4.0.1
4.0.1c
L2
NOS
4.0.1
4.0.1c
L3
NOS
4.0.1
4.0.1c
L5
NOS
4.0.1
4.0.1c
L6
NOS
4.0.1
4.0.1c
This example output indicates the following:

Version 4.0.1 is present on the Primary partition for Rbridges 1, 3, 5, 7.
Version 4.0.1c is present in the Secondary partition for Rbridges 1, 3, 5, 7.
Step 4: Enter the show fabric islports to confirm ISL connectivity.
Confirm ISL connectivity between nodes in the fabric (using single or multihomed, brocade trunks, or individual interfaces). The following example shows
the output from the show fabric islports command after the upgrade of the
Group A nodes:
Name:
RB1_8770
Type:
1001.0
State:
Online
Role:
Fabric Principal
VCS Id:
1
Rbridge-id: 1
WWN:
10:00:00:27:f8:a1:e7:d8
FCF MAC:
00:27:f8:a1:e7:d8
Index
Interface
State
Operational State
===================================================================
0
Te 1/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720"
(Trunk Primary)
1
Te 1/1/2
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720"
(Trunk Primary)
2
Te 1/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770"
(Trunk Primary)
3
Te 1/1/4
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770"
(Trunk Primary)
4
Te 1/1/5
Up
ISL 10:00:00:27:f8:dd:0d:e8 "RB7_6740"
(Trunk Primary)
5
Te 1/1/6
Up
ISL 10:00:00:27:f8:dc:fd:9b "RB8_6740"
(Trunk Primary)
..
.
(downstream)
(downstream)
(downstream)
(downstream)
(downstream)
(downstream)
The highlighted entries indicate the following:
54

53-1003479-01
Rbridge 1 (RB1_8770) has a 10-Gb ISL to each of the six edge VDX nodes
(RB3_8770, RB4_8770, RB5_6720, RB6_6720, RB7_6740, and RB8_6740)
Rbridge 2 (RB2_8770) has a 10-Gb ISL to each of the six edge VDX nodes
(RB3_8770, RB4_8770, RB5_6720, RB6_6720, RB7_6740, and RB8_6740)
The following shows the output from the show fabric islports command on RB2:
Name:
RB2_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 2
WWN:
10:00:00:27:f8:a5:6d:54
FCF MAC:
00:27:f8:a5:6d:54
Index
Interface
State
Operational State
===================================================================
.
.
12
Te 2/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720" (downstream)
(Trunk Primary)
13
Te 2/1/2
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720" (upstream)
(Trunk Primary)
14
Te 2/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770" (downstream)
(Trunk Primary)
15
Te 2/1/4
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770" (Trunk
Primary)
16
Te 2/1/5
Up
ISL 10:00:00:27:f8:dd:0d:e8 "RB7_6740" (downstream)
(Trunk Primary)
17
Te 2/1/6
Up
ISL 10:00:00:27:f8:dc:fd:9b "RB8_6740" (Trunk Primary)
Step 5: Enter the show port-channel summary command to confirm port

channels.
Confirm that all port-channels have two or more active members and are vLAGs
(spanning two or more physical nodes). The following example shows the output
of the show port-channels summary command on Rbridge 1 (RB1_8770):
Member rbridges:
rbridge-id: 5 (1)
rbridge-id: 6 (1)
Link: Te 5/0/3 (0x518018002) sync: 1

Member rbridges:
rbridge-id: 3 (1)
rbridge-id: 4 (1)
Link: Te 3/2/3 (0x318818003) sync: 1
Member rbridges:
rbridge-id: 7 (1)
rbridge-id: 8 (1)
Link: Te 7/0/3 (0x718018002) sync: 1

53-1003479-01
55

Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 1/2/1 (0x118808001) sync: 1
The highlighted entries indicate that a vLAG is formed even with nodes running
different firmware versions. Rbridge 1 (RB1_8770), running FW version 4.0.1, is
a member of vLAG 100 along with Rbridge 2 (RB2_8770), which is running FW
version 4.0.1c.
Step 6: Upgrade nodes in Group B.
Perform the upgrade and verification steps (Step 2 through 7) for upgrade
Group B (Rbridge 3, 5, 7, and 1).
The following is the output of the show vcs command after upgrading all groups.
RB1_8770# show vcs
Config Mode
: Distributed
VCS ID
: 1
VCS GUID
: 8
Rbridge-Id
WWN
Management IP
Status
HostName
---------------------------------------------------------------------------------------1
>10:00:00:27:F8:A1:E7:D8*
10.18.125.112
Online
RB1_8770
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
Online
RB2_8770
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
Online
RB3_8770
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
Online
RB4_8770
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
Online
RB5_6720
6
10:00:00:05:33:5E:F7:83
10.18.124.106
Online
RB6_6720
7
10:00:00:27:F8:DD:0D:E8
10.17.1.42
Online
RB7_6740
8
10:00:00:27:F8:DC:FD:9B
10.17.1.45
Online
RB8_6740
The status of the fabric after successful completion of the upgrade is as follows:
All nodes have rejoined the VCS cluster and are shown as Online.
All nodes in the VCS cluster are running the newly downloaded firmware
version 4.0.1c.
Firmware version 4.0.1c has been committed on all nodes (present in both
Primary and Secondary partitions).
The following is the output from the show version command:
RB1_8770# show version rbridge all
rbridge-id 6
Firmware name:
4.0.1c
Build Time:
10:34:32 Apr 3, 2014
Install Time:
15:58:04 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
2.2.0
Appl
-----------------------------------------NOS
4.0.1c
4.0.1c
rbridge-id 7
56

53-1003479-01

Firmware name:
4.0.1c
Build Time:
10:38:55 Apr 3, 2014
Install Time:
15:51:42 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Appl
-----------------------------------------NOS
4.0.1c
4.0.1c
rbridge-id 8
Firmware name:
4.0.1c
Build Time:
17:38:55 Apr 3, 2014
Install Time:
22:51:35 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Appl
-----------------------------------------NOS
4.0.1c
4.0.1c
rbridge-id 3
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:52:25 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
ACTIVE*
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L3
NOS
4.0.1c
4.0.1c
rbridge-id 4
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:52:28 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
ACTIVE*
4.0.1c
M2
NOS
4.0.1c
STANDBY
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L4
NOS
4.0.1c
4.0.1c
rbridge-id 5
Firmware name:
4.0.1c

53-1003479-01
57
Build Time:
Install Time:
Kernel:
10:34:32 Apr 3, 2014

15:58:31 May 14, 2014
2.6.34.6
BootProm:
Control Processor:
2.2.0
Appl
-----------------------------------------NOS
4.0.1c
4.0.1c
rbridge-id 1
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:58:51 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
STANDBY
4.0.1c
M2
NOS
4.0.1c
ACTIVE*
4.0.1c
L1
NOS
4.0.1c
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L3
NOS
4.0.1c
4.0.1c
L5
NOS
4.0.1c
4.0.1c
L6
NOS
4.0.1c
4.0.1c
rbridge-id 2
Firmware name:
4.0.1c
Build Time:
10:27:57 Apr 3, 2014
Install Time:
15:58:44 May 14, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.1
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1c
ACTIVE*
4.0.1c
L1
NOS
4.0.1c
4.0.1c
L2
NOS
4.0.1c
4.0.1c
L3
NOS
4.0.1c
4.0.1c
L5
NOS
4.0.1c
4.0.1c
L6
NOS
4.0.1c
4.0.1c
58

53-1003479-01
Example C: Release 3.0.1 to 4.0.1 (Fabric Mode)

This chapter provides an example of using the Procedure for Upgrading Odd/Even Nodes for upgrading
the nodes in a fabric in Fabric Cluster mode. The topology of the VCS fabric used in this example is
illustrated in Figure 6 .
FIGURE 6 Topology and Upgrade Groups
This chapter demonstrates the short procedure (without node isolation) for upgrading a fabric in Fabric
Cluster mode. The example given is from Release 3.0.1c to 4.0.1, but a similar procedure is used for
upgrading between minor releases of Release 4 (4.0 to 4.1), and would be used for upgrading from
Release 4 to Release 5.
Figure 6 illustrates the topology used in this example, and the way that nodes are assigned to upgrade
groups to minimize the effect of the upgrade on traffic forwarding.
This procedure does not require prior isolation of nodes from end devices or VDX fabric nodes. Nodes
rejoin the fabric automatically after the upgrade is completed. This example demonstrates upgrading a
VCS fabric implemented in Fabric Cluster mode, where each node in the fabric needs to be configured
individually.

53-1003479-01
59

60

53-1003479-01
NOTE
made to local node flash storage as well as to an external server. The example given below shows the
copy options available and the syntax for copying to local flash storage.
RB1_8770# copy running-config ?
flash://
flash://<filename>
ftp://
scp://
sftp://
syntax for IPv6
startup-config
usb://
RB1_8770# copy running-config flash://RB1_8770_Running_Config
2014/05/14-11:57:03, [DCM-1112], 82711, M2 | Active, INFO, VDX8770-8, Running
configuration
file has been uploaded successfully to flash.
RB1_8770#
Step 2: Enter the show vcs command to verify the state of the fabric.
Before proceeding with a version upgrade, several health checks are
recommended to verify the state of the fabric. Confirm that all of the required
nodes have joined the VCS and identify the principal switch in the fabric. Also,
make a note of the rbridge ID for each node, which you will need when activating
the firmware on each group of nodes.
RB1_8770# show vcs
Config Mode
: Local-Only
VCS ID
: 1
: 6
Rbridge-Id
WWN
Management IP
Status
HostName
--------------------------------------------------------------------------------------1
10:00:00:27:F8:A1:E7:D8*
10.18.125.112
Online
RB1_8770
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
Online
RB2_8770
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
Online
RB3_8770
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
Online
RB4_8770
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
Online
RB5_6720
6
>10:00:00:05:33:5E:F7:83
10.18.124.106
Online
RB6_6720
The example output shows the following:

Configuration mode is "Local-Only," which indicates that the fabric is
implemented in Fabric Cluster mode.
Six nodes are in the fabric, with sequential rbridge IDs from 1 through 6.
The fabric principal switch is identified by the > symbol (RB6_6720).
Step 3: Enter the show fabric all command.
The following command is the output from the show fabric all command.
VCS Id: 1
Config Mode: Local-Only

53-1003479-01
61
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:A1:E7:D8
10.18.125.112
"RB1_8770"*
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
"RB2_8770"
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
"RB3_8770"
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
"RB4_8770"
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
"RB5_6720"
6
10:00:00:05:33:5E:F7:83
10.18.124.106
>"RB6_6720"
Step 4: Enter the show version command.

Verify that the same version is committed on all nodes in the fabric. The same
version must be committed on both Primary and Secondary partitions as a
prerequisite to the upgrade.
Firmware name:
3.0.1c
Build Time:
16:04:39 Oct 18, 2013
Install Time:
02:04:43 May 13, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
1.0.0
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
3.0.1c
STANDBY
3.0.1c
M2
NOS
3.0.1c
ACTIVE*
3.0.1c
L1
NOS
3.0.1c
3.0.1c
L2
NOS
3.0.1c
3.0.1c
L3
NOS
3.0.1c
3.0.1c
L5
NOS
3.0.1c
3.0.1c
L6
NOS
3.0.1c
3.0.1c
Step 5: Enter the show fabric islports command to confirm ISL

connectivity.
Confirm ISL connectivity between nodes in the fabric (single or multi-homed,
using Brocade trunks or individual interfaces).
Name:
RB1_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Config Mode:Local-Only
Rbridge-id: 1
WWN:
10:00:00:27:f8:a1:e7:d8
FCF MAC:
00:27:f8:a1:e7:d8
Index
Interface
State
Operational State
===================================================================
0
Fo 1/3/1
Down
1
Fo 1/3/2
Down
2
Fo 1/3/3
Down
3
Fo 1/3/4
Down
4
Fo 1/3/5
Down
5
Fo 1/3/6
Down
6
Fo 1/3/7
Down
7
Fo 1/3/8
Down
8
Fo 1/3/9
Down
9
Fo 1/3/10
Down
10
Fo 1/3/11
Down
11
Fo 1/3/12
Down
12
Te 1/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720" (downstream)
62

53-1003479-01
(Trunk
Primary)
13
Te
(Trunk
Primary)
14
Te
(Trunk
Primary)
15
Te
(Trunk
Primary)
16
Te
17
Te
18
Te
19
Te
20
Te
1/1/2
Up
1/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770" (downstream)
1/1/4
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770" (downstream)
1/1/5
1/1/6
1/1/7
1/1/8
1/1/9
Down
Down
Down
Down
Down
The example output shows the following:

RB1_8770 has a 10-Gb ISL to each of the four edge VDX nodes (RB3_8770,
RB4_8770, RB5_6720, and RB6_6720).
RB4_8770, RB5_6720, and RB6_6720).
The following shows the output of the show fabric islports command on
RB2_8770:
Name:
RB2_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 2
WWN:
10:00:00:27:f8:a5:6d:54
FCF MAC:
00:27:f8:a5:6d:54
Index
Interface
.
..
108
Te 2/1/1
Primary)
109
Te 2/1/2
Primary)
110
Te 2/1/3
(Trunk
Primary)
111
Te 2/1/4
State
Operational State
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720" (Trunk
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720" (Trunk
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770" (upstream)
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770" (Trunk Primary)
Step 6: Enter the show port-channel summary command.

Confirm that all port channels have two or more active members and are vLAGs,
spanning two or more physical nodes and that the ignore-split option is enabled
on all port channels.
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 1/2/1 (0x118808001) sync: 1
This output shows that RB1_8770 and RB2_8770 (rbridge IDs 1 and 2) are
members of vLAG 100.

53-1003479-01
63
NOTE
Port channels (LAGs) that have all physical links terminated on a single node
will (with the exception of ISSU) experience service interruption while the
associated node has the new version activated (reload and configuration replay,
and so forth).
The following shows the output of the show port-channel summary command
on RB2_8770:
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 2/2/1 (0x218808001) sync: 1

After preparing for the upgrade, as described in the previous section, perform the upgrade. This
section provides an example of the Procedure for Upgrading Odd/Even Nodes applied to upgrading
Release 3.0.1c to 4.0.1. A similar procedure is used for upgrading nodes in Fabric Cluster mode that
do not qualify for ISSU to other versions of Release 4.
64

53-1003479-01
Step 1: Copy the running configuration on each node in the current upgrade group to the start
configuration.
RB1_8770# copy running-config startup-config
This operation will modify your startup configuration. Do you want to continue? [y/
n]:y
2014/05/13-09:25:08, [DCM-1101], 82199, M2, INFO, VDX8770-8, Copy running-config to
startup-config operation successful on this node.
Step 2: Download the firmware.
NOTE
This step can be performed as part of the upgrade preparation for single-MM
nodes.
Single-MM download: For compact switches or chassis-based nodes with a
single MM, the recommended firmware download options are no reboot for
Release 3, and no commit. In Release 4, the option used is no activate.
no reboot: (Release 3.x.x); no activate (Release 4.x.x): These options can be
used in Fabric Cluster mode to download the firmware onto the Secondary
partition of each switch without triggering activation, to defer reloading and
rebooting the switch. This option only downloads the firmware, so it is nondisruptive and can be performed prior to the maintenance window.
no commit: If this option is not specified, after the new firmware is activated
on the switch it is copied to the Standby partition overwriting the previous
version. Using the no commit option allows the firmware to be reverted to the
previous version after the upgrade.
The following is an example of using the firmware download command with the
nocommit and noreboot options.
RB6_6720# firmware download ftp host 10.31.2.25 directory /buildsjc/sre/SQA/nos/
nos4.0.1/nos4.0.1 user Releaseuser password Releaseuser nocommit
noreboot
Checking conditions for downloading to 4.0.1
System sanity check passed.
You are running 'firmware download' with auto-reboot and auto-commit disabled. After
the
firmware is downloaded, please reboot the system and then run 'firmware commit' or
'firmware restore' manually.
2014/05/12-23:43:28, [HASM-1120], 461051, INFO, VDX6720-60, Current version 3.0.1c.
2014/05/12-23:43:28, [SULB-1105], 461052, INFO, VDX6720-60, Firmware upgrade session
(0:
single MM upgrade) starts.
This example shows the firmware download command with the noreboot and
nocommit options for RB6_6720.
After successful firmware download with the no reboot and no commit options,
the Secondary VDX partition has the new firmware version 4.0.1 and the Primary
partition has the 3.0.1c version. You can see this by entering the show version
command, as in the following example:
Firmware name:
3.0.1c
Build Time:
16:15:49 Oct 18, 2013
Install Time:
17:39:52 May 12, 2014
Kernel:
2.6.34.6
BootProm:
2.2.0

53-1003479-01
65
Control Processor:
Appl
-----------------------------------------NOS
3.0.1c
4.0.1
Dual-MM Download: For chassis-based switches with dual MMs that are part
of a fabric cluster, the default firmware download options are recommended.
The default options copy the firmware to both MMs and all line cards with a
single command. Using the no reboot and no commit options with dual-MM
nodes would require running the firmware download on both MMs.
NOTE
The command example below for Rbridge 1 triggers a reload upon completion
and should only be executed during firmware activation for its associated
upgrade group.
Step 3: Activate the new firmware for all of the nodes in upgrade Group A
simultaneously.
In this example, activate the firmware for each group of switches (see Figure 6
on page 59) as follows:
Upgrade group A: Rbridge 1, 3, 5
Upgrade group B: Rbridge 2, 4, 6 (Rbridge 6 is the principal switch)
Activate the dual-MM nodes in each group when you enter the download
firmware command with the default options. Activate the single-MM nodes by
entering the reload command.
Step 4: To activate the firmware on the Secondary partition of a single MM
node, verify the Primary and Secondary versions and then enter the
reload command.
This command is repeated on Rbridge 3, but is now shown.
RB5_6720# show ver
Firmware name:
3.0.1c
Build Time:
16:15:49 Oct 18, 2013
Install Time:
17:39:52 May 12, 2014
Kernel:
2.6.34.6
BootProm:
Control Processor:
2.2.0
Appl
-----------------------------------------NOS
3.0.1c <- Primary Version
4.0.1 <- Secondary Version
RB5_6720#
RB5_6720#
RB5_6720# reload
Warning: Unsaved configuration will be lost. Please run `copy running-config startupconfig` to save the current configuration if not done already.
Are you sure you want to reload the switch? [y/n]y
When RB5_6720 is reloaded to activate the new firmware version, port-channel

91 (spanning RB5_6720 and RB6_6720) changes from a vLAG to a LAG with a
single member remaining in service on RB6_6720. All ingress and egress traffic
66

53-1003479-01
is through RB6_6720. After RB5_6720 comes up, an additional log is generated

indicating that the vLAG has been reformed.
RB6_6720# 2014/05/13-09:48:25, [FVCS-1003], 461129, WARNING, RB6_6720, Possible vLAG
Split
Detected vLAG - ifindex (2800005b), split RBridge(5).
2014/05/13-09:48:25, [NSM-1025], 461130, DCE, INFO, RB6_6720, RBridge ID 5 has left
Port-channel 91. Portchannel has only RBridge ID 6 and is no longer a vLAG.
2014/05/13-09:58:11, [NSM-1002], 461131, DCE, INFO, RB6_6720, Interface
TenGigabitEthernet
2014/05/13-09:58:11, [NSM-1003], 461132, DCE, INFO, RB6_6720, Interface
TenGigabitEthernet
6/0/2 is link down.
2014/05/13-09:58:11, [NSM-1027], 461133, DCE, INFO, RB6_6720, SFP transceiver for
interface TenGigabitEthernet 6/0/2 is removed.
2014/05/13-09:58:11, [NSM-1026], 461134, DCE, INFO, RB6_6720, SFP transceiver for
interface TenGigabitEthernet 6/0/2 is inserted.
2014/05/13-09:58:28, [NSM-1023], 461135, DCE, INFO, RB6_6720, RBridge ID 5 has
joined
Port-channel 91. Port-channel is a vLAG with RBridge IDs 6 5.
This output shows the example for RB6_6720.

Step 5: To activate the firmware on a dual-MM chassis, enter the firmware
download command with the default options.
RB1_8770# firmware download ftp host 10.31.2.25 directory
/buildsjc/sre/SQA/nos/nos4.0.1/nos4.0.1 user Releaseuser password Releaseuser
System sanity check passed.
This command will cause a cold/disruptive reboot and will require that existing
telnet,
secure telnet or SSH sessions be restarted.
2014/05/13-09:27:44, [HASM-1120], 82200, M2, INFO, VDX8770-8, Current version 3.0.1c.
2014/05/13-09:27:44, [SULB-1105], 82201, M2, INFO, VDX8770-8, Firmware upgrade
session (0:
dual-MM upgrade) starts.
NOTE
The command example here (Rbridge 1) triggers a reload upon completion and
should be executed only when activating the firmware for the upgrade group to
which each dual-MM node belongs.
The system performs the following actions when activating the firmware for a
dual-MM node (this is different in an ISSU upgrade):
1. Loads firmware onto standby MM Secondary partition (M1 is initially the
standby in this example).
2. Loads firmware onto active MM Secondary partition (M2 is initially the active in
this example).
3. Reboots the standby MM (M1 below) to activate the new firmware version.
4. The standby MM (M1) comes up after the active MM (M2) is reloaded.
NOTE
Make sure you have console connectivity to the standby MM because during
the upgrade on a dual-MM node, failover occurs to the standby MM
5. Activity is switched between MMs. MM1 becomes active and after reloading,
MM2 becomes the standby.

53-1003479-01
67
The following are the example logs during upgrade of a dual-MM node.
2014/05/13-09:27:44, [HASM-1120], 82200, M2, INFO, VDX8770-8,
2014/05/13-09:27:44, [SULB-1105], 82201, M2, INFO, VDX8770-8,
session (0:
dual-MM upgrade) starts.
2014/05/13-09:27:44, [SULB-1100], 82202, M2, INFO, VDX8770-8,
begins on
M1.
..
..
2014/05/13-09:49:50, [SULB-1101], 82212, M2, INFO, VDX8770-8,
on M1.
2014/05/13-09:49:50, [SULB-1100], 82213, M2, INFO, VDX8770-8,
begins on
M2.
Please avoid powering off the system during prom update.
Finished writing prom image.
Current version 3.0.1c.

Firmware upgrade
Firmware install
Firmware install ends

Firmware install
Tue May 13 16:52:16 UTC 2014 - Initializing the Dcmd and Ccmd database...
Tue May 13 16:52:45 UTC 2014 - Completed intializing the Dcmd and Ccmd database.
2014/05/13-09:53:19, [SULB-1101], 82214, M2, INFO, VDX8770-8, Firmware install ends
on M2.
Swap Begin 0
OSLoader is not defined
2014/05/13-09:53:20, [SULB-1100], 82215, M2, INFO, VDX8770-8, Firmware reboot begins
on M1.
2014/05/13-09:53:28, [RAS-1007], 82216, M1, INFO, VDX8770-8, System is about to
reload.
take over on OMM/OLC interrupt
2014/05/13-09:53:33, [HASM-1106], 82217, M2, INFO, VDX8770-8, Reset the standby
management
module.
2014/05/13-09:53:33, [HASM-1103], 82218, M2, INFO, VDX8770-8, Heartbeat to M1 down.
.
.
2014/05/13-09:57:26, [HASM-1104], 82232, M2, INFO, VDX8770-8, Heartbeat to M1 up.
Waiting for pending actions to exit.
2014/05/13-09:57:37, [BGP-1002], 82233, M1, INFO, VDX8770-8,
action
.
BGP: Daemon ready for
Waiting for pending actions to exit.

sus_install ftp://Releaseuser:***********@10.31.2.25//buildsjc/sre/SQA/nos/nos4.0.1/
nos4.0.1/Release.plist 0x20200040
The command has completed successfully.
2014/05/13-09:57:52, [HASM-1100], 82234, M1, INFO, VDX8770-8, HA State is in sync.
All service instances in sync
2014/05/13-09:57:52, [HASM-1100], 82235, M2, INFO, VDX8770-8, HA State is in sync.
2014/05/13-09:57:53, [SULB-1101], 82236, M2, INFO, VDX8770-8, Firmware reboot ends
on M1.
2014/05/13-09:57:53, [SULB-1100], 82237, M2, INFO, VDX8770-8, Firmware reboot begins
on M2.
2014/05/13-09:57:56, [NSM-1020], 82238, M2 | DCE, INFO, RB1_8770, Interface
TenGigabitEthernet 1/2/1 is administratively down.
2014/05/13-09:57:56, [NSM-1003], 82239, M2 | DCE, INFO, RB1_8770, Interface
2014/05/13-09:57:56, [NSM-1003], 82240, M2 | DCE, INFO, RB1_8770, Interface Portchannel 100 is link down.
Shutting Down Database ...... (New)
Calling DcmClient for Dcm
2014/05/13-09:57:56, [NSM-1025], 82241, M2 | DCE, INFO, RB1_8770, RBridge ID 1 has
left Port-channel 100. Port-channel has only RBridge ID 2 and is no longer a vLAG.
Calling DcmClient for CCM
Completed
2014/05/13-09:58:04, [RAS-1007], 82242, M2, INFO, VDX8770-8, System is about to
reload.
After switchover, the system performs the following actions:
68

53-1003479-01
1. Firmware installation is completed on both LC partitions of each line card.

2. Upon successful firmware installation on each LC partition, each line card is
rebooted to activate the new firmware.
3. After each LC is reloaded, the new firmware is committed (in this example, the
no commit option was not used with the firmware download command).
Logs from the newly active MM (MM1) look like the following.
RB1_8770 console login: receive takeover signal
2014/05/13-09:58:09, [HASM-1103], 80865, M1 | Standby, INFO, VDX8770-8, Heartbeat to
M2
down.
2014/05/13-09:58:09, [HASM-1107], 80866, M1 | Standby, INFO, VDX8770-8, Take over the
active management module.
2014/05/13-09:58:09, [HASM-1101], 80867, M1 | Standby, WARNING, VDX8770-8, HA State
out of
sync.
.
2014/05/13-10:00:23, [HASM-1104], 81176, M1 | Active, INFO, VDX8770-8, Heartbeat to
L1/0
up.
L1/1
up.
L2/0
up.
2014/05/13-10:00:27, [SULB-1105], 81179, M1 | Active, WARNING, VDX8770-8, Firmware
upgrade
session (0: dual-LC partition auto-level) starts.
install
begins on L1/0.
L2/1
up.
L3/0
up.
2014/05/13-10:00:28, [SULB-1105], 81183, M1 | Active, WARNING, VDX8770-8, Firmware
upgrade
session (1: dual-LC partition auto-level) starts.
..
.
install
begins on L2/1.
install
ends on L1/0.
install
begins on L1/1.
reboot
begins on L5/0.
install
ends on L1/1.
install
ends on L3/1.
reboot
begins on L1/0.
reboot
begins on L3/0.
..

L1/0
down.
L1/1
down.

53-1003479-01
69
2014/05/13-10:06:11, [HASM-1103],
L3/0
down.
.
..
2014/05/13-10:07:18, [HASM-1104],
to M1
up.
2014/05/13-10:07:19, [HASM-1104],
to L1/0
up.
2014/05/13-10:07:19, [HASM-1104],
to L1/1
up.
.
.
2014/05/13-10:09:03, [SULB-1101],
reboot ends
on L1/0.
2014/05/13-10:09:03, [SULB-1101],
reboot ends
on L1/1.
2014/05/13-10:09:04, [SULB-1100],
commit
begins on L1/0.
2014/05/13-10:09:04, [SULB-1100],
commit
begins on L1/1.
2014/05/13-10:10:04, [SULB-1101],
commit ends
on L1/0.
2014/05/13-10:10:04, [SULB-1101],
commit ends
on L1/1.
2014/05/13-10:10:04, [SULB-1103],
download
completed successfully on L1/0.
2014/05/13-10:10:04, [SULB-1103],
download
completed successfully on L1/1.
81233, M1 | Active, INFO, VDX8770-8, Heartbeat to
81266, L1/0 | Standby, INFO, VDX8770-8, Heartbeat

81267, L1/1 | Standby, INFO, VDX8770-8, Heartbeat
81268, L1/0 | Active, INFO, VDX8770-8, Heartbeat
81876, M1 | Active, INFO, VDX8770-8, Firmware


Step 1: Wait for all nodes to come up after reload.
As part of the firmware activation, the associated nodes reload. Before proceeding with the
subsequent steps, wait for all nodes to come up after reload. Do not proceed to the next step until post
boot processing is completed for the nodes that have been.
70

53-1003479-01
The following highlighted logs indicate that post-boot processing has completed.
2014/05/13-09:58:49, [DCM-1105], 80801, INFO, chassis, Copy of the downloaded config
file
to the current running-config has completed successfully on this node.
2014/05/13-09:59:04, [DCM-1005], 80802, INFO, chassis, Configuration Replay is
complete.
2014/05/13-09:59:05, [SEC-1334], 80803, INFO, chassis, local security policy not
saved.
2014/05/13-09:59:05, [SEC-1334], 80804, INFO, chassis, local security policy not
saved.
2014/05/13-09:59:07, [HASM-1110], 80805, INFO, chassis, Configuration replay has
completed
on the system.
replay
**********************************************************************
System initialization is complete. NOS is ready to handle all commands
**********************************************************************
Step 2: Enter the show vcs command and fabric all commands to verify the
upgrade.
Perform post-upgrade checks to verify fabric health and compare to results from
the checks performed before upgrading.
Confirm that all of the required nodes have joined the VCS. In this example, a
total of six nodes are in the fabric, as shown by the output for the show fabric all
command. The show VCS command shows only the local node due to a version
mismatch. In the example below from RB1_8770, the version is 4.0.1 and the
other nodes are 3.0.1c.
NOTE
The data plane of the fabric continues to function with mixed versions.
RB1_8770# show vcs
Config Mode
: Local-Only
VCS ID
: 1
: 1
Rbridge-Id
WWN
Management IP
Status
HostName
---------------------------------------------------------------------------------------1
>10:00:00:27:F8:A1:E7:D8*
10.18.125.112
Online
RB1_8770
The following shows the output from the show fabric all command:
VCS Id: 1
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:A1:E7:D8
10.18.125.112
"RB1_8770"*
2
10:00:00:27:F8:A5:6D:54
10.18.125.219
"RB2_8770"
3
10:00:00:27:F8:A2:60:3C
10.17.1.36
"RB3_8770"
4
10:00:00:27:F8:5F:C5:44
10.17.1.37
"RB4_8770"
5
10:00:00:05:33:EC:2C:D2
10.18.125.95
"RB5_6720"
6
10:00:00:05:33:5E:F7:83
10.18.124.106
>"RB6_6720"
The example shows the following:

53-1003479-01
71
Configuration mode is "Local-Only" indicating that each node in the fabric

needs to be configured individually.
A total of six nodes are in the fabric as reflected in the show fabric all output.
The show VCS command shows only the local node due to a version
mismatch. In the from RB1_8770, the version is 4.0.1, while the other nodes
are 3.0.1c.
NOTE
The data plane of the fabric continues to function with mixed versions.
The fabric principal switch is identified by the > symbol ( RB6_6720, as seen
from the show fabric all command).
Step 3: Enter the show version command to verify the upgrade.
Confirm that the correct version is committed on all nodes in the fabric.
Firmware name:
4.0.1
Build Time:
10:37:32 Oct 25, 2013
Install Time:
09:49:49 May 13, 2014
Kernel:
2.6.34.6
BootProm:
1.0.1
Control Processor: e500mc with 7168 MB of memory
Slot
Name
Status
--------------------------------------------------------------------------M1
NOS
4.0.1
ACTIVE*
4.0.1
M2
NOS
4.0.1
STANDBY
4.0.1
L1
NOS
4.0.1
4.0.1
L2
NOS
4.0.1
4.0.1
L3
NOS
4.0.1
4.0.1
L5
NOS
4.0.1
4.0.1
L6
NOS
4.0.1
In the example output, NOS Firmware version 4.0.1 is installed on both Primary
and Secondary partitions on both management and all line cards for Rbridge 1.
Step 4: Enter the show fabric islports command to verify ISLs.
Confirm ISL connectivity between nodes in the fabric.
Name:
RB1_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 1
WWN:
10:00:00:27:f8:a1:e7:d8
FCF MAC:
00:27:f8:a1:e7:d8
Index
Interface
State
Operational State
===================================================================
..
.
96
Te 1/1/1
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720" (Trunk
Primary)
97
Te 1/1/2
Up
(Trunk Primary)
98
Te 1/1/3
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770" (Trunk
Primary)
72

53-1003479-01
99
Te 1/1/4
Primary)
..
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770" (Trunk
The example shows the folllowing:

RB4_8770, RB5_6720, and RB6_6720).
RB4_8770, RB5_6720, and RB6_6720).
The following shows the output of the show fabric islports command on
RB2_8770:
Name:
RB2_8770
Type:
1001.0
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 2
WWN:
10:00:00:27:f8:a5:6d:54
FCF MAC:
00:27:f8:a5:6d:54
Index
Interface
.
..
108
Te 2/1/1
Primary)
109
Te 2/1/2
Primary)
110
Te 2/1/3
(Trunk
Primary)
111
Te 2/1/4
State
Operational State
Up
ISL 10:00:00:05:33:ec:2c:d2 "RB5_6720" (Trunk
Up
ISL 10:00:00:05:33:5e:f7:83 "RB6_6720" (Trunk
Up
ISL 10:00:00:27:f8:a2:60:3c "RB3_8770" (upstream)
Up
ISL 10:00:00:27:f8:5f:c5:44 "RB4_8770" (Trunk Primary)
Step 5: Enter the show port-channel summary to verify the port channels.
Confirm that all port-channels have two or more active members and are vLAGs.
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 1/2/1 (0x118808001) sync: 1
Member rbridges:
rbridge-id: 1 (1)
rbridge-id: 2 (1)
Link: Te 2/2/1 (0x218808001) sync: 1*
<-* indicates Primary LAG member
In this example, RB1_8770 (Rbridge ID 1) is running Release 4.0.1 and is a

member of vLAG 100 along with RB2_8770, which is running Release 3.0.1c.
NOTE
The Primary vLAG interface has moved from RB1_8770 to RB2_8770 after RB1
was reloaded during the upgrade process.

53-1003479-01
73
Step 6: Repeat Steps 3 through 10 for the single-MM and dual-MM nodes
in Group B.
74

53-1003479-01
Example D: Release 2.11a to 3.01c

Example Topology.......................................................................................................... 75
Task 2: Route Traffic Away from the Upgrade Group..................................................... 76
Task 3: Isolate the Upgrade Group from the Fabric........................................................79
Task 5: Rejoin Upgrade Group to the Fabric.................................................................. 86
Task 6: Enable Edge Interfaces In the Upgrade Group.................................................. 87
Task 8: Upgrade the Remaining Groups.........................................................................90
This chapter provides an example of using the procedure for Upgrading One Node at a Time firmware
from Release 2.x to 3.x or 3.x to 3.y. During this procedure, nodes are isolated from end devices and
other nodes in the fabric during the upgrade, and are added back into the VCS after the upgrade is
complete. Figure 7 illustrates the fabric used for testing and documenting this procedure.
FIGURE 7 Test Network for Example D
Example Topology
The procedure outlined in the following section demonstrates upgrading a VCS fabric from 2.x.x to
3.x.x. For each of the node groups within a given VCS the upgrade steps are given below.
The key characteristics of the edge VCS fabrics illustrated in Figure 7 on page 75 are summarized in
the sections that follow.
Node Distribution Edge VCS 1

There are 24 VDX nodes in the edge VCS:

53-1003479-01
75
Three edge aggregation nodes: R-bridges 1, 2, 3, which provide aggregation of edge VDX nodes
and connection to the core VCS (VCS 30).
Three top of rack (ToR) nodes per server rack: R-bridges 4-6, 7-9, 10-12, 13-15, 16-18, 19-21,
22-24.
NOTE
This example shows a specific deployment with three ToR nodes, but three ToR nodes are not
required. Two ToR nodes provide sufficient functionality for many use cases.
Node Distribution Aggregation VCS 30

There are three VDX nodes in the aggregation VCS:
Three edge aggregation nodes: R-bridges 1-3.
Each of the Edge VCS fabrics is triple homed to three unique nodes in the aggregation VCS and
configured as a LACP vLAG.
Node Connection Edge VCS 1

The ISLs within a given edge fabric include the following:
Rbridge 1 has ISLs to the first ToR node of each server rack in other words, 4, 7, 10, 13, 16, 19, 22.
Rbridge 2 has ISLs to the second ToR node of each server rack in other words, 5, 8, 11, 14, 17, 20,
23.
Rbridge 3 has ISLs to the third ToR node of each server rack in other words, 6, 9, 12, 15, 18, 21,
24.
Rbridge 1, 2, and 3 have full meshed direct connectivity via two 20 Gb ISL trunks.
Middle server rack ToR node has two additional ISLs; one to each of the other ToR nodes in the
same server rack. For example, from Rbridge 5 to 4 and from Rbridge 5 to 6.
Upgrade Groups for Edge VCS 1
The upgrade node groups, used to minimize traffic disruption during the upgrade process, are defined
as follows:
Group A Rbridges: 1, 4, 7, 10, 13, 16, 19, 22
Group B Rbridges: 2, 5, 8, 11, 14, 17, 20, 23
Group C Rbridges: 3, 6, 9, 12, 15, 18, 21, 24

See the Preparing for the Upgrade on page 13 section for instructions about how to prepare for the
upgrade, which is similar to the other upgrade methods.
Task 2: Route Traffic Away from the Upgrade Group

This section provides an example of the upgrade from Release 2.11a to 3.01c for Upgrade Group A.
76

53-1003479-01
Step 1: On VCS 1 interface ten, 1/0/1 is administratively shut down and the interface is then no
longer a member of port-channel 1000.

53-1003479-01
77
Step 2: Administratively shut down port-channel 1000 on VCS 1 Rbridge 1.

EDGE_AGG_RB1#
EDGE_AGG_RB1# conf t
Entering configuration mode terminal
EDGE_AGG_RB1(config)# interface Ten 1/0/1
EDGE_AGG_RB1(conf-if-te-1/0/1)# shut
EDGE_AGG_RB1# 2014/01/12-05:54:13, [NSM-1003], 67003, INFO, EDGE_AGG_RB1, Interface
Port-channel 1000 is link down.
2014/01/12-05:54:13, [NSM-1002], 67004, INFO, EDGE_AGG_RB1, Interface
2014/01/12-05:54:13, [NSM-1024], 67006, INFO, EDGE_AGG_RB1, rBridge ID 1 has left
Port-channel 1000. Port-channel is a vLAG with rBridge-IDs 2 3.
EDGE_AGG_RB1(config)# interface Port-channel 1000
EDGE_AGG_RB1(config-Port-channel-1000)# shut
2014/01/12-05:54:42, [NSM-1020], 67007, INFO, EDGE_AGG_RB1, Interface Port-channel
1000 is administratively down.
EDGE_AGG_RB1(config-Port-channel-1000)# 2014/01/12-06:03:56, [SNMP-1007], 67008,
INFO, EDGE_AGG_RB1, The last fabric change happened at: Sun Jan 12 06:03:54 2014
Step 3: Shut down physical interfaces on all edge nodes within the node
group.
Shut down the physical interfaces that connect directly to the servers. For
example, for node Group A, shut down interfaces connected to servers for RB
4, 7, 10, 13, 16, 19, 22.
NOTE
All server connections are physically dual or triple homed to VDX nodes so that
connectivity is maintained when interfaces on one of the VDX nodes are
disabled.
In this example, on Rbridge 4, the configuration to shut down interfaces gig
4/0/1 through to gig 4/0/48 was cut and pasted to the console of the switch.
After each port is shut down, a log is generated indicating that the interface is
administratively down and that the rbridge has left the port channel and
indicates the rbridges that remain in the port channel.
EDGE_RB4# conf t
EDGE_RB4(config)# int gig 4/0/1
EDGE_RB4(conf-if-gi-4/0/1)# shut
EDGE_RB4(conf-if-gi-4/0/1)# !2014/01/12-05:57:21, [NSM-1020], 75925, INFO,
EDGE_RB4, Interface GigabitEthernet 4/0/1 is administratively down.
EDGE_RB4(conf-if-gi-4/0/1)#
EDGE_RB4(conf-if-gi-4/0/1)# int gig 4/0/2
2014/01/12-05:57:21, [NSM-1003], 75926, INFO, EDGE_RB4, Interface GigabitEthernet
4/0/1 is link down.
2014/01/12-05:57:21, [NSM-1003], 75927, INFO, EDGE_RB4, Interface Port-channel 1 is
link down.
EDGE_RB4(conf-if-gi-4/0/2)# !
2014/01/12-05:57:21, [NSM-1025], 75928, INFO, EDGE_RB4, rBridge ID 4 has left Portchannel 1. Port-channel has only rBridge ID 5 and is no longer a vLAG.
.
.
EDGE_RB4(conf-if-gi-4/0/48)# 2014/01/12-05:57:28, [NSM-1025], 76004, INFO,
EDGE_RB4, rBridge ID 4 has left Port-channel 20. Port-channel has only rBridge ID
5 and is no longer a vLAG.
2014/01/12-05:57:28, [NSM-1020], 76005, INFO, EDGE_RB4,
4/0/21 is administratively down.
78
Interface GigabitEthernet

53-1003479-01
2014/01/12-05:57:28, [NSM-1003], 76006, INFO, EDGE_RB4,

4/0/21 is link down.
2014/01/12-05:57:29, [NSM-1020], 76007, INFO, EDGE_RB4,
2014/01/12-05:57:29, [NSM-1003], 76008, INFO, EDGE_RB4,
..
Step 4: Shut down port channels on all edge nodes within the node group.
For example, for node Group A, shut down the port channels configured on RB 4,
7, 10, 13, 16, 19, 22. In this example, on Rbridge 4, the configuration to shut
down the port-channels was cut and pasted to the console of the switch. After
each port channel is shut down, a log is generated indicating that the interface is
administratively down.
EDGE_RB4# conf t
EDGE_RB4(config)# int port-channel 1
EDGE_RB4(config-Port-channel-1)# shut
2014/01/12-06:01:56, [NSM-1020], 76041, INFO, EDGE_RB4,
EDGE_RB4(config-Port-channel-1)# !
EDGE_RB4(config-Port-channel-1)#
EDGE_RB4(config-Port-channel-1)# int port-channel 2
2014/01/12-06:01:57, [NSM-1020], 76042, INFO, EDGE_RB4,
2014/01/12-06:01:57, [NSM-1020], 76043, INFO, EDGE_RB4,
..
..
2014/01/12-06:02:09, [NSM-1020], 76062, INFO, EDGE_RB4,
EDGE_RB4(config-Port-channel-31)# exit
Interface Port-channel 1 is

Step 1: Shut down ISLs from adjacent ToR nodes that connect to the ToR nodes in the upgrade
group.
For example, when upgrading Group A (RB 4, 7, 10, 13, 16, 19, 22), the ISLs on RB 5 that connect to
RB4 are shut down along with ISLs between RB 8 and RB7, and so forth.
NOTE
Middle server rack ToR VDX nodes have two ISLs; one to each of the other ToR nodes in the same
server rack (for example from Rbridge 5 to 4 and to 6.

53-1003479-01
79
In this example, RB 5 port 5/0/50 is connected to RB4 as indicated by the show fabric ISL output on
RB5. This is the adjacent ToR ISL to be disabled for isolating upgrade Group A from the fabric during
the upgrade.
EDGE_RB5# show fabric isl
Rbridge-id: 5
#ISLs: 3
Src
Src
Nbr
Nbr
Index
Interface
Index
Interface
Nbr-WWN
BW
Trunk Nbr-Name
--------------------------------------------------------------------------------------------1
Te 5/0/49
9
Te 2/0/9
10:00:00:27:F8:66:3A:D8
10G
Yes
"EDGE_AGG_RB2"
2
Te 5/0/50
2
Te 4/0/50
10:00:00:27:F8:88:F1:A5
10G
Yes
"EDGE_RB4"
3
Te 5/0/51
51
Te 6/0/51
10:00:00:05:33:DF:1E:83
10G
Yes
"EDGE_RB6"
EDGE_RB5# conf t
EDGE_RB5(config)# int ten 5/0/50
EDGE_RB5(conf-if-te-5/0/50)# shut
2014/01/12-06:05:54, [NSM-1020], 2264090, INFO, EDGE_RB5, Interface
TenGigabitEthernet
EDGE_RB5(conf-if-te-5/0/50)# 2014/01/12-06:05:54, [NSM-1003], 2264091, INFO,
EDGE_RB5,
Interface TenGigabitEthernet 5/0/50 is link down.
The following shows the logs observed on RB4 after ISL shut down on RB5:
TenGigabitEthernet
TenGigabitEthernet
2014/01/12-06:05:56, [SNMP-1007], 76068, INFO, EDGE_RB4, The last fabric change
happened at: Sun Jan 12 06:05:54 2014
Step 2: Shut down ISLs from adjacent edge aggregation nodes to isolate
the upgrade group from the VCS fabric.
For example, for Group A, the ISL on RB2 to RB1 is shut down and on RB3, the
ISL to RB1.
NOTE
At this point, Group A forms a separate VCS while the remainder of the VDX
nodes remain in the original VCS.
In this example, for Group A, the adjacent nodes to RB1 are RB2 and RB3.
RB2 connects to RB1 through dual 10-Gb ISL links (20-Gb trunk). Ports ten
2/0/3 and ten 2/0/4 are shut down on RB2.
RB3 connects to RB1 through dual 10-Gb ISL links (20-Gb trunk). Ports ten
3/0/3 and ten 3/0/4 are shut down on RB3.
Additionally, the ISL from the principal switch (RB16 to RB1) is shut down.
Because RB16 is the principal switch, it becomes a member of node Group D.
Therefore, to isolate Group A from the remainder of the fabric, the ISL link
between RB16 and RB1 must be disabled (if RB16 was not the principal switch
it would have been part of group A).
EDGE_AGG_RB2# show fabric isl
Rbridge-id: 2
80
#ISLs: 9

53-1003479-01
Src
Src
Nbr
Nbr
Index
Interface
Index
Interface
Nbr-WWN
BW
Trunk
Nbr-Name
--------------------------------------------------------------------------------------------4
Te 2/0/4
4
Te 1/0/4
10:00:00:27:F8:3A:46:A8
20G
Yes
"EDGE_AGG_RB1"
6
Te 2/0/6
6
Te 3/0/6
10:00:00:27:F8:3A:38:F8
20G
Yes
"EDGE_AGG_RB3"
9
Te 2/0/9
1
Te 5/0/49
10:00:00:05:33:B6:55:CF
10G
Yes
"EDGE_RB5"
10
Te 2/0/10
10
Te 8/0/10
10:00:00:05:33:F6:58:97
10G
Yes
"EDGE_RB8"
.
EDGE_AGG_RB2(config)# int ten 2/0/3
INFO
: Sun Jan 12 06:08:38 2014 : Success sending the portrole notification
EDGE_AGG_RB2(conf-if-te-2/0/3)# 2014/01/12-06:08:38, [NSM-1020], 148419, INFO,
EDGE_AGG_RB2, Interface TenGigabitEthernet 2/0/3 is administratively down.
TenGigabitEthernet
2/0/3 is link down.
EDGE_AGG_RB2(conf-if-te-2/0/3)# int ten 2/0/4
TenGigabitEthernet
2/0/4 is link down.
The following shows the output from the show fabric isl command on
EDGE_AGG_RB3:
EDGE_AGG_RB3# show fabric isl
Rbridge-id: 3
#ISLs: 9
Src
Src
Nbr
Nbr
Index
Interface
Index
Interface
Nbr-WWN
BW
Trunk
Nbr-Name
--------------------------------------------------------------------------------------------3
Te 3/0/3
5
Te 1/0/5
10:00:00:27:F8:3A:46:A8
20G
Yes
"EDGE_AGG_RB1"
6
Te 3/0/6
6
Te 2/0/6
10:00:00:27:F8:66:3A:D8
20G
Yes
"EDGE_AGG_RB2"
9
Te 3/0/9
49
Te 6/0/49
10:00:00:05:33:DF:1E:83
10G
Yes
"EDGE_RB6"
EDGE_AGG_RB3# conf
EDGE_AGG_RB3(config)# int ten 3/0/3
INFO
TenGigabitEthernet
3/0/3 is link down.
EDGE_AGG_RB3,
Interface TenGigabitEthernet 3/0/4 is administratively down.
TenGigabitEthernet
3/0/4 is link down.
EDGE_RB16# show fabric isl
Rbridge-id: 16
#ISLs: 2
Src
Src
Nbr
Nbr
Index
Interface
Index
Interface
Nbr-WWN
BW
Trunk
NbrName
--------------------------------------------------------------------------------------

53-1003479-01
81
-------49
Te 16/0/49
13
Te 1/0/13
10:00:00:27:F8:3A:46:A8
10G
Yes
"EDGE_AGG_RB1"
50
Te 16/0/50
50
Te 17/0/50
10:00:00:05:33:A2:7B:30
10G
Yes
"EDGE_RB17"

EDGE_RB16(conf-if-te-16/0/49)# 2014/01/12-06:09:31, [NSM-1020], 405913, INFO,
EDGE_RB16,
TenGigabitEthernet
After the ISLs on the adjacent edge aggregation nodes are shut down as well
as the ISL to the fabric principal switch, the node group becomes completely
isolated from the remainder of the fabric. In this example, for Group A, the only
members of the fabric belong to Group A (RB 1, 4, 7, 10, 13, 19, 22).
EDGE_AGG_RB1(config)# do show fabric all
VCS Id: 1
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:3A:46:A8
10.18.125.85
"EDGE_AGG_RB1"*
4
10:00:00:27:F8:88:F1:A5
10.17.0.128
"EDGE_RB4"
7
10:00:00:05:33:DB:C4:8A
10.18.124.217
"EDGE_RB7"
10
10:00:00:05:33:87:19:E9
10.18.125.90
>"EDGE_RB10"
13
10:00:00:05:33:DF:16:83
10.18.125.93
"EDGE_RB13"
19
10:00:00:05:33:DE:4D:70
10.18.125.99
"EDGE_RB19"
10:00:00:05:33:DF:29:F4
10.18.125.47
"EDGE_RB22"
Step 3: Shut down the ISLs on each of the ToR nodes that connect to the
edge aggregation node.
For example, for Group A, the ISL from RB4 to RB1 is shut down; then the ISL
from RB7 to RB1, and so forth.
In this example, ToR RB4 from Group A has one remaining ISL that is up to
RB1. Each ISL from ToR nodes to the edge aggregation node RB1 are
shutdown to isolate each node prior to upgrading the firmware version. This
allows for re-joining the fabric sequentially and more gracefully compared to the
entire node group at once.
Step 4: Identify the ISLs by entering the show fabric islports command.
EDGE_RB4# show fabric islports
Name:
EDGE_RB4
Type:
116.4
State:
Online
Role:
Fabric Subordinate
VCS Id:
1
Rbridge-id: 4
WWN:
10:00:00:27:f8:88:f1:a5
FCF MAC:
00:27:f8:88:f1:a5
Index
Interface
State
Operational State
===================================================================
1
Te 4/0/49
Up
ISL 10:00:00:27:f8:3a:46:a8 "EDGE_AGG_RB1" (upstream)
(Trunk
Primary)
2
Te 4/0/50
Down
3
Te 4/0/51
Down
4
Te 4/0/52
Down
5
Te 4/0/53
Down
6
Te 4/0/54
Down
EDGE_RB4# conf t
82

53-1003479-01
EDGE_RB4(conf-if-te-4/0/49)# 2014/01/12-06:13:11, [NSM-1020], 76072, INFO, EDGE_RB4,
2014/01/12-06:13:11, [NSM-1003], 76073, INFO, EDGE_RB4, Interface TenGigabitEthernet
4/0/49 is
link down.

Step 1: Copy the running configuration on each switch in the upgrade node group to the start
configuration on each node.

53-1003479-01
83
Writing these configuration changes to the startup configuration ensures the node will come up in
isolation and will not be added back to the fabric until desired.
EDGE_RB4# copy running-config startup-config
This operation will modify your startup configuration. Do you want to continue? [y/
n]:y
EDGE_RB4# 2014/01/12-06:15:42, [DCM-1101], 76075, INFO, VDX6710-54, Copy runningconfig to
startup-config operation successful on this node.
Step 2: Reload each node in the upgrade group to activate the new
firmware.
EDGE_RB4# reload
Warning: Unsaved configuration will be lost.
Are you sure you want to reload the switch? [y/n]:y
The system is going down for reload NOW !!
Step 3: Wait for all nodes to come up after reload until post-boot
processing is completed.
Switches are fully up once the logs noted below are shown on the console.
2014/01/12-06:42:38, [HASM-1110], 78784, INFO, VDX6710-54, Configuration replay has
completed on the system.
**********************************************************************
System initialization is complete. NOS is ready to handle all commands <- shown on
6710-54 only
**********************************************************************
In this example, for Group A edge aggregation nodes adjacent to RB1 (RB2
and RB3), the following changes occur:
RB2 connects to RB1 through dual 10-Gb ISL links (20 Gb trunk): both ports
ten 2/0/3 and ten 2/0/4 are un-shut on RB2 in this step.
RB3 connects to RB1 through dual 10-Gb ISL links (20 Gb trunk): both ports
are un-shut on RB3 in this step.
EDGE_AGG_RB2(conf-if-te-2/0/4)# no shut
2014/01/12-06:42:35, [SNMP-1007], 148424, INFO, EDGE_AGG_RB2, The last fabric change
happened at: Sun Jan 12 06:42:32 2014
TenGigabitEthernet
2/0/4 is administratively up.
INFO
TenGigabitEthernet
2/0/4 is online.
TenGigabitEthernet
TenGigabitEthernet
2/0/4 is online.
2014/01/12-06:42:36, [SSMD-1312], 148429, INFO, EDGE_AGG_RB2, CEEMap _vcs_cee
assigned to
interface TenGigabitEthernet 0/4.
ten 2/0/3
TenGigabitEthernet
EDGE_AGG_RB2, Interface TenGigabitEthernet 2/0/3 is online.
EDGE_AGG_RB3,
Interface TenGigabitEthernet 3/0/4 is administratively up.
INFO
TenGigabitEthernet
3/0/4 is online.
84

53-1003479-01
TenGigabitEthernet
TenGigabitEthernet
3/0/4 is online.
assigned to
EDGE_AGG_RB3(conf-if-te-3/0/4)# 2014/01/12-06:42:27, [SNMP-1007], 30004, INFO,
EDGE_AGG_RB3, The last fabric change happened at: Sun Jan 12 06:42:26 2014
TenGigabitEthernet
INFO
TenGigabitEthernet
3/0/3 is online.
TenGigabitEthernet
TenGigabitEthernet
3/0/3 is online.
assigned to
Activity on RB1:
After enabling the ISLs from adjacent edge aggregation nodes (RB2 and RB3)
above corresponding interface up logs are observed on RB1. Once the ISLs are
up, RB1 re-joins the fabric as shown in the output below.
NOTE
The remaining switches in Group A are still isolated.
EDGE_AGG_RB1# 2014/01/12-06:42:25, [NSM-1001], 69582, DCE, INFO, EDGE_AGG_RB1,
Interface
2014/01/12-06:42:26, [NSM-1002], 69583, DCE, INFO, EDGE_AGG_RB1, Interface
2014/01/12-06:42:26, [NSM-1001], 69585, DCE, INFO, EDGE_AGG_RB1, Interface Vlan 4093
is online.
2014/01/12-06:42:27, [SSMD-1312], 69586, DCE, INFO, EDGE_AGG_RB1, CEEMap _vcs_cee
assigned
to interface TenGigabitEthernet 1/0/6.
assigned
to interface TenGigabitEthernet 1/0/5.
assigned to
interface TenGigabitEthernet 1/0/4.

53-1003479-01
85
Task 5: Rejoin Upgrade Group to the Fabric

.
EDGE_AGG_RB1# show fabric all

VCS Id: 1
Rbridge-id
WWN
IP Address
Name
---------------------------------------------------------------------------1
10:00:00:27:F8:3A:46:A8
10.18.125.85
"EDGE_AGG_RB1"*
2
10:00:00:27:F8:66:3A:D8
10.18.125.86
"EDGE_AGG_RB2"
3
10:00:00:27:F8:3A:38:F8
10.18.125.87
"EDGE_AGG_RB3"
5
10:00:00:05:33:B6:55:CF
10.17.0.65
"EDGE_RB5"
6
10:00:00:05:33:DF:1E:83
10.18.125.80
"EDGE_RB6"
8
10:00:00:05:33:F6:58:97
10.18.125.88
"EDGE_RB8"
9
10:00:00:05:33:74:E2:FA
10.18.125.89
"EDGE_RB9"
11
10:00:00:05:33:87:3A:F1
10.18.125.91
"EDGE_RB11"
12
10:00:00:05:33:F2:DC:A1
10.18.125.92
"EDGE_RB12"
14
10:00:00:27:F8:07:0E:1B
10.18.125.94
"EDGE_RB14"
15
10:00:00:05:33:EC:2C:D2
10.18.125.95
"EDGE_RB15"
16
10:00:00:05:33:5E:F7:83
10.18.124.106
>"EDGE_RB16"
17
10:00:00:05:33:A2:7B:30
10.18.124.238
"EDGE_RB17"
18
10:00:00:05:33:F6:54:97
10.18.125.44
"EDGE_RB18"
20
10:00:00:05:33:F6:A6:4F
10.18.125.43
"EDGE_RB20"
21
10:00:00:05:33:DE:6C:16
10.18.125.33
"EDGE_RB21"
23
10:00:00:05:33:EC:7D:2E
10.18.125.45
"EDGE_RB23"
24
10:00:00:05:33:DE:63:F1
10.18.124.166
"EDGE_RB24"
Task 5: Rejoin Upgrade Group to the Fabric

Step 1: Enable ISLs from ToR nodes to the edge aggregation node for the node group.
Enter the no shut command for ports that were disabled in Step 7.
86

53-1003479-01
Task 6: Enable Edge Interfaces In the Upgrade Group
In this example, the ISL from RB4 to RB1 is unshut allowing RB4 to rejoin the fabric. This step is to be
repeated on each node in the upgrade group after reload.
EDGE_RB4# conf t
EDGE_RB4(conf-if-te-4/0/49)# no shut
2014/01/12-06:45:03, [NSM-1019], 78787, DCE, INFO, EDGE_RB4, Interface
TenGigabitEthernet
2014/01/12-06:45:03, [NSM-1027], 78788, DCE, INFO, EDGE_RB4, SFP transceiver for
interface
TenGigabitEthernet 4/0/49 is removed.
EDGE_RB4(conf-if-te-4/0/49)# 2014/01/12-06:45:04, [NSM-1026], 78789, DCE, INFO,
EDGE_RB4,
SFP transceiver for interface TenGigabitEthernet 4/0/49 is inserted.
TenGigabitEthernet
4/0/49 is online.
TenGigabitEthernet
TenGigabitEthernet
4/0/49 is online.
2014/01/12-06:45:04, [NSM-1001], 78793, DCE, INFO, EDGE_RB4, Interface Vlan 4093 is
online.
2014/01/12-06:45:05, [SSMD-1312], 78794, DCE, INFO, EDGE_RB4, CEEMap _vcs_cee
assigned to
interface TenGigabitEthernet 4/0/49.
Step 2: Enable ISLs from ToR to ToR nodes.

Enter the no shut command for ports that were disabled in Step 5. In this
example, RB 5 port 5/0/50 connected to RB4 is un-shut . The ToR-to-ToR ISL
connection is brought back into service. Repeat this all ToR-to-ToR connections.
A log confirming that the interface is online is displayed, as shown below.
EDGE_RB5(conf-if-te-5/0/50)# no shut
TenGigabitEthernet 5
/0/50 is administratively up.
INFO
TenGigabitEthernet
5/0/50 is online.
TenGigabitEthernet
TenGigabitEthernet
5/0/50 is online.
2014/01/12-06:47:56, [SSMD-1312], 2264108, INFO, EDGE_RB5, CEEMap _vcs_cee assigned
to
Task 6: Enable Edge Interfaces In the Upgrade Group

Step 3: Enable edge-facing interfaces on ToR nodes for the upgrade group.
In this example, the physical (server-facing) interfaces shutdown in Step 3 are brought up
administratively.
NOTE
L2 protocol will remain down since the port-channels are still shutdown.

53-1003479-01
87
The configuration change in this step was performed through cut and paste to the console.
EDGE_RB4# conf t
EDGE_RB4(config)# int gig 4/0/1
EDGE_RB4(conf-if-gi-4/0/1)# no shut
2014/01/12-06:50:41, [NSM-1019], 78800, DCE,
GigabitEthernet
2014/01/12-06:50:41, [NSM-1019], 78801, DCE,
GigabitEthernet
2014/01/12-06:50:41, [NSM-1019], 78802, DCE,
GigabitEthernet
2014/01/12-06:51:01, [NSM-1019], 78847, DCE,
GigabitEthernet
INFO, EDGE_RB4,
Interface
INFO, EDGE_RB4,
Interface
INFO, EDGE_RB4,
Interface
INFO, EDGE_RB4,
Interface
Step 4: Enable port-channels on the ToR nodes for the upgrade group.
In this example, the server-facing port channel interfaces shutdown in Step 4
are brought into service and RB4 rejoins the VLAGs with RB5 and RB6. The
configuration change in this step was performed through cut and paste to the
console. Logs indicating that the RB has formed VLAGs are displayed as
shown below.
EDGE_RB4# conf t
EDGE_RB4(config)# int port-channel 1
EDGE_RB4(config-Port-channel-1)# no shut
2014/01/12-06:54:29, [NSM-1019], 78848, DCE, INFO, EDGE_RB4,
1 is
administratively up.
GigabitEthernet
4/0/1 is online.
2 is
administratively up.
GigabitEthernet
4/0/2 is online.

joined Portchannel 1. Port-channel is a vLAG with RBridge IDs 5 4.
GigabitEthernet
GigabitEthernet
88
Interface Port-channel
Interface
Interface Port-channel
Interface
RBridge ID 4 has
Interface
Interface

53-1003479-01
4/0/1 is online.
.
2014/01/12-06:54:30, [NSM-1023], 2264109, INFO, EDGE_RB5,

Portchannel 2. Port-channel is a vLAG with rBridge IDs 5 4.
2014/01/12-06:54:31, [NSM-1023], 2264110, INFO, EDGE_RB5,
2014/01/12-06:54:31, [NSM-1023], 2264111, INFO, EDGE_RB5,
Portchannel 4. Portchannel is a vLAG with rBridge IDs 5 4.
2014/01/12-06:54:32, [NSM-1023], 2264112, INFO, EDGE_RB5,
Portchannel 3. Portchannel is a vLAG with rBridge IDs 5 4.
2014/01/12-06:54:34, [NSM-1023], 2264113, INFO, EDGE_RB5,
2014/01/12-06:54:36, [NSM-1023], 2264114, INFO, EDGE_RB5,
2014/01/12-06:54:36, [NSM-1023], 2264115, INFO, EDGE_RB5,
2014/01/12-06:54:37, [NSM-1023], 2264116, INFO, EDGE_RB5,
2014/01/12-06:54:37, [NSM-1023], 2264117, INFO, EDGE_RB5,
2014/01/12-06:54:38, [NSM-1023], 2264118, INFO, EDGE_RB5,
2014/01/12-06:54:40, [NSM-1023], 2264119, INFO, EDGE_RB5,
2014/01/12-06:54:41, [NSM-1023], 2264120, INFO, EDGE_RB5,
2014/01/12-06:54:42, [NSM-1023], 2264121, INFO, EDGE_RB5,
2014/01/12-06:54:42, [NSM-1023], 2264122, INFO, EDGE_RB5,
2014/01/12-06:54:43, [NSM-1023], 2264123, INFO, EDGE_RB5,
Port-
rBridge ID 4 has joined


Step 5: Enable port channel on edge VCS that connects to the core.
After un-shutting the physical interface and port channel on RB1 of VCS1, RB1
reforms the vLAG with RB2 and RB3.
EDGE_AGG_RB1# conf t
EDGE_AGG_RB1(config)# interface Port-channel 1000
EDGE_AGG_RB1(config-Port-channel-1000)# no shut
2014/01/12-06:56:59, [NSM-1019], 69630, DCE, INFO, EDGE_AGG_RB1, Interface Portchannel
1000 is administratively up.
EDGE_AGG_RB1(config-Port-channel-1000)# 2014/01/12-06:57:00, [NSM-1002], 69632, DCE,
INFO,
EDGE_AGG_RB1, Interface TenGigabitEthernet 1/0/1 is protocol down.
2014/01/12-06:57:01, [NSM-1023], 69633, DCE, INFO, EDGE_AGG_RB1, RBridge ID 1 has
joined
Port-channel 1000. Port-channel is a vLAG with RBridge IDs 2 3 1.
2014/01/12-06:57:01, [NSM-1001], 69635, DCE, INFO, EDGE_AGG_RB1, Interface Portchannel
1000 is online.

53-1003479-01
89

Refer to the section Verifying the Upgrade on page 22 section for details about how to confirm that the
upgrade completed successfully.
Task 8: Upgrade the Remaining Groups

Perform Task 2 through 7 to upgrade the nodes in each of the remaining upgrade groups.
90

53-1003479-01

Vcs Nos Upgrade DP

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Vcs Nos Upgrade DP

Загружено:

Авторское право:

Доступные форматы

53-1003479-01

Brocade VCS Network OS

2014, Brocade Communications Systems, Inc. All Rights Reserved.

Chapter 2: Upgrade Procedure Summaries.............................................................................. 13

Example A: Release 4.1.1 to 5.0.0 (Logical Chassis)................................................................25

Example B: Release 4.0.1 to 4.0.1c (Logical Chassis)..............................................................37

Example C: Release 3.0.1 to 4.0.1 (Fabric Mode).................................................................... 59

Example D: Release 2.11a to 3.01c........................................................................................ 75

Brocade VCS Network OS Upgrade Deployment Guide

Brocade VCS Network OS Upgrade Deployment Guide

Brocade VCS Network OS Upgrade Deployment Guide

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 1: Upgrade Planning

Brocade VDX 6710-54

Brocade VCS Network OS Upgrade Deployment Guide

Upgrade Paths and Methods

Upgrade Paths and Methods

Current version loaded on the nodes

Effect of Version Changes on Configuration

Upgrade Paths without Configuration Loss

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 1: Upgrade Planning

Recommended Upgrade Method

Procedure for Upgrading Odd/Even

Procedure for Upgrading Odd/Even

Procedure for Upgrading Odd/Even

Brocade VCS Network OS Upgrade Deployment Guide

Procedure for Upgrading Odd/Even

Chapter 1: Upgrade Planning

TABLE 1 Version Changes that Preserve Existing Connfiguration (Continued)

Recommended Upgrade Method

Procedure for Upgrading Odd/Even

Release 4 ISSU hardware

Release 4 ISSU firmware version

Upgrading Odd/Even Nodes (without

Upgrading One Node at a Time (with

Upgrade Paths with Configuration Loss

Procedure for Upgrading Odd/Even

Brocade VCS Network OS Upgrade Deployment Guide

Upgrade Using HA Topology

TABLE 2 Version Changes Resulting in Loss of Configuration (Continued)

Procedure for Upgrading Odd/Even

Disruptive upgrade using coldboot

Upgrade Using HA Topology

HA Topology Helps Maintain Traffic Forwarding During Upgrade:

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 1: Upgrade Planning

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 2: Upgrade Procedure Summaries

Preparing for the Upgrade

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 2: Upgrade Procedure Summaries

Brocade VCS Network OS Upgrade Deployment Guide

In-Service Software Upgrade Overview

In-Service Software Upgrade Overview

Brocade VCS Network OS Upgrade Deployment Guide

ISSU Hardware and Version Requirements

ISSU Hardware and Version Requirements

ISSU Features and Limitations

No data path disruption occurs for Layer 2 and FCoE traffic.

Brocade VCS Network OS Upgrade Deployment Guide

Chapter 2: Upgrade Procedure Summaries

Task 1: Prepare for the Upgrade