Catalyst 9800 WLCのアップグレード|クイックスタートガイド

はじめに

このドキュメントでは、ワイヤレスコントローラのアップグレードに使用できるさまざまな方法と、適切なコントローラを選択する方法について説明します。

要件

次の項目に関する知識が推奨されます。

• Catalyst 9800ワイヤレスLANコントローラ(WLC)
  
  

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

要件と検証

このドキュメントでは、実行するアップグレードのタイプによって異なるため、すべての要件と検証について説明するわけではありません。ただし、問題を回避するために、アップグレードの前にいくつかのチェックを行う必要があります（次のセクションを参照）。

1. アップグレードパスの確認：アップグレードするバージョンのリリースノート(RN)ドキュメントに移動して、特定のバージョンにアップグレードできることを確認します。すべてのRNには「アップグレードパス」セクションがあり、アップグレードパスがサポートされているかどうかを確認できます。バージョン17.12.Xのアップグレードパスの例：https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/release-notes/rn-17-12-9800.html#Cisco_Concept.dita_59a2987f-2633-4630-8c7b-a8e8aecdeaf7
2. APの互換性の確認：コントローラに加入しているAPが、アップグレードしようとしているバージョンと互換性があることを確認します。互換性マトリクス(https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html#c9800-ctr-ap_support)を参照して、APモデルの互換性を確認できます。
3. コントローラがインストールモード（「Show version」で確認可能）で、バンドルモードではないことを確認します。バンドルモードはリカバリのみを目的としており、APのプレダウンロード、パッチ、ISSUアップグレード、およびその他の機能はサポートしていません。

アップグレード手順

ワイヤレスコントローラをアップグレードする手順は、スタンドアロンコントローラ(WLC)かHAペア（SSOまたはN+1冗長性）かによって異なります。 このドキュメントでは、さまざまなアップグレード手順の概要を説明します。

スタンドアロンコントローラ

スタンドアロンコントローラのアップグレードでは、アップグレード中にコントローラがリロードされるため、ダウンタイムが必要です。ただし、アクセスポイントにイメージを事前にダウンロードすることで、このダウンタイムを短縮できます。これにより、コントローラのアップグレード後にAPがイメージのダウンロードを開始するのを回避できます。これにより、イメージのダウンロードに必要なダウンタイムが解消されます。APがWANリンク上にあるかどうかや、設定されているCAPWAPウィンドウサイズによっては、ダウンロードに数分から数時間かかる場合があります。通常、コントローラをアップグレードする前に、アクセスポイントにイメージを事前にダウンロードしておくことを推奨します。 

CLIワークフロー

このセクションでは、コントローラをアップグレードするために実行するコマンドの簡単な要約を示します。各コマンドの詳細な説明とすべての手順を次に示します。

コマンド	説明
add file <file>をインストールします	CCOからブートフラッシュにダウンロードされたイメージは、コントローラにロードされ、パッケージに展開されます。その時点ではWLCのリロードは行われません。
ap image predownload	v2イメージに対応するAPイメージは、APに事前にダウンロードされます
install activate コマンド	アクティブ化により、コントローラでアップグレードがトリガーされ、リロードされます
install commit	コミットにより、変更が永続的なものになります

手順

次に、APのプレダウンロードを使用してスタンドアロンコントローラをアップグレードする手順を示します。この手順では、アップグレードを行うためのCLIコマンドを示します。また、GUIの手順も説明しています。

ステップ0（オプション）：未使用ファイルの削除

最初に、必要に応じて、コントローラから非アクティブなファイルを削除して空き領域を増やすことができます。

install remove inactive

注：この処理には数分かかる場合があります。この操作が完了するまで、先に進まないでください。

ステップ1：イメージをコントローラにアップロードします。

https://software.cisco.com/download/find/9800から「.bin」イメージをダウンロードします。ダウンロードした.binイメージをコントローラにアップロードするには、ftp/sftp/tftp/http方式で次のコマンドを使用します。

copy tftp|ftp|sftp://
    
    
      / 
     
       bootflash: 
      
    

注：コントローラで次のコマンドを使用して、イメージのmd5/sha512ハッシュを確認します。

verify /md5|/sha512 
    
    

ステップ2：コントローラにイメージをインストールする

最初の手順では、コントローラにイメージを「インストール」します。リロードは必要ありません。

install add file bootflash:
    
    

これが完了すると、次のコマンドを使用してイメージが「Inactive」と表示されます。

show install summary

この時点で、APへのイメージのプレダウンロードを開始できます。APを事前にダウンロードしていない場合は、コントローラのアップグレード後にAPがイメージをダウンロードする必要があります。

ステップ3:APへのイメージの事前ダウンロード

APのプレダウンロードをトリガーするには、次のコマンドを使用します。

ap image pre-download

ダウンロード前のステータスを確認するには、「show ap image」コマンドを使用します。次のステップに進む前に、すべてのAPが新しいイメージをダウンロードするまで待つ必要があります。APの数や、APとWLCの間の遅延によっては、この処理に数分/時間かかる場合があります。

ステップ4：イメージをアクティブにする

プレダウンロードが完了したら、イメージを「アクティブ化」できます。コントローラがリロードされ、新しくインストールしたイメージでコントローラがブートします。

install activate

WLCが到達可能になると、APは新しいイメージを検出し、バックアップパーティションとスワップして、新しいバージョンでリロードします。

9800コントローラで、新しいイメージがU状態（アクティブおよびアンコミット）であることを確認できます。 新しいイメージを永続化する場合は、イメージをコミットする必要があります。コミットしない場合は、自動中断タイマー（デフォルトは6時間）が終了すると、コントローラがリロードされます。

ステップ5：イメージを確定します。

イメージをコミットするには、次のコマンドを実行します。

install commit

GUI の手順

GUIを使用してワイヤレスコントローラをアップグレードする場合は、Administration > Software Upgradeの順に選択し、アップグレードパラメータを設定します。.binファイルをデスクトップから直接アップロードするか、TFTP/SFTP/FTPサーバからロードするかを選択できます。APを事前にダウンロードするかどうかも選択できます。すべてが設定されたら、前述のステップ1 ～ 3に対応する「ダウンロードしてインストール」をクリックできます。必要に応じて、「Remove Inactive Files」ボタンをクリックして、新しいイメージをアップロードする前に未使用のファイルを削除することもできます。これは、オプションの手順0に対応しています。

右側のステータスセクションの下にある「Show logs」ボタンをクリックすると、APのプレダウンロードの進捗状況をモニタできます。

イメージのアップロードとインストールが完了したら、[構成の保存とアクティブ化]ボタンをクリックします。これで設定が保存され、コントローラのアップグレードが開始されます。これはステップ4に対応します。

セッションがタイムアウトしたら、コントローラに再度ログインし、Administration > Software Upgradeに移動して、現在使用可能な「Commit」ボタンをクリックします。これはステップ5に対応します。

APは、コントローラが到達可能であることを再度検出すると、バックアップパーティションでリロードを開始し、新しいバージョンで稼働しているコントローラに加入します。

ハイアベイラビリティ(HA)のコントローラ

ワイヤレスコントローラには、冗長性を確保する複数の方法があります。HA SSO（ステートフルスイッチオーバー）ペア、N+1冗長性、またはその両方を使用できます。

• HA SSO:WLC間で継続的な同期を行うアクティブおよびスタンバイコントローラがあります。
• N+1：プライマリコントローラとセカンダリコントローラがありますが、相互接続されていません。両方のコントローラが同じバージョンを実行し、シームレスに動作するように同一に設定する必要があります。APはプライマリコントローラに加入し、プライマリコントローラに障害が発生した場合はセカンダリコントローラにフォールバックします。 

ステートフルスイッチオーバー(SSO)の冗長性

コントローラがHA SSOモードの場合、アップグレードする方法は2つあります。「従来の」アップグレードまたはISSU(In-Service Software Upgrade)のいずれかを実行できます。

• 「クラシック」アップグレード：スタンドアロンコントローラに対して説明したアップグレードプロセスと同じです。両方のコントローラが同時にリロードされ、APは新しいバージョンでリロードされます。APイメージを事前にダウンロードするかどうかを決定できます。このアップグレードの合計ダウンタイム：コントローラのリロード+ APのリロード時間。スタンドアロンコントローラのアップグレードに要する時間と同じです
• ISSUアップグレード：これはゼロダウンタイムアップグレードです。スタンバイコントローラのアップグレード、スイッチオーバーの実行、（古い）アクティブコントローラのアップグレード、そして最後にずらしてAPのアップグレードを行います。24時間365日体制で、ダウンタイムをできる限り短縮する必要のある環境に最適です。

従来のアップグレード

「スタンドアロンコントローラ」セクションの前のセクションを参照してください。手順はまったく同じです。イメージがアクティブからスタンバイコントローラに自動的にコピーされ、両方のコントローラが同時にアップグレードされます。コントローラがアップグレードされると、イメージをAPに事前ダウンロードした場合はAPがパーティションをスワップし、事前ダウンロードが行われていない場合は新しいイメージをダウンロードします。 

注：アップグレードに進む前に、両方のコントローラがアクティブ/スタンバイ – ホット状態になっていることを確認してください（「show redundancy」コマンドを使用）。

ISSUアップグレード

ISSU機能を使用すると、アップグレード中のダウンタイムを短縮できます。コントローラは1台ずつアップグレードし、APは段階的にリロードします。十分なカバレッジがある場合、ワイヤレスクライアントはAP間でローミングできます。APが隔離されている場合、そのAPに接続されているクライアントのダウンタイム（APのリロード時間）が発生します。

両方のコントローラが1つずつアップグレードを行い、APがリブートとアップグレードを行う際にずらして制御するため、このアップグレードにはかなり長い時間がかかります。この結果、クライアントがダウンタイムに気づくことはなく、メンテナンス時間は長くなります。

ISSUのアップグレードを実行する際には、考慮すべき事項がいくつかあります（制限事項、実行する注意事項など）。たとえば、ISSUのアップグレードはインストールモードでのみ使用でき、バンドルモードでは使用できません。ISSUの手順（および手順とコマンド）の詳細な説明については、このドキュメントを参照してください。

N + 1の冗長性

N+1の冗長性は、相互に直接接続されていないが、まったく同じ設定で、同じバージョンを実行している2つのコントローラのセットがある場合に発生します。この例では、1つの「プライマリ」コントローラ（すべてのAPが結合されている）と「セカンダリ」コントローラがあり、プライマリコントローラに障害が発生した場合にバックアップとして使用できます。アップグレードに進む場合、2つの「スタンドアロン」コントローラを使用する場合と同様です。ただし、「N+1ヒットレスローリングAPアップグレード」機能を使用する従来のアップグレードと比較してダウンタイムを短縮する方法があるため、この種の冗長性には大きな利点があります。これにより、アップグレードされたセカンダリコントローラにAPを移動しながら、APの段階的なアップグレードを実行できます。同時にリロードされるAPのサブセットは少ないため、ダウンタイムが制限されます。 

このタイプのアップグレードのフローを次に示します。

1. セカンダリコントローラをターゲットリリースにアップグレードします。これは、接続されているAPがないため、APのプレダウンロードなしで従来のアップグレードで実行できます。この段階では、プライマリがV1を実行し、セカンダリがV2を実行しています。 
2. ターゲットイメージ(V2)をプライマリコントローラにインストールします。ただし、アクティブ化は行いません。これにより、V2イメージをAPに事前にダウンロードできます。
3. ダウンロード前の処理が終了したら、「ap image upgrade destination」コマンドを使用して、APの段階的なアップグレードを開始します。これにより、回避されたAPアップグレードとAPのV2イメージでのリロードがトリガーされ、セカンダリWLCに参加します。
4. すべてのAPがセカンダリWLCに加入したら、プライマリコントローラをV2にアップグレードします。 
5. 必要に応じてAPをプライマリコントローラに簡単に戻すことができます。両方のWLCが同じV2バージョン上にあるため、これによってAPのリロードが必要にならないことに注意してください。CAPWAPの再起動だけが必要で、この処理は1分未満で完了します。  

「N+1ヒットレスローリングAPアップグレード」手順の詳細（手順とコマンドを含む）については、このドキュメントを参照してください。

現在SMUまたはAPSPがインストールされている場合はどうなりますか（SMUまたはAPSPがインストールされている場合）。

次のリリースにアップグレードする前に、現在インストールされているSMUまたはAPSPパッチを削除する必要はありません。

毎回ROMMONをアップグレードする必要がありますか。

ROMMONバージョンはIOS-XEバージョンに関連しないため、それほど一般的ではありません。ROMMONの変更点は、https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_upgrade_fpga_c9800.html#id_132283に記載されています。

IOS-XEのアップグレードでは、ROMMONのアップグレードは必須ではありません。ただし、新しいIOS-XEリリースをインストールするには、ROMMON 17.7以降を実行する必要があります。最新のIOS-XEリリースにアップグレードすると、古いROMMONが機能しなくなる可能性があります。

ROMMONバージョンのすべての変更が解決済みの警告に記載されているわけではないことに注意してください。これは、文書化されていない内部的な機能拡張と修正があるためです。

参考資料

• 17.12.Xコンフィギュレーションガイド
• ISSUアップグレード
• N+1ヒットレスローリングAPアップグレード