Reset Search
 

 

Article

NOS Firmware Upgrade Best Practices

« Go Back

Information

 
TitleNOS Firmware Upgrade Best Practices
Symptoms
Prior to upgrading a VCS fabric, it is recommended to review/check the following:
  1. Field Notices which can affect the firmware upgrade process
  2. Console connection to each switch if possible to allow recovery if needed
  3. Backup switch configurations to FTP/SCP server
  4. Gather data from each switch to allow GTAC to check each switch's health to ensure a successfully upgrade.
  5. Collect environment outputs for before and after firmware upgrade connectivity validation
Environment
  • VDX platforms
Cause


 
Resolution

Prior to upgrading a VCS fabric, it is recommended to review/check the following:

  1. Field Notices which can affect the firmware upgrade process:

  1. Console connection to each switch if possible to allow recovery if needed

  2. Backup switch configurations to FTP/SCP server

    If VCS is in Logical Chassis mode, then the configuration only needs to be backed up from the principal switch
  • copy running-config ftp://login:password@x.x.x.x/path/config.txt
If VCS is in Fabric mode, then the configuration needs to be backed up from each switch
  • copy running-config ftp://login:password@x.x.x.x/path/config.txt
  1. Collect environment outputs for before and after firmware upgrade connectivity validation

  • term len 0
  • show fabric all
  • show fabric isl all
  • show port-channel summary
  • show ip interface brief rb all
  • show ip interface brief rb all | ex down
  • show fabric route topology
  • show mac-address-table dynamic
  • show interface status
  • show fcoe login
  1. Gather data from each switch to allow Extreme GTAC to check each switch's health to ensure a successfully upgrade.

  • Both GOS (Guest OS) are HA synced
    • show version output contains both GOS 
  • Multicast root is the current principal switch
    • show vcs and show fabric all show same RB as principal
    • show fabric route multicast shows principal RB as multicast root
  • Current principal priorities are unique
    • show run rb logical
  • Run 'unhide foscmd' to access the below outputs as root
sw0# unhide foscmd
Password: ******** (fibranne)
  • Disk space usage
    • fos df -h shows usage less than 80%
    • fos df -i shows usage less than 80%
  • Existence of config cleanup file if write erase was executed in the past due to DEFECT000630071 where the below files were not fully cleaned up on all 4 partitions. As a result, upon bootup after a partition swap from a firmware upgrade, the configuration is defaulted. Execute the below to check for the existence of the '.__dcmccm__cfgonlycleanupreqd' files in each GOS partition. 
    • 6740/6940 (SW/0: 127.2.1.0, SW/1: 127.2.2.0)
      • fos /usr/bin/rsh 127.2.1.0 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd
      • fos /usr/bin/rsh 127.2.2.0 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd
    • 8770-4 (MM1: 127.2.1.1, MM2: 127.2.1.2)
      • fos /usr/bin/rsh 127.2.1.1 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd
      • fos /usr/bin/rsh 127.2.1.2 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd
    • 8770-8 (MM1: 127.2.1.15, MM2: 127.2.1.16)
      • fos /usr/bin/rsh 127.2.1.15 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd
      • fos /usr/bin/rsh 127.2.1.16 ls -lh /etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd /mnt/etc/fabos/Dcmd/.__dcmccm__cfgonlycleanupreqd

Step #4 and #5 data can be collected via the below expect script which can be executed on a Linux system. 

  • vdx_firmware_upgrade_prep.expect
    • vdx_firmware_upgrade_prep.6740-6940.expect
    • vdx_firmware_upgrade_prep.8770-4.expect
    • vdx_firmware_upgrade_prep.8770-8.expect
  • Update the password variable in expect script with the switch password
$ head vdx_firmware_upgrade_prep.expect
...
### UPDATE Password ####
set pass password;

Usage: vdx_firmware_upgrade_prep.expect <vdx_user> <vdx_switch_ip>

Log file: <ip_date>.log will be created in the local Linux directory. 

Example: ./vdx_firmware_upgrade_prep.expect admin 10.26.143.84
...
##################################################################################
#
# OUTPUT SAVED TO FILE: /home/gtac/10.26.143.84_2018-09-30.log
#
##################################################################################

 

When ODD/EVEN approach is used for upgrading, the principal switch should always be upgraded last and in the following order:

  1. Upgrade switches with ODD RB_ID excluding principal switch
  2. Upgrade switches with EVEN RB_ID excluding principal switch
  3. Once ODD and EVEN switches are on the new firmware, upgrade the principal switch
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255