Cisco APIC インストール、アップグレード、ダウングレード ガイド

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco APIC インストール、アップグレード、ダウングレード ガイド

Chapter Title

Cisco APIC およびスイッチ ソフトウェアのアップグレードとダウングレード

Results

Updated:
April 27, 2021

Chapter: Cisco APIC およびスイッチ ソフトウェアのアップグレードとダウングレード

Cisco APIC およびスイッチ ソフトウェアのアップグレードとダウングレード

ファームウェア管理について

このガイドで使用されている「ファームウェア」という用語は、Cisco APIC のアプライアンス ファームウェアを指します。ファームウェアのアップグレードは、Cisco APIC GUI のメニュー バーで [管理 (ADMIN)] > [ファームウェア (Firmware)]を選択して行えます。4.x より前の APIC リリースでは、[ナビゲーション (Navigation)] ペインの [コントローラ ファームウェア (Controller Firmware)] を選択します。この用語は、CIMC、BIOS、LOM、および RAID コントローラ、および NIC/VIC PCI アダプタなどの、 Cisco APIC のコンポーネント ファームウェアと混同しないようにする必要があります。

バージョン名称

ファームウェアを管理するには、次の情報が必要です。

  • ファームウェア リポジトリ： ファームウェア リポジトリは、Cisco ACI ファブリックをアップグレードするために必要なファームウェア イメージを保存する分散ストアです。ファームウェア リポジトリは、クラスタ内のすべてのコントローラに同期されます。ファームウェア ソース ポリシーを設定した場合、ファームウェア イメージは、外部サーバ（HTTP または（SCP）からファームウェア リポジトリにダウンロードされます。リポジトリに保存可能なファームウェア イメージには 3 つの種類があります。

    • Cisco APICイメージ: このイメージは、Cisco アプリケーション ポリシー インフラストラクチャ コントローラ上で実行されるソフトウェアで構成されています (Cisco APIC)。

    • スイッチ イメージ: このイメージは、Cisco ACI スイッチ上で実行されるソフトウェアから構成されています。

    • カタログ イメージ: このイメージは、Cisco によって作成された内部ポリシーで構成されています。これらの内部ポリシーには、ハードウェアの各モデルの機能、ソフトウェアの異なるバージョン間の互換性、およびハードウェアと診断テストに関する情報が含まれます。このイメージは、通常一括でコントローラのイメージとともにアップグレードされます。特定のリリースのリリース ノートに具体的な指示がない限り、管理者はカタログ イメージを個別にアップグレードする必要はありません。

  • ファームウェア グループ、およびファームウェア ポリシー: ファームウェア グループは、スイッチのグループのファームウェア ポリシーを設定します。ファームウェア ポリシーは、グループのスイッチで、目的のファームウェア バージョンを指定します。

  • コントローラ ファームウェア ポリシーおよびコントローラ メンテナンス ポリシー： 4.x より前のリリースの APIC に適用されます。コントローラ ファームウェア ポリシーは、コントローラで必要なバージョンを指定します。コントローラ メンテナンス ポリシーでは、コントローラのアップグレードがいつ開始する必要がを指定します。コントローラ ファームウェア ポリシーとコントローラメンテナンス ポリシーは、クラスタ内のすべてのコントローラに適用されます。

  • メンテナンス グループおよびメンテナンス ポリシー： 4.x より前のリリースの APIC に適用されます。メンテナンス グループは、メンテナンス ポリシーを設定するスイッチのグループです。メンテナンス ポリシーは、アップグレードのスケジュールを指定します。

ファームウェアのアップグレード モード

Cisco APIC を使用してファームウェアをアップグレードする方法は、リリースによって異なります。

Cisco APIC 4.x より前のリリース

Cisco APIC GUI で、[管理 (Admin)] > [ファームウェア (Firmware)] > [ファブリック ノードのファームウェア (Fabric Node Firmware)] > [メンテナンス グループ (Maintenance Groups)] に移動してファームウェアをアップグレードできます。メンテナンス グループを選択し、[アクション (Actions)] メニューから [ワンタイム ウインドウ トリガーの作成 (Create One Time Window Trigger)] または [繰り返しウィンドウ トリガーの作成 (Create Recurring Window Trigger)]を選択して、アップグレードのスケジュールを設定します。

Cisco APIC を使用してファームウェアをアップグレードするには、2 つのモードがあります。

  • [即座にアップグレード (Upgrade immediately)]：このモードでは、ファームウェアのアップグレード プロセスを直ちに開始します。

  • [アップグレードをスケジュール (Schedule an upgrade)]：このモードでは、ファームウェアのアップグレードのスケジュールをそれ以後の日時に設定することができます。[スケジューラ (scheduler)] フィールドで、既存のトリガー スケジューラを選択するか、または [トリガースケジューラの作成 (Create trigger scheduler)] をクリックして新しいトリガー スケジューラを作成します。

Cisco APIC リリース 4.x 以降

Cisco APIC GUI で、[管理 (Admin)] > [ファームウェア (Firmware)] に移動してファームウェアをアップグレードできます。[インフラストラクチャ (Infrastructure)] タブをクリックし、[ノード (Nodes)] サブタブをクリックします。[アクション (Actions)] をクリックし、[ノードのアップグレードをスケジュール (Schedule Node Upgrade)] をクリックします。[アップグレード グループの名前 (Upgrade Group Name)] 領域で、既存のグループを選択するか、新しいグループを作成します。

Cisco APIC を使用してファームウェアをアップグレードするには、2 つのモードがあります。

  • [今すぐ (Now)]：このモードでは、ファームウェアのアップグレード プロセスを直ちに開始します。

  • [後日にスケジュール (Schedule for Later)]：このモードでは、ファームウェアのアップグレードのスケジュールをそれ以後の日時に設定することができます。[スケジューラ (scheduler)] フィールドで、既存のトリガー スケジューラを選択するか、または [トリガースケジューラの作成 (Create trigger scheduler)] をクリックして新しいトリガー スケジューラを作成します。

Cisco APIC およびスイッチ ソフトウェアのアップグレードまたはダウングレードに対する重要な注意事項

次に、Cisco APIC およびスイッチソフトウェアをアップグレードまたはダウングレードする前に理解しておくべき重要な注意事項を示します。

ファームウェア管理に関する重要な注意事項

  • 4.2(6) リリース以降、SNMPv3 は Secure Hash Algorithm-2（SHA-2）認証タイプをサポートします。Cisco APIC リリース4.2(6) 以降を実行していて、SHA- 2 認証タイプを使用している場合、Cisco APIC リリース4.2 (6) から以前のリリースにダウングレードすると、ダウングレードがブロックされ、次のエラー メッセージが表示されます。 
    SHA-2 authentication type is not supported.

    認証タイプを MD5 に変更するか、対応する SNMPv3 ユーザを削除して続行するかを選択できます。

  • Cisco APIC ノードの https://aciappcenter.cisco.com/ からアプリケーションを実行している場合は、次のようにします。

    • それらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする前に、これらのアプリケーションを無効にします。

    • これらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする際に、アプリをインストールしたり、削除したりしないでください。

    • これらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする際に、アプリ イメージのアップグレードを実行しないでください。

    • 3.2(1) リリース以前のリリースからアップグレードし、アップグレード前にアプリケーションがインストールされていた場合、アプリケーションは機能しなくなります。アプリケーションを再度使用するには、それらをアンインストールしてから再インストールする必要があります。

    ファブリック全体 (APIC ノードとスイッチ) の APIC ソフトウェアのアップグレードまたはダウングレードプロセスが完了したら、それらを無効にした場合は、アプリを再度有効にします。APIC ソフトウェアのアップグレードまたはダウングレードプロセスが完了した後、アプリケーションをインストールまたは削除したり、アプリ イメージのアップグレードを実行したりできます。

  • シスコは、Cisco Application Centric Infrastructure (ACI) の不具合 (CSCvs16767) を最近特定しました。スパイン スイッチからの fmgroup 更新を処理するときに、Multicast FIB Distribution (MFDM) プロセスがクラッシュします。この問題は、リモートのリーフ スイッチが 14.1(2) リリースからの直接トラフィック転送機能を備えており、スパイン スイッチから不明なタイプ/長さ/値 (TLV) を受信した場合に発生します。この状況は、読み取り可能なラベルスタック深度 (RLD) が有効になっていて、スパイン スイッチが 14.2(2) リリースにアップグレードされた場合に発生します。これにより、fmgroup メッセージに新しい TLV が追加されます。

    この問題を回避するには:

    • 14.1(2) リリースから 14.2(2) リリースにアップグレードする場合、直接トラフィック転送機能が有効になっているファブリック内にリモート リーフ スイッチがある場合は、最初にリモートリーフスイッチを 14.2(2) リリースにアップグレードしてから、スパイン スイッチをアップグレードします。通常のリーフ スイッチ (非リモート リーフ スイッチ) は、このバグの影響を受けません。

    • 14.1(2) リリースにダウングレードする場合、直接トラフィック転送機能が有効になっているファブリック内にリモート リーフ スイッチがある場合は、まずスパイン スイッチを 14.1(2) リリースにダウングレードしてから、リモート リーフ スイッチをダウングレードします。通常のリーフ スイッチ (非リモート リーフ スイッチ) は、このバグの影響を受けません。

  • APIC リリース 4.1 (1) および 4.1 (2) では、イーサネットのトランシーバーを検証するためのソフトウェアチェックが追加されています。リリース4.1 よりも前では、このチェックはソフトウェアには存在しませんでした。このチェックは、イーサネット ポートが正しく識別されるようにするために必要です。ソフトウェア チェックでファイバ チャネル SPROM 値を持つイーサネット トランシーバーが検出された場合、そのトランシーバーは検証チェックに失敗し、ダウン状態になります。イーサネットのすべてのイーサネットに誤ってプログラムされた SPROM が FC 準拠として識別される場合、これらのイーサネットは、トランシーバーの検証に失敗し、APIC リリース 4.1(1) および 4.1(2) での起動に失敗します。このシナリオでは、それぞれのベンダーに連絡して、プログラムされた SPROM 値を更新し、対処してください。

    予期されるイーサネット SPROM プログラミングを持つすべてのイーサネットトランシーバーは、アップグレード後も動作し続けるはずです。


    （注）  

    このイーサネット トランシーバー ソフトウェアチェックは、リリース 4.1(2) 以降の APIC リリースでは有効になりません。

  • /firmware パーティションが 75% を超えていないことを確認します。パーティションが 75％ を超えている場合は、リポジトリから未使用のファームウェア ファイルを一部削除する必要があります。これは、圧縮されたイメージを保存し、イメージを抽出するための適切なスペースを提供します。Cisco APIC はイメージを自動的に取得します。

  • Cisco APIC では、UEFI からのブートはサポートされていません。Cisco APIC は HDD (PCI RAID アダプタ) からの起動のみをサポートします。

  • リリース 2.1(4) 以降では、サードパーティ製ミクロンソリッドステートドライブ (SSD) ファームウェア自動更新のサポートが追加されました。標準的な Cisco APIC ソフトウェア アップグレードプロセスの一環として、アップグレード時にスイッチが再起動します。そのブート時のプロセスでは、システムは現在の SSD ファームウェアもチェックし、必要に応じて SSD ファームウェアへのアップグレードを自動的に実行します。システムが SSD ファームウェアのアップグレードを実行すると、スイッチは後でもう一度クリーン リブートします。

  • イーサネットの帯域内または帯域外アクセスを介したスイッチ アクセスができなくなった場合に備えて、アップグレードまたはダウングレード時にシリアル コンソール アクセスが必要です。

  • ファームウェアを使用して Cisco APIC をアップロードするときに、 GUI の 転送時間がウェブ トークンのタイムアウト値を超えると、ウェブ トークンがタイムアウトし、アップロードが失敗します。Cisco APIC GUI を使用してファームウェアをアップロードする前に、予想されるアップロード時刻以降にウェブ トークンのタイムアウト値を大きく必要があります。

Cisco APIC およびスイッチ ソフトウェアのアップグレードに関する重要な注意事項

  • GUI を使用してメンテナンス ポリシーを作成する場合、CLI を使用して同じポリシーを変更することはできません。同様に、CLI を使用してメンテナンス ポリシーを作成した場合、GUI を使用して同じポリシーを変更することはできません。

  • ACI スイッチをアップグレードしているときに、アップグレード プロセスの 80% に達した時点で、実際にはスイッチのアップグレードが完了してリロード処理中であるにもかかわらず、GUI に示されるアップグレード プロセスが 80 ～ 90% でフリーズすることがあります。アップグレード プロセスが正常に完了したことを確認できるように、表の右上隅にある [Refresh] ボタンをクリックしてスイッチの最新のステータスを取得してください。

  • ファブリックのいずれかのノードが Graceful Insertion and Removal（GIR）モードまたはメンテナンス モードの場合は、Cisco ACI ファブリックをアップグレードしないでください。ファブリックのいずれかのノードが GIR モードの場合にファブリックをアップグレードすると、たとえそのノードが現在のアップグレード グループの一部ではなくても、他のすべての接続されたノードがリロードされた後に、そのノードにアクセスできなくなります。

  • 複数のリーフ スイッチを同時にアップグレードしていて、各スイッチについて [Schedule Node Upgrade] 画面で [Graceful Maintenance] オプションを選択する場合、Cisco Application Policy Infrastructure Controller（Cisco APIC）に接続されているリーフ スイッチを別のメンテナンス グループに配置して、Cisco APIC に接続されているリーフ スイッチが一度にアップグレードされるようにする必要があります。

  • 一般に、ポッド内のすべてのスパイン スイッチを一度にアップグレードすることは推奨されませんが、マルチポッド セットアップでアップグレードにグレースフル メンテナンス オプションを使用している場合は特にそうしないでください。そうしないと、アップグレードが失敗し、スパイン スイッチがファブリックから無期限に隔離されたままになります。これは、グレースフル メンテナンス アップグレードプロセスの一環として、OSPFがファブリックから隔離できるように、アップグレードされる各スパイン スイッチでダウンされます。この方法でアップグレードすると、スパイン スイッチ自体を含むポッド全体が、自己回復手段なしで他のポッド内の APIC およびスイッチとの通信を失います。

    このため、[グレースフルメンテナンス（Graceful Maintenance）] オプションを使用している場合は、スイッチが個別にアップグレードされるように、同じポッドのスパイン スイッチを異なるメンテナンス グループに配置する必要があります。ポッドにスパイン スイッチが1つしかない場合は、アップグレードの前に [グレースフル メンテナンス（Graceful Maintenance）] オプションを無効にする必要があります。この手順に従わない場合は、CSCvn28063 に示されている回避策を参照してください。

  • 1回限りのアップグレード スケジュールまたは定期的アップグレード スケジュールのいずれを設定しているかに応じて、アップグレード スケジュールを過去の日付に設定した場合、システムの反応は異なります。

    • 過去の日付を使用して1 回限りのアップグレードスケジュールを設定すると、システムによって設定が拒否されます。

    • 定期的アップグレードまたは 1 度だけのアップグレードのスケジュールに過去の日付が設定されている場合、スケジューラはただちにアップグレードをトリガします。たとえば、水曜日に正午にいて、正午の火曜日ごとに定期アップグレードスケジュールを設定した場合、スケジューラは最初にアップグレードをすぐにトリガーし、その時点から火曜日ごとにアップグレードを実行します。

    詳細については、「ファームウェアのアップグレード モード」を参照してください。

  • 最低でも /19 のサブネット マスクを推奨します。

  • アップグレードを実行すると、通常、キックスタート変数はアップグレード プロセスの一部として書き換えられます。ただし、特定の状況では、NX OS から ACI にアップグレードし、ブート変数を正しく設定しないと、スイッチがブート ローダ モードに復帰する可能性があります。この状況を回避するために、アップグレードを実行する前にブート変数が正しく設定されていることを確認します。

  • APIC では、現在実行中のバージョンのシステムから、特定の新しいバージョンのアップグレード パスがサポートされているかどうかを確認する互換性チェック機能があります。[Ignore Compatibility Checks] の設定はデフォルトでは [off] に設定されているため、デフォルトでは互換性が調べられ、可能なアップグレードがないかチェックされます。何らかの理由で [Ignore Compatibility Checks] の設定を [on] に変更して互換性チェック機能を無効にする必要がある場合は、「互換性チェックを無視する設定の変更（リリース 4.x より前のリリース）」または「互換性チェックを無視する設定の変更（リリース 4.x 以降）」をご覧ください。

  • Cisco ACI マルチポッド導入では、PIM BIDIR 範囲としてインターポッド ネットワークで 239.255.255.240 （デフォルトの ACI システム GIPo）を設定する必要があります。この要件は、[システム GIPo としてインフラ GIPo を使用する（Use Infra GIPo as System GIPo）] オプションを有効にすることで回避できます。このオプションは、ファブリック内のすべてのスイッチ ノードが2.2(1) 以降などのサポートされているバージョンにアップグレードされた後にのみ有効にする必要があります。

  • リリース4.0以降、以前のリリースで使用されていたファームウェア グループおよびメンテナンス グループの代わりに、ノード アップグレード グループ ポリシーが使用されます。Cisco APIC を 4.0 より前のリリースからリリース 4.0(1) 以降にアップグレードする場合は、アップグレードの前にすべてのファームウェア グループおよびメンテナンス グループ ポリシーを削除する必要があります。

    • ファームウェア グループ ポリシーを削除するには、 [管理（Admin）] > [ファームウェア（Firmware）] > [ファブリック ノード ファームウェア（Fabric Node Firmware）] > [ファームウェア グループ（Firmware Groups）] に移動し、ファームウェア グループの名前を右クリックして[[ファームウェア グループの削除（Delete the Firmware Group）] を選択します。

    • メンテナンス グループ ポリシーを削除するには、 [管理（Admin）] > [ファームウェア（Firmware）] > [ファブリック ノード メンテナンス（Fabric Node Maintenance）] > [メンテナンス グループ（Maintenance Groups）] に移動し、メンテナンス グループの名前を右クリックして[メンテナンスグループの削除（Delete the Maintenance Group）] を選択します。

    これらの設定のいずれかを保持する必要がある場合は、シスコのサポートに連絡して設定を評価し、アップグレードする前に必要な変更を行ってください。

  • 4.x 以降のリリースでは、ファームウェア ポリシーが POST 要求によってメンテナンス ポリシーとは異なる名前で作成された場合、ファームウェア ポリシーは削除され、新しいファームウェア ポリシーが同じ名前で作成され、アップグレードが失敗します。この問題は、4.x 以降のリリースにアップグレードする前に作成されたポリシーの名前が異なる場合にも発生する可能性があります。この問題を回避するには、ファームウェア ポリシーとメンテナンス ポリシーを同じ名前で作成します。

  • Cisco APIC リリース 4.0(1) から、バッシュを使用して Cisco APIC スイッチ ソフトウェアをアップグレードすることはできません。NX-OS スタイル CLI を使用して、CLI による ソフトウェアのアップグレード の説明に従って、代わりに Cisco APIC とスイッチ ソフトウェアをアップグレードします。

  • Cisco APIC リリース 3.0 (1) から、Cisco APIC アップグレード中にスイッチのアップグレードがトリガーされると、すべての Cisco APIC が正常にアップグレードされた後でスイッチがアップグレードされます。Cisco APIC アップグレード プロセス中、スイッチは IN キュー 状態になります。

  • APIC ソフトウェアをリリース 2.3 から 3.2(2l) よりも前のリリースにアップグレードする場合、ドメイン名ベースのマイクロセグメンテーション EPG の設定データを含む domainmgr DME データベースがこれにより、APIC クラスタの状態が完全に適合していないと表示されます。この問題が発生した場合は、シスコ サポートに連絡し、CSCvv13780 のサポートをリクエストしてください。

  • 2.2(1) 以降のリリースから、 Cisco APIC には SSD 1 および 2 HDD が必須となり、このリリースにアップグレードする前に両方の RAID ボリュームが正常な状態になっている必要があります。SSD は Cisco APIC の起動に必要であり、SSD がインストールされていない場合は Cisco APIC は起動しません。SSD インストール ステータスの確認を参照してください。

  • マルチステップのアップグレードを実行中は、サポートされている場合 Cisco APIC リリース 2.1 かそれ以降の中間バージョンを使用して、「CSCvb94260」に関連する問題を防止することをお勧めします。

  • Cisco APIC リリース 1.2(2) 以降では、アウトオブバンド管理ノード EPG でコントラクトが提供されると、アウトオブバンド ノード管理アドレスで設定されるローカル サブネットが、デフォルトの Cisco APIC アウトオブバンド コントラクト送信元アドレスになります。以前は、任意のアドレスをデフォルトの Cisco APIC アウトオブバンド コントラクト送信元アドレスにすることが可能でした。

  • アップグレードの前に、適切に設定された OOB EPG の下で契約が行われることを確認します。1.2(2) リリースにアップグレードするとき、アウトオブバンド ノード管理エンドポイント グループに適用されるデフォルト以外のアウトオブバンド契約は、Cisco APIC に対して予期しない接続の問題を起こす可能性があります。Cisco APIC リリース以前には影響がない誤って設定されているアウトオブバンド契約が存在する場合、1.2(2) リリースにアップグレードすると、そのような誤った設定のアウトオブバンド契約を使用するアウトオブバンド管理 EPG により、Cisco APIC のクラスタにアクセスできなくなる可能性があります。

Cisco APIC およびスイッチ ソフトウェアのダウングレードに関する重要な注意事項

  • Cisco APIC へのログイン時に、認証方式として DUO アプリケーションを使用する機能は、Cisco APIC リリース 5.0 (1) の一部として導入されました。リリース 5.0(1) を実行していて、デフォルトの認証方式として [DUO] が設定されていて、リリース 5.0 (1) から以前のリリースに DUO がサポートされていない場合は、その後で、リリース 5.0 (1) より前のリリース (ローカル、LDAP、RADIUS など) にデフォルトの認証方式を変更することを推奨します。この状況でダウングレードする前にデフォルトの認証方式を変更しない場合は、ダウングレード後にフォールバック オプションを使用してログインする必要があります。その後、認証方式をリリース5.0(1) より前に使用可能なオプションに変更する必要があります。

    [管理 (Admin)] > [AAA] > [認証 (Authentication)] に移動し、ページの )[デフォルト認証 (default authentication)] エリアの [Realm (領域)] フィールドの設定を変更して、システムをダウングレードする前にデフォルトの認証方式を変更します。また、ダウングレード後に、手動で DUO ログイン ドメインを削除する必要があります。

  • インポートされた設定が、希望のバージョン設定が 1.0(1x) に設定されているファームウェア ポリシーで構成されている場合、スイッチは 1.0(1x) バージョンにダウンロード可能です。

  • 新しく追加されたマイクロセグメンテーション EPG 設定は、サポートしていないソフトウェア リリースにダウングレードする前に削除する必要があります。

  • リーフ スイッチから始まるファブリックをダウングレードすると、障害コード F 1371 の policy-deployment-failed のような障害が発生します。

  • 内部 EPG 拒否設定が設定された Cisco APIC を、1.2(2) リリースからそれ以前のリリースにダウングレードすることはサポートされていません。内部 EPG 拒否設定は、ダウングレードする前に手動で削除する必要があります。

  • Cisco APIC ソフトウェアのダウングレードを行う際は、最初に Federal Information Processing Standards（FIPS）を無効にする必要があります。詳細は、「Cisco APIC and Federal Information Processing Standards (FIPS)」の資料を参照してください。

  • Cisco ACI ファブリックで Federal Information Processing Standards（FIPS）を有効または無効にしている場合、変更を有効にするためファブリック内のスイッチをそれぞれリロードする必要があります。FIPS 設定を変更した後に最初のリロードを発行すると、設定されているスケール プロファイル設定が失われます。スイッチは動作状態ですが、デフォルトのポート スケール プロファイルを使用します。FIPS 設定が変更されていない場合は、この問題は後続のリロードでは発生しません。FIPS は Cisco NX-OS リリース 13.1(1) またはそれ以降でさぽーとされています。

  • FIPS をサポートしているリリースから FIPS をサポートしていないリリースにファームウェアをダウングレードする必要がある場合、最初に Cisco ACI ファブリックで FIPS を無効にして、FIPS 設定の変更のためファブリック内のすべてのスイッチをリロードする必要があります。

  • エニーキャスト サービスを Cisco ACI ファブリックで設定している場合は、Cisco APIC 3.2(x) から以前のリリースにダウングレードする前に、外部デバイスでエニーキャスト ゲートウェイ機能を無効にしてエニーキャスト サービスを停止する必要があります。

  • Cisco APIC 1.2(1x) から 1.0(4q) 以前にダウングレードする、または 1.1(1x)、1.1(2x)、1.1(3x)、1.1(4x) から 1.0(4h) 以前にダウン グレードする場合、下記のステートレス ダウングレード手順に従ってください。この手順はファブリックを再構築するため、ファブリック停止を計画する必要があります。

  • Cisco APIC 3.0(1) 以前のリリースにダウングレードする前に、Cisco N9K-C9508-FM-E2 ファブリック モジュールを物理的に削除する必要があります。

  • リモート リーフ スイッチを展開している場合、Cisco APIC ソフトウェアをリリース 3.1(1) またはそれ以降からリモート リーフ スイッチ機能をサポートしていない以前のリリースダウン グレードする際、ダウングレードする前にノードの使用を停止する必要があります。リモート リーフ スイッチのダウン グレードの前提条件に関する詳細は、「Cisco APIC レイヤ 3 ネットワー キング設定ガイド 」の「リモート リーフ スイッチ」の章を参照してください 。

アップグレードまたはダウン グレードするワークフローを Cisco ACI ファブリック

Cisco APIC ではファブリック全体のアップグレードを一元管理することができるため、ファブリックのアップグレードが簡素化されます。Cisco APIC は、イメージのリポジトリとして、またブート サーバとして機能します。リーフ スイッチとスパイン スイッチは Cisco APIC にインバンド接続されるため、スイッチはアップグレード時に Cisco APIC からファームウェアをダウンロードします。アップグレードを正常に完了するには、アップグレードするリーフ スイッチおよびスパイン スイッチから Cisco APIC への接続が可能である必要があります。接続を維持するためには、少なくとも 2 つのメンテナンス グループを定義し、一度に 1 つのグループをアップグレードする必要があります。最初のグループのアップグレードが正常に完了するのを待ってから、2 番目のグループをアップグレードします。このセクションでは、中断を最小限に抑えながらアップグレードを正常に完了するための推奨手順を説明します。

高レベルは、アップグレードまたはダウン グレードする手順は Cisco ACI ファブリックは、次のとおり。

  • プロシージャまたはの手順を実行、アップグレードし、特定のリリースのリリース ノートに限りは、同じのダウン グレードします。

  • 必要な必要な CIMC バージョンがあることを確認 Cisco APIC アップグレードします。必要に応じて、サポートされている CIMC バージョンに対する Cisco APIC のリリース ノートと CIMC ソフトウェアのアップグレード手順について CIMC ソフトウェアのアップグレード を参照してください。

  • Cisco ACI コントローラ イメージ（Cisco APIC イメージ）をリポジトリにダウンロードします。

  • リポジトリに Cisco ACI スイッチ イメージをダウンロードします。

  • Application Policy Infrastructure コントローラ（Cisco APIC）のクラスタをアップグレードします。

  • 続行する前に、ファブリックが動作していて、APIC クラスタが「完全に適合」していることを確認します。

  • スイッチを複数のグループに分割して、グループ別にスイッチをアップグレードし、各スイッチ グループをアップグレードした後にファブリックが動作していることを確認します。たとえば、赤と青の 2 つのグループにスイッチを分割したとします。この場合、次のアップグレード プロセスを完了します。

    1. 赤のグループのスイッチをアップグレードします。

    2. ファブリックが動作していることを確認します。

    3. 青のグループのスイッチをアップグレードします。

    4. ファブリックが動作していることを確認します。


（注）  

場合、 Cisco ACI ファブリックの導入環境に Cisco AV が含まれて、Cisco AV との互換性のバージョンにアップグレードする Cisco APIC 。Cisco AV をアップグレードするには、セクションを参照してください。 のアップグレード シーケンスの推奨 Cisco APIC 、ファブリックのスイッチと Cisco AV で、 Cisco Application Virtual Switch Installation guide 』 。

ガイドライン

また、一部の一般的なガイドラインを次のとおりですす Cisco ACI ファブリック アップグレードまたはダウン グレード。

  • スイッチを 2 つまたは複数のグループに分割します。一度に 1 つの グループをアップグレードします。その方法、アップグレードの] ウィンドウの中にまったくファブリック帯域幅をしない失われます。

  • 無効にされた設定ゾーンに属するノードは、アップグレードまたはダウングレードしないでください。

  • 特定のリリースでは、またはのリリースの組み合わせは、いくつかの制限およびアップグレードまたはダウン グレード手順の推奨事項があります。対象リリースのリリース ノートをダブルチェックしてから、 Cisco ACI ファブリックをアップグレードまたはダウングレードしてください。

  • アップグレードまたはダウン グレードがトリガーされると、前に、ファブリックに何らかの調査および解決済みの必要があります。未使用または未完了の設定を含めることがありますアップグレードは影響しません無害の障害がファブリックの可能性があります。アップグレードまたはダウン グレード操作の前にすべての障害を評価する必要があります。ディスク使用率は関連の障害は、設備新しいソフトウェアを開梱中に問題が発生することができます、アップグレードする前に対処する必要があります。

  • アップグレードまたはダウン グレード操作をトリガーする前にする必要がファブリックがで構成されている、 十分に適合 状態。すべて Cisco APIC s にあります 十分に適合 間を移動する前に状態 Cisco APIC イメージ バージョンのスイッチを開始する前にアップグレードまたはダウン グレードします。アップグレードまたはコントローラに追加されていない中にダウン グレード コントローラまたはスイッチを開始する 十分に適合 動作状態が予期しない結果につながることができます。

    複数のバージョンのアップグレードまたはダウン グレード操作を実行するときに、ファブリックがあることを確認する必要があります、 十分に適合 状態。たとえば、A から B へのアップグレード後に、バージョン A、C に B をからアップグレードするかどうかを待つ必要がありますすべてのコントローラとスイッチでは、 十分に適合 および C に B のバージョンからアップグレードを開始する前にバージョン B の動作の状態

  • アップグレードまたはダウン グレード ファブリックする前に構成のバックアップを収集することをお勧めします。

  • Multi-Pod 構成では、アップグレードまたはダウン グレードを行う場合に、リーフ スイッチとスパイン スイッチを異なるメンテナンス グループに配置することをお勧めします。また、「4 つのグループによる方法」で説明している方法を使用してリーフ スイッチとスパイン スイッチを分割することをお勧めします。

    Cisco APICリリース4.2(5) 以前では、同じメンテナンス グループに複数のポッドからのスイッチがあり、アップグレードを試みた場合、一度に 1 つのポッドからのスイッチのみがアップグレードされます。他のポッドの他のスイッチは、アップグレードを開始する前に、以前のポッドのアップグレードが完了するまで待機します。

    Cisco APICリリース4.2(5) 以降、この制限が緩和され、複数のポッドを同時に並行してアップグレードできるようになりました。この Multi-Pod パラレル アップグレードは、API Cがリリース 4.2(5) 以降で動作している場合に有効です。スイッチが 4.2(5) の同等のスイッチリリースであるリリース 14.2(5) よりも古いバージョンであっても同様です。


（注）  
2 つ以上のグループのアップグレードまたはダウン グレードをスイッチに分割することをお勧めします。2 つのグループ、および 4 つのグループにスイッチを得られると、それぞれの例を次にします。

2 つのグループによる方法

  1. 2 つのグループに、スイッチを分割: 赤いグループと青色グループ。赤色のグループと青のグループにその他の半分で、スパイン スイッチの半分いずれかを配置します。赤色のグループと青のグループにその他の半分でも、リーフ スイッチの半分いずれかを配置します。

  2. 赤色のグループをアップグレードします。

  3. 赤のグループのアップグレードが完了した後は、ファブリックが正常な状態を確認します。

  4. 青色のグループをアップグレードします。

4 つのグループによる方法

  1. 4 つのグループをスイッチに分割: 赤いスパイン スイッチ グループ、青色スパイン スイッチ グループ、赤色のリーフ スイッチ グループ、および青色リーフ スイッチ グループ。いずれかを配置赤色スパイン スイッチでスパイン スイッチの半分グループ、およびその他の半分スパイン スイッチの青色スパイン スイッチのグループにします。次に、赤色のリーフ スイッチ グループ、および青のリーフ スイッチのグループ内の他の半半のリーフ スイッチを配置します。

  2. 赤のリーフ スイッチのグループをアップグレードします。

  3. 赤のリーフ スイッチのグループのアップグレードが完了した後は、ファブリックが正常な状態を確認します。

  4. 青のリーフ スイッチのグループをアップグレードします。

  5. 青のリーフ スイッチのグループのアップグレードが完了した後は、ファブリックが正常な状態を確認します。

  6. 赤のスパイン スイッチのグループをアップグレードします。

  7. 赤のスパイン スイッチのグループのアップグレードが完了した後は、ファブリックが正常な状態を確認します。

  8. 青のスパイン スイッチのグループをアップグレードします。

ACI のアップグレードまたはダウングレード前の検証チェック

ここでは、特定の問題または障害を検出するために APIC によって実行される検証と、スムーズなアップグレードまたはダウングレードを確実にするために事前に実行する必要がある推奨アクションについて説明します。

検証が実行される状況は 3 つあります。

検証をトリガーするアクション

実行内容

実行時

サポートされているリリース

APICのアップグレードまたはダウングレードを設定する場合。

ファブリック全体または APIC 自体に関連する検証。

APIC に異なるターゲット ファームウェア バージョンが選択されている場合。

Cisco APIC リリース4.2(1) 以降、自動的に実行される特定の検証。

スイッチのアップグレードまたはダウングレードを設定する場合。

設定されたメンテナンス グループ（アップグレード グループ）のスイッチに関連する検証。

メンテナンスグループ（アップグレードグループ）で [Submit] をクリックした場合。

Cisco APIC リリース4.2(4) 以降、特定の検証が自動的に実行されました。

Cisco DC App Center から入手可能な Pre-Upgrade Validator アプリを使用する場合。

上記の両方の検証。アプリを使用すると、APIC ソフトウェアの古いバージョンがインストールされているファブリックでも、最新の検証を実行できます。

Pre-Upgrade Validator アプリを使用して検証を実行する場合。

Cisco APIC リリース3.2(1) 以降で使用可能な検証。


（注）  

ソフトウェアをアップグレードまたはダウングレードする前に APIC によって実行されるこの項で説明する検証チェックは、GUI を使用してアップグレードまたはダウングレードを実行する場合にのみ使用できます。CLI を使用してアップグレードまたはダウングレードを実行する場合、これらの検証チェックは使用できません。

アップグレードまたはダウングレード前の障害検証

Cisco APIC リリース4.2(1) 以降では、アップグレードまたはダウングレード操作をトリガーしようとすると、操作に影響する可能性がある現在アクティブな障害に基づいて警告が発生します。操作を続行する前に、このような障害を解決することをお勧めします。

ACI ファブリックで次のいずれかが検出された場合：

  • 重大度がクリティカルでタイプ 設定 の障害、または

  • 次の障害のいずれか

アップグレードまたはダウングレード操作がブロックされ、続行できなくなります。

表 1. リリース4.2(1) で導入された障害検証

Fault

説明

F0101

fltEqptStorageFailed。この障害は、APIC ノードのストレージ デバイスで不具合が生じると発生します。APIC クラスタの多くの操作、特にアップグレードおよびダウングレード操作では、内部データベースの更新をクラスタ内の任意の APIC ノードでスムーズに実行できるように、正常なストレージが必要です。

F0130

fltCompCtrlrConnectFailed。この障害は、VMM コントローラにオフラインのマークが付けられると発生します。リカバリが進行中です。

F1528

fltEqptStorageFull-Major。この障害は、ストレージの使用量が APIC ノードで 85% ～ 90% になると発生します。APIC ノードには、アップグレードまたはダウングレードするターゲット ファームウェア イメージを抽出するための一定量の空き領域が必要です。

F1529

fltEqptStorageFull-Critical。この障害は、ストレージの使用量が APIC ノードで 90% を超えるとになると発生します。APIC ノードには、アップグレードまたはダウングレードするターゲット ファームウェア イメージを抽出するための一定量の空き領域が必要です。

F2732

fltEqptStorageWearout-Critical。この障害は、SSD メディアの耐久ンジケータ (残存期間) が APIC ノードで 1% 未満の場合に発生します。ライフタイムが短い SSD を使用すると、アップグレードやダウングレード操作など、内部データベースの更新が必要な操作が失敗する可能性があります。

F3073

fltEqptFlashFlash-worn-out｡この障害は、フラッシュ SSD のライフタイムの使用率がリーフまたはスパインスイッチで 90% の耐久性制限に達した場合に発生します。ライフタイムが短いフラッシュSSDでは、APIC 通信などの内部データベースの更新が必要な操作が失敗する可能性があります。

F3074

fltEqptFlashFlash-minor-alarm。この障害は、フラッシュ SSD のライフタイムの使用率がリーフまたはスパインスイッチで 80% の耐久性制限に達した場合に発生します。ライフタイムが短いフラッシュ SSD では、APIC 通信などの内部データベースの更新が必要な操作が失敗する可能性があります。

F606391

fsmFailCompHvGetHpNicAdj。この障害は、VMM ドメインに統合されるホスト上の物理アダプタに関する LLDP/CDP 隣接関係の情報が検出されないときに発生します。隣接関係が欠落している状態でアップグレードまたはダウングレードを実行すると、そのようなホストに対するリーフ スイッチ上の VLAN が、操作後に再プログラミングされないことがあります。

表 2. リリース5.1(1) で導入された障害検証

Fault

説明

F3544

fltActrlStatsReportPreFixProgFailed。この障害は、ハードウェアまたはソフトウェアのプログラミングの失敗のいずれかが原因で、pcTag へのプレフィックスをマッピングするために、スイッチがエントリをアクティベートすることができないときに発生します。これらのエントリは、主に L3Out ルートを L3Out EPG にマッピングするために使用されます。この問題の状態にあるスイッチは、リブートまたはアップグレード後に異なるエントリ セットをアクティブ化できない場合があります。これにより、アップグレード前に動作していたサービスが、アップグレード後に失敗する可能性があります。

F3545

fltActrlStatsReportZoneRuleProgFailed。この障害は、ハードウェアまたはソフトウェアのプログラミングの失敗のいずれかが原因で、スイッチがコントロール ルール（ゾーニング ルール）をアクティベートすることができないときに発生します。この問題の状態にあるスイッチは、リブートまたはアップグレード後に異なるコントラクト セットのアクティブ化に失敗することがあります。これにより、アップグレード前に動作していたサービスが、アップグレード後に失敗する可能性があります。

これらの障害と推奨処置の詳細については、CISCO APIC System fault/Events Search Tool および Cisco ACI System Messages Reference Guide を参照してください。

アップグレードまたはダウングレード前の非障害検証

Cisco APIC リリース 4.2(4) および 4.2(5) 以降では、アップグレードまたはダウングレード操作をトリガーしようとすると、操作に影響する可能性がある設定またはその他の動作ステータスに基づいて警告が表示されます。操作を進める前に、このような警告を解決することをお勧めします。

アップグレードまたはダウングレードの前に検証される項目は次のとおりです。

表 3. 非障害検証

名前

説明

エラー メッセージ

推奨処置

リリースで利用可能

ブートフラッシュ ストレージ チェック

この検証では、スイッチ ノードを正常にアップグレードするのに十分なブートフラッシュ ストレージがあるかどうかを確認します。

次のノードでは、イメージをダウンロードするための領域がブートフラッシュ フォルダーにありません。<List of node IDs> 。

この問題を解決するには、スイッチノードのブートフラッシュをクリーンアップします。

  1. スイッチ CLI にログインします。

  2. ブートフラッシュの内容を確認します。

    ls -l /bootflash

  3. 未使用のスイッチ ファームウェア イメージなど、ブートフラッシュ内の不要なファイルを削除します。

    rm /bootflash/<filename>

4.2(4)

5.0(1)

NTP ステータスの確認

この検証では、APIC に Network Time Protocol（NTP）が設定されているかどうかを確認します。

NTP が設定されていない。

すべてのノードでクロックを同期するように NTP を設定することを推奨します。各ノードのクロックに大きな違いがあると、ノード間のデータベース同期で問題が発生する可能性があります。

この問題を解決するには、NTP を次のように設定します。

  1. APIC 内で、[ファブリック] > [ファブリック ポリシー] > [ポッド ポリシー] > [ポリシー] > [日付と時刻] に移動します。

  2. NTP サーバの IP アドレスを設定します。

  3. 設定されたデータおよび時間ポリシーが、 [ファブリック] > [ファブリック ポリシー] > [ポッド] のポッド ポリシー グループおよびポッド プロファイルに関連付けられていることを確認します。

または：

  1. ACIファブリックの [System] > [QuickStart] > [ACI ファブリックの初回セットアップ] に移動します。

  2. 初回セットアップウィザードの指示に従って NTP を設定します。

4.2(5)

5.0(1)

CIMC 互換性

この検証では、ターゲット ファームウェア バージョンが現在実行中の CIMC バージョンと互換性があるかどうかを確認します。

APIC で推奨される CIMC バージョンが実行されていません。<推奨される CIMC バージョンと対応するノード ID のリスト> 。

この問題を解決するには、CIMC をエラー メッセージで指定されたバージョンにアップグレードすることをお勧めします。

4.2(4)

致命的な障害

APIC が、アップグレードに進む前に対処する必要がある障害を検出しました。

アップグレードが検出される前に解決する必要がある障害：<クリティカルな設定障害および/またはファブリックで現在アクティブな特定の障害> 。

障害と考えられる解決策については、アップグレードまたはダウングレード前の障害検証 を参照してください。

Docker Bridge IP チェック

この検証では、AppCenter の APIC のコンテナ ブリッジ IP アドレスがデフォルト以外の IP アドレスで設定されているかどうかを確認します。APIC のコンテナ ブリッジ IP アドレスの変更は、APIC リリース 4.2(1) 以降でのみサポートされます。

デフォルト以外の Docker ブリッジ IP が設定されているため、ダウングレードを開始できません。ダウングレード後に Docker アプリケーションに接続の問題が発生する可能性があります。デフォルトの Docker ブリッジ IP に戻します：172.17.0.1/16

デフォルトの Docker ブリッジ IP アドレスに戻します：172.17.0.1/16

5.1(1)

ハードウェアの互換性チェック

この検証では、ファブリック内のすべてのスイッチ ノードがターゲット ファームウェアと互換性があり、サポートされているかどうかがチェックされます。

次のノードはターゲット バージョンと互換性がありません：<ノード ID のリスト> 。

この問題を解決するには、すべてのノードを同じファームウェア バージョンにすることが推奨されるため、互換性のあるノードにノードを交換します。

または、現在のグループから互換性のないノードを削除して、互換性のないノードが現在のファームウェア バージョンのままになるようにすることもできます。

4.2(4)

5.0(1)

インバンド/ OOB ルート チェック

この検証では、[テナント] > [mgmt] > [ノード管理 EPG] の下のテナント管理ノードEPGでインバンドまたはアウトオブバンドEPGにスタティックルート（MO：mgmtStaticRoute）が設定されているかどうかを確認します。この機能は、APIC リリース 5.1 以降でのみサポートされます。

特定のスタティック ルートがインバンド/OOB 用に設定されているため、ダウングレードを開始できません。続行する前に削除してください。

mgmtStaticRoute MO を削除します。

インフラ VLAN ID チェック

この検証では、クラスタ内の APIC に同じインフラ VLAN ID があるかどうかを確認します。

クラスタ内の APIC には異なるインフラ VLAN ID があります。

APIC またはスイッチ ノードで別のインフラ VLAN が使用されている場合、APIC クラスタまたは ACI ファブリックを正しく形成できません。不正なインフラ VLAN を持つ APIC は、APIC クラスタに参加しません。不正なインフラ VLAN を持つスイッチ ノードは非アクティブ ステータスになります。正しいインフラ VLAN を再設定するには、このようなノードをクリーン リブートで初期化する必要があります。

この問題を解決するには、APIC でインフラ VLAN を再設定します。

  1. CLI を通じて、APIC ノードで cat /data/data_admin/sam_exported.config | grep infraVlan を確認して、不正なインフラVLANを持つAPICを特定します。

  2. APIC を初期化するには、不正なインフラ VLAN を使用して、APIC の CLI から次のコマンドを入力します。

    1. acidiag touch clean

    2. acidiag touch setup

    3. acidiag reboot

  3. APIC が再起動し、初期化スタートアップ スクリプトで起動します。正しいインフラ VLAN が設定されていることを確認します。

    スイッチ ノードは、接続された APIC またはスイッチ ノードから受信した LLDP に基づいてインフラ VLAN をプログラムします。いずれかのスイッチ ノードの VLAN が正しくない場合は、最初に APIC などの接続されたノードを修正します。次に、次の手順を実行して新しいインフラ VLAN を受け入れます。

    • 非アクティブ状態のスイッチ ノードでCLIを使用して次のコマンドのいずれかを確認し、誤ったインフラ VLAN を持つノードを特定します。

      • moquery -c lldpInst | grep infraVlan

      • cat /mit/sys/lldp/inst/summary | grep infraVlan

    • 不正なインフラ VLAN が設定されたスイッチ ノードで次のコマンドを入力して、ノードを初期化します。

      1. setup-clean-config.sh

      2. reload

4.2(4)

Intersight デバイス コネクタ ステータス

この検証では、Intersight Device Connector（DC）のアップグレードが進行中かどうかを確認します。DC のアップグレード中に APIC のアップグレードを開始すると、DC のアップグレードが失敗することがあります。

Intersight Device Connector のアップグレードが進行中です。

この問題を解決するには、しばらく待ってから APIC のアップグレードを再試行します。Intersight Device Connector のアップグレードは、通常 1 分未満で完了します。

4.2(5)

多層

この検証では、ファブリックに Tier-2 リーフ ノードがある場合、ターゲット ファームウェア バージョンで多層トポロジがサポートされているかどうかを確認します。このチェックは、主にダウングレード シナリオ用です。

Tier 2 リーフは、ターゲット バージョンではサポートされていません。ファブリックには、Tier 2 リーフとして次のノードがあります。<List of node IDs> 。

多層機能は、APIC リリース4.1(1) 以降でサポートされています。このリリース以前は、ファブリック内の APIC およびスイッチ ノードは、階層2で接続された多層トポロジおよびリーフ ノードを認識できません。

この問題を解決するには、[コントローラから削除（Remove from Controller）] オプションを使用して Tier-2 リーフ ノードをデコミッションします。[コントローラから削除（Remove from Controller）] オプションを使用すると、スイッチが ACI ファブリックおよびすべての APIC から完全に削除されます。登録済みのノードと割り当てられたインフラストラクチャ VTEP IP アドレスが削除されるので、スイッチはファブリック メンバーシップに表示されなくなります。

[コントローラから削除（Remove from Controller）] オプションを使用して、ACI ファブリックから階層 2 リーフ ノードを解放するには、次の手順を実行します。

  1. メニュー バーで、[ファブリック（Fabric）] を選択します。

  2. [Navigation] ペインで、 [Inventory] > [Pod #]を選択します。

  3. [Navigation] ペインでデコミッションするスイッチをクリックします。

    1. [General] タブをクリックします。

    2. Actions > [コントローラからアクションを削除（Remove Actions from Controller）]を選択します。

APIC: 5.1(1)

Switch: 5.0(1)

スイッチ: 4.2(5)

OOB 管理 IP

この検証では、OOB（アウトオブバンド）管理 IP 設定なしでノードの存在をチェックし、すべてのノードに常にアクセスできることを確認します。アップグレード/ダウングレード中に、ACI インフラ経由でノードに到達できない場合があります。念のため、各ノードへのコンソールアクセスを準備することをお勧めします。

次のノードにはアウトオブバンド管理 IP がありません: <アウトオブバンド管理 IP がないノードのリスト>:

すべてのノードにアウトオブバンド（OoB）管理IPを設定することをお勧めします。これにより、APIC がアップグレードまたはダウンロード中に ACI ファブリック インフラ ネットワークを通じて特定のノードへの到達可能性が失われる場合、OoB を通じて直接各ノードのステータスを確認できる方法を確保できます。ノードの再起動中に到達可能性が失われることは予想される動作です。同じ理由で、各ノードにコンソール アクセスできることも推奨します。

この問題を解決するには、すべての APIC およびスイッチ ノードの管理ポートが物理的にアップ状態であり、スタティック アウトオブバンド管理 IP を設定します。

  1. 管理テナントに移動します ([テナント (Tenants)] > すべてのテナント (ALL TENANTS)] > [mgmt])。

  2. [ナビゲーション (Navigation)] ペインで、[ノード管理アドレス (Node Management Addresses)] を右クリックし、[静的ノード管理アドレスの作成 (Create Node Management Addresses)] をクリックします。

4.2(4)

リモート リーフの互換性

この検証では、ファブリックがリモート リーフ機能を使用している場合、ターゲット ファームウェア バージョンでリモート リーフ機能がサポートされているかどうかを確認します。このチェックは、主にダウングレード シナリオ用です。

リモート リーフはターゲット バージョンではサポートされていません。このファブリックには、リモート リーフとして次のノードがあります。<List of node IDs> 。

リモート リーフ機能は、APIC リリース 3.1(1) 以降でサポートされています。このリリース以前は、ファブリック内のAPICおよびスイッチ ノードは、サテライト サイトのリモート リーフ ノードを正しく認識できません。

この問題を解決する手順は、次のとおりです。

  1. vPC ドメインを削除します。

  2. SCVMM を使用している場合は、vTEP - 仮想ネットワーク アダプタを削除します。

  3. [コントローラから削除（Remove from Controller）] オプションを使用して、リモート リーフ ノードをデコミッションします。

    1. メニュー バーで、[ファブリック（Fabric）] を選択します。

    2. [Navigation] ペインで、 [Inventory] > [Pod #]を選択します。

    3. [Navigation] ペインでデコミッションするスイッチをクリックします。

      • [General] タブをクリックします。

      • Actions > [コントローラからアクションを削除（Remove Actions from Controller）]を選択します。

  4. インフラ テナントで WAN L3Out へのリモート リーフ スイッチを削除します。

  5. マルチポッドを使用している場合は、VLAN 5 の infra-L3Out を削除します（リモート リーフ スイッチがレガシー モードで実行されている場合にのみ適用可能）。

  6. リモートというプールを削除します。

詳細については、「APIC ドキュメント ページ」の「Layer 3 Networking Configuration Guide」の章を参照してください。

APIC: 5.1(1)

スイッチ: 5.0(1)

スイッチ: 4.2(5)

ルート リフレクタ

この検証は、各ポッドに少なくとも 2 つのスパイン ノードがインフラ MP-BGP のルート リフレクタとして設定されているかどうかをチェックします。すべてのルート リフレクタ スパイン ノードが同時に使用できない場合、ファブリックは L3Outs からの外部ルートへの到達可能性を失います。

ポッド <List of pod IDs> インフラ MP-BGP のルート リフレクタが 2 つ未満です。

ポッドごとに少なくとも 2 つのスパイン ノードをインフラ MP-BGP ルート リフレクタとして設定し、アップグレードまたはダウングレード中であっても、いずれか 1 つが常にアップ状態になるようにすることを推奨します。ルート リフレクタ スパイン ノードは、L3Out を通じて学習した外部ルートを同じポッド内のすべてのリーフ ノードに配布します。アップグレードまたはダウングレード中にすべてのルートリフレクタスパインノードが同時にリブートした場合、外部ルートはL3Outが展開されているボーダーリーフノードでのみ使用できます。

この問題を解決するには、少なくとも2つのスパインノードをルート リフレクタのスパインノードとして設定します。

  1. [システム (System)] > [システム設定 (System Settings)] に移動します。

  2. [ナビゲーション (Navigation)] ペインで、[BGP ルート リフレクタ (BGP Route Reflector)] を右クリックし、[ルート リフレクタ ノード ポリシー EPの作成 (Create Route Reflector Node Policy EP)] を選択します。

4.2(4)

SNMPv3 認証の互換性

この検証では、現在の SNMPv3 ユーザー認証およびプライバシー タイプがターゲット APIC ファームウェアでサポートされているかどうかを確認します。APIC リリース 5.1 よりも前では、HMAC-MD5-96 と HMAC-SHA1-96 のみがサポートされる認証タイプであり、AES-128、DES、または none はサポートされる唯一のプライバシータイプです。

設定された SNMPv3 ユーザー認証またはプライバシー タイプは、ターゲット APIC ファームウェア バージョンではサポートされていません。

SNMPv3 ユーザー（snmpUserP）の認可タイプまたはプライバシー タイプをサポートされているタイプに変更します。

5.1(1)

スパイン冗長性チェック

この検証では、更新グループに、特定のポッド内のすべてのルート リフレクタ スパインまたはすべてのIPN側スパインが含まれていないことを確認します。ポッド内のすべてのルート リフレクタ スパインが同時に使用できない場合、ファブリックは L3Outs から外部ルートへの到達可能性を失います。ポッド内のすべての IPN 対応スパインが同時に使用できない場合、ファブリックはポッド全体の到達可能性を失います。

各ポッドは、トラフィック損失を回避するために、少なくとも 2 つの個別のグループでスパインノードをアップグレード/ダウングレードする必要があります。次のポッドのすべてのスパインは、同じメンテナンス グループに属します。<List of Pod IDs>

トラフィック損失を避けるために、少なくとも 2 つの別々のグループで同じポッド内のスパイン ノードをアップグレードまたはダウングレードすることを推奨します。特にマルチポッドまたはマルチサイト設定では、IPN（ポッド間ネットワーク）または ISN（サイト間ネットワーク）に接続されているすべてのスパイン ノードがアップグレードまたはダウングレード中に再起動されると、別のポッドまたはサイトへのすべてのトラフィックが完全に失われます。

この問題を解決するには、現在のグループから一部のスパイン ノードを削除します。グループからスパイン ノードを削除する場合は、IPN / ISN 接続に注意してください。

4.2(4)

5.0(1)

ターゲット ファームウェアのチェック

この検証では、ターゲット APIC ファームウェア イメージがクラスタ内のすべての APIC で同期されているかどうかを確認します。

ターゲット ファームウェアがから欠落しています。イメージの同期が進行中の可能性があります。

一定期間後にアップグレードをトリガーします。

5.1(1)

バージョンの互換性

ノードがターゲット バージョンと互換性がない場合、またはターゲット バージョンが現在実行中のバージョンと互換性がない場合、APIC はこの問題について警告します。

ターゲット バージョンが現在の実行中のバージョンと互換性がありません。

APIC およびスイッチ ノードのアップグレードまたはダウングレードは、サポートされているファームウェアバージョン間でのみ実行し、アップグレードまたはダウングレードの前後でオブジェクト モデルの定義とソフトウェアの実装に互換性があることを確認する必要があります。

この問題を解決する手順は、次のとおりです。

  • 互換性のあるターゲット バージョンを選択します。

    現在のバージョンからサポートされているアップグレードおよびダウングレード パスについては、APIC のアップグレード/ダウングレードのサポート マトリックスを参照してください。また、中間リリースを経由するアップグレードまたはダウングレードの詳細については、複数の中間リリースを介するアップグレードまたはダウングレードを理解する を参照してください。

  • または、[互換性チェックを無視 (Ignore Compatibility Check)] オプションを選択できます (詳細については、互換性チェックを無視する設定の変更（リリース 4.x 以降） を参照してください)。

    （注）   

    次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にすることを選択すると、[互換性の確認を無視（Ignore Compatibility Check）] に移動して、システム内で発生する可能性があります。システムにサポートされていないアップグレードを行うリスクがあります。これにより、システムの構成が失われ、ファブリック全体の初期化が必要になる場合があります。

4.2(4)

vPC ノード

この検証では、ファームウェア更新中に冗長性とハイアベイラビリティを確保するために、リーフ ノードにvPCが設定されているかどうかがチェックされます。ファブリックが ECMP などの他の手段によって冗長性を提供している場合、または意図的にシングル ホーム サーバがある場合は、このチェックを無視します。

次のノードは vPC にありません。<vPC ペアにないノードのリスト> 。

いずれかのリーフ ノード ペアに対して vPC を設定して、vPC ペアの一方のリーフノードを介してトラフィックを転送し、もう一方がアップグレードまたはダウングレードのためにリブートするようにすることを推奨します。これを行わないと、アップグレードまたはダウングレード中にトラフィック損失が発生する可能性があります。

この問題を解決するには、VPC ペアを次のように設定します。

  1. [ファブリック (Fabric)] > [アクセス ポリシー (Access Policies)]に移動します。

  2. [クイック スタート (Quick Start)] メニューから、[インターフェイスフェース、PC、および vPC の設定 (Configure an interface, PC, And vPC)] をクリックしてウィザードを開始します。このウィンドウから vPC スイッチ ペアを設定できます。

4.2(4)

GUI を使用したエラーメッセージおよびオーバーライドオプションの例

警告メッセージが GUI で表示される場合は、次の 3 つの状況が考えられます。

  • クエリのロード中に、次のようなメッセージが表示される場合があります。

    これは、クエリからデータをロードするのに少し時間がかかることがあるために発生する可能性があります。この状況では、システムがクエリからのデータのロードを完了するまでしばらく待ちます。

  • 何らかの理由でクエリが失敗した場合は、次のようなメッセージが表示されることがあります。

    この警告は、何らかの理由でクエリが失敗した場合に表示されます (たとえば、システムで過負荷が発生している可能性があります)。この場合、アップグレードに問題が発生する原因となる障害があるかどうかを確認する必要があります。

    ただし、失敗したクエリの問題に対処せずにブロックをオーバーライドし、アップグレードまたはダウングレードを続行する場合は、[予期していない問題につながることがあるアクティブな障害がシステムに存在している可能性があることを理解しました。アップグレードを続行します (I understand there may be active faults on the system which can lead to unexpected issues, proceed with the upgrade)] フィールドの横にあるボックスをオンにします。これにより、失敗したクエリに関する問題に対処せずに、アップグレードまたはダウングレード プロセスを続行できます。

  • 障害のクエリが完了すると、次のようなメッセージが表示される場合があります。

    この警告メッセージは、障害クエリが完了して、システムが 1 つ以上の障害を検出したときに表示されます。この状況では、 [ここをクリック (Click Here )] リンクをクリックして、システムが検出した障害の詳細情報を取得してください。

    可能な場合は、アップグレードまたはダウングレード プロセスに進む前に、障害で発生した問題を解決することを推奨します。これらの障害と推奨処置の詳細については、CISCO APIC System fault/Events Search Tool および Cisco ACI System Messages Reference Guide を参照してください。

    ただし、障害で発生した問題に対処せずにブロックをオーバーライドし、アップグレードまたはダウングレードを続行する場合は、[予期していない問題につながることがあるアクティブな障害がシステムに存在していることを理解しました。アップグレードを続行します (I understand there are active faults on the system which can lead to unexpected issues, proceed with the upgrade)] フィールドの横にあるボックスをオンにします。これにより、検出された障害に対処せずに、アップグレードまたはダウングレードプロセスを続行できます。

エラー メッセージの例および NX-OS スタイル CLI を使用したオプションのオーバーライド

NX-OS スタイルの CLI を使用してソフトウェアをアップグレードしようとすると、次のようになる可能性があります。

apic# firmware upgrade controller-group

ファブリックの障害が検出された場合は、次のようなエラー メッセージが表示されることがあります。

Error: Migration cannot proceed due to 23 active critical config faults. Resolve the faults to proceed

可能な場合は、アップグレードまたはダウングレード プロセスに進む前に、障害で発生した問題を解決することを推奨します。これらの障害と推奨処置の詳細については、CISCO APIC System fault/Events Search Tool および Cisco ACI System Messages Reference Guide を参照してください。

ただし、ブロックをオーバーライドして、障害で発生した問題に対処せずにアップグレードまたはダウングレードを続行する場合は、ignore-validation オプションを使用してアップグレードを続行します。 

apic# firmware upgrade controller-group ignore-validation

Cisco APIC 長期リリース

Cisco APIC長命リリースでは、ながら、品質や安定性を保証する頻繁なメンテナンス ドロップ (約 18 か月)、最大長期的な単位で所定のリリースを維持するのに役立ちますソフトウェア リリースです。Cisco では、時間の任意の時点の 2 つの長命リリースをサポート可能性があります。ただし、アクティブなメンテナンスがプライマリは長命最新のリリースに置かれています。これらのリリースは、他のリリースよりも長い期間に維持されます。長命リリースは、頻繁にアップグレードされませんネットワークのまたは広く採用されている機能を展開するために推奨されます。


（注）  

リリース ブランチは、長期リリースとしてサポートされている場合もあれば、サポートされていない場合もあります。たとえば、2.x には 2.1、2.2、2.3 の 3 つのリリース ブランチが存在する可能性があります。しかし、2.x の 3 つのリリース ブランチのうち、1 つは長期リリース（2.2）としてサポートされている可能性がありますが、他の 2 つのリリース ブランチ（2.1 と 2.3）は長期リリースとしてサポートされていない可能性があります。

長命リリースのライフ サイクル

  • 長命のメジャー リリースのライフ サイクルは、マイナーの最初のリリースの first customer shipment（FCS; から始まります。

  • メジャー リリースのは、製品の障害に対処する利用可能な行ったは複数のリリース、メンテナンス リリースの概要フェーズを開始します。

  • 、その後で、メジャー リリースはが成熟メンテナンス フェーズに移行します。このフェーズでは、リリースは、重大度 1 および 2 の重大度の欠陥が、顧客が見つかりませんでしたのみの不具合修復を受け取ります。内部で発見された不具合で個別に対処します。

  • すべての長命リリース サポートへのアップグレードまたはダウン グレード長命次または前のリリースの最後のメンテナンス バージョンをそれぞれ

Cisco Nexus 9000 ACI モード スイッチと Application Policy Infrastructure Controller（APIC）を、新規に展開するお客様、またはすでに展開済みのお客様は、次の長期リリースから選択することをお勧めします。

Cisco APIC の長期リリース バージョン

長命の Cisco スイッチのリリース バージョン

4.2(x)

14.2(x)

3.2(x)

13.2(x)

2.2(x)

12.2(x)

特定の長期リリース バージョンに対応した最新のメンテナンス リリースとパッチにアップグレードすることをお勧めします。最新の Cisco Nexus 9000 ACI モード スイッチと Cisco APIC の展開は、該当する Cisco ソフトウェア ダウンロード ページからダウンロードできます。

現在のソフトウェア ビルドの確認

このセクションの手順を使用して、ファブリック内のスイッチおよび APIC で現在実行されているソフトウェア ビルドを確認します。

APIC での現在のソフトウェアビルドの確認

ファブリックの APIC で現在実行されているソフトウェア ビルドを確認できます。

  • Cisco APIC GUI ウィンドウの右上隅にあるアイコン () をクリックし、[バージョン情報 (About)] を選択します。

  • [Controllers] ページに移動します。

    • リリース 5.1(1) 以前のリリースの場合、[管理 (Admin] > [ファームウェア] > [インフラストラクチャ] > [コントローラ] に移動します。ソフトウェア ビルドは、このページの表の [現在のファームウェア (Current Firmware)] 列に表示されます。

    • リリース5.1(1) 以降の場合は、[Admin] > [Firmware] に移動し、左側のナビゲーションウィンドウで [Dashboard] をクリックします。ソフトウェア ビルドは、ページの [Controllers] 領域の [Firmware] フィールドに表示されます。

      この同じページの [コントローラ（Controllers）] 領域を検索することで、個々の APIC で実行されているソフトウェア ビルドを確認することもできます。各 APIC で実行されているソフトウェアビルドは、[Current Version] 列に表示されます。

スイッチの現在のソフトウェア ビルドの確認

ファブリック内のリーフスイッチおよびスパインスイッチで現在実行されているソフトウェアビルドを確認するには、

  • リリース5.1(1) より前のリリースの場合は、[管理] > [ファームウェア] > [インフラストラクチャ] > [ノード] に移動します。ソフトウェア ビルドは、このページの表の [現在のファームウェア (Current Firmware)] 列に表示されます。

  • リリース5.1(1) 以降の場合は、[管理] > [ファームウェア] に移動します。左側のナビゲーション ウィンドウで [ノード] をクリックし、ファブリックの各リーフ スイッチとスパインスイッチの [ターゲット バージョン] 列の情報を表示します。[Status] 列の [Completed] エントリは、リーフまたはスパイン スイッチがこのターゲットバージョンに正常にアップグレードされたことを示します。

Cisco APIC およびスイッチ ソフトウェアのアップグレードについて

最初に触れるリリースについては、「Cisco アプリケーション ポリシー インフラストラクチャ コントローラ リリース ノート」を常にチェックしてください。

APIC のアップグレード段階の説明

アップグレード プロセス中に APIC が実行する段階は、現在実行しているソフトウェアのバージョンとアップグレード先のソフトウェアのバージョンによって異なります。

4.2(5) より前のリリースからリリース 4.2(5) 以降へのアップグレード

ソフトウェアの現在実行中のバージョンが Cisco APIC リリース 4.2(5) よりも前で、リリース4.2 (5) 以降にアップグレードする場合、このセクションでは、アップグレード プロセス中に各 APIC が実行する段階について説明します。

  • アップグレードを開始する前に、各 APIC は 100% で表示されます。これは、各 APIC で以前に実行されたインストール、アップグレード、またはダウングレードが正常に完了したことを示します。

  • アップグレードプロセスを開始すると、すべての APIC のステータスが 100% から 0% に変わり、次の段階を経ます。

    • ステータスは、最初に [ファームウェア アップグレードのキュー作成（Firmware upgrade queued）] と表示されます。

    • ステータスが[ファームウェア アップグレードの進行中（Firmware upgrade in progress）] に変わります。

  • 次に、インストーラによって最初に選択された APIC がアップグレードを開始し、次の図に示すように 5％ に進みます。


    （注）  

    アップグレード プロセスを開始するために最初に選択される APIC は、インストーラによって最初に呼び出される APIC に応じてランダムに選択されます。つまり、クラスタ内で最初にアップグレードを開始する APIC は、必ずしも番号が最も小さいAPICではありません。

    この段階では、次のようなエラーおよび警告メッセージが表示されることがあります。

    これは正常な動作であり、アップグレード プロセスの一環として APIC がリブートされるためです。

クラスタ内の最初の APIC が 5％ に達すると、各 APIC はアップグレード プロセスの次の段階に進み、[アップグレードの進行状況（Upgrade Progress）] 領域に表示されます。

  • インストーラによって呼び出される最初の APIC: 0％ → 5％ → 100％

  • クラスタ内の残りの APIC: 0％ → 100％

次の表に、このアップグレード プロセスの各段階で行われる処理の詳細を示します。

アップグレードの経過表示

説明
0%

アップグレード インストーラが開始し、アップグレード プロセスが開始されたときに表示されます。
5%

この段階では、クラスタ内のすべての APIC に対して次の設定が行われます。インストーラによって呼び出された最初の APIC のステータスは 5% のままで、クラスタ内の残りの APIC のステータスは 0% のままです。

  • この段階では、最初の APIC がクラスタ内の他の APIC で設定チェックを実行し、アップグレード プロセスが開始される前にすべての APIC で特定のアップグレード前の設定を実行します。

  • 設定チェックとアップグレード前の設定が完了し、ターゲット バージョンが APIC に事前ロードされると表示されます。

  • クラスタ内のすべての APIC は、インストーラによって最初に呼び出された APIC、次に 2 番目の APIC、3 番目の APIC の順に順次アップグレードされます。この段階では、各 APIC は、その前の APIC が完了するのを待ってから、アップグレードを開始します。つまり、最初の APIC ノードが最初にアップグレードを開始し、最初の APIC がアップグレード プロセスを完了するまで 2 番目と 3 番目の APIC が待機します。最初の APIC ノードがこの段階を完了すると、2 番目の APIC は￥がアップグレードプロセスを開始し、3 番目の APIC は待機します。

  • すべての APIC は、アップグレード プロセスのデータ変換フェーズを順番に実行します。アップグレード プロセスのこの段階で、アップグレード プロセスが失敗すると、システムは以前のバージョンのソフトウェアにロールバックします。

    この段階のデータ変換部分が完了すると、この段階で各 APIC がリブートします。各 APIC がリブートすると、次のように表示されます。

    • 次のエラーおよび警告メッセージが表示される場合があります。

      不明な理由により、サーバ側のエラーまた はWeb ソケット接続が閉じられたため、要求が失敗しました

      これは正常な動作であり、アップグレード プロセスの一環として APIC がリブートされるためです。

    • APIC は、GUI の APIC コントローラのリストから一時的に表示されなくなり、リブートが完了してアップグレードが正常に完了すると、リストに再表示されます。

    ブラウザが接続されている Cisco APIC がアップグレードされて再起動すると、ブラウザには最初にエラー メッセージが表示されます。その後、この APIC にログインするために使用したブラウザには何も表示されません。ただし、必要に応じて、クラスタ内の残りの APIC にログインして、アップグレード プロセスの進行状況をモニタし続けることができます。

100 %

APIC がアップグレード プロセス全体を正常に完了したときに表示されます。

4.2(5) より前のリリースからリリース 4.2(5) 以降へのアップグレード

ソフトウェアの現在の実行バージョンが Cisco APIC リリース 4.2(5) 以降で、それ以降のリリースにアップグレードする場合、このセクションでは、アップグレード プロセス中に各 APIC が実行する段階について説明します。

  • アップグレードを開始する前に、各 APIC は 100% で表示されます。これは、各 APIC で以前に実行されたインストール、アップグレード、またはダウングレードが正常に完了したことを示します。

  • アップグレード プロセスを開始すると、次の図に示すように、すべての APIC のステータスが 100% から 0% に変わります。

  • 次に、インストーラによって最初に選択された APIC がアップグレードを開始し、次の図に示すように 5％ に進みます。


    （注）  

    アップグレード プロセスを開始するために最初に選択される APIC は、インストーラによって最初に呼び出される APIC に応じてランダムに選択されます。つまり、クラスタ内で最初にアップグレードを開始する APIC は、必ずしも番号が最も小さいAPICではありません。

  • インストーラによって 2 番目に選択された APIC がアップグレードを開始し、5％ に進みます。

  • インストーラによって 3 番目に選択された APIC がアップグレードを開始し、5％ に進みます。

    クラスタ内に 3 つ以上の APIC がある場合、クラスタ内のすべての APIC が 5％ になるまでプロセスが続行されます。

クラスタ内のすべての APIC が 5％ に達すると、各 APIC はアップグレード プロセスの次の段階に進み、[アップグレードの進捗状況（Upgrade Progress）] 領域に表示されます。

  • インストーラによって最初に呼び出される APIC: 0％ → 5％ → 10％ → 25％ → 50％ → 75％ → 100％

  • クラスタ内の残りのAPIC: 0％ → 5％ → 25％ → 50％ → 75％ → 100％

次の表に、このアップグレード プロセスの各段階で行われる処理の詳細を示します。

アップグレードの経過表示

インストール ステージ

インストール ステージ ステータス

説明
0%

次のアップグレードの準備完了

キュー（Queued）

アップグレード インストーラが開始し、アップグレード プロセスが開始されたときに表示されます。
5%

互換性の確認

コントローラのハードウェアとソフトウェアの互換性を確保する

アップグレード インストーラが開始し、アップグレード プロセスが開始されたときに表示されます。

10%

コントローラの正常性の確認

コントローラがアップグレードを続行できることを確認するためのアップグレード前の検証チェックの実行

この段階では、インストーラで呼び出される最初の APIC がクラスタ内の他の APIC で設定チェックを実行し、アップグレード プロセスが開始される前にすべての APIC で特定のアップグレード前の設定を実行します。最初の APIC はこの段階で 10% に移行しますが、クラスタ内の他の APIC は5% のままになります。

25 %

アップグレードの実行

コントローラにターゲット バージョンをインストールします

設定チェックとアップグレード前の設定が完了し、ターゲット バージョンが APIC に事前ロードされると表示されます。

クラスタ内の他の APIC で設定チェックとアップグレード前の設定を実行している最初の APIC は、この段階で10% から25% に移行しますが、クラスタ内の残りの APIC は、この段階では5% から25% に直接移動します。

50%

アップグレードする他のコントローラの待機

他のコントローラが設定の移行を完了するまで待機

クラスタ内の APIC は、インストーラによって最初に呼び出された APIC、次に 2 番目の APIC、3 番目の APIC の順に順次アップグレードされます。この段階では、各 APIC は、その前の APIC が完了するのを待ってから、アップグレードを開始します。つまり、最初の APIC ノードが最初にアップグレードを開始し、最初の APIC がアップグレード プロセスを完了するまで 2 番目と 3 番目の APIC が待機します。最初の APIC ノードがこの段階を完了すると、2 番目の APIC は￥がアップグレードプロセスを開始し、3 番目の APIC は待機します。

75%

設定の移行

コントローラで変換を実行しています

アップグレード プロセスのデータ変換フェーズで表示されます。ここでも、クラスタ内のすべての APIC 間のアップグレードプロセスの順番が異なるため、1つの APIC はこの段階で50% から75% に移行しますが、他の2つの APIC は50% のままになります。最初の APIC がアップグレードプロセスのこのフェーズを完了すると、クラスタ内の2番目の APIC がこのフェーズを開始し、50% から75% に移行します。2 番目の APIC がアップグレードプロセスのこのフェーズを完了するまで、残りの APIC は 50% のままになります。

アップグレード プロセスのこの段階 (50% ステージと 75% ステージの間) で、アップグレード プロセスが失敗すると、システムは以前のバージョンのソフトウェアにロールバックします。

この段階のデータ変換部分が完了すると、この段階で各 APIC がリブートします。各 APIC がリブートすると、次のように表示されます。

  • 次のエラーと警告メッセージが表示される場合があります。

    不明な理由により、サーバ側のエラーまたは Web ソケット接続が閉じられたため、要求が失敗しました

    これは正常な動作であり、アップグレード プロセスの一環として APIC がリブートされるためです。

  • APIC は、GUI の APIC コントローラのリストから一時的に表示されなくなり、リブートが完了してアップグレードが正常に完了すると、リストに再表示されます。

ブラウザが接続されている Cisco APIC がアップグレードされて再起動すると、ブラウザには最初にエラー メッセージが表示されます。その後、この APIC にログインするために使用したブラウザには何も表示されません。ただし、必要に応じて、クラスタ内の残りの APIC (APIC がリロードされた時点でまだ 50% だった APIC) にログインして、アップグレード プロセスの進行状況をモニタし続けることができます。

100 %

次のアップグレードの準備完了

Successful（成功）

APIC がアップグレード プロセス全体を正常に完了したときに表示されます。

異なるメンテナンス グループ内のリーフ スイッチをアップグレードするときに起こりうる問題

シスコは、Cisco ACI リーフ スイッチ間のバージョンの不一致が原因で予期せぬ EP 通知メッセージが発生し、それを EPM プロセスが受信して EPM クラッシュにつながるおそれがあるという障害を発見し、バグ CSCvi76161 で報告しました。該当するソフトウェア リリースを 13.2(2) 以降にアップグレードするか、 13.2(2) 以降のリリースを該当するソフトウェア リリースにダウングレードする場合にのみ、この問題が発生します。

この問題は、2 つの異なるメンテナンス グループに属するリーフ スイッチをアップグレードするときに発生するおそれがあります。たとえば、Leaf 101 がメンテナンス グループ「Odds」、Leaf 102 がメンテナンス グループ「Evens」とします。メンテナンス グループ「Odds」をアップグレード（それに伴い Leaf 101 をアップグレード）すると、「Odds」のアップグレード後、Leaf 102 が HAP のリセットとリロードを続ける場合があります。

この問題には回避策が 2 つあります。

  • 2 段階でアップグレードを実行: 現在の Cisco NX-OS リリースに応じて、次の手順のいずれかを実行します。

    • Cisco NX-OS の 12.2(4p) 以前のリリースを実行しているファブリックの場合、12.2(4r) にアップグレードしてから目的のリリースにアップグレードします。

    • Cisco NX-OS の 12.3(1) リリースを実行しているファブリックの場合、13.1(2t) にアップグレードしてから目的のリリースにアップグレードします。

  • testapi バイナリを使用: testapi バイナリ使用して、アップグレード中はエンドポイント通知機能を一時的に無効にします。Cisco APIC を 3.2(2) 以降のリリースにアップグレードしたら、リーフ スイッチをアップグレードする前に、testapi バイナリを使用する必要があります。このメソッドを使用する場合は、Cisco TAC にお問い合わせください。

複数の中間リリースを介するアップグレードまたはダウングレードを理解する

Cisco ACI ファブリックでは基本的に、すべてのノード (APIC、リーフ スイッチ、およびスパイン スイッチ) が同じソフトウェア リリースまたは互換性のあるソフトウェア リリースである必要があります。この場合、APIC ノードの標準リリース形式は x.y(z)、リーフおよびスパイン スイッチは、スイッチ固有の標準リリース形式の 1x.y(z) になります。たとえば、 APIC ノードがソフトウェアリリース 4.1(1) である場合、リーフ スイッチとスパイン スイッチは、スイッチ固有の互換性のあるソフトウェアリリースである 14.1(1) である必要があります。

ただし、多数のスイッチのある巨大なファブリックをアップグレードまたはダウングレードする場合や、数日かけてアップグレードまたはダウングレードを行う場合など、ファブリック内で異なるリリースを同時に使用することになる状況があります (詳細については、Cisco ACI スイッチの混合バージョン中に許可される操作 を参照してください)。このような状況では、ファブリック内には常に、多くとも 2 つの異なる APIC とスイッチ ソフトウェア リリースが存在し得ます。

これは、 APIC 3.0(2) リリースから 4.1(2) リリースに直接アップグレードする場合など、現在のリリースから直接アップグレードまたはダウングレード パスを使用している場合は問題ではありません。これは、直接のパスがなく、目的のリリースに到達するために複数の中間リリースを通過する必要がある場合に問題になります (サポートされているアップグレードおよびダウングレード パスについては、 APIC のアップグレード/ダウングレードのサポート マトリックス (APIC Upgrade/Downgrade Support Matrix)を参照してください)。

現在のリリースからの直接のアップグレード パスが存在しないリリースにアップグレードする場合は、すべての APIC とスイッチを、直接アップグレード パスが存在する、サポート対象の中間リリースにアップグレードしたうえで、そのリリースから目的のリリースにアップグレードする必要があります。状況によっては、目的のリリースにアップグレードする前に、複数の中間リリースにアップグレードしなければならない場合があります。この場合、複数の対象 APIC とスイッチの両方をそのつど同じリリースにアップグレードします。

たとえば、 APICアップグレード/ダウングレードサポートマトリックスに、リリース 2.3(1) からリリース 4.2(3) へのアップグレードのための複数の中間リリースが示されている場合、次のような状況が考えられます。

この状況では、次の方法でアップグレードを実行します。

  1. APIC を 3.1(2) リリースにアップグレードし、スイッチを 13.1(2) リリースにアップグレードします。

  2. 3.1 (2)/13.1 (2) へのアップグレード後に、すべての APIC およびスイッチが完全に適合した状態で、動作していることを確認します。

  3. APIC を 4.1 (2) リリースにアップグレードし、スイッチを 14.1(2) リリースにアップグレードします。

  4. 4.1 (2)/14.1 (2) へのアップグレード後に、すべての APIC およびスイッチが完全に適合した状態で、動作していることを確認します。

  5. APICを 4.2(3) リリースにアップグレードし、スイッチを 14.2(3) リリースにアップグレードします。

  6. 4.2(3)/14.2(3) へのアップグレード後に、すべての APIC およびスイッチが完全に適合した状態で、動作していることを確認します。

Cisco APIC およびスイッチ ソフトウェアのアップグレード パス

Cisco APIC およびスイッチ ソフトウェアのアップグレード パスは、本ドキュメントでは提供されません。Cisco APIC およびスイッチ ソフトウェアの最新のアップグレード パスのサポートについては、「Cisco APIC アップグレード/ダウングレード サポート一覧」を参照してください。

https://www.cisco.com/c/dam/en/us/td/docs/Website/datacenter/apicmatrix/index.html

Cisco APIC およびスイッチ ソフトウェアのダウングレードについて

最初に触れるリリースについては、「Cisco アプリケーション ポリシー インフラストラクチャ コントローラ リリース ノート」を常にチェックしてください。

APIC ダウングレード段階の説明

APIC ダウングレードの準備段階

現在実行中のソフトウェアのバージョンまたはダウングレード先のソフトウェアのバージョンに関係なく、APIC のダウングレードには常に一定の段階があります。

  • ダウングレードを開始する前に、各 APIC は 100％ で表示されます。これは、各 APIC で以前に実行されたインストール、アップグレード、またはダウングレードが正常に完了したことを示します。

  • ダウングレード プロセスを開始すると、次の図に示すように、すべての APIC のステータスが 100％ から 0％ に変わります。

  • 次に、インストーラによって最初に選択された APIC がダウングレードを開始し、次の図に示すように 5％ に進みます。


    （注）  

    ダウングレード プロセスを開始するために最初に選択される APIC は、インストーラによって最初に呼び出される APIC に応じてランダムに選択されます。つまり、クラスタ内でダウングレードを開始する最初の APIC は、必ずしも番号が最も小さい APIC ではありません。

  • インストーラによって 2 番目に選択された APIC は、ダウングレードを開始し、5％ に進みます。

  • インストーラによって 3 番目に選択された APIC は、ダウングレードを開始し、5％ に進みます。

    クラスタに 3 個を超える APIC がある場合、プロセスは、クラスタのすべての APIC が 5% になるまで続きます。

クラスタ内のすべての APIC がダウングレードの進行中に 5％ に達すると、ダウングレード プロセス中に APIC が通過する段階は、現在実行中のソフトウェアのバージョンと、ダウングレードするソフトウェアのバージョンによって異なります。 特定のダウングレードで発生するステージの詳細については、以下の該当するセクションを参照してください。

リリース 4.2(5) 以降から 3.2(x) 以降のリリースへのダウングレード

ソフトウェアの現在実行中のバージョンが Cisco APIC リリース 4.2(5) 以降で、リリース 3.2(x) 以降のリリースにダウングレードする場合、このセクションでは、各 APIC がダウングレード プロセス中に実行する段階について説明します。

  • まず、クラスタ内のすべてのAPICは、APIC ダウングレードの準備段階 で説明されているように、特定の準備段階を経ます。

  • クラスタ内のすべての APIC が 5％ に達すると、各 APIC はダウングレード プロセスの次の段階に進み、[アップグレードの進行状況（Upgrade Progress）] 領域に表示されます。

    • インストーラによって最初に呼び出される APIC: 0％ → 5％ → 10％ → 25％ → 50％ → 75％ → 100％

    • クラスタ内の残りのAPIC: 0％ → 5％ → 25％ → 50％ → 75％ → 100％

次の表に、このダウングレード プロセスの各段階で行われる処理の詳細を示します。

アップグレードの経過表示

インストール ステージ

インストール ステージ ステータス

説明
0%

次のアップグレードの準備完了

キュー（Queued）

アップグレード インストーラが開始し、アップグレード プロセスが開始されたときに表示されます。
5%

互換性の確認

コントローラのハードウェアとソフトウェアの互換性を確保する

ダウングレード インストーラが開始され、ダウングレード プロセスが開始されたときに表示されます。

10%

コントローラの正常性の確認

コントローラがアップグレードを続行できることを確認するためのアップグレード前の検証チェックの実行

この段階では、最初の APIC がクラスタ内の他の APIC で設定チェックを実行し、ダウングレード プロセスが開始される前にすべての APIC で特定のダウングレード前の設定を実行します。最初の APIC はこの段階で 10% に移行しますが、クラスタ内の他の APIC は5% のままになります。

25 %

アップグレードの実行

コントローラにターゲット バージョンをインストールします

設定チェックとダウングレード前の設定が完了し、ターゲット　バージョンが APIC に事前ロードされると表示されます。

クラスタ内の他の APIC で設定チェックとダウングレード前の設定を実行している最初の APIC は、この段階で 10% から25% に移行しますが、クラスタ内の残りの APIC は、この段階では5% から25% に直接移動します。

50%

アップグレードする他のコントローラの待機

他のコントローラが設定の移行を完了するまで待機

クラスタ内のAPICは、一度にすべて同時にダウングレードするのではなく、インストーラによって最初に呼び出されたAPIC、2番目のAPIC、3番目のAPICの順に順次ダウングレードされます。この段階では、各 APIC は、その前の APIC が完了するのを待ってから、ダウングレードを開始します。つまり、最初の APIC が最初にダウングレードを開始し、2 番目と 3 番目の APIC は最初の APIC がダウングレード プロセスを完了するまで待機します。最初の APIC がこの段階を完了すると、2 番目の APIC がダウングレード プロセスを開始し、3 番目の APIC が待機します。

75%

設定の移行

コントローラで変換を実行しています

ダウングレード プロセスのデータ変換フェーズで表示されます。ここでも、クラスタ内のすべての APIC 間のダウングレード プロセスの順番が異なるため、1 つの APIC はこの段階で50% から 75% に移行しますが、他の2つの APIC は 50% のままになります。最初の APIC がダウングレード プロセスのこのフェーズを完了すると、クラスタ内の 2 番目の APIC がこのフェーズを開始し、50% から 75% に移行します。2 番目の APIC がダウングレード プロセスのこのフェーズを完了するまで、残りの APIC は 50% のままになります。

ダウングレード プロセスのこの段階 （50% ステージと 75% ステージの間）で、ダウングレード プロセスが失敗すると、システムは以前のバージョンのソフトウェアにロールバックします。

この段階のデータ変換部分が完了すると、この段階で各 APIC がリブートします。各 APIC がリブートすると、次のように表示されます。

  • システムが APIC への接続に失敗したことを示すエラー メッセージが表示される場合があります。これは正常な動作であり、APIC がダウングレード プロセスの一部としてリブートされるためです。

  • APIC は、GUI の APIC コントローラのリストから一時的に表示されなくなり、リブートが完了してダウングレードが正常に完了すると、リストに再表示されます。

ブラウザが接続されている Cisco APIC がダウングレードされて再起動すると、ブラウザには最初にエラー メッセージが表示されます。その後、この APIC にログインするために使用したブラウザには何も表示されません。ただし、必要に応じて、クラスタ内の残りの APIC (APIC がリロードされた時点でまだ 50% だった APIC) にログインして、ダウングレード プロセスの進行状況をモニタし続けることができます。

100 %

次のアップグレードの準備完了

Successful（成功）

APIC がダウングレード プロセス全体を正常に完了したときに表示されます。

リリース 4.2(5) 以降からリリース 3.2(x) 以前へのダウングレード

ソフトウェアの現在の実行バージョンが Cisco APIC リリース 4.2(5) 以降であり、リリース 3.2(x) 以前にダウングレードする場合、このセクションでは、各 APIC がダウングレード プロセス中に実行する段階について説明します。

  • まず、クラスタ内のすべてのAPICは、APIC ダウングレードの準備段階 で説明されているように、特定の準備段階を経ます。

  • クラスタ内のすべての APIC が 5％ に達すると、各 APIC はダウングレード プロセスの次の段階に進み、[アップグレードの進行状況（Upgrade Progress）] 領域に表示されます。

    • インストーラによって最初に呼び出される APIC：0％ → 5％ → 10％ → 50％ → 75％ → 100％

    • クラスタ内の残りの APIC：0％ → 5％ → 50％ → 75％ → 100％

次の表に、このダウングレード プロセスの各段階で行われる処理の詳細を示します。

アップグレードの経過表示

インストール ステージ

インストール ステージ ステータス

説明
0%

次のアップグレードの準備完了

キュー（Queued）

アップグレード インストーラが開始し、アップグレード プロセスが開始されたときに表示されます。
5%

互換性の確認

コントローラのハードウェアとソフトウェアの互換性を確保する

ダウングレード インストーラが開始され、ダウングレード プロセスが開始されたときに表示されます。

10%

コントローラの正常性の確認

コントローラがアップグレードを続行できることを確認するためのアップグレード前の検証チェックの実行

この段階では、最初の APIC がクラスタ内の他の APIC で設定チェックを実行し、ダウングレード プロセスが開始される前にすべての APIC で特定のダウングレード前の設定を実行します。最初の APIC はこの段階で 10% に移行しますが、クラスタ内の他の APIC は5% のままになります。

50%

アップグレードする他のコントローラの待機

他のコントローラが設定の移行を完了するまで待機

ダウングレード プロセスのこの段階では、次の処理が行われます。

  • 設定チェックとダウングレード前の設定が完了し、ターゲット バージョンが APIC に事前ロードされます。

    クラスタ内の他の APIC で設定チェックとダウングレード前の設定を実行している最初の APIC は、この段階で 10% から 50% に移行しますが、クラスタ内の残りの APIC は、この段階では 5% から 50% に直接移動します。

  • クラスタ内の APIC は、一度にすべて同時にダウングレードするのではなく、インストーラによって最初に呼び出された APIC、2 番目の APIC、3 番目の APIC の順に順次ダウングレードされます。この段階では、各 APIC は、その前の APIC が完了するのを待ってから、ダウングレードを開始します。つまり、最初の APIC が最初にダウングレードを開始し、2 番目と 3 番目の APIC は最初の APIC がダウングレード プロセスを完了するまで待機します。最初の APIC がこの段階を完了すると、2 番目の APIC がダウングレード プロセスを開始し、3 番目の APIC が待機します。

75%

設定の移行

コントローラで変換を実行しています

ダウングレード プロセスのデータ変換フェーズで表示されます。ここでも、クラスタ内のすべての APIC 間のアップグレードプロセスの順番が異なるため、1 つの APIC はこの段階で 50% から75% に移行しますが、他の 2 つの APIC は5 0% のままになります。最初の APIC がダウングレード プロセスのこのフェーズを完了すると、クラスタ内の 2 番目の APIC がこのフェーズを開始し、50% から 75% に移行します。2 番目の APIC がダウングレード プロセスのこのフェーズを完了するまで、残りの APIC は 50% のままになります。

ダウングレード プロセスのこの段階 （50% ステージと 75% ステージの間）で、ダウングレード プロセスが失敗すると、システムは以前のバージョンのソフトウェアにロールバックします。

この段階のデータ変換部分が完了すると、この段階で各 APIC がリブートします。各 APIC がリブートすると、次のように表示されます。

  • システムが APIC への接続に失敗したことを示すエラー メッセージが表示される場合があります。これは正常な動作であり、APIC がダウングレード プロセスの一部としてリブートされるためです。

  • APIC は、GUI の APIC コントローラのリストから一時的に表示されなくなり、リブートが完了してダウングレードが正常に完了すると、リストに再表示されます。

ブラウザが接続されている Cisco APIC がダウングレードされて再起動すると、ブラウザには最初にエラー メッセージが表示されます。その後、この APIC にログインするために使用したブラウザには何も表示されません。ただし、必要に応じて、クラスタ内の残りの APIC (APIC がリロードされた時点でまだ 50% だった APIC) にログインして、ダウングレード プロセスの進行状況をモニタし続けることができます。

100 %

次のアップグレードの準備完了

Successful（成功）

APIC がダウングレード プロセス全体を正常に完了したときに表示されます。

ステートレス ダウングレード手順

手順

ステップ 1

ファブリック設定をエクスポートします。

ステップ 2

Cisco APIC で eraseconfig コマンドを実行します。これで、コントローラが再起動されます。コントローラがステップ 3 移動する前にリブートされていることを確認します。

ステップ 3

ファブリックを再検索します。

ステップ 4

目的のリリースにファブリックのダウン グレードします。

ステップ 5

Cisco APIC で eraseconfig setup コマンドを実行します。この手順は、使用中のバージョンで必要になる可能性がある追加のコマンドをスクリプトから実行できるようにするために必要です。eraseconfig setup コマンドによって Cisco APIC がリロードされます。

ステップ 6

実行、 セットアップ clean config.sh スイッチのノードでスクリプトを作成し、それらをリロードします。

ステップ 7

Initial setup(初期セットアップ、初期設定) スクリプトを実行します、 Cisco APIC s。

ステップ 8

ファブリックをインポート「マージ」モードを使用して設定をインポートします。

Cisco APIC およびスイッチ ソフトウェアのサポートされているダウングレード パス

Cisco APIC およびスイッチ ソフトウェアのダウングレード パスは、本ドキュメントでは提供されません。Cisco APIC およびスイッチ ソフトウェアの最新のダウングレード パスのサポートについては、「Cisco APIC アップグレード/ダウングレード サポート一覧」を参照してください。

https://www.cisco.com/c/dam/en/us/td/docs/Website/datacenter/apicmatrix/index.html

スケジューラによるアップグレードについて

スケジューラを使用すると、Cisco APIC クラスタやスイッチのアップグレードなど、操作の時間枠を指定します。これらの時間枠は、1 -回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。このセクションでは、アップグレードのスケジューラの仕組みについて説明します。スケジューラに関する詳細情報については、『Cisco アプリケーション セントリック インフラストラクチャの基礎』を参照してください。


（注）  

クラスタのアップグレードを実行する場合、 Cisco APIC はクラスタに参加するためすべて同じバージョンである必要があります。ファブリックに参加する際の自動アップグレードはありません。

  • Cisco APIC クラスタ アップグレード：Cisco APIC のデフォルトのスケジューラ オブジェクトがあります。一般的なスケジューラ オブジェクトには複数のプロパティがありますが、開始時間のプロパティのみ Cisco APIC クラスタ アップグレードに設定可能です。開始時間を指定する場合、 Cisco APIC アップグレード スケジューラは 1 日の期間に指定された開始時刻からアクティブになります。コントローラに対して runningVersion != desiredVersion の場合、このアクティブな 1 日のウィンドウの間いつでもクラスタ アップグレードを開始します。スケジューラのその他のパラメータは Cisco APIC アップグレードに設定できません。スケジューラを使用しない 1 回のトリガを使用して、Cisco APIC アップグレードを実行できることにも注意してください。この 1 回のトリガは、[今すぐアップグレード] とも呼ばれます。

  • スイッチのアップグレード：スケジューラはメンテナンス グループに関連付けることができます。スイッチのメンテナンス グループに接続されているスケジューラには、「startTime」、「concurCap」および「duration」などいくつかの設定可能なパラメータがあります。これらのパラメータは下記に説明されています。

    • startTime：アクティブなウィンドウの開始。

    • concurCap：同時にアップグレードするノードの数。

    • Duration：アクティブなウィンドウの長さ。

    グループ内のスイッチに対して runningVersion != desiredVersion の場合、このアクティブな 1 日のウィンドウの間いつでもスイッチはアップグレードの対象となります。アップグレードの対象ノード間で、次の制約がアップグレードの候補の選択に適用されます。

    • 「concurCap」ノード以上には現在アップグレードできません。

    • 1 回でアップグレードされるのは仮想ポート チャネル（vPC）ペアの 1 つのノードのみです。

    • Cisco APIC クラスタはノードのアップグレードを開始する前に正常な状態である必要があります。


    （注）  

    GUI、CLI、または REST API を使用して、即時アップグレードとスケジューラベースのアップグレードのオプションがあります。たとえば、CLI では、EXEC モードで firmware upgrade switch-group コマンドを使用して、スイッチグループをすぐにアップグレードできます。このコマンドは、設定されたスケジュール済みアップグレードよりも優先されます。

GUI を使用したスケジューラ―の構成

トリガー スケジューラを使用すると、管理者による介入なしで 1 つ以上のノードをアップグレードして再起動できる、1 回限りまたは繰り返しの期間を定義できます。

手順

ステップ 1

[トリガー スケジューラの作成 (Create Trigger Scheduler)] ウィンドウにアクセスします。

詳細については、「ファームウェアのアップグレード モード」を参照してください。

ステップ 2

[トリガー スケジューラの作成 (Create Trigger Scheduler)] ウィンドウで、[名前 (name)] フィールドにスケジューラ ポリシーの名前を入力し、[スケジュール ウィンドウ (schedule Windows)] 領域で [+] をクリックして [スケジュールの作成 (Create Schedule)create schedule]ウィンドウを表示します。

ステップ 3

[ウィンドウ タイプ (Window Type)] フィールドで、1 回限りまたは定期スケジュール ウィンドウのどちらを設定するかに応じて、[1 回限り (One Time)] または [定期 (Recurring)] をクリックします。

ステップ 4

[ウィンドウ名 (Window Name)] フィールドで、このスケジュール ウィンドウの名前を入力します。

このフィールドの最大文字数は 16 です。
ステップ 5

[スケジュール (schedule)] ウィンドウを実行する日付と時刻を決定します。

日付と時刻を設定するためのオプションは、ワンタイムまたは定期スケジュール ウィンドウのどちらを設定するかによって異なります。

  • 1 回限りのスケジュール ウィンドウを設定している場合は、[日付 (Date) )] フィールドに、1回限りのスケジュール ウィンドウが発生する日付を入力します。このフィールドでは、YYYY-MM-DD HH: MM: SS AM/PM の形式を使用するか、下矢印をクリックしてカレンダーから日付と時刻を選択します。

    （注）   

    [1 回限りのスケジュール (one-time schedule)] ウィンドウの過去の日付と時刻 (現在の日付と時刻の前) を入力すると、システムはそのエントリを拒否します。

  • [定期スケジュール (Recurring Schedule)] ウィンドウを設定している場合は、次のフィールドに必要な情報を入力します。

    • [日 (Day)]: 定期スケジュールウィンドウを実行する日付を選択します。定期スケジュールウィンドウを毎週実行する特定の日を選択するか、または定期的なスケジュールウィンドウを毎日、すべての偶数日または週のすべての奇数の曜日に実行するかを選択します。

    • [時間 (hour)]: 軍事 24 時間のクロック値 (0-23) を使用して、スケジュールウィンドウを繰り返す時間を入力します。

    • [分 (minute)]: 定期スケジュールウィンドウを発生させる分を入力します。

    たとえば、毎日午後 11:30 の火曜日に定期スケジュールウィンドウを設定する場合は、次のように選択します。

    • Day: 火曜日

    • 時間:22

    • 分:30

（注）   

定期スケジュールウィンドウの過去の日付と時刻 (現在の日時よりも前) を入力すると、スケジューラはすぐにアップグレードをトリガーします。たとえば、水曜日に正午にあり、火曜日ごとの午後 11:30 に定期アップグレードスケジュールを設定した場合、スケジューラは最初にアップグレードをトリガーし、その時点から火曜日ごとの午後 11:30 にアップグレードを実行します。

ステップ 6

[最大同時ノード (Maximum Concurrent nodes)] フィールドに、同時アップグレードを行うことが許可されるノードの最大数を入力します。

このフィールドに 0 を入力すると、ノードが APIC ノードであるか、リーフまたはスパインスイッチであるかに応じて、ソフトウェアによってデフォルト値が自動的に選択されます。

  • リリース 4.2(5) より前のリリースでは、このフィールドのデフォルト値「0」は APIC ノードの場合は 1、リーフまたはスパイン スイッチの場合は 20 と解釈されます。このフィールドに入力できる POD ごとの最大ノード数は 200 です。

  • リリース 4.2(5) 以降では、このフィールドのデフォルト値「0」は、APIC ノードでは 1 と解釈されます。リーフまたはスパイン スイッチの場合、このフィールドのデフォルト値の「0」の解釈は 20 から無制限に変更されています。つまり、このフィールドに「0」を入力すると、一度にアップグレードできるリーフ スイッチまたはスパイン スイッチの数は無制限になります。

ステップ 7

[最大実行時間 (Maximum Running time)] フィールドで、スケジュール ウィンドウの最大継続時間を入力します。これは、アップグレード プロセスを開始するために許可する時間の長さです。

このフィールドでは、DD: HH: MM: SS の形式を使用し、最大 24 時間 (01:00:00:00) を使用します。[スケジューラ (scheduler)] ウィンドウで時間制限を適用しない場合は、[無制限 (unlimited)] を入力します。

たとえば、これらのフィールドに次の値を入力したとします。

  • 最大同時ノード (Maximum Concurrent Nodes)数:20

  • 最大実行時間 (Maximum Running Time): 00:00:30:00

この場合、このスケジュール ウィンドウでは、20 個のノードを同時にアップグレードできます。これらの 20 ノードは、上記のフィールドに入力した開始時刻から 30 分以内にアップグレードプロセスが正常に開始した場合にのみアップグレードされます。アップグレード プロセスが 30 分以内に正常に開始されない場合、この時点では 20 ノードはアップグレードされません。また、定期スケジュール ウィンドウを設定した場合、次回スケジューラ ウィンドウが繰り返しに設定されたときに、システムはこれらの 20 ノードのアップグレードを試行します。

20 スイッチのデフォルト グループでは、通常、スイッチのグループごとにアップグレードに最大 12 分かかります。[最大実行時間 (Maximum Running Time)] フィールドに入力した値は、グループ内のスイッチがアップグレードするために必要な時間には影響しません。たとえば、[最大実行時間 (Maximum Running Time)] フィールドに値 5 を入力した場合は、アップグレードが 5 分後に開始されない場合、システムはスイッチのアップグレードプロセスを放棄することのみを意味します。これは、システムが 5 分後にアップグレードプロセスを停止することを意味するものではありません。

ステップ 8

[トリガー スケジューラ―の作成 (Create Trigger Scheduler)] ウィンドウで必要な情報の入力が完了したら、[OK] をクリックします。

[トリガー スケジューラ―の作成 (Create Trigger Scheduler)] ウィンドウが再度表示され、新しく設定されたスケジュール ウィンドウがスケジュール ウィンドウ テーブルに表示されます。

ステップ 9

このトリガー スケジューラに対して追加のスケジュール ウィンドウを作成するかどうかを決定します。

このトリガー スケジューラに対してより多くのスケジュール ウィンドウを作成する場合は、[スケジュール ウィンドウ (Schedule Windows)] 領域で [+] をクリックして、[スケジュール ウィンドウの作成 (Create Schedule Window)] ウィンドウを再度表示します。

たとえば、毎日 2 回開始するようにアップグレードを設定する場合や、毎日 12:00 AM と PM の場合、または特定の曜日にアップグレードを設定する場合は、より多くのスケジュールウィンドウを作成することができます。
ステップ 10

必要なスケジュールウィンドウの設定が完了したら、[トリガー スケジューラの作成 (Create Trigger Scheduler )] ウィンドウで [送信 (Submit)] をクリックします。

[ノード アップグレードの選択 (Select Node Upgrade) ] ウィンドウが再度表示されます。

ステップ 11

[ノード アップグレードの選択 (Select Node Upgrade)] ウィンドウで、[スケジューラ (Scheduler)] フィールドを見つけて、先ほど設定したトリガースケジュールを選択します。

ステップ 12

[ノード アップグレードの選択 (Select Node Upgrade)] ウィンドウで必要な追加設定を完了し、[送信 (Submit)] をクリックします。

NX-OS スタイルの CLI を使用したスケジューラ―の構成

スケジュールにより、設定のインポート/エクスポートまたはテクニカル サポートの収集などの操作を 1 つ以上の指定した時間帯に発生させることができます。

スケジュールには、一連のタイム ウィンドウ（オカレンス）が含まれます。これらのウィンドウは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。期間や実行するタスクの最大数などのウィンドウで定義されているオプションにより、スケジュール設定されたタスクの実行時期が決定されます。たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。

各スケジュールは、APIC が 1 つまたは複数のメンテナンス時間帯に入っているかどうか、定期的に確認します。入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。

スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。オカレンスは次のいずれかになります。

  • 絶対（1 回）時間帯：絶対時間帯は、1 回しか発生しないスケジュールを定義します。これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。

  • 繰り返し時間帯：繰り返し時間帯は、繰り返しのスケジュールを定義します。この時間帯は、タスクの最大数に達するまで、または時間帯に指定された日の終わりに達するまで継続します。

手順

  コマンドまたはアクション 目的
ステップ 1

configure

例:

apic1# configure

グローバル コンフィギュレーション モードを開始します。

ステップ 2

[no] scheduler schedule-name

例:

apic1(config)# scheduler controller schedule myScheduler

新しいスケジューラを作成するか、既存のスケジューラを設定します。

ステップ 3

[no] description text

例:

apic1(config-scheduler)# description 'This is my scheduler'

このスケジューラの説明を追加します。テキストにスペースが含まれている場合は、単一引用符で囲む必要があります。

ステップ 4

[no] absolute window ウィンドウ名

例:

apic1(config-scheduler)# absolute window myAbsoluteWindow

絶対（1 回）の時間帯スケジュールを作成します。

ステップ 5

[no] max concurrent nodes count

例:

apic1(config-scheduler-absolute)# max concurrent nodes 300

同時に処理できるノード（タスク）の最大数を設定します。指定できる範囲は 0 ～ 65535 です。ノード数を制限しない場合は 0 に設定します。

ステップ 6

[no] max running time time

例:

apic1(config-scheduler-absolute)# max running time 00:01:30:00

dd:hh:mm:ss の形式でタスクの最大実行時間を設定します。指定できる範囲は 0 ～ 65535 です。時間の制限がない場合は 0 に設定します。

ステップ 7

[no] time start time

例:

apic1(config-scheduler-absolute)# time start 2016:jan:01:12:01

[[[yyyy:]mmm:]dd:]HH:MM 形式で開始時刻を設定します。

ステップ 8

exit

例:

apic1(config-scheduler-absolute)# exit

スケジューラ コンフィギュレーション モードに戻ります。

ステップ 9

[no] recurring window ウィンドウ名

例:

apic1(config-scheduler)# recurring window myRecurringWindow

繰り返し時間帯のスケジュールを作成します。

ステップ 10

[no] max concurrent nodes count

例:

apic1(config-scheduler-recurring)# max concurrent nodes 300

同時に処理できるノード（タスク）の最大数を設定します。指定できる範囲は 0 ～ 65535 です。ノード数を制限しない場合は 0 に設定します。

ステップ 11

[no] max running time time

例:

apic1(config-scheduler-recurring)# max running time 00:01:30:00

dd:hh:mm:ss の形式でタスクの最大実行時間を設定します。指定できる範囲は 0 ～ 65535 です。時間の制限がない場合は 0 に設定します。

ステップ 12

[no] time start { daily HH:MM | weekly （使用状況を参照） HH:MM}

例:

apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

期間（毎日または毎週）と開始時刻を設定します。weekly を選択した場合、次のオプションから選択します。

  • monday

  • tuesday

  • wednesday

  • thursday

  • friday

  • saturday

  • sunday

  • even-day

  • odd-day

  • every-day

例

次に、毎週水曜日に実行するよう繰り返しスケジューラを設定する例を示します。 


apic1# configure
apic1(config)# scheduler controller schedule myScheduler
apic1(config-scheduler)# description 'This is my scheduler'
apic1(config-scheduler)# recurring window myRecurringWindow
apic1(config-scheduler-recurring)# max concurrent nodes 300
apic1(config-scheduler-recurring)# max running time 00:01:30:00
apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

REST API を使用したスケジューラ―の構成

スケジュールにより、設定のインポート/エクスポートまたはテクニカル サポートの収集などの操作を 1 つ以上の指定した時間帯に発生させることができます。

スケジュールには、一連のタイム ウィンドウ（オカレンス）が含まれます。これらのウィンドウは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。期間や実行するタスクの最大数などのウィンドウで定義されているオプションにより、スケジュール設定されたタスクの実行時期が決定されます。たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。

各スケジュールは、APIC が 1 つまたは複数のメンテナンス時間帯に入っているかどうか、定期的に確認します。入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。

スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。オカレンスは次のいずれかになります。

  • 絶対（1 回）時間帯：絶対時間帯は、1 回しか発生しないスケジュールを定義します。これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。

  • 繰り返し時間帯：繰り返し時間帯は、繰り返しのスケジュールを定義します。この時間帯は、タスクの最大数に達するまで、または時間帯に指定された日の終わりに達するまで継続します。

手順

ステップ 1

リポジトリにスイッチ イメージをダウンロードします。

例:

POST URL: https://<ip address>/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="Switch_Image_download" proto="http" url="http://<ip address>/<ver-no>"/>
</firmwareRepoP>
ステップ 2

次のポリシーを、POST 送信することにより、ノード ID が 101、102、103、104 の スイッチから構成されるファームウェア グループを作成し、ノード ID 101、102、103、104 によるメンテナンス グループを作成します。

例:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<fabricInst>
<firmwareFwP
    name="AllswitchesFwP"
    version="<ver-no>"
    ignoreCompat="true">
</firmwareFwP>

<firmwareFwGrp
    name="AllswitchesFwGrp" >
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<firmwareRsFwgrpp
    tnFirmwareFwPName="AllswitchesFwP">
</firmwareRsFwgrpp>
</firmwareFwGrp>

<maintMaintP
    name="AllswitchesMaintP"
    runMode="pauseOnlyOnFailures" >
</maintMaintP>

<maintMaintGrp
    name="AllswitchesMaintGrp">
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<maintRsMgrpp
    tnMaintMaintPName="AllswitchesMaintP">
</maintRsMgrpp>
</maintMaintGrp>
</fabricInst>
ステップ 3

スケジューラに基づいてすべてのスイッチをアップグレードするには、次のようなポリシーをポストします。

例:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<trigSchedP annotation="" descr="" dn="uni/fabric/schedp-EveryEightHours" name="EveryEightHours" nameAlias="" ownerKey="" ownerTag="" userdom="">
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="17" minute="0" name="third" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="9" minute="0" name="second" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="1" minute="0" name="first" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
</trigSchedP>

アップグレードする前に LLDP に接続を無効にする方法

Cisco ACI ファブリックから Cisco APIC 2.x にアップグレードする前に、アップグレード対象が異なるインフラストラクチャ VLAN を持つ別の 2 つの Cisco ACI ファブリックが参加する、バックツー バック リーフ スイッチの接続を介した LLDP を持つ場合、それらの LLDP 接続を最初に無効にする必要があります。

それらの接続で LLDP を無効にしない場合、アップグレードが Cisco ACI を上書きし、スパインとリーフ スイッチ間の接続を中断します。

  • ターゲット接続で LLDP を無効にする方法の 1 つは、ポリシーを使用することです。共通のリーフ スイッチ インターフェイス プロファイルの関連付けられたインターフェイスを含み、共通のインターフェイス ポリシー グループとインターフェイス プロファイルを関連付けます。受信状態と送信状態が無効になる特別な LLDP インターフェイス ポリシーであるポリシー グループを含みます。

  • lldp が受信および送信を行わない CLI NX-OS スタイル CLI コマンドの対象のインターフェイスにも適用できます。

  • REST API POST で無効にすることもできます。 

    POST https://<apic>/api/node/mo/uni/infra/lldpIfP-LLDP-Disabled.json
{
  "lldpIfPol":{
    "attributes":{
      "dn":"uni/infra/lldpIfP-LLDP-Disabled",
      "name":"LLDP-Disabled",
      "adminRxSt":"disabled",
      "adminTxSt":"disabled",
      "status":"created"
    },"children":[]
  }
}

GUI を使用したソフトウェアのアップグレード

ここでは、実行しているソフトウェアのバージョンに応じて、GUI を使用してソフトウェアをアップグレードする方法について説明します。

GUI を使用したソフトウェアのアップグレード（リリース 4.x より前のリリース）

GUI を使用してソフトウェアをアップグレードできます。このセクションの手順は、リリース 4.x より前の Cisco APIC リリースに適用されます。現在実行されているソフトウェア ビルドは、現在のソフトウェア ビルドの確認での説明に従って確認できます。

GUI を使用した Cisco APIC ソフトウェアのバージョンのアップグレード（リリース 4.x より前のリリース）


（注）  
Cisco APIC とスイッチの正しいアップグレード順序を決めるため、Cisco APIC およびスイッチ ソフトウェアのアップグレードについて、およびアップグレード後のバージョンのリリース ノートを参照してください。

ファブリック内の APIC のソフトウェアをアップグレードするには、次の GUI ベースのアップグレード手順を使用します。

何らかの理由で、これらの GUI ベースのアップグレード手順を使用してファブリック内の APIC のソフトウェアをアップグレードできない場合（新しい注文または製品返品と交換（RMA）を通じて APIC を受け取った場合、GUI を使用してアップグレードを実行するためにファブリックに参加できない場合）、APIC ソフトウェアをアップグレードする代わりに、CIMC を使用して APIC でソフトウェアのクリーン インストールを実行できます。これらの手順については、インストール Cisco APIC 仮想メディアを使用してソフトウェア を参照してください。

手順
ステップ 1

メニュー バーで、[管理 (ADMIN)] > [ファームウェア (Firmware)] を選択し、[ナビゲーション (Navigation)] ペインで、[コントローラ ファームウェア (Controller Firmware)] をクリックします。

[作業（Work）] ペインの Cisco APIC には、各コントローラにロードされた現在のファームウェアが表示されます。ファームウェアが最後にアップグレードされたときの状態も表示されます。
ステップ 2

[ナビゲーション (Navigation)]ペインで、[ダウンロード タスク (Download Tasks)] をクリックします。

ステップ 3

[作業 (Work)] ペインで、[全般 (General)] > [アクション (Actions)] を選択し、[外部ファームウェア ソースの作成 (Create Outside Firmware source)] をクリックして、次のアクションを実行します。

ステップ 4

[外部ファームウェア ソースの作成 (Create Outside Firmware source)] ダイアログ ボックスで、次の操作を実行します。

  1. [ソース名 (Source Name)] フィールドに、Cisco APIC イメージ ファイルの名前（apic_image）を入力します。

  2. [プロトコル (Protocol)] フィールドで、[HTTP] オプション ボタンをクリックします。

    （注）   
    http ソースまたはセキュア コピー プロトコル（SCP）ソースからソフトウェア イメージをダウンロードする場合は、該当するオプション ボタンをクリックし、<SCP サーバ>:/<パス> の形式を使用します。URL の例としては、10.67.82.87:/home/<username>/ACI/aci-apic-dk9.1.0.2j.iso のようになります。

  3. [URL] フィールドに、イメージをダウンロードする URL を入力します。[送信 (Submit)] をクリックします。`

Cisco APIC のファームウェア イメージがダウンロードされるのを待ちます。
ステップ 5

[ナビゲーション (Navigation)]ペインで、[ダウンロード タスク (Download Tasks)] をクリックします。[Work] ペインで、[Operational] をクリックして、イメージのダウンロード状態を表示します。

[ナビゲーション (Navigation)] ペインで、ダウンロードが 100% に達したら、[ ファームウェア リポジトリ (Firmware Repository)]をクリックします。
[作業 (Work)] ペインに、ダウンロードされたバージョン番号およびイメージ サイズが表示されます。
ステップ 6

[ナビゲーション (Navigation)] ペインで、[コントローラ ファームウェア (Controller Firmware)] をクリックします。[作業 (Work)] ペインで、[アクション (Actions)] > [コントローラ ファームウェア アップグレード ポリシー (Upgrade Controller Firmware Policy)]を選択します。[コントローラ ファームウェア アップグレード ポリシー (Upgrade Controller Firmware Policy)] ダイアログボックスで、次の操作を実行します。

  1. [ターゲット ファームウェア バージョン (Target Firmware Version)] フィールドで、ドロップダウン リストから、アップグレードするイメージ バージョンを選択します。

  2. [ポリシー追加 (Apply Policy)] フィールドで、[今すぐ適用 (Apply Now)] のオプション ボタンをクリックします。[送信 (Submit)] をクリックします。`

[ステータス（Status）] ダイアログボックスに [変更が保存されました（Changes Saved Successfully）] というメッセージが表示され、アップグレード プロセスが開始されます。アップグレード中にコントローラ クラスタを使用できるように、Cisco APIC は順番にアップグレードされます。

ステップ 7

[ナビゲーション (Navigation)]ペインの [コントローラ ファームウェア (Controller Firmware)] をクリックして、アップグレードの状態を 作業 ([Work)] ペインで確認します。

（注）   

コントローラのアップグレードはランダムに行われます。Cisco APIC のアップグレードにはそれぞれ約 10 分かかります。コントローラのイメージがアップグレードされると、クラスタからドロップし、新しいバージョンで再起動します。その間、クラスタ内の他の Cisco APIC は動作しています。コントローラが再起動すると、クラスタに再び参加します。その後、クラスタが収束し、次のコントローラのイメージのアップグレードを開始します。クラスタがすぐに収束せず、完全な適合状態にならなければ、その後のアップグレードは、クラスタが収束して完全な適合状態になるまで待機状態になります。この間、アップグレードされる各 Cisco APIC の [ステータス（Status）] カラムに[クラスタ コンバージェンスの待機（Waiting for Cluster Convergence）]というメッセージが表示されます。

（注）   

ブラウザが接続されている Cisco APIC がアップグレードされて再起動すると、ブラウザにエラー メッセージが表示されます。

ステップ 8

ブラウザの URL フィールドに、すでにアップグレード済みの Cisco APIC の URL を入力し、プロンプトに応じてその Cisco APIC にサインインしてください。

GUI を使用したリーフおよびスパイン スイッチ ソフトウェアのバージョンのアップグレード（リリース 4.x より前のリリース）

始める前に

全コントローラが新しいファームウェア バージョンにアップグレードされるまで待機してから、スイッチのファームウェアのアップグレードに進みます。

手順
ステップ 1

メニュー バーで、[管理 (ADMIN)] > [ファームウェア (Firmware)] を選択し、[ナビゲーション (Navigation)] ペインで、[ファブリック ノード ファームウェア (Fabric Node Firmware)] をクリックします。

[Work] ペインに、ファブリック内の全スイッチのリストが表示されます。ファームウェアが最後にアップグレードされたときの状態も表示されます。
ステップ 2

[Navigation] ペインで、[Download Tasks] をクリックします。

ステップ 3

[Work] ペインで、[General] > [Actions] を選択し、[Create Outside Firmware source] をクリックして、次のアクションを実行します。

  1. [Source Name] フィールドにスイッチ イメージの名前（switch_image）を入力します。

  2. [Protocol] フィールドで、[Secure copy] オプション ボタンをクリックします。

    （注）   
    Http ソースまたは Secure Copy Protocol（SCP）のどちらからソフトウェア イメージをダウンロードするかに応じて、適切なラジオ ボタンを選択します。

  3. [URL] フィールドに、イメージをダウンロードする URL を入力します。

  4. [Username] フィールドに、セキュア コピーのユーザ名を入力します。

  5. [Password] フィールドに、セキュア コピーのパスワードを入力します。[Submit] をクリックします。`

    スイッチ ファームウェア イメージがダウンロードされるのを待ちます。
ステップ 4

[ナビゲーション (Navigation)]ペインで、[ダウンロード タスク (Download Tasks)] をクリックします。[Work] ペインで、[Operational] をクリックして、イメージのダウンロード状態を表示します。

[ナビゲーション (Navigation)] ペインで、ダウンロードが 100% に達したら、[ ファームウェア リポジトリ (Firmware Repository)]をクリックします。
[作業 (Work)] ペインに、ダウンロードされたバージョン番号およびイメージ サイズが表示されます。
ステップ 5

ナビゲーション ] ペインで、右クリックして ファブリック ノード ファームウェア ] をクリックし、 ファームウェア アップグレード ウィザード 。

作業 ] ペインで、 ファームウェア グループの作成 ダイアログボックスが表示されます。
ステップ 6

[Create Firmware Group] ダイアログボックスで、次の操作を実行します。

  1. [Nodes] の下にある [Select All] タブをクリックして、[Selected] 列のファブリック内の全ノードを選択します。[Next] をクリックします。

  2. 「Firmware Group] の下にある [Group Name] フィールドにグループ名を入力します。

  3. [互換性チェックを無視する (Ignore Compatibility Check)] フィールドで、互換性チェック機能を無効にするように特別に指示されていない限り、デフォルトの設定を オフ (チェック解除) の設定のままにします。

    （注）   

    次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にする] を選択すると、 互換性の確認を無視 に移動して、システム内で発生する可能性がありますシステムには、サポートされていないアップグレードを加えるのリスクを実行する] フィールドで、使用不可の状態。詳細については、「互換性チェックを無視する設定の変更（リリース 4.x より前のリリース）」を参照してください。

  4. [Target Firmware Version] フィールドで、ドロップダウン リストから、スイッチをアップグレードするための目的のイメージ バージョンを選択します。[Next] をクリックします。

  5. メンテナンス グループ 、すべてのスイッチでは 2 つのメンテナンス グループを作成します。たとえば、偶数番号のデバイスを含むグループと、奇数番号のデバイスを含む別のグループを作成します。

    （注）   

    1 つのメンテナンス グループは、同時すべてリーフとスパイン スイッチをアップグレードは、中に推奨してリーフとスパイン スイッチをダウンをソフトウェアの中にすることをファブリック全体を防ぐために複数の (2 つまたは複数) メンテナンスのグループに分割することアップグレードします。リーフとスパイン スイッチでのほぼ同じグループで構成される 2 つ以上のメンテナンス グループにリーフおよびスパイン スイッチを分割することにより、ソフトウェアのアップグレード中に、ファブリックの継続的な動作半分をアップグレードすることによって (以下) ファブリック ノードの一度に 1 つ.

  6. [Create Maintenance Group] タブをクリックします。

  7. [メンテナンス グループの作成 (Create Maintenance Group)] ダイアログ ボックスの [グループ名 (Group Name)] フィールドにグループの名前を入力します。

  8. [Run mode] フィールドで、デフォルト モードである [Pause only Upon Upgrade Failure] オプション ボタンを選択します。

  9. 確認、 グレースフル メンテナンス アップグレードを実行する前に、正常な挿入および削除 (登場させ) モードにノードが停止するチェック ボックス。

    参照してください、 Cisco APIC Getting Started guide 』、リリース 3.x グレースフル挿入と削除 (登場させ) モードについて。GIR モードのルールと制限事項については、ファームウェア管理について の 重要な注意 セクションを参照してください。

  10. [Submit] をクリックします。`

  11. [Finish] をクリックします。

[Work] ペインに、全スイッチがアップグレードが予定されているファームウェア グループおよびメンテナンス グループの名前とともに表示されます。
ステップ 7

[Navigation] ペインで、[Fabric Node Firmware] > [Firmware Groups]を展開し、作成したファームウェア グループの名前をクリックします。

[Work] ペインに、以前に作成されたファームウェア ポリシーの詳細が表示されます。
ステップ 8

[Navigation] ペインで、[Fabric Node] [ファームウェア > [メンテナンス グループ] を展開し、作成したメンテナンスグループをクリックします。

[Work] ペインに、メンテナンス ポリシーの詳細が表示されます。
ステップ 9

作成したメンテナンス グループを右クリックし、[Upgrade Now] をクリックします。

ステップ 10

[Upgrade Now] ダイアログボックスで、「Do you want to upgrade the maintenance group policy now?」 に対する [Yes] をクリックします。[OK] をクリックします。

（注）   

[Work] ペインで、[Status] にグループ内の全スイッチが同時にアップグレードされていく状況が表示されます。グループ内のデフォルトの同時実行数は 20 に設定されます。したがって、20 台のスイッチが同時にアップグレードされ、その後また 20 台のスイッチの組がアップグレードされます。障害が発生した場合、スケジューラがサスペンドし、Cisco APIC 管理者の手動操作が必要になります。スイッチのアップグレードには、グループごとに最長で 12 分かかります。スイッチはアップグレードすると再起動し、接続が切断されて、クラスタ内のコントローラはグループ内のスイッチとしばらくの間、通信しません。スイッチが起動後にクラスタに再加入した場合、コントローラ ノードの下に全スイッチが一覧で表示されます。クラスタに仮想ポート チャネル（vPC）構成が存在する場合、アップグレード プロセスでは、vPC ドメインにある 2 台のスイッチのうち一度に 1 台のスイッチのみがアップグレードされます。

ステップ 11

[Navigation] ペインで、[Fabric Node Firmware] をクリックします。

[Work] ペインで、一覧表示される全スイッチを確認します。[Current Firmware] 列に、アップグレード イメージの詳細が、各スイッチに対して表示されます。ファブリック内のスイッチが新しいイメージにアップグレードされることを確認します。

GUI を使用したカタログ ソフトウェアのバージョンのアップグレード（リリース 4.x より前のリリース）

通常、カタログ イメージは、Cisco APIC イメージのアップグレード時にアップグレードされます。ただし、管理者がカタログ イメージをアップグレードしなければならない場合もあります。

手順
ステップ 1

メニュー バーで、[ADMIN] > [Firmware] を選択します。[Navigation] ペインで、[Catalog Firmware] をクリックします。

ステップ 2

[Work] ペインで、[Actions] > [Change Catalog Firmware Policy] を選択します。

ステップ 3

[Change Catalog Firmware Policy] ダイアログボックスで、次の操作を実行します。

  1. [Catalog Version] フィールドで、目的のカタログ ファームウェアの バージョンを選択します。

  2. ファームウェアをただちにアップグレードするために、[Apply Policy] フィールドの [Apply Now] オプション ボタンをクリックします。[Submit] をクリックします。`

  3. [Work] ペインで、[Target Firmware version] フィールドが [Current Firmware Version] フィールドのイメージ バージョンに一致する画像が表示されるまで待機します。

    これでカタログのバージョンが、アップグレードされました。

互換性チェックを無視する設定の変更（リリース 4.x より前のリリース）

、Apic 内では、現在実行中のバージョンのシステムから、特定の新しいバージョンのアップグレード パスがサポートされているかどうかを確認する互換性チェック機能があります。[Ignore Compatibility Checks] の設定はデフォルトでは [off] に設定されているため、デフォルトでは互換性が調べられ、可能なアップグレードがないかチェックされます。何らかの理由で [Ignore Compatibility Checks] の設定を [on] に変更して、互換性チェック機能を無効にする必要がある場合は、次の手順に従ってください。


（注）  

次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にする] を選択すると、 互換性の確認を無視 に移動して、システム内で発生する可能性がありますシステムには、サポートされていないアップグレードを加えるのリスクを実行する] フィールドで、使用不可の状態。

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

ステップ 2

互換性チェックを無視する機能が含まれている画面にアクセスします。次に例を示します。

  • ファームウェア管理左側のパネルで、[選択 ファブリック ノード ファームウェア を右クリックし、 ファームウェア グループ ] を選択します ファームウェア グループの作成 します。

  • 左側のパネル ファームウェア管理、下を右クリックして コントローラ ファームウェア ] を選択します コントローラのアップグレード 。

ステップ 3

該当する項目を選択、 互換性の確認を無視 ()] フィールド。

  • ボックスにチェック マークを入力 を有効にする 、 互換性の確認を無視 (機能を無効に互換性チェック、システムが可能なアップグレードの互換性をオンにしないように)] オプションをまたは

  • (空のボックスをオンのままに)] ボックスから、チェック マークを削除 を無効にする 、 互換性の確認を無視 オプション (機能を有効に互換性チェック、システムで可能なアップグレードの互換性を確認するため)。

GUI を使用したソフトウェアのアップグレード（リリース 4.x 以降）

GUI を使用してソフトウェアをアップグレードできます。このセクションの手順は、Cisco APIC リリース 4.x 以降に適用されます。現在実行されているソフトウェア ビルドは、現在のソフトウェア ビルドの確認での説明に従って確認できます。

イメージのダウンロード（リリース 4.x 以降）

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

[サマリー（Summary）] ウィンドウが表示され、次の情報が表示されます。

  • [ノード（Nodes）] タイル：物理ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [仮想ノード（Virtual Nodes）] タイル：仮想ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [コントローラ（Controller）] タイル：このコントローラで使用されているファームウェア バージョンに関する情報を提供します。カタログのバージョンに関する情報も提供します。

  • [コントローラ ストレージ（Controller Storage）] タイル：各コントローラのストレージ容量に関する情報を提供します。

ステップ 2

[イメージ（Images）] タブをクリックし、[アクション（Actions）] アイコンをクリックし、スクロールダウン メニューから [ファームウェアを APIC に追加（Add Firmware to APIC）] を選択します。

[ファームウェアを APIC に追加（Add Firmware to APIC）] ポップアップ ウィンドウが表示されます。
ステップ 3

ファームウェア イメージをローカル ロケーションからインポートするかリモート ロケーションからインポートするかを決めます。

  • 「ローカル」ロケーションからファームウェア イメージをインポートする場合は、[ファームウェア イメージの場所（Firmware Image Location）] フィールドの [ローカル（Local）] オプション ボタンをクリックします。[参照...（Browse...）] ボタンをクリックし、インポートするファームウェア イメージがあるローカル システムのフォルダに移動します。ステップ 4に進みます。

  • 「リモート」 ロケーションからファームウェア イメージをインポートする場合は、[ファームウェア イメージの場所（Firmware Image Location）] フィールドの [リモート（Remote）] オプション ボタンをクリックし、次の操作を実行します。

  1. [ダウンロード名（Download Name）] フィールドで、スクロールダウン メニューに表示されるオプションを使用して既存のダウンロードを選択するか、 Cisco APIC イメージ ファイルの名前（apic_imageなど）を入力してダウンロードを新しく作成します。

    （注）   

    [ダウンロード名（Download Name）] フィールドに既存のダウンロード名を入力してから、フィールドの横にあるゴミ箱アイコンをクリックして、既存のダウンロード タスクを削除することもできます。

    新しいダウンロードを作成している場合は下記のフィールドが表示されます。

  2. [プロトコル（Protocol）] フィールドで、[HTTP] または [セキュア コピー（Secure copy）] のどちらかのオプション ボタンをクリックします。

  3. [URL] フィールドに、イメージのダウンロード元の URL を入力します。

    • 前の手順で [HTTP] オプション ボタンを選択した場合は、ソフトウェア イメージのダウンロードに使用する http ソースを入力します。

    • 前の手順で [セキュア コピー（Secure copy）] ラジオ ボタンを選択した場合は、ソフトウェア イメージのダウンロードに使用する Secure Copy Protocol（SCP）ソースを入力します。

    HTTP ソースと SCP ソースの両方の形式は次のとおりです。

    <HTTP/SCP サーバ IP または FQDN>:/<path>/<filename>

    URL の例は、10.1.2.3:/path/to/the/image/aci-apic-dk9.5.0.1a.iso です。

    プロトコルとして SCP を選択した場合は、次のフィールドが表示されます。

  4. [Username] フィールドに、セキュア コピーのユーザ名を入力します。

  5. [認証タイプ（Authentication Type）] フィールドで、ダウンロードの認証タイプを選択します。次のタイプを選択できます。

    • パスワードを使用

    • SSH 公開/秘密キー ファイルを使用

    デフォルトは、[パスワードの使用 (Use Password)] です。

  6. [パスワードを使用（Use Password）] を選択した場合は、[パスワード（Password）] フィールドにセキュア コピーのパスワードを入力します。

  7. [SSH 公開/秘密キー ファイルを使用（Use SSH Public/Private Key Files）] を選択した場合は、次の情報を入力します。

    • SSH キーのコンテンツ: SSH 秘密キーのコンテンツ。

    • SSH キーのフレーズ: SSH 秘密キーの生成に使用される SSH キー パスフレーズ

      （注）   

      提供された SSH 秘密キーに基づいて、APIC はこのトランザクションのために一時的な SSH 公開キーを内部的に作成し、リモート サーバとの接続を確立します。リモート サーバが「authorized_keys」の 1 つとして対応する公開キーをもつことを確認する必要があります。認証チェックが実行されると、APIC の一時公開キーが削除されます。

    次のように入力して、いずれかの APIC で SSH 秘密キー（〜/.ssh/id_rsa）および対応する SSH 公開キー（〜/.ssh/id_rsa.pub）を生成できます。 

    ssh-keygen -t rsa -b 2048 -C "<username>@<apic_name>"

    または、別のマシンでそれらを生成できます。いずれの方法の場合も、ダウンロード構成ごとに生成された秘密キーを提供する必要があります。
ステップ 4

[送信 (Submit)] をクリックします。`

Cisco APIC のファームウェア イメージがダウンロードされるのを待ちます。
ステップ 5

必要に応じて [イメージ（Images）] タブを再度クリックして、イメージのダウンロード ステータスを表示します。

ダウンロードが 100% に達したら、表内でダウンロードしたファームウェア イメージの行をダブルクリックして、その特定ファームウェア イメージの [ファームウェアの詳細（Firmware Details）] ページを表示します。

GUI を使用した Cisco APIC ソフトウェアのバージョンのアップグレード（リリース 4.x 以降）


（注）  
Cisco APIC とスイッチの正しいアップグレード順序を決めるため、Cisco APIC およびスイッチ ソフトウェアのアップグレードについて、およびアップグレード後のバージョンのリリース ノートを参照してください。

ファブリック内の APIC のソフトウェアをアップグレードするには、次の GUI ベースのアップグレード手順を使用します。

何らかの理由で、これらの GUI ベースのアップグレード手順を使用してファブリック内の APIC のソフトウェアをアップグレードできない場合（新しい注文または製品返品と交換（RMA）を通じて APIC を受け取った場合、GUI を使用してアップグレードを実行するためにファブリックに参加できない場合）、APIC ソフトウェアをアップグレードする代わりに、CIMC を使用して APIC でソフトウェアのクリーン インストールを実行できます。これらの手順については、インストール Cisco APIC 仮想メディアを使用してソフトウェア を参照してください。

始める前に

必要に応じて、イメージのダウンロード（リリース 4.x 以降） で説明している手順を使用して、アップグレードに使用するイメージをダウンロードします。

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

[サマリー（Summary）] ウィンドウが表示され、次の情報が表示されます。

  • [ノード（Nodes）]タイル：物理ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [仮想ノード（Virtual Nodes）] タイル：仮想ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [コントローラ（Controller）] タイル：このコントローラで使用されているファームウェア バージョンに関する情報を提供します。カタログのバージョンに関する情報も提供します。

  • [コントローラ ストレージ（Controller Storage）] タイル：各コントローラのストレージ容量に関する情報を提供します。

ステップ 2

[インフラストラクチャ（Infrastructure）] タブをクリックし、[コントローラ（Controllers）] サブタブを選択していない場合はクリックして選択します。

ステップ 3

[アクション（Actions）] > [コントローラ アップグレードのスケジュール（Schedule Controller Upgrade）] を選択します。

[コントローラ アップグレードのスケジュール（Schedule Controller Upgrade）] ダイアログ ボックスが表示されます。

場合によっては、次のようなエラーメッセージが表示されることがあります。

エラー メッセージの意味と、エラー メッセージに応じた推奨処置の詳細については、ACI のアップグレードまたはダウングレード前の検証チェックを参照してください。

ステップ 4

[コントローラ アップグレードのスケジュール（Schedule Controller Upgrade）] ダイアログ ボックスで、次の操作を実行します。

  1. [ターゲットのファームウェア バージョン (Target Firmware Version)] フィールドで、ドロップダウン リストから、アップグレードするイメージ バージョンを選択します。

  2. [アップグレード開始時刻（Upgrade Start Time）] フィールドで、2 つのオプション ボタンのいずれかをクリックします。

    • [今すぐアップグレード（Upgrade now）]

    • [後でアップグレード（Upgrade later）]： アップグレードを実行する日付と時刻を選択します。

      次に、[後でアップグレード (Upgrade later)] フィールドのさまざまなエントリに関連したシナリオの例と、各シナリオでのシステムの反応の例を示します。

      • [開始時刻 (Start Time)] が現在の時刻より前のポイントに設定された場合: アップグレードポイントが過去のポイントに設定されていると、システムによって設定が拒否されます。

      • [開始時刻 (Start Time)] が現在の時刻より 後のポイントに設定された場合: アップグレードは、設定した時点で開始されます。

  3. [互換性チェックを無視する (Ignore Compatibility Check)] フィールドで、互換性チェック機能を無効にするように特別に指示されていない限り、デフォルトの設定を オフ (チェック解除) の設定のままにします。

    （注）   

    次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にする] を選択すると、 互換性の確認を無視 に移動して、システム内で発生する可能性がありますシステムには、サポートされていないアップグレードを加えるのリスクを実行する] フィールドで、使用不可の状態。詳細については、「互換性チェックを無視する設定の変更（リリース 4.x 以降）」を参照してください。

[ステータス（Status）] ダイアログボックスに [変更が保存されました（Changes Saved Successfully）] というメッセージが表示され、アップグレード プロセスが開始されます。アップグレード中にコントローラ クラスタを使用できるように、Cisco APIC は順番にアップグレードされます。

ステップ 5

必要に応じて、[インフラストラクチャ（Infrastructure）] ペインで [コントローラ（Controllers）] サブタブを再度クリックして、アップグレードのステータスを確認します。

コントローラのアップグレードはランダムな順番で行われます。Cisco APIC のアップグレードにはそれぞれ約 10 分かかります。コントローラのイメージがアップグレードされると、クラスタからドロップし、新しいバージョンで再起動します。その間、クラスタ内の他の Cisco APIC は動作しています。コントローラが再起動すると、クラスタに再び参加します。その後、クラスタが収束し、次のコントローラのイメージのアップグレードを開始します。クラスタがすぐに収束せず、適合状態にならない場合、アップグレードはクラスタが収束して完全に正常になるまで延期されます。この間、アップグレードされる各 Cisco APIC の [ステータス（Status）] カラムには、[クラスタ コンバージェンスの待機（Waiting for Cluster Convergence）]というメッセージが表示されます。

Cisco APIC リリース 4.2(5) 以降では、コントローラのアップグレード プロセスのステータスに関する追加情報が提供される場合があります。APICアップグレードのさまざまな段階の詳細については、APIC のアップグレード段階の説明 を参照してください。

（注）   

実際のアップグレード プロセスは、以前のリリースと同じように、リリース 4.2(5) のままです。ただし、リリース 4.2(5) 以降では、アップグレード プロセス中の段階を示す追加情報が提供されました。
ステップ 6

ブラウザの URL フィールドに、すでにアップグレード済みの Cisco APIC の URL を入力し、プロンプトに応じてその Cisco APIC にサインインしてください。

GUI を使用したリーフおよびスパイン スイッチ ソフトウェアのバージョンのアップグレード（リリース 4.x 以降）

始める前に
手順
ステップ 1

作業を進める前に、全コントローラが新しいファームウェア バージョンにアップグレードされていることを確認します。

全コントローラが先に新しいファームウェア バージョンにアップグレードされるまでは、スイッチのファームウェアをアップグレードしないでください。
ステップ 2

メニュー バーで、[管理] > [ファームウェア] を選択します。

[サマリー（Summary）] ウィンドウが表示され、次の情報が表示されます。

  • [ノード（Nodes）] タイル：物理ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [仮想ノード（Virtual Nodes）] タイル：仮想ノードで使用されているファームウェア バージョンに関する情報を提供します。

  • [コントローラ（Controller）] タイル：このコントローラで使用されているファームウェア バージョンに関する情報を提供します。カタログのバージョンに関する情報も提供します。

  • [コントローラ ストレージ（Controller Storage）] タイル：各コントローラのストレージ容量に関する情報を提供します。

ステップ 3

[Infrastructure] タブをクリックし、[Nodes] サブタブをクリックします。
ステップ 4

[アクション (Actions)] をクリックし、[ノードのアップグレードをスケジュール (Schedule Node Upgrade)] を選択して、次の操作を実行します。

場合によっては、次のようなエラーメッセージが表示されることがあります。

エラー メッセージの意味と、エラー メッセージに応じた推奨処置の詳細については、ACI のアップグレードまたはダウングレード前の検証チェックを参照してください。

  1. [グループ タイプ (Group Type)] フィールドで、[スイッチ (Switch)] または [vPod] のいずれかを選択します。

  2. このフィールドが使用可能な場合は、[アップグレード グループ (Upgrade Group)] フィールドで、[既存 (Existing)] または [新規 (New)] のいずれかを選択します。

    リリース 4.1 (2) 以降では、[アップグレード グループ (Upgrade group)] フィールドを使用して、既存または新規のアップグレードグループを使用しているかどうかを選択できます。

    • [既存 (existing)]: 既存のアップグレードグループを使用する場合に選択します。既存のアップグレード グループのプロパティを変更する場合は、この例の [ アップグレード グループ名 (Upgrade Group Name)] フィールドで既存のアップグレードグループを選択し、このページの残りのフィールドに変更を加えます。

    • [新規 (New)]: 新しいアップグレード グループを作成する場合に選択します。この場合は、[アップグレード グループ名 (Upgrade Group name)] フィールドに新しいアップグレード グループの名前を入力し、このページの残りのフィールドに情報を入力して新しいアップグレード グループを作成します。

  3. [アップグレード グループ名 (Upgrade Group name)] フィールドで、既存のアップグレード グループのスクロールダウン メニューからアップグレード グループ名を選択するか、新しいアップグレード グループのテキスト ボックスに名前を入力します。

    [アップグレード グループ名（Upgrade Group Name）] フィールドで、スクロールダウン メニューに表示されるオプションを使用して既存のアップグレード グループを選択するか、フィールドの隅にある「x」をクリックしてフィールドをクリアし、アップグレード グループの名前を入力します

    既存のポッド メンテナンス グループを選択した場合は、そのメンテナンス グループに関連付けられているフィールドに自動的に入力されます。

  4. サイレント ロール パッケージのアップグレードを実行するかどうかを決定します。

    （注）   

    通常のスイッチ ソフトウェア アップグレードではなく、ACI スイッチ ハードウェア SDK、ドライバなどの内部パッケージのアップグレードを実行する必要がある場合にのみ、[手動サイレント ロール パッケージ アップグレード (Manual Silent Roll Package Upgrade)](SR パッケージ アップグレード) を選択します。SR パッケージのアップグレードを実行する場合、メンテナンス グループは SR パッケージのアップグレード専用であり、通常のスイッチ ソフトウェア アップグレードは実行できません。詳細については、Cisco APIC GUI を使用してサイレント ロール パッケージのアップグレードの設定のセクションを参照してください。

  5. [Target Firmware Version] フィールドで、ドロップダウン リストから、スイッチをアップグレードするための目的のイメージ バージョンを選択します。

  6. [互換性チェックを無視する (Ignore Compatibility Check)] フィールドで、互換性チェック機能を無効にするように特別に指示されていない限り、デフォルトの設定を オフ (チェック解除) の設定のままにします。

    （注）   

    次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にする] を選択すると、 互換性の確認を無視 に移動して、システム内で発生する可能性がありますシステムには、サポートされていないアップグレードを加えるのリスクを実行する] フィールドで、使用不可の状態。詳細については、「互換性チェックを無視する設定の変更（リリース 4.x 以降）」を参照してください。

  7. アップグレードを実行する前に、ノードをグレースフル挿入と削除 (GIR) モードに設定する場合は、[グレースフル メンテナンス (Graceful Maintenance)] チェックボックスをオンにします。

    参照してください、 Cisco APIC Getting Started guide 』、リリース 3.x グレースフル挿入と削除 (登場させ) モードについて。GIR モードのルールと制限事項については、ファームウェア管理について の 重要な注意 セクションを参照してください。

  8. [実行モード（Run Mode）] フィールドで、ノード セットのメンテナンス プロセスが正常に完了した後で自動的に次のノード セットに進むための実行モードを選択します。

    次のオプションがあります。

    • 障害時に一時停止せず、クラスタの状態を待機しない（Do not pause on failure and do not wait on cluster health）

    • アップグレードの失敗時に一時停止します

    デフォルトは [アップグレードの失敗時のみ一時停止Pause only Upon Upgrade Failure）] です。

  9. [アップグレード開始時刻 (Upgrade Start Time)] フィールドで、[今すぐ (Now)] または [後でスケジュール (Schedule for Later)] のいずれかを選択します。

    一度にアップグレードできるスイッチの数は、リリースによって異なります。

    • リリース 4.2(5) 以前のリリースでは、グループ内のデフォルトの同時実行は 20 に設定されています。したがって、20 台のスイッチが同時にアップグレードされ、その後また 20 台のスイッチの組がアップグレードされます。

    • リリース 4.2(5) およびそれ以降では、グループ内のデフォルトの同時実行数が20から無制限 (一度にアップグレードできるリーフまたはスパインスイッチのデフォルト数は無制限) に変更されました。

    上記の値は、[今すぐ（Now）] と [後でスケジュール（Schedule for Later）]の両方に適用されます。

    [後でスケジュール (Schedule For Later)] を選択した場合は、既存のトリガー スケジューラを選択するか、または [トリガー スケジューラを作成 (Create trigger scheduler)] をクリックして新しいトリガー スケジューラを作成します。詳細については、GUI を使用したスケジューラ―の構成を参照してください。

  10. リリース 4.1(2) 以降の場合は、[すべてのノード (All Nodes)] エリアの右側にある [+] アイコンをクリックします。

    [アップグレード グループにノードを追加 (Add Nodes to Upgrade Group)] ページが表示されます。

  11. [アップグレード グループにノードを追加 (Add Nodes To Upgrade Group)] ページ (リリース 4.1 (2) 以降) または [ノード選択 (Node Selection) ] フィールド (4.1(2) 以前のリリースの場合) で、[範囲 (Range)] または [手動 (Manual)] を選択します。

    • [範囲（Range）] を選択した場合は、[グループ ノード ID（Group Node Ids）] フィールドに範囲を入力します。

    • [手動（Manual）] を選択した場合は、選択可能なリーフ スイッチとスパイン スイッチのリストが [すべてのノード（All Nodes）] 領域に表示されます。このアップグレードに含めるノードを選択します。

      表示されるノードは、[グループ タイプ（Group Type）] フィールドで [スイッチ（Switch）] を選択した場合は物理リーフ スイッチおよびスパイン スイッチであり、[Vpod] を選択した場合は仮想リーフ スイッチまたは仮想スパイン スイッチです。

  12. [Submit] をクリックします。`

    その後、メイン ファームウェア のページに戻ります。

    Cisco APIC リリース 4.2(5) 以降では、[ワーク (Work)] ペインに [ダウンロード進行状況 (download progress)] フィールドがあります。これにより、ノード アップグレードのファームウェアのダウンロードの進行状況に関するステータスが表示されます。

    • ファームウェアのダウンロードが何らかの理由で失敗した場合、[ダウンロード進行状況 (Download Progress)] フィールドのステータスに [赤] と表示されます。この場合、ステータスバーの上にカーソルを置くと、エラーポップアップが表示されます。この場合、[ダウンロード進行状況: ダウンロード失敗 (Download status: download-failed)] というメッセージが表示されます。

    • ファームウェアのダウンロードが成功すると、[ダウンロード進行状況 (Download Progress)] フィールドのステータス バーが緑色に変わり、100%が表示されます。この場合、ステータスバーの上にカーソルを置くと、 「[ダウンロード進行状況: ダウンロード済み 」というメッセージが表示されます。

    また、イメージをダウンロードするための /firmware パーティションに十分なスペースがない場合は、この画面に通知が表示されることがあります。/firmware パーティションが 75% を超えていないことを確認します。パーティションが 75％ を超えている場合は、リポジトリから未使用のファームウェア ファイルを一部削除する必要があります。これは、圧縮されたイメージを保存し、イメージを抽出するための適切なスペースを提供します。

Admin > Firmware > Infrastructure > Nodes の下のテーブルには、各ノードが属しているアップグレードグループを示す [アップグレードグループ（Upgrade Group）]（以前はPODメンテナンスグループとして表示されていました）の列があります。特定のノードのこの列を右クリックすると、次のオプションが表示されます。

  • アップグレード グループの編集（4.1(2) より前のリリース）

  • アップグレード グループの表示（リリース4.1 (2) 以降）

  • アップグレード グループの削除（Delete Upgrade Group）

リリース 4.1(2) よりも前では、このオプションを使用してアップグレード グループを編集し、ターゲットバージョンを変更してノードのアップグレードをトリガーできます。リリース 4.1(2) 以降では、この列は既存のアップグレード グループの詳細を表示するためにのみ使用できます。任意のリリースで選択したアップグレード グループを削除できます。

ステップ 5

リリース 4.1 (2) 以降の場合、アップグレード グループからノードを削除するには、次のようにします。

  1. アップグレード グループから削除するテーブル内のノードを選択します。

  2. [すべてのノード (All Nodes)] エリアの右側にある [ゴミ箱 (trashcan)] アイコンをクリックします。

  3. [送信（Submit）] をクリックします。

互換性チェックを無視する設定の変更（リリース 4.x 以降）

、Apic 内では、現在実行中のバージョンのシステムから、特定の新しいバージョンのアップグレード パスがサポートされているかどうかを確認する互換性チェック機能があります。[Ignore Compatibility Checks] の設定はデフォルトでは [off] に設定されているため、デフォルトでは互換性が調べられ、可能なアップグレードがないかチェックされます。何らかの理由で [Ignore Compatibility Checks] の設定を [on] に変更して、互換性チェック機能を無効にする必要がある場合は、次の手順に従ってください。


（注）  

次に、ボックスにチェック マークを入力して、互換性チェック機能を無効にする] を選択すると、 互換性の確認を無視 に移動して、システム内で発生する可能性がありますシステムには、サポートされていないアップグレードを加えるのリスクを実行する] フィールドで、使用不可の状態。

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

ステップ 2

互換性チェックを無視する機能が含まれている画面にアクセスします。次に例を示します。

  • [インフラストラクチャ（Infrastructure）] タブをクリックし、[コントローラ（Controllers）] サブタブをクリックし、[アクション（Action）] > [コントローラ アップグレードのスケジュール（Schedule Controller Upgrade）] をクリックします。

  • [インフラストラクチャ（Infrastructure）] タブをクリックし、[ノード（Nodes）] サブタブをクリックし、[アクション（Action）] > [ノード アップグレードのスケジュール（Schedule Node Upgrade）] をクリックします。
ステップ 3

該当する項目を選択、 互換性の確認を無視 ()] フィールド。

  • ボックスにチェック マークを入力 を有効にする 、 互換性の確認を無視 (機能を無効に互換性チェック、システムが可能なアップグレードの互換性をオンにしないように)] オプションをまたは

  • (空のボックスをオンのままに)] ボックスから、チェック マークを削除 を無効にする 、 互換性の確認を無視 オプション (機能を有効に互換性チェック、システムで可能なアップグレードの互換性を確認するため)。

GUI を使用したソフトウェアのアップグレード（リリース 5.1x 以降）

GUI を使用してソフトウェアをアップグレードできます。このセクションの手順は、Cisco APIC リリース 5.1.x 以降に適用されます。現在実行されているソフトウェア ビルドは、現在のソフトウェア ビルドの確認での説明に従って確認できます。

ダッシュボードへのアクセス

[Admin] > [Firmware] > [Dashboard] に移動して、ファブリック内の APIC ノードとスイッチのファームウェア ステータスを示すダッシュボードにアクセスできます。

イメージの追加（リリース 5.1x 以降）

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

[ダッシュボード（Dashboard）] ウィンドウが表示され、コントローラとリーフおよびスパイン スイッチ（ノード）に関する一般情報が表示されます。
ステップ 2

左側のナビゲーション バーの イメージ をクリックします。

[Image] ウィンドウが表示され、以前にダウンロードしたイメージが表示されます。
ステップ 3

[アクション（Actions）] アイコンをクリックし、スクロールダウン メニューから [ファームウェアを追加（Add Firmware] を選択します。

[ファームウェア イメージを追加（Add Firmware Image）] ポップアップ ウィンドウが表示されます。
ステップ 4

ファームウェア イメージをローカル ロケーションからインポートするかリモート ロケーションからインポートするかを決めます。

  • コンピューターからファームウェア イメージをインポートする場合は、[ロケーション（Location）] フィールドで、[ローカル（Local）] ラジオ ボタンをクリックします。[ファイルの選択（Choose File）] ボタンをクリックし、インポートするファームウェア イメージがあるローカル システムのフォルダに移動します。ステップ 5に進みます。

  • リモート ロケーションからファームウェア イメージをインポートする場合は、リモート ロケーションからファームウェア イメージをインポートするために使用する方法に応じて、[セキュア コピー（Secure copy） または [HTTP] をクリックします。

    • [セキュア コピー（Secure copy）] ラジオ ボタンを選択した場合は、ソフトウェア イメージのダウンロードに使用する Secure Copy Protocol（SCP）ソースを入力します。

      1. [URL] フィールドに、イメージのダウンロード元の URL を入力します。

        SCP ソースの形式は次のとおりです。

        <SCP server IP or FQDN>:/<path>/<filename>

        URL の例は 10.1.2.3:/path/to/the/image/aci-apic-dk9.5.0.1a.iso です。

      2. [Username] フィールドに、セキュア コピーのユーザ名を入力します。

      3. [認証タイプ（Authentication Type）] フィールドで、ダウンロードの認証タイプを選択します。次のタイプを選択できます。

        • [Password]

        • SSH 公開/秘密ファイル

        デフォルトは、「Password」です。

        • [パスワード（Password）] を選択した場合は、[パスワード（Password）] フィールドにセキュア コピーのパスワードを入力します。

        • [SSH 公開/秘密ファイル（SSH Public PrivateFiles）] を選択した場合は、次の情報を入力します。

          • Ssh Key Contents：SSH 秘密キーの内容。

          • Ssh Key Passphrase：SSH 秘密キーの生成に使用される SSH キー パスフレーズ。

            （注）   

            提供された SSH 秘密キーに基づいて、APIC はリモート サーバとの接続を確立するために、このトランザクションのために一時的な SSH 公開キーを内部的に作成します。リモート サーバに「authorized_keys」の 1 つとして対応する公開キーがあることを確認する必要があります。認証チェックが実行されると、APIC の一時公開キーが削除されます。

            次のように入力して、いずれかの APIC で SSH 秘密キー（~/.ssh/id_rsa）および対応する SSH 公開キー（~/.ssh/id_rsa.pub）を生成できます。 

            ssh-keygen -t rsa -b 2048 -C "<username>@<apic_name>"

            または、別のマシンで生成することもできます。どちらの方法でも、ダウンロード設定ごとに生成された秘密キーを指定する必要があります。

    • 前の手順で [HTTP] オプション ボタンを選択した場合は、ソフトウェア イメージのダウンロードに使用する http ソースを入力します。

      HTTP ソースの形式は次のとおりです。

      <HTTP server IP or FQDN>:/<path>/<filename>

      URL の例は 10.1.2.3:/path/to/the/image/aci-apic-dk9.5.0.1a.iso です。

ステップ 5

[送信（Submit）] をクリックします。

Cisco APIC ファームウェア イメージのアップロードが開始されます。アップロードプロセスの進行状況が [Uploading] ウィンドウに表示されます。

GUI を使用した Cisco APIC ソフトウェアのバージョンのアップグレード（リリース 5.1x 以降）


（注）  
Cisco APIC とスイッチの正しいアップグレード順序を決めるため、Cisco APIC およびスイッチ ソフトウェアのアップグレードについて、およびアップグレード後のバージョンのリリース ノートを参照してください。

ファブリック内の APIC のソフトウェアをアップグレードするには、次の GUI ベースのアップグレード手順を使用します。

何らかの理由で、これらの GUI ベースのアップグレード手順を使用してファブリック内の APIC のソフトウェアをアップグレードできない場合（新しい注文または製品返品と交換（RMA）を通じて APIC を受け取った場合、GUI を使用してアップグレードを実行するためにファブリックに参加できない場合）、APIC ソフトウェアをアップグレードする代わりに、CIMC を使用して APIC でソフトウェアのクリーン インストールを実行できます。これらの手順については、インストール Cisco APIC 仮想メディアを使用してソフトウェア を参照してください。

始める前に

必要に応じて、「イメージの追加（リリース 5.1x 以降）」で説明している手順を使用して、アップグレードに使用するイメージを追加します。

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

[ダッシュボード（Dashboard）] ウィンドウが表示され、コントローラとリーフおよびスパイン スイッチ（ノード）に関する一般情報が表示されます。
ステップ 2

左側のナビゲーションウィンドウで、[コントローラ（Controllers）]をクリックします。

[コントローラ（Controllers）] ウィンドウが表示され、コントローラのファームウェア情報が示されます。
ステップ 3

[更新のセットアップ（Setup Update）] ボタンをクリックします。

[コントローラ ファームウェアの更新のセットアップ（Setup Controller Firmware Upgrade）] ウィンドウの [バージョン設定（Version Selection）] ステップが表示され、システムにダウンロードしたすべてのソフトウェア イメージが表示されます。
（注）   

代わりに、次のエラー メッセージが表示されます。

No firmware images available. Please check the Images tab.

アップグレードに使用できるイメージがありません。イメージの追加（リリース 5.1x 以降） で説明している手順を使用して、アップグレードに使用するイメージを追加します。

ステップ 4

ファームウェアの更新に使用するイメージを選択し、[次へ（Next)]をクリックします。

[検証（Validation）] ステップが表示されます。
ステップ 5

[検証（Validation）] 画面に表示される情報を確認します。

リリース 5.1(1) 以降では、特定の検証チェックが実行され、[検証（Validation）] 画面に表示されます。各検証チェックが成功したか失敗したかを示すメッセージが表示されます。

失敗した検証チェックについては、アップグレードに進む前に、これらの障害または問題に対処することを推奨します。エラー メッセージの意味と、エラー メッセージに応じた推奨処置の詳細については、ACI のアップグレードまたはダウングレード前の検証チェックを参照してください。

[検証（Validation）] ウィンドウで発生した障害または問題に対処したら、[次へ（Next）] をクリックして [確認（Confirmation）] ウィンドウに進みます。

ステップ 6

[確認（Confirmation）] ウィンドウで、情報が正しいことを確認し、[インストールの開始（Begin Install）] をクリックします。

[コントローラ（Controllers）] ウィンドウが再び表示され、アップグレードのステータスが表示されます。

アップグレード中にコントローラ クラスタを使用できるように、Cisco APIC は順番にアップグレードされます。Cisco APIC のアップグレードにはそれぞれ約 10 分かかります。コントローラのイメージがアップグレードされると、クラスタからドロップし、新しいバージョンで再起動します。その間、クラスタ内の他の Cisco APIC は動作しています。コントローラが再起動すると、クラスタに再び参加します。その後、クラスタが収束し、次のコントローラのイメージのアップグレードを開始します。クラスタがすぐに収束せず、適合状態にならない場合、アップグレードはクラスタが収束して完全に正常になるまで延期されます。この間、アップグレードされる各 Cisco APIC の [アップグレード ステータス（Upgrade Status）] カラムに[クラスタ コンバージェンスの待機（Waiting for Cluster Convergence）]というメッセージが表示されます。

ブラウザが接続されている APIC がアップグレードされて再起動すると、ブラウザには最初にエラー メッセージが表示されます。その後、この APIC にログインするために使用したブラウザには何も表示されません。ただし、必要に応じて、クラスタ内の残りの APIC にログインして、アップグレード プロセスの進行状況をモニタし続けることができます。

コントローラのアップグレード プロセスのステータスに関する追加情報が提供される場合があります。APICアップグレードのさまざまな段階の詳細については、APIC のアップグレード段階の説明 を参照してください。

（注）   

実際のアップグレードプロセスは、以前のリリースと同じように、リリース 5.1(1) のままです。ただし、リリース 5.1(1) 以降では、アップグレード プロセス中の段階を示す追加情報が提供されました。
ステップ 7

ブラウザの URL フィールドに、すでにアップグレード済みの Cisco APIC の URL を入力し、プロンプトに応じてその Cisco APIC にサインインしてください。

GUI を使用したリーフおよびスパイン スイッチ ソフトウェアのバージョンのアップグレード（リリース 5.1.x 以降）


（注）  
Cisco APIC とスイッチの正しいアップグレード順序を決めるため、Cisco APIC およびスイッチ ソフトウェアのアップグレードについて、およびアップグレード後のバージョンのリリース ノートを参照してください。

ヒント

リーフおよびスパイン スイッチのアップグレードを 2 つのフェーズでスケジュールします。

  • ダウンロード フェーズ。ステップ 1 から ステップ 10 までで説明されたフェーズです。ネットワークの速度とアップグレードグループに含まれるノードの数によっては、このフェーズに数時間かかる場合があります。ダウンロード フェーズ中はノードが稼働しているため、ダウンロードフェーズのメンテナンス ウィンドウをスケジュールする必要はありません。

  • ステップ 13 以降で説明するアップグレードフェーズ。ノードはアップグレード プロセスの一部としてリブートするため、プロセスのアップグレード フェーズのメンテナンス ウィンドウをスケジュールする必要がありますが、そのフェーズの時間が大幅に短縮されるため、ノードを中断するとメンテナンス ウィンドウが大幅に短くなります。 2つのフェーズ（ダウンロードとアップグレード）にアップグレードします。

始める前に
手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

ダッシュボード ウィンドウが表示され、コントローラ およびリーフとスパイン スイッチ（ノード）に関する一般情報を示します。
ステップ 2

左側のナビゲーションウィンドウで、[ノード（Nodes）]をクリックします。

[ノード（Nodes）] ウィンドウが表示され、リーフおよびスパイン スイッチのアップグレードグループのファームウェア情報が示されます。
ステップ 3

[Actions] アイコンをクリックし、スクロール ダウン メニューから [更新グループの作成（Create Update Group）]を選択します。

[ノード ファームウェアの更新のセットアップ（Setup Node Firmware Update）] ウィンドウの [バージョン選択（Version Selection）] ステップが表示され、システムにダウンロードしたすべてのソフトウェア イメージが表示されます。
ステップ 4

[バージョンの選択（Version Selection）] ステップで、アップグレード グループの名前を入力し、ファームウェア アップデートに使用するイメージを選択して、[次へ（Next）] をクリックします。

[ノード選択（Node Selection）] ステップが表示されます。
ステップ 5

[ノード選択（Node Selection）] ステップで、[ノードの追加（Add Nodes）] ボタンをクリックします。

[ノードの選択（Select Nodes）] ステップが表示されます。
ステップ 6

[ノードの選択（Select Nodes）] ステップで、このアップグレード グループの一部として含めるノードを選択します。

このウィンドウでは、ノード範囲またはノード名でフィルタリングすることもできます。[ノード選択（Node Selection）] ステップが再び表示されます。
ステップ 7

[ノード選択（Node Selection）] ステップで、アップグレードするノードがリストされていることを確認します。

このアップグレードグループから削除するノードの行にあるごみ箱アイコンをクリックして、このグループからノードを削除することもできます。
ステップ 8

[ノード選択（Node Selection）] ステップのすべてが正しいことを確認したら、[次へ（Next）] をクリックします。

[検証（Validation）] ステップが表示されます。
ステップ 9

検証ステップで提供される情報を確認します。

このページには、アップグレードに影響する可能性のある障害または問題が表示されます。アップグレードを続行する前に、表示される障害または問題に対処することを推奨します。エラー メッセージの意味と、エラー メッセージに応じた推奨処置の詳細については、ACI のアップグレードまたはダウングレード前の検証チェックを参照してください。

[検証（Validation）] ステップで発生した障害または問題に対処したら、[次へ（Next）] をクリックして [確認（Confirmation）] ステップに進みます。

ステップ 10

[確認（Confirmation）] ステップで、情報が正しいことを確認し、[ダウンロードの開始（Begin Download）] をクリックします。

システムは、前の画面で選択したすべてのノードへのソフトウェアのダウンロードを開始し、各ノードのダウンロード ステータスを表示します。
ステップ 11

グループ内のアップグレードするすべてのノードのダウンロードが正常に完了したことを確認します。

[ステータス（Status）] 列に [失敗（Failed）] と表示されているノードがある場合は、いくつかのオプションがあります。

  • ページの下部にある [すべて再試行（Retry All）] をクリックして、アップグレードグループ内のすべてのノードのダウンロードを再試行します。

  • ページの下部にある [すべてキャンセル（Cancel All）] をクリックして、アップグレードグループ内のノードのダウンロードをキャンセルします。必要に応じて、[ノードの選択（Node Selection）][ ウィンドウに戻り、異なるノードで異なるアップグレード グループを作成します。

  • ダウンロード フェーズで成功したノードのアップグレードを続行できるように、このアップグレード グループから失敗したノードを手動で削除する場合は、このアップグレードから手動で削除するノードの横にある鉛筆アイコンをクリックします。グループ化して [削除（Remove）] をクリックします。

また、イメージをダウンロードするための /firmware パーティションに十分なスペースがない場合は、この画面に通知が表示されることがあります。/firmware パーティションが 75% を超えていないことを確認します。パーティションが 75％ を超えている場合は、リポジトリから未使用のファームウェア ファイルを一部削除する必要があります。これは、圧縮されたイメージを保存し、イメージを抽出するための適切なスペースを提供します。

グループ内のすべてのノードの [ダウンロード完了（Download Complete）]のステータスが表示されると、画面の上部に [インストール準備完了（Ready to Install）] と表示されます。

ステップ 12

次に示す詳細オプションのいずれかが必要な場合は、[詳細設定（Advanced Settings）] をクリックして [詳細設定（Advanced Settings）] ウィンドウを表示します。

通常、これらの詳細オプションを設定する必要はありません。オプションを無効にするか、デフォルト値を使用することを推奨します。

[詳細設定（Advanced Settings）] ウィンドウで、必要に応じて次のいずれかの操作を実行します。

  • [互換性チェックを無視する (Ignore Compatibility Check)] フィールドで、互換性チェック機能を無効にするように特別に指示されていない限り、デフォルトの設定を いいえ の設定のままにします。

    （注）   

    [互換性チェックを無視 (Ignore Compatibility Check)] フィールドで はいにして互換性チェック機能を無効にした場合、システムでサポートされていないアップグレードが実行されるリスクがあり、システムが利用できない状態になる可能性があります。詳細については、「互換性チェックを無視する設定の変更（リリース 4.x 以降）」を参照してください。

  • グレースフルアップグレードを実行してリブート前にファブリックからノードを分離し、トラフィックが他の使用可能なノードにプロアクティブに転送されるようにする場合は、[グレースフルチェック（Graceful Check）] オプションで [はい（Yes）] を選択します。分離が完了すると、スイッチは自動的にリブートされます。

    このオプションは、ノードを独立してメンテナンスモードにします。これは、Graceful Insertion and Remove（GIR）によって内部的に使用されるモードと基本的に同じです。GIR の詳細については、『Cisco APIC Getting Started Guide』を参照してください。

    GIR モードのルールと制限事項については、ファームウェア管理について の 重要な注意 セクションを参照してください。

  • [実行モード（Run Mode）] フィールドで、ノード セットのメンテナンス プロセスが正常に完了した後で自動的に次のノード セットに進むための実行モードを選択します。

    次のオプションがあります。

    • 障害時に一時停止せず、クラスタの状態を待機しない（Do not pause on failure and do not wait on cluster health）

    • アップグレードの失敗時に一時停止します

    デフォルトは [アップグレードの失敗時のみ一時停止Pause only Upon Upgrade Failure）] です。

[詳細設定（Advanced Settings）] ウィンドウでいずれかのアクションの実行が完了したら、[完了（Done）] をクリックします。その後、メイン ファームウェア のページに戻ります。

ステップ 13

アップグレードプロセスの一部としてノードをリブートできるメンテナンスウィンドウがある場合は、[すべてインストール（Install All）] をクリックしてソフトウェアのインストールを開始します。

[ノード ファームの更新（Node Firmware Update）] ウィンドウで、アップグレードグループ内のノードのアップグレードの進行状況をモニタできます。このウィンドウを閉じ、左側のナビゲーションウィンドウで [ノード（Nodes）] をクリックして、テーブルの [ステータス（Status）] 列でアップグレードグループの全体的なステータスを確認することもできます。

ステップ 14

すべてのノードのステータスが [完了済み（Completed）] になったら、[完了（Done）] をクリックします。

REST API を使用したソフトウェアのアップグレード

REST API を使用して、ソフトウェアをアップグレードすることができます。

REST API を使用した Cisco APIC ソフトウェアのアップグレード

手順

ステップ 1

リポジトリに Cisco APIC イメージをダウンロードします。

例:

POST URL: https://<ip address>/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="APIC_Image_download" proto="http" url="http://<ip address>/<ver-no>"/>
</firmwareRepoP>
ステップ 2

コントローラの目的のバージョンを設定するには、次のポリシーを POST 送信します。

例:

POST URL: https://<ip address>/api/node/mo/uni/controller.xml
<firmwareCtrlrFwP
    version="<ver-no>"
    ignoreCompat="true">
</firmwareCtrlrFwP>
ステップ 3

コントローラのアップグレードをただちに起動する次のポリシーを POST 送信します。

例:

POST URL : https://<ip address>/api/node/mo/uni/controller.xml
<maintCtrlrMaintP
    adminState="up" adminSt="triggered">
</maintCtrlrMaintP>

REST API を使用したスイッチ ソフトウェアのアップグレード

手順

ステップ 1

リポジトリにスイッチ イメージをダウンロードします。

例:

POST URL: https://<ip address>/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="Switch_Image_download" proto="http" url="http://<ip address>/<ver-no>"/>
</firmwareRepoP>
ステップ 2

ソフトウェア リリースに応じて、必要なノード ID を持つファームウェア グループとメンテナンス グループを作成するための適切なポリシーを投稿します。

  • リリース 4.0(1) 以前のリリースの場合、次のポリシーを、POST 送信することにより、ノード ID が 101、102、103、104 の スイッチから構成されるファームウェア グループを作成し、ノード ID 101、102、103、104 によるメンテナンス グループを作成します。 

    POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<fabricInst>
<firmwareFwP
    name="AllswitchesFwP"
    version="<ver-no>"
    ignoreCompat="true">
</firmwareFwP>

<firmwareFwGrp
    name="AllswitchesFwGrp" >
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<firmwareRsFwgrpp
    tnFirmwareFwPName="AllswitchesFwP">
</firmwareRsFwgrpp>
</firmwareFwGrp>

<maintMaintP
    name="AllswitchesMaintP"
    runMode="pauseOnlyOnFailures" >
</maintMaintP>

<maintMaintGrp
    name="AllswitchesMaintGrp">
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<maintRsMgrpp
    tnMaintMaintPName="AllswitchesMaintP">
</maintRsMgrpp>
</maintMaintGrp>
</fabricInst>

  • リリース 4.0(1) 以降のリリースの場合、次のポリシーを、POST 送信することにより、ノード ID が 101、102、103、104 の スイッチから構成されるファームウェア グループを作成し、ノード ID 101、102、103、104 によるメンテナンス グループを作成します。 

    POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<fabricInst>   
       <maintMaintP
              version="<ver-no>"
              name="AllswitchesFwP"
              runMode="pauseOnlyOnFailures">
       </maintMaintP>
       <maintMaintGrp name="AllswitchesMaintGrp">
              <fabricNodeBlk name="Blk101" from_="101" to_="101">
              </fabricNodeBlk>
              <fabricNodeBlk name="Blk102" from_="102" to_="102">
              </fabricNodeBlk>
              <fabricNodeBlk name="Blk103" from_="103" to_="103">
              </fabricNodeBlk>
              <fabricNodeBlk name="Blk104" from_="104" to_="104">
              </fabricNodeBlk>
              <maintRsMgrpp tnMaintMaintPName="AllswitchesMaintGrp">
              </maintRsMgrpp>
       </maintMaintGrp>
</fabricInst>
ステップ 3

すべてのスイッチのアップグレードをただちにトリガする次のポリシーを POST します。

例:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<maintMaintP
    name="AllswitchesMaintP" adminSt="triggered">
</maintMaintP>
アップグレード中にコントローラ クラスタを使用できるように、Cisco APIC は順番にアップグレードされます。

REST API を使用したカタログ ソフトウェア バージョンのアップグレード

通常、カタログ イメージは、Cisco APIC イメージのアップグレード時にアップグレードされます。ただし、管理者がカタログ イメージをアップグレードしなければならない場合もあります。

手順

カタログ イメージをアップグレードします。

例:

http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<firmwareCatFwP
    version=“catalog-1.0(1e)”  ignoreCompat=“yes” />
</firmwareCatFwP>

CLI による ソフトウェアのアップグレード

CLI を使用して、ソフトウェアをアップグレードできます。

NX-OS を使用した Cisco APIC ソフトウェアのアップグレード

手順

ステップ 1

送信元からコントローラにイメージをダウンロードします。

例:

admin@ifc1:~> scp <username>@<Host IP address that has the image>:/<absolute path to the image including image file name>  .
admin@ifc1:~> pwd
/home/admin
admin@ifc1:~> ls
<ver-no>.bin
ステップ 2

リポジトリ情報を表示します。

例:

apic1# show firmware repository
ステップ 3

リポジトリにファームウェア イメージを追加します。

apic1# firmware repository add <name of the image file>

例:

apic1# firmware repository add aci-apic-dk9.2.0.1r.iso
ステップ 4

アップグレードするコントローラを設定します。

apic# configure
apic1(config)# firmware
apic1(config-firmware)# controller-group
apic1(config-firmware-controller)# firmware-version <name of the image file>

例:

apic# configure
apic1(config)# firmware
apic1(config-firmware)# controller-group
apic1(config-firmware-controller)# firmware-version aci-apic-dk9.2.2.2e.bin
ステップ 5

コントローラをアップグレードします。

例:

apic1(config-firmware-controller)# exit
apic1(config-firmware)# exit
apic1(config)# exit
apic1# firmware upgrade controller-group

アップグレード中にコントローラ クラスタを使用できるように、Cisco APIC は順番にアップグレードされます。アップグレードはバックグラウンドで実行されます。

ステップ 6

コントローラのアップグレードを確認します。

例:

apic1# show firmware upgrade status
 Pod         Node        Current-Firmware      Target-Firmware       Status                     Upgrade-Progress(%) 
 ----------  ----------  --------------------  --------------------  -------------------------  --------------------
 1           1           apic-2.3(0.376a)                            success                    100                 
 1           2           apic-2.3(0.376a)                            success                    100                 
 1           3           apic-2.3(0.376a)                            success                    100                 
 1           101         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           102         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           103         n9000-12.3(0.100)     n9000-12.3(0.102)     upgrade in progress        5                   
 1           104         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           201         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           202         n9000-12.3(0.100)     n9000-12.3(0.102)     upgrade in progress        5                   
apic1#

NX-OS スタイル CLI を使用したスイッチのアップグレード

手順

ステップ 1

送信元からコントローラにイメージをダウンロードします。

例:

admin@ifc1:~> scp <username>@<Host IP address that has the image>:/<absolute path to the image including image file name>  .
admin@ifc1:~> pwd
/home/admin
admin@ifc1:~> ls
<ver-no>.bin
ステップ 2

リポジトリ情報を表示します。

例:

apic1# show firmware repository
ステップ 3

リポジトリにファームウェア イメージを追加します。

apic1# firmware repository add <name of the image file>

例:

apic1# firmware repository add aci-apic-dk9.2.0.1r.iso
ステップ 4

アップグレードのスイッチのグループを設定します。 

apic1# configure
apic1(config)# firmware 
apic1(config-firmware)# switch-group <name of the switch group> 
apic1(config-firmware-switch)# switch <switches to add to group>
apic1(config-firmware-switch)# firmware-version <name of the image file>

例:

apic1# configure
apic1(config)# firmware 
apic1(config-firmware)# switch-group group1 
apic1(config-firmware-switch)# switch 101-104,201,202
apic1(config-firmware-switch)# firmware-version aci-n9000-dk9.12.2.2e.bin

上記の switch コマンドで no 引数を使用して、次のようにグループからスイッチを削除することもできます。 

apic1(config-firmware-switch)# no switch 203,204
ステップ 5

現在のノード セットでアップグレードが失敗した場合に次のノード セットに進むかどうかを指定します。

apic1(config-firmware-switch)# [no] run-mode {pause-never | pause-on-failure}

例:

apic1(config-firmware-switch)# run-mode pause-on-failure
ステップ 6

アップグレードにスケジューラを割り当てるか、すぐにアップグレードするかを決定します。

  • アップグレードをいつ実行するのかを指定するには、スケジューラが存在する必要があります。

    スケジューラの詳細については、「スケジューラによるアップグレードについて」を参照してください。

    既存のスケジューラをアップグレードに割り当てるには、次の手順を実行します。

    apic1(config-firmware-switch)# schedule <scheduler-name>

    次に例を示します。

    apic1(config-firmware-switch)# schedule myNextSunday

  • スイッチ グループをすぐにアップグレードするには、EXEC モードに戻り、コマンド firmware upgrade switch-group を入力します。

    （注）   

    この状況では、firmware upgrade switch-group コマンドはすぐにアップグレードを実行します。

    これは、設定済みのスケジュールされたアップグレードよりも優先されます。 

    apic1(config-firmware-switch)# exit
apic1(config-firmware)# exit
apic1(config)# exit
apic1# firmware upgrade switch-group <name of the switch group>

    次に例を示します。

    apic1(config-firmware-switch)# exit
apic1(config-firmware)# exit
apic1(config)# exit
apic1# firmware upgrade switch-group group1
ステップ 7

スイッチ グループのアップグレード ステータスを確認します。 

apic1# show firmware upgrade status switch-group <name of the switch group>

このコマンドから生成される出力は、リリースによって異なります。

  • リリース 4.2(5) よりも前のリリースでは、次のような出力が表示されます。

    apic1# show firmware upgrade status switch-group group1
 Pod         Node        Current-Firmware      Target-Firmware       Status                     Upgrade-Progress(%) 
 ----------  ----------  --------------------  --------------------  -------------------------  --------------------
 1           1           apic-2.3(0.376a)                            success                    100                 
 1           2           apic-2.3(0.376a)                            success                    100                 
 1           3           apic-2.3(0.376a)                            success                    100                 
 1           101         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           102         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           103         n9000-12.3(0.100)     n9000-12.3(0.102)     upgrade in progress        5                   
 1           104         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           201         n9000-12.3(0.102)     n9000-12.3(0.102)     success                    100                 
 1           202         n9000-12.3(0.100)     n9000-12.3(0.102)     upgrade in progress        5                   
apic1#

  • リリース4.2 (5) 以降では、次のような出力が表示されます。ここでは、[Download-Status] および[Download-Progress(%)] 列を使用して追加情報を提供します。 

    apic1# show firmware upgrade status switch-group group1
  Pod         Node        Current-Firmware      Target-Firmware       Status                     Upgrade-Progress(%)   Download-Status            Download-Progress(%)
 ----------  ----------  --------------------  --------------------  -------------------------  --------------------  -------------------------  --------------------
 1           101         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           107         n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100                 
 1           108         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           112         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           113         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           121         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           122         n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100                 
 1           123         n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100                 
 1           124         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           126         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           127         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           128         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           130         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           171         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           172         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           173         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           174         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           175         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           196         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           197         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           201         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 2           303         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           501         n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           502         n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100                 
 1           1001        n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           1002        n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100                 
 1           1901        n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           1902        n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           1903        n9000-15.0(0.138)     n9000-15.0(0.144)     upgrade in progress        45                    downloaded                 100                 
 1           3999        n9000-15.0(0.138)     n9000-15.0(0.144)     waiting in queue           0                     downloaded                 100  
apic1#

NX-OS スタイル CLI を使用したカタログ ソフトウェア バージョンのアップグレード

デフォルトで、コントローラをアップグレードすると、自動的に対応するカタログ コントローラのバージョンにアップグレードされます。つまり、リポジトリにコントローラのイメージを追加すると、リポジトリにもカタログ イメージが追加されます。

別のカタログ イメージをコピーし、リポジトリに追加することもできます。

手順

ステップ 1

カタログ イメージをリポジトリに追加します。

例:

apic1(config)# firmware                                      
apic1(config-firmware)# catalog-version aci-catalog-dk9.2.2.2e.bin
ステップ 2

カタログ アップグレード ステータスを確認します。

例:

apic1# show catalog
Catalog-version : 2.2(2e)
apic1#

デバッグ CLI を使用したコントローラのアップグレード

実行中のファームウェア イメージと互換性がない新しい Cisco APIC ファームウェア イメージをインストールする場合は、デバッグ CLI を使用してアップグレードできます。


（注）  

これらの手順で、この Cisco APIC から以前のすべてのユーザ データを削除します。クラスタが一部の場合、コントローラはクラスタの他のコントローラからデータを取得できます。

3 つの手順でデバッグ CLI を使用してコントローラをアップグレードする

手順

ステップ 1

管理者として Cisco APIC にログインします。

ステップ 2

Cisco APIC からユーザのデータを消去します。

例:

admin@apic1:~> acidiag touch clean
ステップ 3

Cisco APIC のイメージをインストールします。

例:

admin@apic1:~> acidiag install http://<ip>/<ver-no>
ステップ 4

Cisco APIC をリブートします。

例:

admin@apic1:~> acidiag reboot

API を使用したファームウェア バージョンおよびアップグレード ステータスの確認

確認内容 URL の例

コントローラで現在実行中のファームウェアのバージョン

GET URL：https://<ip address>/api/node/class/firmwareCtrlrRunning.xml

スイッチで現在実行中のファームウェアのバージョン

GET URL：https://<ip address>/api/node/class/firmwareRunning.xml

コントローラとスイッチのアップグレードの状態

GET URL：https://<ip address>/api/node/class/maintUpgJob.xml

SSD インストール ステータスの確認

この手順を使用して、Cisco APIC に SSD がインストールされているか確認します。

手順

ステップ 1

管理者ユーザとして Cisco APIC にログインします。

ステップ 2

コマンド acidiag hwcheck | grep -A 6 "Physical Disk /dev devices" を入力します。 

admin@APIC1:~> acidiag hwcheck | grep -A 6 "Physical Disk /dev devices". 
====================== Physical Disk /dev devices
 
Disk /dev/sda: 999.0 GB, 998999326720 bytes, 1951170560 sectors
Disk /dev/sdb: 119.5 GB, 119453777920 bytes, 233308160 sectors
Disk /dev/sdc: 4009 MB, 4009754624 bytes, 7831552 sectors
Disk /dev/mapper/vg_ifc0_ssd-data: 113.8 GB, 113816633344 bytes, 222298112 sectors
 
admin@APIC1:~>
ステップ 3

CIMC にログインします。
ステップ 4

[ストレージ] > [物理ドライブ情報] を選択します。

ステップ 5

SSD がインストールされているかどうかを確認します。

アップグレード プロセス中にフォールトのトラブルシューティング

メンテナンス ポリシーごとに 1 つのスケジューラが存在します。デフォルトでアップグレードフォールトが検出されると、スケジューラを停止し、そのグループのノードはアップグレードを開始しません。スケジューラは、アップグレード フォールトの場合に手動介入によるデバッグを必要とします。手動介入が完了したら、一時停止されたスケジューラを再開させる必要があります。

スイッチのステータスが「queued」になっている場合は、以下を確認します。

  • コントローラのクラスタが正常かどうか。コントローラ クラスタは、正常な状態にする必要があります。API に「waitingForClusterHealth = yes」と表示されている場合、または GUI で [Waiting for Cluster Convergence] に対して [Yes] が表示されている場合は、コントローラのクラスタが正常ではないことを示しています。正常になるまで、アップグレードを開始していないスイッチのステータスは「queued」のままになります。

  • スイッチのメンテナンス グループが一時停止していないか。スイッチがアップグレードに失敗すると、グループは一時停止状態になります。

スイッチについて API で「waitingForClusterHealth = no」と表示されるまで、または GUI で [クラスタ コンバージェンスの待機（Waiting for Cluster Convergence）] に [いいえ（No）] が表示されるまで約 60 分以上かかる場合は、スケジューラの一時停止を確認するステップを完了します。

ダウンロード障害の一般的な原因

ダウンロード障害の一般的な原因は、次のようなものがあります。

  • 不十分な許可

  • ディレクトリまたはファイルが見つからない

  • 宛先のディレクトリに空きがない

  • リクエストのタイムアウト/許容可能な時間内にダウンロードが完了できなかった

  • サーバ エラー/不明なサーバ エラー

  • 無効な Ack

  • ユーザー名/パスワード認証の問題

ダウンロードを再開するには手順のいずれかを実行します。

クラスタの収束の確認

GUI を使用して、クラスタ コンバージェンスを確認します。

定期メンテナンス後に、クラスタの収束の進行状況をモニタできます。GUI に [コントローラ ファームウェア] 画面が表示され、1 つのクラスタの収束プロセスごとに一連のメッセージが示されます。これらのメッセージは [Status] フィールドに表示されます。


（注）  

成功するため、アップグレードの 2 つのグループに、スイッチを分割必須です。

  • Cisco APIC リリース 4.2(5)以前では、デフォルトで、システムは一度に 20 個のスイッチをアップグレードします。

  • Cisco APIC リリース 4.2(5) 以降、デフォルトでは、システムが一度にアップグレードできるスイッチの数が 20 から無制限に変更されました。

この数は、スケジューラを使用するときに変更できます。

コントローラとスイッチのアップグレードの進行に伴い、キューに入っているノードの数とアップグレード中のノードの数、および成功したアップグレードの数に関するメッセージが表示されます。

表示されるノードのアップグレード ステータスは次のとおりです。

  • NotScheduled：現在、ノードに対してアップグレードはスケジュールされていません。

  • Scheduled：ノードに対してアップグレードがスケジュールされています。

  • Queued：現在アクティブな時間枠（スケジュール）があり、ノードがアップグレードの認可を要求しています。

  • Inprogress：現在、ノードに対してアップグレードが進行中です。

  • CompleteOK：アップグレードが正常に完了しました。

  • CompleteNOK：ノードでのアップグレードが失敗しました。

  • Inretryqueue：アップグレードを再試行するためにノードがキューに入っています（5 回試行した後に、失敗が宣言されます）。

This may take a while. すべてのクラスタが正常に収束されると、[コントローラ ファームウェア] 画面の [クラスタ コンバージェンスの待機] フィールドに「No」と表示されます。

コントローラのアップグレードを一時停止することの確認

コントローラのアップグレードは、GUI または REST API のいずれかを使用して一時停止を確認することができます。

GUI を使用してコントローラのアップグレード スケジューラ一時停止しているかどうかを確認するには

手順
ステップ 1

メニュー バーで、[ADMIN] > [Firmware] を選択します。

ステップ 2

[Navigation] ペインで、[Fabric Node Firmware] > [Controller Firmware] を展開します。

ステップ 3

スケジュールされたメンテナンス ポリシーが一時停止して かどうかが表示されます アップグレードに失敗しました で、 ステータス 内の列、 作業 ペインで、特定の Cisco APIC 。

ものが正しく進行していることが表示されます ファームウェア アップグレード queued、クラスタ コンバージェンスを待機中 で [Status] カラムで、 作業 ペインで、特定の Cisco APIC 。

ステップ 4

問題を特定して、この問題を修正します。

ステップ 5

をクリックします アクション ] タブをクリックします コントローラ ファームウェア ポリシーのアップグレード 。

REST API を使用してコントローラのアップグレード スケジューラ一時停止しているかどうかを確認するには

手順

コントローラ メンテナンス ポリシーのためにスケジューラが一時停止されていることを確認するには、次の API を POST 送信します。

例:
https://<ip address>/api/node/class/maintUpgStatus.xml

次のような返品が表示されます。

例:
https://<ip address>/api/node/class/maintUpgStatus.xml

ConstCtrlrMaintP ==> controller group
Nowgrp ===> A switch group

<?xml version="1.0" encoding="UTF-8"?>
<imdata totalCount="2">
    <maintUpgStatus childAction="" dn="maintupgstatuscont/maintupgstatus-ConstCtrlrMaintP" faultDelegateKey="uni/fabric/
maintpol-ConstCtrlrMaintP" lcOwn="local" maxConcurrent="0" modTs="2014-08-28T14:45:24.232-07:00" polName="
ConstCtrlrMaintP" runStatus="paused" status="" uid="0" waitOnClusterHealth="no" windowName=""/>
    <maintUpgStatus childAction="" dn="maintupgstatuscont/maintupgstatus-nowgrp" faultDelegateKey="" lcOwn="local" 
maxConcurrent="0" modTs="2014-08-28T08:05:15.148-07:00" polName="nowgrp" runStatus="running" status="" uid="0" 
waitOnClusterHealth="no" windowName=""/>
</imdata>

スイッチのアップグレードの一時停止確認

GUI または REST API のいずれかを使用して、スイッチのアップグレードの一時停止を確認できます。

GUI を使用してスイッチ アップグレード スケジューラの一時停止を確認する

手順
ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

ステップ 2

[ナビゲーション] ペインで、[ファブリック ノード ファームウェア] > [メンテナンス グループ] を展開します。

ステップ 3

[メンテナンス グループ] を展開して、[すべてのスイッチ] をクリックします。

ステップ 4

[作業] ペインで、[スケジューラのステータス] が [一時停止] を読み取っているか確認します。

（注）   

[スケジューラのステータス] が [実行中] を読み取り、グループ内のノードがアップグレードを続行または完了している場合、デバイスが実行されアップグレードが続行または完了します。

ステップ 5

デバイスに移動し、手順 1 ～ 4 を繰り返します。

この時点で、[スケジューラのステータス] は [実行中] を読み取ります。

ステップ 6

右上の [アクション] ドロップダウンリストを使用して、[アップグレード スケジューラの再開] を選択します。

ステップ 7

右上の [アクション] ドロップダウン リストを使用して、[今すぐアップグレード] を選択します。

REST API を使用してスイッチのアップグレード スケジューラが時停止しているか確認する

手順

スイッチ メンテナンス ポリシーのためにスケジューラが一時停止されていることを確認するには、次の API を POST 送信します。

例:
https://<ip address>/api/node/class/maintUpgStatus.xml

次のような返品が表示されます。

例:
https://<ip address>/api/node/class/maintUpgStatus.xml

ConstCtrlrMaintP ==> controller group
Nowgrp ===> A switch group

<?xml version="1.0" encoding="UTF-8"?>
<imdata totalCount="2">
    <maintUpgStatus childAction="" dn="maintupgstatuscont/maintupgstatus-ConstCtrlrMaintP" faultDelegateKey="uni/
fabric/maintpol-ConstCtrlrMaintP" lcOwn="local" maxConcurrent="0" modTs="2014-08-28T14:45:24.232-07:00" 
polName="ConstCtrlrMaintP" runStatus="paused" status="" uid="0" waitOnClusterHealth="no" windowName=""/>
    <maintUpgStatus childAction="" dn="maintupgstatuscont/maintupgstatus-nowgrp" faultDelegateKey="" lcOwn="
local" maxConcurrent="0" modTs="2014-08-28T08:05:15.148-07:00" polName="nowgrp" runStatus="running" status="" 
uid="0" waitOnClusterHealth="no" windowName=""/>
</imdata>

スコントローラのメンテナンス ポリシーのために一時停止したスケジューラの再開

GUI または REST API のいずれかを使用してコントローラ メンテナンス ポリシーの一時停止スケジューラを再開することができます。

コントローラのアップグレード スケジューラ Resume を GUI を使用して一時停止しています

手順

ステップ 1

メニュー バーで、[ADMIN] > [Firmware] を選択します。

ステップ 2

[Navigation] ペインで、[Fabric Node Firmware] > [Controller Firmware] を展開します。

ステップ 3

[Work] ペインで、[Policy] タブをクリックします。

ステップ 4

[Controller Maintenance Policy] 領域で、[Running Status] フィールドの表示が [Paused] であることを確認します。

ステップ 5

[Actions] タブをクリックし、[Resume Upgrade Scheduler] をクリックします。

ステップ 6

をクリックします アクション ] タブを選択します コントローラ ファームウェア ポリシーのアップグレード ドロップダウンリストから。

ステップ 7

[アクション（Actions）] タブをクリックし、ドロップダウン リストから [今すぐ適用（Apply Now）] を選択します。

REST API を使用して一時停止したコントローラのアップグレード スケジューラを再開する

手順

ステップ 1

コントローラ メンテナンス ポリシーのために一時停止されたスケジューラを再開するには、次の API をPOST 送信します。

この例では、メンテナンス ポリシーは ConstCtrlrMaintP です。

例:

URL: https://<ip address>/api/node/mo.xml 
<maintUpgStatusCont>
<maintUpgStatus polName="ConstCtrlrMaintP" status="deleted" />
</maintUpgStatusCont>
ステップ 2

Cisco APIC コントローラ ソフトウェアをアップグレードするために最初に使用される REST API を使用します。

スイッチのメンテナンス ポリシーのために一時停止したスケジューラの再開

一時停止したスイッチのアップグレード スケジューラを再開するために GUI を使用する

手順

ステップ 1

メニュー バーで、[管理] > [ファームウェア] を選択します。

ステップ 2

[ナビゲーション] ペインで、[ファブリック ノード ファームウェア] > [メンテナンス グループ] > [maintenance_group_name] を展開します。

ステップ 3

[Work] ペインで、[Policy] タブをクリックします。

ステップ 4

[Maintenance Policy] 領域で、[Running Status] フィールドの表示が [Paused] であることを確認します。

ステップ 5

[メンテナンス ポリシー] 領域で、[スケジューラのステータス] フィールドに [一時停止] が表示され、[クラスタ コンバージェンスの待機] フィールドに [いいえ] が表示されていることを確認します。

ステップ 6

[Actions] タブをクリックし、[Resume Upgrade Scheduler] をクリックします。

ステップ 7

[アクション] タブをクリックして、ドロップダウン リストから [今すぐアップグレード] を選択します。

REST API を使用して一時停止したスイッチ アップグレード スケジューラを再開する

手順

ステップ 1

スイッチ メンテナンス ポリシーのために一時停止されたスケジューラを再開するには、次の API をPOST 送信します。

この例では、メンテナンス ポリシーは swmaintp です。

例:

URL: https://<ip address>/api/node/mo.xml 			 
<maintUpgStatusCont>
<maintUpgStatus polName="swmaintp" status="deleted" />
</maintUpgStatusCont>
ステップ 2

最初に使用した REST API を使用してスイッチ ソフトウェアをアップグレードします。

クリーン再起動の実行

最初にファブリックを起動する際にファブリックのクリーン再起動を実行し、ファブリックが正常に動作しない場合、クリーン再起動がファブリックを再度起動する唯一のオプションとなります。

手順

ステップ 1

アウトオブバンド管理で各 Cisco APIC にログインし Cisco APIC DME アプリケーションを停止します。

例:

acidiag stop mgmt
ステップ 2

アウトオブバンド管理を使用して各スイッチにログインします。アウトオブバンド管理が使用できない場合は、コンソールを使用してログインします。次のコマンドを使用して、スイッチをクリーン再起動します。

例:

/bin/setup-clean-config.sh
vsh-c reload
ステップ 3

次の通りに各 Cisco APIC にログインし、Cisco APIC を再起動します。

例:

acidiag touch clean
acidiag reboot
（注）   
このエラーを無視する：「acidiag: error: curl: (52) Empty reply from server」

ファブリックがクリーン再起動されると、ノードは検出されません。ノード ポリシーをポストするか、UI を使用してスイッチを登録できます。

Cisco ACI スイッチの混合バージョン中に許可される操作

Cisco ACI ファブリックには基本的に、すべてのノード (APIC、リーフスイッチ、およびスパインスイッチ) が同じソフトウェアリリースまたは互換性のあるソフトウェアリリース上にある必要があります。この場合、APIC ノードの標準リリース形式は x.y(z)、リーフおよびスパインスイッチには、スイッチ固有の標準リリース形式の 1x.y(z) があります。たとえば、APIC ノードがソフトウェアリリース 4.1(1) 上にある場合、リーフ スイッチとスパイン スイッチは、スイッチ固有のバージョン 14.1(1) である必要があります。

ただし、この状況では通常、スイッチ ノードを複数の異なるグループ (メンテナンス グループ) に分割することになるため、多数のスイッチ ノードを持つ大きな ACI ファブリックのソフトウェアをアップグレードしようとすると、これは困難な要件となる可能性があります。これにより、一度に1つのアップグレードを実行して、サービスの中断を回避できますスイッチ ノードまたはメンテナンス グループの数、およびネットワーク トラフィック、サービス、およびアプリケーションの検証プロセスに応じて、1 日のメンテナンス グループをアップグレードできますが、その他のメンテナンス グループのアップグレードを待つ必要がある場合があります。

リリース 2.2(1) 以降では、ソフトウェアのアップグレードによりすべての ACI スイッチが同じバージョンになっていない場合でも、一部の操作を実行できます。この動作は、リリース 2.3(1) で拡張され、この状況で実行できるさらに多くの操作をサポートするようになりました。次の表では、リリース 2.2(1) および 2.3(1) 以降のスイッチが混在リリースにある場合に実行できる操作について説明します。


（注）  

  • 表 1 で説明されているサポートされている操作を実行するには、最初にすべての APIC ノードを新しいバージョンにアップグレードする必要があります。すべての APIC ノードが正常にアップグレードされ、完全にアップグレードされるまで、操作を実行しないでください。

  • vPC ペアのリーフ スイッチの 表 1 でサポートされている操作は、両方の vPC ペアのリーフ スイッチがソフトウェアの同じリリースにある場合にのみ実行できます。

  • 表 1 でリストされている操作を実行できるのは、古い (from) バージョンですでにサポートされていた機能に関連している場合だけです。

  • 3.0 以前のリリースでは、ファブリック内の ACI ノードのバージョンの違いを通知する赤いバナーの警告が表示されています。このバナーの警告は、リリース 3.0 以降に削除されました。
表 4. アップグレード パスごとに混合バージョンでサポートされる操作

アップグレード パス

サポートされる操作

移行前

移行後

2.2(x)

サポートされているアップグレード パスのすべてのバージョン

  • 設定のエクスポート

  • テクニカル サポートの収集

  • 物理的なネットワークの変更 (再起動、ケーブル交換など)

  • メジャー リリースの前に導入された機能のポリシー変更*

2.3(x) 以降

サポートされているアップグレード パスのすべてのバージョン

  • 設定のエクスポート

  • テクニカル サポートの収集

  • 物理的なネットワークの変更 (再起動、ケーブル交換など)

  • メジャー リリースの前に導入された機能のポリシー変更*

  • 機能のポリシー変更: 表 2

* この操作がサポートされるのは、アップグレードが同じリリースの列車内にある場合 (たとえば 3.2(5d) から 3.2(5f) へのアップグレードであり、リリースは 3.2(5) リリースのトレーニングの一部ですが、そのリリースのdとfのバージョンの間でアップグレードが発生します)。

リリース 2.3(1) 以降、Application Policy Infrastructure Controller は上記のネットワーク設定機能と混合 OS 動作中の変更に一覧表示したものに加えて、次の機能をサポートします。

表 5. リリース 2.3(x) 以降からのアップグレードでバージョンが混在する場合にサポートされる操作

機能

操作

コントラクト

  • フィルタ、件名、コントラクトを作成、更新、削除します。

  • コントラクトをエクスポートおよびインポートします。

  • EPG に関係する提供および消費されたコントラクトを追加および削除します。

  • vzAny で提供および消費されたコントラクトを追加および削除します。

エンドポイント グループ

  • EPG を作成および削除します。

  • VMM、物理、外部、L2 外部、L3 外部ドメインの関連付けを追加および削除します。

  • スタティック ポートの割り当ておよびノードへの静的リンクを追加、削除、更新します。

  • 1 つの EPG から別の EPG にエンドポイントを移動します。

  • uSeg EPG からベースに EPG にエンドポイントを移動します。

マイクロセグメンテーション

uSeg EPG を追加および更新します。

VMotion

リーフ スイッチ全体の vMotion。

VM 操作

仮想マシンのオンおよびオフ。

ブリッジ ドメイン

ブリッジ ドメインを作成、更新、削除します。

VMM ドメイン

次の操作は、VMware vDS および Cisco AV でのみサポートされます。

  • VMM ドメインを作成し削除します。

  • VLAN プールを作成し更新します。

  • マルチキャスト プールを追加し削除します。

  • vMware vCenter を追加し更新します。

  • vSwitch ポリシーを追加し更新します。

レイヤ 2 またはレイヤ 3 アウト

L2 外部および L3 外部ドメインを追加、更新、削除します。

アクセス ポリシー

  • スイッチ ポリシー、インターフェイス ポリシー、ポリシー グループ、接続エンティティ プロファイル（AEP）を追加、更新、削除します。

トラブルシューティング

  • SPAN 設定を追加、更新、削除します。

  • syslog サーバを追加、更新、削除します。

物理ネットワーク

  • ポート ステータスを有効化および無効化します。

  • 物理サーバのオンおよびオフ。

  • リーフ スイッチおよびリーフ スイッチ間で物理サーバを移動します。

  • スパイン スイッチとリーフ スイッチのリロード。

  • スパイン スイッチ LC カード、FC カード、CS カードと SUP カードのリロード。

  • スパイン スイッチとリーフ スイッチのデコミッション。

  • 仮想ポート チャネル（vPC）ドメインの追加と削除。

  • プライマリ リンク、セカンダリ リンク、および仮想ポート チャネル（vPC）内のすべてのリンクをフラップします。

  • すべてのポート チャネル リンクをフラップし、ポート チャネルで 1 つのリンクをフラップして、FEX で NIF ポートをフラップし、ラック上部の全面パネル ポートをフラップします。

ファブリック ポリシー

  • NTP サーバ、SNMP、BGP ルート リフレクタ、L2 MTU ポリシーを追加、更新、削除します。

  • Cisco APIC 接続設定を更新します。

次の定義は、Cisco APIC リリースについて説明するために使用されます。

  • Cisco APIC メジャー リリースには、新しいソフトウェア機能およびその他のハードウェアの更新のサポートが含まれています。メジャー リリースの例には、2.2(1n) と 2.1(1h) が含まれます。

  • Cisco APIC マイナーまたはメンテナンス リリース（MR）には、バグ修正や既存のリリースからのパッチが含まれています。マイナーまたはメンテナンス リリースの例には、2.0(1m) と 2.0(2f) が含まれます。

  • Cisco APIC パッチ リリースには、特定の不具合の修正が含まれています。パッチのリリースの例には、2.1(1h) と 2.1(1i) が含まれます。

サイレント ロール パッケージのアップグレードについて

Cisco APIC Release 4.1(2) では、サイレント ロール パッケージ アップグレード (SR アップグレード) 機能が導入されています。SR アップグレードを使用すると、ACI スイッチのソフトウェア OS 全体をアップグレードしなくても、ACI スイッチのハードウェア SDK、ドライバなどの内部パッケージのアップグレードを手動で実行できます。通常、ACI スイッチのソフトウェア OS のアップグレード機能は、内部パッケージも処理するため、SR アップグレードを実行する必要はありません。

Cisco APIC Release 4.1(2) では、SR アップグレード機能は次の 2 つのスイッチをサポートしています。

  • N9K-C93216TC-FX2

  • N9K-C93360YC-FX2

Cisco APIC GUI を使用してサイレント ロール パッケージのアップグレードの設定

始める前に

手順

ステップ 1

作業を進める前に、全コントローラが新しいファームウェア バージョンにアップグレードされていることを確認します。

全コントローラが先に新しいファームウェア バージョンにアップグレードされるまでは、スイッチのファームウェアをアップグレードしないでください。
ステップ 2

メニュー バーで、[管理] > [ファームウェア] を選択します。

ステップ 3

[ワーク (Work)] ペインで、[インフラストラクチャ (Infrastructure)] > [ノード (Nodes)] をクリックします。

ステップ 4

[アクション (Actions)] をクリックし、[ノードのアップグレードをスケジュール (Schedule Node Upgrade)] を選択して、次の操作を実行します。

  1. [グループ タイプ (Group Type)] フィールドで、[ローカル (local)] を選択します。

  2. このフィールドが使用可能な場合は、[グループのアップグレード (Upgrade Group)] フィールドで [既存 (Existing)] または [新規 (New)] のいずれかを選択します。

    • [既存 (existing)]ー既存のアップグレード グループのノードのアップグレードをスケジュールすることができます。

    • [新規 (new)]: 新しいアップグレード グループを作成できます。

  3. [アップグレード グループ名 (Upgrade Group Name)] フィールドで、ドロップダウン メニューで指定されたオプションを使用して既存のアップグレード グループを選択するか、または新しいアップグ レードグループを作成するための名前を入力します。

    4.1(2) 以前のリリースでは、新しいアップグレード グループを作成するために、フィールドの隅にある x をクリックしてフィールドをクリアし、新しいアップグレード グループの名前を入力します。

    既存のポッド メンテナンス グループを選択した場合は、そのメンテナンス グループに関連付けられているフィールドに自動的に入力されます。

  4. [手動サイレント ロール パッケージのアップグレード (Manual Silent Roll Package Upgrade)] チェックボックスをオンにします。

    （注）   

    手動サイレント ロール パッケージのアップグレード (Manual Silent Roll Package Upgrade)を選択した場合:

    • [サイレント ロール パッケージのバージョン (Silent Roll Package version)] ドロップダウンリストに、SR アップグレードパッケージのバージョンのリストが表示されます。

    • 次のフィールドは無効になっています。

      • ターゲットのファームウェア バージョン

      • 互換性チェックの無視

      • グレースフル メンテナンス

  5. [サイレント ロール パッケージのバージョン (Silent Roll Package Version)] ドロップダウン リストをクリックして、SR パッケージのアップグレード用のパッケージを選択します。

  6. [実行モード（Run Mode）] フィールドで、ノード セットのメンテナンス プロセスが正常に完了した後で自動的に次のノード セットに進むための実行モードを選択します。

    次のオプションがあります。

    • 障害時に一時停止せず、クラスタの状態を待機しない（Do not pause on failure and do not wait on cluster health）

    • アップグレードの失敗時のみ一時停止（Pause only Upon Upgrade Failure）

    デフォルトは [アップグレードの失敗時のみ一時停止Pause only Upon Upgrade Failure）] です。

  7. [アップグレード開始時刻 (Upgrade Start Time)] フィールドで、[今すぐ (Now)] または [後でスケジュール (Schedule for Later)] のいずれかを選択します。

    [予定をスケジュール（Schedule for Later）] を選択した場合は、[スケジューラ（Scheduler）] スクロールダウン メニューを使用してトリガー値を選択します。

  8. [すべてのノード (All Nodes)] テーブルの右側にあるプラス アイコンをクリックします。

    [アップグレード グループにノードを追加 (Add Nodes to Upgrade Group)] ページが表示されます。

  9. [アップグレード グループにノードを追加 (Add Nodes To Upgrade Group)] ページで、次のいずれかを選択します。

    • [範囲 (Range)] を選択した場合は、[グループ ノード ID (Group Node Ids)] フィールドに範囲を入力します。

    • [手動 (Manual)] を選択した場合は、選択可能なリーフ スイッチとスパイン スイッチのリストが [すべてのノード (All Nodes)] 領域に表示されます。このアップグレードに含めるノードを選択します。

      表示されるノードは、物理リーフ スイッチとスパイン スイッチであることに注意してください。

  10. [送信 (Submit)]をクリックします。

ステップ 5

アップグレード グループからノードを削除するには、次のようにします。

  1. アップグレード グループから削除するテーブル内のノードを選択します。

  2. [すべてのノード (All Nodes)] テーブルの右側にあるゴミ箱アイコンをクリックします。

  3. [送信（Submit）] をクリックします。

CLI を使用したサイレント ロール パッケージのアップグレードの設定

このセクションでは、SR パッケージのアップグレードを設定および設定解除する方法と、CLI を使用して SR パッケージのアップグレードおよび SR パッケージのバージョンを設定した後にアップグレードをトリガーする方法について説明します。

SR パッケージのアップグレードの詳細については、サイレント ロール パッケージのアップグレードについて を参照してください。

手順

ステップ 1

SR パッケージのアップグレードを設定するには、次のようにします。


Switch# configure 
Switch(config)# firmware 
Switch(config-firmware)# switch-group new
Switch(config-firmware-switch)# sr-version aci-srpkg-dk9.1.0.0.bin 
Switch(config-firmware-switch)# sr-upgrade 
Switch(config-firmware-switch)# show running-config 
# Command: show running-config firmware switch-group new
# Time: Wed Mar 13 15:55:59 2019
  firmware
    switch-group new 
      sr-version aci-srpkg-dk9.1.0.0.bin
      sr-upgrade
      exit
    exit
ステップ 2

SR パッケージのアップグレードを設定解除するには、次のようにします。


Switch# configure 
Switch(config)# firmware 
Switch(config-firmware)# switch-group new
Switch(config-firmware-switch)# no sr-upgrade 
Switch(config-firmware-switch)# show running-config 
# Command: show running-config firmware switch-group new
# Time: Wed Mar 13 16:17:01 2019
  firmware
    switch-group new 
      sr-version aci-srpkg-dk9.1.0.0.bin
      exit
    exit
ステップ 3

SR パッケージのバージョンと SR パッケージのアップグレードを設定した後にアップグレードをトリガーするには、次のようにします。

（注）   

SR パッケージのアップグレードが設定されている場合は、アップグレードをトリガーするために SR パッケージのバージョンを空にすることはできません。SR パッケージのアップグレードが設定されていない場合は、ファームウェアバージョン (スイッチバージョン) を空にすることはできません。 

Switch# firmware upgrade switch-group new

REST API を使用したサイレント ロール パッケージのアップグレードの設定

ここでは、REST API を使用する SR パッケージのアップグレードを設定する方法について説明します。

SR パッケージのアップグレードの詳細については、サイレント ロール パッケージのアップグレードについて を参照してください。

手順

SR パッケージのアップグレードを設定するには、次のようにします。


<fabricInst>        
                <maintMaintP
                srVersion="srpkg-1.0(1)"
                srUpgrade="yes"
                name="m1"
                runMode="pauseOnlyOnFailures">
                </maintMaintP>
                <maintMaintGrp name="m1">
               <fabricNodeBlk name="Blk101"
               from_="101" to_="101">
               </fabricNodeBlk>
                <maintRsMgrpp
                tnMaintMaintPName="m1">
                </maintRsMgrpp>
                </maintMaintGrp>
</fabricInst>

Cisco Nexus 9300 プラットフォーム スイッチから Cisco Nexus 9300 EX プラットフォーム スイッチへの移行

仮想ポート チャネル（vPC）内の Cisco Nexus 9300 プラットフォーム スイッチを Cisco Nexus 9300 EX プラットフォーム スイッチに移行するには、次の手順を実行します。

手順

ステップ 1

Cisco Nexus 9300 プラットフォーム スイッチからケーブルを取り外します。スイッチの電源を切ります。
ステップ 2

Cisco APIC にログインします。

ステップ 3

Fabric > Inventory > Unreachable Nodes を選択します。

ノードが到達不可能なことを確認します。[ノード名] と [ノード ID] のノードを作成します。

ステップ 4

ノードを選択します。[アクション] メニューから、[コントローラから削除] を選択します。

Cisco APIC からノードが削除されるまで 5 ～ 10 分間待機します。

ステップ 5

Cisco Nexus 9300 プラットフォーム スイッチ上のトラフィックをモニタします。すべてのトラフィックはその他の Cisco Nexus 9300 プラットフォーム スイッチによって処理されると、トラフィックへの影響が最小限になるか、影響を受けません。
ステップ 6

Cisco Nexus 9300 EX プラットフォームのスイッチと Cisco Nexus 9300 プラットフォーム スイッチを交換します。
ステップ 7

Cisco Nexus 9300 EX プラットフォーム スイッチの電源をオンにして、ケーブルを接続します。
ステップ 8

Cisco Nexus 9300 EX プラットフォームで Cisco APIC リリース 3.0 (1) ソフトウェアをロードします。スイッチを起動します。

ステップ 9

Cisco APIC にログインします。

ステップ 10

Fabric > Inventory > Fabric Membership を選択します。

スイッチが表示されていることを確認します。
ステップ 11

手順 3 から [ノード名] と [ノード ID] を Cisco Nexus 9300 EX プラットフォーム スイッチに割り当てます。

ステップ 12

すべての関連するポリシーが Cisco Nexus 9300-EX プラットフォーム スイッチにプッシュされ、エンドポイントの同期が完了するまで数分間待機します。確認のため、[操作] > [容量ダッシュ ボード] を選択します。このスイッチのポート チャネルは有効になっていません。

ステップ 13

その他の Cisco Nexus 9300 プラットフォーム スイッチからケーブルを取り外します。スイッチの電源を切ります。
ステップ 14

その他の Cisco Nexus 9300 プラットフォーム スイッチで手順 1-12 を繰り返します。

アップグレードの例

コントローラ アップグレードの例

Cisco APIC イメージをリポジトリにダウンロードする 

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="APIC_Image_download" proto="http" url="http://172.21.158.190/aci-apic-dk9.1.0.0.72.iso"/>
</firmwareRepoP>

スイッチ イメージをリポジトリにダウンロードする

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="Switch_Image_download" proto="http" url="http://172.21.158.190/aci-n9000-dk9.11.0.0.775.bin"/>
</firmwareRepoP>

コントローラ ファームウェア ポリシー：コントローラの目的のバージョン設定 

POST URL: http://trunk6-ifc1/api/node/mo/uni/controller.xml
<firmwareCtrlrFwP
   	 version="apic-1.0(0.72)"
   	 ignoreCompat="true">
</firmwareCtrlrFwP>

コントローラのメンテナンス ポリシー：コントローラのアップグレードのトリガを今すぐ開始する

POST URL: http://trunk6-ifc1/api/node/mo/uni/controller.xml
<maintCtrlrMaintP
	adminState="up" adminSt="triggered">
</maintCtrlrMaintP>

コントローラで現在実行中のバージョンを取得する

(all controllers) GET URL : http://trunk6-ifc1.insieme.local/api/node/class/firmwareCtrlrRunning.xml
(a controller) GET URL : http://trunk6-ifc1.insieme.local/api/node/mo/topology/pod-1/node-1/sys/ctrlrfwstatuscont/ctrlrrunning.xml

コントローラのアップグレードのステータスを取得する

(all controllers) GET URL : http://trunk6-ifc1.insieme.local/api/node/class/maintUpgJob.xml
(a controllers) GET URL : http://trunk6-ifc1.insieme.local/api/node/mo/topology/pod-1/node-1/sys/ctrlrfwstatuscont/upgjob.xml

スイッチのアップグレード例

スイッチのファームウェア グループ: スイッチで同じファームウェア ポリシー グループ

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<firmwareFwGrp name="AllswitchesFwGrp" >
        <fabricNodeBlk name="Blk101to104” from_="101" to_="104” />
       <firmwareRsFwgrpp tnFirmwareFwPName="AllswitchesFwP” />
</firmwareFwGrp>

スイッチのファームウェアのファームウェア ポリシー: セットが必要なバージョン

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<firmwareFwP name="AllswitchesFwP” version="n9000-11.0(0.775)” ignoreCompat="true">
</firmwareFwP>

スイッチのメンテナンス グループ: スイッチで同じメンテナンス ポリシー グループ

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<maintMaintGrp name="AllswitchesMaintGrp">
        <fabricNodeBlk name="Blk101to104” from_="101" to_="104” />
        <maintRsMgrpp tnMaintMaintPName="AllswitchesMaintP” />
</maintMaintGrp>

スイッチのメンテナンス ポリシー: maitenance のセットアップのスケジュール

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<maintMaintP name="AllswitchesMaintP” runMode="pauseOnlyOnFailures" >
</maintMaintP>

今すぐ開始: メンテナンス グループでトリガーのアップグレード

POST URL: http://trunk6-ifc1/api/node/mo/uni/fabric.xml
<maintMaintP name="AllswitchesMaintP" adminSt="triggered">
</maintMaintP>

スイッチで現在実行中のバージョンを取得します。

(all switches) GET UR : http://trunk6-ifc1.insieme.local/api/node/class/firmwareRunning.xml
(a switch) GET URL: http://trunk6-ifc1.insieme.local/api/node/mo/topology/pod-1/node-101/sys/fwstatuscont/running.xml

スイッチのアップグレードのステータスを取得します。

(all switches) GET URL: http://trunk6-ifc1.insieme.local/api/node/class/maintUpgJob.xml
(a switch) GET URL: http://trunk6-ifc1.insieme.local/api/node/mo/topology/pod-1/node-101/sys/fwstatuscont/upgjob.xml

Was this Document Helpful?

FeedbackFeedback

Contact Cisco