1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Cisco Nexus 9000シリーズのNX-OSアップグレード手順まとめ

1
Last updated at Posted at 2026-10-14

はじめに

本記事では、Cisco Nexus 9000シリーズで使用されるOS「NX-OS」のバージョンアップ方法について、事前の計画から実際のアップグレード作業まで、一連の流れを解説します。

NX-OSのアップグレードには、対象バージョンの選定、アップグレードパスの確認、ISSU(In-Service Software Upgrade)の対応可否、EPLDの更新など、事前に確認すべき事項が数多くあります。

Cisco公式ドキュメントには必要な情報が掲載されていますが、複数のドキュメントに分散しているため、初めてアップグレードを実施する場合は、全体像を把握するだけでも一苦労です。

そこで、本記事ではアップグレードの計画から実施までに必要な情報を整理しました。

この記事を一通り読んでいただければ、Cisco公式ドキュメントの内容も理解しやすくなると思います。

(本当はCiscoが必要な情報を網羅的に整理した資料を提供してくれればよいのですが……。)

注意

本記事はNexus 9000シリーズのNX-OSモードを対象としています。

実際のアップグレード手順やISSUの対応状況は、機種、ハードウェア構成、NX-OSバージョン、使用している機能によって異なります。

本記事のコマンドは実行例です。作業時には、必ず対象バージョンの公式ドキュメントを確認してください。

バージョンアップ前に行うこと(机上確認)

まずは、アップグレード計画を立てるために必要な情報を収集します。

ライフサイクルポリシーの確認

最初に、NX-OSのバージョン命名規則やライフサイクルポリシーについて理解しておきましょう。

NX-OSには複数のリリース系列があり、それぞれサポート期間やメンテナンス方針が異なります。

長期的な運用を考えるうえでも、リリース体系やサポートポリシーを把握しておくことが重要です。

参考資料

Cisco Community:NX-OSソフトウェアのリリースとバージョンサポートポリシーについて

利用中のOSバージョンのEOL確認

ライフサイクルポリシーを理解したら、現在利用しているNX-OSバージョンのEOL(End of Life)を確認します。

EOLに関するアナウンスには、販売終了日、ソフトウェアメンテナンス終了日、最終サポート日など、複数の重要な日付が含まれています。

これらの日付を確認し、サポート終了前にアップグレードを完了できるよう計画を立てましょう。

個人的には、検証やトラブル発生時の対応期間を確保するため、最終サポート日の少なくとも3か月前にはアップグレードを完了できるスケジュールが望ましいと考えています。

参考資料

Cisco:Nexus 9000シリーズ EoS/EoL Notice一覧

推奨リリースバージョンの確認

次に、Ciscoが推奨するNX-OSのバージョンを確認します。

Ciscoは、Nexus 9000シリーズ向けに推奨リリースを公開しています。

2026年10月15日時点で確認できるCisco公式ドキュメント(2026年6月4日更新)では、以下のバージョンが推奨されています。

対象ハードウェア 推奨リリース
NX-OS 10.5(x)対応機種 10.5(5)M
10.5(x)非対応で10.4(x)対応の機種 10.4(7)M
10.4(x)非対応のEXシリーズ 10.3(8)M
NX-OS 10.x非対応でサポート期間内の機種 9.3(16)

ただし、推奨リリースは更新されるため、アップグレード計画を立てる際には必ず最新情報を確認してください。

また、推奨バージョンであっても、利用しているハードウェアや機能によっては適用できない場合があります。

参考資料

Cisco:Recommended Cisco NX-OS Releases for Cisco Nexus 9000 Series Switches

ISSUについて

NX-OSでは、ISSU(In-Service Software Upgrade)と呼ばれる機能を利用することで、データトラフィックへの影響を抑えながらOSをアップグレードできます。

ISSUには、大きく分けて以下の2種類があります。

  • 標準ISSU(Standard ISSU)
  • 拡張ISSU(Enhanced ISSU)

拡張ISSUでは、Linux Container(LXC)を利用したアーキテクチャにより、アップグレード時のコントロールプレーンへの影響を低減します。

ただし、ISSUの利用可否はハードウェアやNX-OSバージョン、使用中の機能によって異なります。

また、ISSUを利用できる場合でも、すべての通信が必ず無影響になるとは限りません。事前の互換性確認と検証が重要です。

ISSUの仕組みや標準ISSUと拡張ISSUの違いについては、以下の記事にまとめています。

参考資料

Cisco:Nexus 9000シリーズ NX-OSソフトウェアアップグレードおよびダウングレードガイド

ターゲットOSバージョンの選定とリリースノートの確認

推奨リリースやライフサイクルを踏まえ、アップグレード先となるNX-OSのバージョンを決定します。

ターゲットバージョンを選定したら、該当バージョンのリリースノートを確認し、以下の事項を整理・評価します。

  • 新機能や仕様変更の有無
  • 修正された不具合(Resolved Caveats)
  • 既知の不具合(Open Caveats)
  • ハードウェアとの互換性
  • 使用している機能のサポート状況
  • アップグレード時の制約事項
  • セキュリティ上の問題や修正状況

個人的には、アップグレード計画の中で最も時間を要する工程だと考えています。

特に重要なのは、既知の不具合が現在の環境に影響するかどうかの評価です。

単純に最新版を選ぶのではなく、既存環境との互換性や不具合の影響を踏まえて、適切なバージョンを選定しましょう。

参考資料

Cisco:Nexus 9000シリーズ 製品サポート

アップグレードパスの確認

ターゲットOSバージョンが決まったら、現在のバージョンから直接アップグレードできるか確認します。

NX-OSでは、バージョンの組み合わせによって直接アップグレードできない場合があり、中間バージョンを経由する必要があります。

また、直接アップグレードできる場合でも、ISSUによる無停止アップグレードがサポートされているとは限りません。

そのため、以下の事項を確認しておきましょう。

  • 直接アップグレードが可能か
  • 中間バージョンへのアップグレードが必要か
  • ISSUを利用できるか
  • Disruptive Upgrade(通信断を伴うアップグレード)が必要か

Ciscoが公開しているISSU Matrixで、アップグレードパスとISSUの対応状況を確認できます。

参考資料

Cisco:Nexus 9000 and 3000 Upgrade and ISSU Matrix

インストール・アップグレードガイドの確認

次に、ターゲットバージョンのインストール方法とアップグレード手順を確認します。

Cisco公式のアップグレードガイドには、コマンドの実行方法だけでなく、事前条件や制約事項、注意点なども記載されています。

特に、利用している機能によってISSUが制限される場合があるため、該当する項目は必ず確認しておきましょう。

参考資料

Cisco:Nexus 9000シリーズ インストールおよびアップグレードガイド

ターゲットバージョンのEPLD確認

NX-OSのアップグレードとあわせて、EPLD(Electronic Programmable Logic Device)の更新についても確認します。

EPLDは、スイッチ内部のプログラマブルロジックデバイスに関するファームウェアです。

Ciscoでは、ハードウェア機能の強化や既知の問題の修正を目的として、EPLDのアップデートを提供しています。

OSのバージョンアップ時には、EPLDについても更新の必要性を確認しておくことをお勧めします。

ただし、EPLDの更新にはモジュールのリロードやサービスへの影響が伴う場合があります。

そのため、事前にリリースノートを確認し、通信影響を評価したうえで実施可否を決定してください。

なお、NX-OS 10.5(3)F以降ではEPLDイメージがNX-OSイメージに同梱される方式に変更されています。

このため、従来のようにEPLDのイメージファイルを別途取得する手順が適用されない場合があります。

また、一部の機種では個別のEPLD更新手順が必要になるため、ターゲットバージョンのガイドを確認してください。

参考資料

Cisco:Nexus 9000シリーズ FPGA/EPLDアップグレードリリースノート 10.2(3)

Cisco:Nexus 9000シリーズ FPGA/EPLDアップグレードリリースノート 10.5(5)M

バージョンアップ前に行うこと(実機確認)

机上での評価が完了したら、続いて実機での事前確認を行います。

まずは、以下のファイルや情報を準備しておきましょう。

  • ターゲットOSのbinファイル
  • ターゲットOSのハッシュ値
  • EPLDのimgファイル(必要なバージョンのみ)
  • EPLDのハッシュ値(必要なバージョンのみ)

また、作業前には現行のコンフィグレーションをバックアップし、障害発生時の復旧手順も準備しておくことをお勧めします。

現在のOSバージョンの確認

現在稼働しているNX-OSのバージョンを確認します。

show version

ハードウェア情報や稼働時間などもあわせて確認しておきましょう。

現在のEPLDバージョンの確認

現在のEPLDバージョンを確認します。

show version module 1 epld

上記はモジュール1を確認する例です。

モジュラー型の機器などでは、対象モジュールに合わせて番号を変更してください。

OS・EPLDイメージのアップロード

事前に取得したOSイメージと、必要に応じてEPLDイメージをNexusにアップロードします。

ファイル転送にはTFTP、SCP、SFTPなどを利用できます。

個人的には、TFTPサーバーを別途用意するよりも、NexusのSFTPサーバー機能を利用する方法をお勧めします。

以下のコマンドでSFTPサーバー機能を有効化できます。

configure terminal
feature sftp-server
end

その後、WinSCPなどのSFTPクライアントを利用してファイルを転送します。

SFTPを利用するメリットは以下のとおりです。

  • TCPによる信頼性の高いファイル転送が可能
  • SSHによる通信の暗号化に対応
  • WinSCPなどのGUIツールから操作できる

ただし、SFTPでも転送中断などによってファイルが不完全になる可能性があります。

そのため、転送後は必ずハッシュ値を確認してください。

また、SFTPサーバー機能が作業後に不要になる場合は、組織のセキュリティポリシーに従って無効化を検討してください。

ハッシュ値の確認

アップロードしたファイルが破損していないことを確認するため、ハッシュ値を照合します。

以下はSHA-512を利用した確認例です。

OSイメージ

show file bootflash:nxos64-cs.10.x.x.M.bin sha512sum

EPLDイメージ

show file bootflash:n9000-epld.10.x.x.M.img sha512sum

※ファイル名は実際に取得したイメージファイルに置き換えてください。

コマンドの実行結果とCiscoのソフトウェアダウンロードページで公開されているハッシュ値を比較し、一致していることを確認します。

ストレージ使用率の確認

アップグレード前に、ストレージの空き容量を確認します。

dir bootflash:

また、内部ファイルシステムの使用率についても確認しておくことをお勧めします。

show system internal flash

特に、/nxos/tmp ディレクトリの使用率が高い場合、アップグレード時の事前チェックなどでエラーが発生する可能性があります。

そのため、事前に使用率を確認しておきましょう。

注意

/nxos/tmp 配下には、システムが利用するファイルが存在する場合があります。

ファイル名やサイズだけを根拠に削除すると、予期しない問題を引き起こす可能性があります。

使用率が高い場合でも安易に削除せず、原因と対象ファイルの用途を確認してください。判断が難しい場合はCisco TACへの問い合わせをお勧めします。

互換性チェックおよびISSU対応可否の確認

次のコマンドで、ターゲットOSとの互換性とISSUの対応可否を確認します。

show install all impact nxos bootflash:nxos64-cs.10.x.x.M.bin non-disruptive

コマンド実行結果のImpact列を確認してください。

  • non-disruptive:無停止アップグレードが可能と判定された状態
  • disruptive:通信への影響を伴うアップグレードと判定された状態

ただし、non-disruptiveと表示された場合でも、すべてのトラフィックや制御プロトコルが完全に無影響であることを保証するものではありません。

実際のサービス影響については、利用している機能やネットワーク構成を踏まえて評価してください。

設定変更セッションの確認

アップグレード中に別のユーザーが設定変更を行わないよう、事前にアクティブな設定変更セッションが存在しないことを確認します。

show configuration session summary

設定変更が行われていないことを確認したうえで、アップグレードを実施しましょう。

OnePKの無効化確認

OnePKが有効な場合、ISSUはサポートされません。

そのため、次のコマンドでOnePKが無効化されていることを確認します。

show feature | include onep

該当機能がdisabledとなっていることを確認してください。

ただし、OnePKが無効であれば必ずISSUを実施できるというわけではありません。

その他の事前条件についても確認が必要です。

参考資料

Cisco:Cisco's onePK Introduction

boot poapの無効化確認

boot poap enableが設定されている場合、ISSUがブロックされます。

次のコマンドで設定状況を確認します。

show boot

boot poap enableが設定されていないことを確認してください。

boot modeの確認

現在のブートモードを確認します。

show boot mode

標準ISSUと拡張ISSUでは、使用するブートモードが異なります。

特にvPC構成の場合、ISSU実施前に両ピアのブートモードが一致していることを確認してください。

なお、対応する機種とNX-OSバージョンによっては、LXCモードが必須となります。

詳細については後述します。

Spanning Treeの確認

Spanning Treeを利用している環境では、ISSU実施前にトポロジの状態を確認する必要があります。

次のコマンドで、Spanning Treeの観点からISSUを実施できるか確認します。

show spanning-tree issu-impact

Ciscoのアップグレードガイドでは、主に以下の事項が確認条件として挙げられています。

  • STPインスタンスでトポロジ変更が発生していないこと
  • Bridge Assurance(BA)の設定がISSUの制約に抵触しないこと
  • Non-Edge Designated Forwarding Portが制約に抵触しないこと
  • vPC構成の場合、対向ピアもISSUの条件を満たしていること

※vPC Peer Linkなど、一部のポートは条件の例外として扱われます。

実際の対応可否は、対象バージョンのアップグレードガイドとコマンドの実行結果を確認して判断してください。

running-configの保存

アップグレード前に、running-configをstartup-configへ保存します。

copy running-config startup-config

あわせて、現在のコンフィグレーションを外部の管理サーバーなどへバックアップしておくことをお勧めします。

その他の事前確認

ここまでに紹介した項目以外にも、環境に応じて以下の情報を取得しておくと、アップグレード前後の比較や障害発生時の原因調査に役立ちます。

show module
show interface status
show port-channel summary
show vpc
show vpc brief
show logging last 100

また、BGPやOSPFなどのルーティングプロトコルを利用している場合は、それぞれのネイバー状態も確認しておきましょう。

アップグレード前の正常な状態を記録しておくことが、作業後の正常性確認で重要になります。

NX-OSのアップグレード

事前確認が完了し、問題がないことを確認したら、NX-OSのアップグレードを実施します。

ISSUを利用したアップグレード

ISSUがサポートされている場合は、以下のコマンドでアップグレードを実施します。

install all nxos bootflash:nxos64-cs.10.x.x.M.bin non-disruptive

non-disruptiveオプションを指定することで、無停止アップグレードを要求します。

ただし、実行前には必ず互換性チェックを完了させてください。

ISSUでは、データプレーンの転送を維持しながらソフトウェアを更新できますが、処理中はコントロールプレーンに一時的な影響が発生することがあります。

そのため、SSHによる管理アクセスが一時的に切断されたり、再接続できなくなったりする場合があります。

影響時間は標準ISSUと拡張ISSU、ハードウェア構成などによって異なるため、事前検証をお勧めします。

なお、ISSUを利用できない場合は、通信断を伴うアップグレード方式を選択する必要があります。

その場合は、対象バージョンのアップグレードガイドに従って実施してください。

vPC構成の場合

vPCを利用した冗長構成では、2台のNexusを個別にアップグレードします。

一方のNexusでアップグレードを実施しても、対向のvPCピアが自動的にアップグレードされるわけではありません。

そのため、以下の事項に注意してください。

  • Ciscoが指定するアップグレード順序を遵守する
  • 両ピアのブートモードとバージョン互換性を確認する
  • 片系のアップグレード後に通信状態やvPCの正常性を確認する
  • 問題がないことを確認してから、もう一方のアップグレードを実施する

特に、片系だけが新しいバージョンとなる期間が発生するため、その組み合わせがサポートされていることを事前に確認しておきましょう。

EPLDのアップグレード

EPLDのアップグレードが必要な場合は、OSのアップグレードとあわせて実施する方法があります。

以下は、NX-OSとEPLDのイメージが個別に提供されているバージョンでの実行例です。

install all nxos bootflash:nxos64-cs.10.x.x.M.bin epld bootflash:n9000-epld.10.x.x.M.img

この方法では、OSとEPLDをあわせて更新できますが、通信断を伴うアップグレードとなるため注意してください。

また、NX-OS 10.5(3)F以降ではEPLDがOSイメージに同梱されるため、上記の個別EPLD指定は使用しません。

EPLDの更新方法はバージョンや機種によって異なり、個別にinstall epldコマンドを実行する必要がある場合もあります。

必ず対象バージョンのEPLDアップグレードガイドを確認してください。

なお、冗長構成であっても、EPLD更新時の通信断が必ず短時間に収まるとは限りません。

業務への影響がある環境では、事前検証やメンテナンス時間の確保をお勧めします。

バージョンアップ後の確認

アップグレード完了後は、正常に更新されたことを確認します。

OSバージョンの確認

show version

ターゲットとして指定したNX-OSバージョンで起動していることを確認します。

EPLDバージョンの確認

EPLDを更新した場合は、対象モジュールのバージョンを確認します。

show version module 1 epld

インストール結果の確認

以下のコマンドで、アップグレード処理の結果を確認します。

show install all status

エラーが発生していないことを確認しましょう。

ネットワークの正常性確認

事前に取得した情報と比較し、ネットワークが正常に動作していることを確認します。

show module
show interface status
show port-channel summary
show vpc
show vpc brief
show logging last 100

必要に応じて、ルーティングプロトコルのネイバー状態や実際の通信についても確認してください。

特に重要なのは、OSのバージョンが正常に更新されているだけでなく、アップグレード前と同じ状態でネットワークサービスが提供されていることです。

NX-OSのダウングレード

NX-OSは、サポートされているバージョンの組み合わせであれば、ダウングレードすることも可能です。

基本的には、アップグレードと同様にinstall allコマンドを使用します。

install all nxos bootflash:nxos64-cs.10.x.x.M.bin

※ダウングレード先のOSイメージを指定してください。

ただし、ダウングレードはアップグレードと異なり、利用中の機能や設定が古いバージョンでサポートされていない可能性があります。

そのため、以下の事項について事前に確認する必要があります。

  • ダウングレード先のバージョンが対象機種に対応しているか
  • 現在利用している機能がサポートされているか
  • コンフィグレーションの互換性に問題がないか
  • ダウングレードパスがサポートされているか
  • 再起動や通信断による影響が許容できるか

また、NX-OSではISSD(In-Service Software Downgrade)による無停止ダウングレードはサポートされていません。

アップグレードと同じように無停止でダウングレードできるわけではないため、注意してください。

ダウングレード前の互換性確認

必要に応じて、以下のコマンドで互換性を確認します。

show incompatibility-all nxos bootflash:nxos64-cs.10.x.x.M.bin
show install all impact nxos bootflash:nxos64-cs.10.x.x.M.bin

なお、特定のリリース間ではダウングレードがサポートされない場合もあります。

実施前に必ずCisco公式のダウングレードガイドとリリースノートを確認してください。

その他の注意事項

EPLDのダウングレードについて

EPLDは、原則としてダウングレードを前提とした運用を避けることをお勧めします。

NX-OS自体をダウングレードできる場合でも、EPLDを同じように元のバージョンへ戻せるとは限りません。

EPLDのダウングレードが必要となった場合は、対象機種とバージョンのサポート状況を確認し、必要に応じてCisco TACに相談してください。

boot mode lxcについて

NX-OSのバージョンやハードウェアによっては、拡張ISSUで使用されるLXCモードが標準で有効化されます。

具体的には、以下のとおりです。

NX-OSバージョン 対象プラットフォーム 動作
10.3(3)F以降 Nexus 9300-FX3 / 9300-GX LXCモードが必須
10.4(1)F以降 Nexus 9300-FX / 9300-FX2 LXCモードが必須

これらの機種では、該当バージョン以降、通常モードへの切り替えがサポートされません。

そのため、アップグレード前後でブートモードが変わる場合があります。

特にvPC構成では、片系のアップグレードによって両ピアのブートモードが一時的に異なる可能性があります。

ただし、ブートモードが異なる状態での動作やISSUが常にサポートされるわけではありません。

事前に対応状況を確認し、Ciscoのアップグレード手順に従ってください。

参考資料

Cisco:Nexus 9000シリーズ NX-OS 10.4(x) アップグレードおよびダウングレードガイド

LACP Fast Timerについて

LACP Fast Timerを使用している場合、ISSUの制約に注意が必要です。

Ciscoのアップグレードガイドでは、LACP Fast Timerの設定が無停止ISSUの制約として挙げられています。

そのため、自装置だけでなく、対向装置を含めたLACPの設定状況を確認してください。

LACPのタイマー設定はリンクアグリゲーションの動作に関係するため、変更する場合は事前の影響評価が必要です。

HSRPのextended-holdについて

HSRPを利用している場合、ISSU実施時にhsrp timers extended-holdの設定が必要となる場合があります。

この設定は、ISSU中のHSRPの動作に関係するため、使用しているNX-OSのバージョンやネットワーク構成を踏まえて適用を判断してください。

特に、デフォルト値のままで問題がないか、タイマー変更による影響が発生しないかを確認しておくことが重要です。

参考資料

Cisco Community:Nexus 9000シリーズ hsrp timers extended-hold 利用上の注意事項

まとめ

本記事では、Cisco Nexus 9000シリーズのNX-OSアップグレードについて、計画段階から実際の作業までの流れを整理しました。

NX-OSのアップグレード自体は、それほど複雑なコマンド操作を必要としません。

一方で、バージョン選定やアップグレードパスの確認、ISSUの制約事項の把握など、事前準備には多くの時間を要します。

特に重要なのは、以下の3点です。

  1. ライフサイクルと既知の不具合を踏まえ、適切なOSバージョンを選定すること
  2. 使用している機能やハードウェア構成を踏まえ、ISSUの対応可否を確認すること
  3. アップグレード前後の正常性確認と、障害発生時の復旧手順を準備すること

適切な事前準備を行うことで、アップグレードに伴うリスクを低減できます。

本記事が、NX-OSのアップグレード計画や実際の作業を進める際の参考になれば幸いです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?