アップグレード障害の影響を受ける17.12上のCatalyst APの検証と回復

はじめに

このドキュメントでは、アクセスポイント(AP)がCisco Bug ID CSCwf25731およびCSCwf37271の影響を受ける場合の検証および回復手順について説明します。

対話型支援

CCOクレデンシャルを使用してログインすると、Cisco AI Assistant for Supportにより、このバグがお客様のネットワークに適用可能かどうか、また、適用可能であれば回復オプションを判別するために、このバグが対話式に判別されます。開始するには

1. ドキュメントの右下隅にあるCisco AI Assistant for Supportアイコンをクリックします。
   • 
2. シスコのクレデンシャルを使用してログインします。
3. ログインしたら、ブラウザのタブまたはドキュメントを更新します。
4. このドキュメントに関する質問を開始するには、右下隅にあるボットアイコンをクリックします。
   
   • 

最良の結果を得るには、簡単な質問から始めて、徐々に複雑さを増やします。回答に問題がある場合は、親指ダウンアイコンをクリックしてフィードバックを送信してください。Cisco AI Assistant for Supportの解答が不明確な場合は、常にこのドキュメントを参照できます。

CONTEXT

現在17.12.4/5/6/6aを実行しているシステム、またはこれらのバージョンを相当期間実行していたシステムにアップグレードやAPSPを適用すると、特定の条件下で、該当するアクセスポイントモデル（該当するアクセスポイントのリストを参照）がブートループに陥る可能性があります。これは、アクセスポイントのストレージ上のディスク領域が不足しているためにイメージのインストールが失敗したことが原因です。これは日々の運用やSMUには影響しませんが、ISSU、フルコントローラコードのアップグレード、またはAPSPのインストールの際には重大なリスクとなります。これは、これらの手順にはアクセスポイント(AP)のイメージのアップグレードが含まれるためです。

設定の回避策が存在しないため、追加のプロセスに従う必要があり、このドキュメントで説明されている必須のアップグレードプレチェック手順が必要になります。

これを解決するには、アクセスポイント(AP)がアップグレードを試みる前に、特定のAPSPバージョンの修正（次の「修正済みコード」表に示す）をWLCにインストールする必要があります。あるいは、すでに以降のリリースに移行していて、該当するバージョンのいずれかを実行している場合は、クリーンアップAPSP（17.15.4dおよび17.18.2で使用可能）を使用します。システム履歴が不明な場合でも、影響を受けるバージョンが環境内に存在する場合は、アップグレードまたはAPSPのインストールの前にストレージチェックを実行することを強く推奨します。

根本原因の詳細

17.12.4 ～ 17.12.6aを実行しているアクセスポイントは、永続的なログファイル/storage/cnssdaemon.logを生成するライブラリのバグの影響を受けます。このファイルは1日に5 MBずつ増加し、リブートしても削除されず、最終的にデバイスのストレージ領域が使い果たされます。その結果、アクセスポイント(AP)がブートパーティション1(Part1)から実行されていて、ブートパーティション2(Part2)がログファイルのためにいっぱいになっている場合、ブートパーティション2に新しいイメージを保存できないため、アップグレードプロセスは失敗し、ブートループが発生する可能性があります。これを防ぐには、このドキュメントの手順を実行してストレージをクリアするか、アクセスポイントがパーティション2から起動したことを確認してから、アップグレードを実行する必要があります。

影響を受けるコードとアクセスポイント

影響を受けるアクセスポイント

この問題が発生する可能性があるのは、次のアクセスポイントモデルだけです。ネットワークがこれらの特定のモデルを使用しない場合、お客様の環境は影響を受けないため、これ以上の対策は必要ありません。

• Catalyst 9124(I/D/E)
• Catalyst 9130(I/E)
• Catalyst 9136I
• Catalyst 9162I
• Catalyst 9163E
• Catalyst 9164I
• Catalyst 9166(I/D1)
• Catalyst IW9167(I/E)

影響を受けるコード

ネットワーク全体でこれを確認するには、すべてのWLCから次のコマンドを実行し、WLCに存在するコードが下の表にリストされているかどうかを確認します。

WLC# show version | in Version

または、アクセスポイントから同じことを実行することもできます。出力をチェックして、プライマリイメージまたはバックアップイメージのいずれかで、表に示されている影響を受けるイメージが実行されているかどうかを確認します。

AP# show version | in Image

コントローラ影響コード	アクセスポイントの影響を受けるイメージ
17.12.4	17.12.4.0 ～ 17.12.4.212
17.12.5	17.12.5.0 ～ 17.12.5.208
17.12.6/6a	17.12.6.0 ～ 17.12.6.200

固定コード

次の表に、この不具合の修正が含まれているWLCソフトウェアのバージョンと対応するAPSP(Access Point Service Pack)を示します。以下に示すバージョンについては、このドキュメントの作成時点でAPSPのインストールを通じてのみ修正プログラムを利用できます。

コントローラおよびAPSP固定コード	アクセスポイントの固定イメージ
17.12.4 + APSP13	17.12.4.213
17.12.5 + APSP9	17.12.5.209
17.12.6a + APSP1	17.12.6.201
17.12.7a	17.12.7.13
17.15.3 + APSP12	17.15.3.212
17.15.4b + APSP6	17.15.4.206
17.15.4d + APSP1	17.15.4.225
17.15.5	17.15.5.36
17.18.1 + APSP3	17.18.1.203
17.18.2 + APSP1	17.18.2.201

アップグレードパスとバグの適用性

次の表を使用して、現在のWLCとアクセスポイントソフトウェアバージョンがこの不具合に該当するかどうか、およびどのようなアップグレード手順を実行するかを判断してください。現在の展開が、「バグ対応およびアップグレードパス」表に記載されたリリースのいずれかに一致する場合は、以降のアップグレードを行う前に、「アップグレードの事前確認」セクションで説明されているストレージ事前確認を行う必要があります。

バグは該当せず、アップグレードパス

次の表は、使用しているWLCとアクセスポイントがこの不具合に該当しないかどうかを示しています。

現在のコード	ターゲットコード	バグの適用性	アップグレード前：事前チェックが必要	ターゲット/アップグレードパス	アップグレードの事前チェック	注釈
17.3.x / 17.6.x / 17.9 x	17.12.x	いいえ	いいえ	17.12.4 + APSPx 17.12.5 + APSPx17.12.6a + APSPx17.12.7	いいえ	インストール先のリリースノートを確認
17.9.x	任意(17.12.4/5/6/6aを除く)	いいえ	いいえ	アップグレード先のパスに従う	いいえ	17.9.1から。5への直接アップグレードはサポートされていません。詳細はリリースノートを参照してください。17.9.6以降を使用してください
17.12.1 ～ 17.12.3	任意(17.12.4/5/6/6aを除く)	いいえ	いいえ	アップグレード先のパスに従う	通常のプロセス	インストール先のリリースノートを確認
17.15+新規導入	[Any]	いいえ	いいえ	[Any]	いいえ
17.18.+新規導入	[Any]	いいえ	いいえ	[Any]	いいえ

バグ対応およびアップグレードパス

次の表に、ご使用のWLCとアクセスポイントがこの不具合に該当するかどうかを示します。

現在のコード	ターゲットコード	バグの適用性	アップグレード前：事前チェックが必要	ターゲット/アップグレードパス	アップグレードの事前チェック	注釈
17.12.4/5/6/6a	17.12.x（4、5、6、6aなど）、APSP	Yes	はい：「アップグレードの事前チェック」セクションを参照してください	17.12.4 + APSP、17.12.5 + APSP、17.12.6a + APSP、17.12.7	Yes	修正済みのAPSPをインストールした後は、将来の17.12アップグレードのために追加の事前確認は必要ありません
17.12.4/5/6/6a	17.15.x / 17.18.x	Yes	はい：「アップグレードの事前チェック」セクションを参照してください	それぞれの17.12.x APSPをアップグレードした後、17.15.x + APSPまたは17.18.x + APSPにアップグレード	最初の17.12 APSPアップグレードでは「はい」で、それ以降のアップグレードでは「いいえ」です。
任意のリリース。ただし、以前のイメージは17.12.4/5/6/6a	17.15.x	Yes	はい：「アップグレードの事前チェック」セクションを参照してください	17.15.x + APSP	Yes
任意のリリース。ただし、以前のイメージは17.12.4/5/6/6a	17.18.x	Yes	はい：「アップグレードの事前チェック」セクションを参照してください	17.18.x + APSP	Yes

アップグレードの事前確認

アクセスポイントがコードまたはAPSPのインストール用にパーティション2（パート2）に十分な空き領域を確保するには、次の手順に従ってストレージスペースを安全に回復する必要があります。

1. 特定：手動または自動のプレチェックを実行して、バグに適用できる特定のアクセスポイントを特定します。自動プレチェックが強く推奨されます。
2. リカバリ：パート2でスペースの空きというフラグが付いているアクセスポイントについては、「スペースのリカバリ」セクションで説明するリカバリ手順に従ってください。
3. 確認：事前チェックを再実行して、すべてのデバイスが正常であり、パート2の空き領域の問題が解決されていることを確認します。
4. アップグレード：「修正済みコード」セクションに記載されている修正済みAPSPへのアップグレードを続行します。

2つの事前確認方法があります。

• 手動
• 自動化

推奨される方法は、時間を節約し、人的エラーを回避できる自動化方式です。

手動による事前確認

1. WLCでPrimaryおよびBackup imageの列を確認すると、アクセスポイントで該当するリリースが稼働しているかどうかを確認できます（上記の「該当コード」セクションを参照）。

WLC# show ap image
Total number of APs  : 4

AP Name             Primary Image          Backup Image            Predownload Status   Predownload Version  Next Retry Time   Retry Count   Method
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap117.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap217.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap317.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap417.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A

また、次のコマンドを実行して両方のイメージパーティションを確認することにより、アクセスポイントレベルで同様の検証を直接実行することもできます。

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209

アクティブなブートパーティションを確認します。「show boot」コマンドを使用して、「BOOT path-list」がpart1を指していることを確認します。これは、アクセスポイントが現在プライマリパーティションから実行されており、問題を引き起こす可能性があるセカンダリパーツ(part2)にアップグレードしようとしていることを示します。

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1

2. /dev/ubivol/part2パーティションをチェックして、現在のファイルシステムの使用状況を確認します。「Available」列に85M未満と表示された場合、パーティションにはAPSPをインストールするための十分な領域がないため、アップグレードが失敗し、ブートループが発生する可能性があります。

AP# show filesystems
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                880.9M         0    880.9M   0% /dev
/sysroot                883.8M    219.6M    664.1M  25% /
tmpfs                     1.0M     56.0K    968.0K   5% /dev/shm
tmpfs                   883.8M         0    883.8M   0% /run
tmpfs                   883.8M         0    883.8M   0% /sys/fs/cgroup
/dev/ubivol/part1       372.1M     79.7M    292.4M  21% /part1
/dev/ubivol/part2       520.1M    291.3M    228.9M  56% /part2

3. 両方のパーティションのイメージの整合性を検証して、破損していないことを確認します。プライマリイメージとバックアップイメージの両方のすべてのフィールドのステータスが「Good」である必要があります。そうでないフィールドが表示される場合は、プロセスを停止して、「TACサービスリクエストをオープンするタイミング」のセクションに進んでください。

AP# show image integrity
/part1(Backup) 17.12.5.209
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good
/part2(primary) 17.12.5.41
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good

part1からブートし、/dev/ubivol/part2で使用可能な85 M未満のアクセスポイントをリストします。これは、これらのアクセスポイントでスペースの回復が必要になるためです。このドキュメントの「リカバリ」セクションに移動してください。

自動プレチェック

自動プレチェックを行うには、WLANPollerツールを使用します。このツールを使用すると、すべてのアクセスポイントに対して必要なコマンドを同時に実行して、影響を受けるアクセスポイントを特定できます。このツールは、次のリンクから直接ダウンロードできます。https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/

手順：

1.Extraction:WLANPollerファイルを任意のディレクトリに解凍します。解凍すると、次のような名前の2つのディレクトリと1つのアプリケーションが表示されます。

• data
• confd
• WlanPollerGUI

2. 設定:WlanPollerGUIアプリケーションを起動し、次のように設定します。

操作タイプ:WLCおよびAPを選択します。Access PointOnlyオプションの場合は、アクセスポイントをカンマ区切り形式（192.168.166.105、Timpadil9166など）でリストした「.txt」ファイルをアップロードします。 次に、Enter Credentialsをクリックします。

Access Point Onlyモードの場合、「.txt」ファイルが次の例に従っていることを確認します。

クレデンシャル:WLC IPアドレスとクレデンシャルを入力します。アクセスポイントのユーザ名、パスワード、およびアクセスポイント加入プロファイルのイネーブルパスワードを含めます。Saveをクリックし、続いてProceedをクリックします。

ワークフロー:Access Point Flash Checkerワークフローを選択して、必要な診断コマンドを実行します。次に、Proceedをクリックします。

CLIコマンドリスト：この手順は自動的にスキップされます。必要なコマンドリストは、アクセスポイントのフラッシュチェッカーワークフロー（手順3）にすでに含まれています。

アクセスポイントフィルタ：このオプションの手順では、特定のサイトでフィルタリングできます。これを使用する場合は、このボックスをオンにしてSite Tagの名前を入力します（大文字と小文字は区別されます）。 終了するか、このステップをスキップした場合は、Previewをクリックします。

プレビュー：ここでWLANPollerの設定を確認します。必要なCLIコマンドは、前のワークフローステップで入力されたものです。詳細を確認した後、Confirm and Start WLANPollerをクリックしてSSH接続とデータ収集を開始します。

3.結果：このツールは、必要なコマンドを実行するためにアクセスポイントへのSSH接続を確立します。結果が表示され、復旧が必要なアクセスポイントを特定できます。このデータのレコードが、WLANPoller抽出ディレクトリ内のdataサブフォルダに自動的に保存されます。

結果の事前確認

スキャンに基づいて、WLANPollerは該当するアクセスポイントを次のいずれかのオプションに分類します。

• Safe state but Access Point has buggy image in the back up partition：アクセスポイントは現在アップグレードしても安全です。コード/APSPのインストールを続行できます。ただし、バックアップパーティションには影響を受けやすいイメージが引き続き含まれることに注意してください。
• イメージパーティションのスワップによる回復：アクセスポイントは現在パーティション1からブートされていますが、パーティション2にはアップグレードに必要なスペースがありません。アクセスポイントのブートパーティションのスワップが必要です。
• devshellを使用した回復：どちらのパーティションにも新しいコードまたはAPSPをインストールするための十分な領域がないため、アクセスポイントはdevshellによる回復を必要とします。
• このAPのイメージ整合性チェックに失敗しました：パーティション1またはパーティション2のイメージで整合性チェックに失敗しました。手動による介入が必要になる場合があります。

リカバリ

事前チェックの結果に基づいて、ネットワークに最適な適切な回復オプションを次のように選択できます。

結果	回復オプション
安全な状態ですが、アクセスポイントのバックアップパーティションにバグのあるイメージがあります	「informational」。コード/APSPのインストールに進むことができます。
イメージパーティションのスワップによる回復	次の 4 つのオプションがあります。 1. アクセスポイントのコアファイルを削除します。 2. アクセスポイントを工場出荷時の状態にリセットする。 3. アクセスポイントイメージのブートパーティションのスワップ。 4. cnssdaemon.logファイル(Access Point devshell)を削除します。 環境とリソースの可用性に最適な回復オプションを選択します。
devshellを使用したリカバリ	選択肢が 2 つあります。 1. cnssdaemon.logファイル(Access Point devshell)を削除します。 2. アクセスポイントを工場出荷時の状態にリセットする。 環境とリソースの可用性に最適な回復オプションを選択します。
このアクセスポイントのイメージ整合性チェックに失敗しました	次の手順に従います：TACサービスリクエストをオープンするタイミング

アクセスポイントの現在の状態に応じて、2つのリカバリパスがあります。アクセスポイントの状態は次のとおりです。

1. パーティション2の空き領域が少ない:この現象は、コード/APSPのインストールを試行するアップグレード前の段階（アップグレードの事前確認中）で発生します。
2. Access Point bootloop:これは、コード/APSPのインストールがスペース不足にもかかわらず試行された場合に、アップグレード後に発生します。

アクセスポイントの可能性のある各状態の詳細な回復手順を次に説明します。

パーティション2の空き領域が少ない

アップグレードの事前チェックで、パーティション1でブートしており、パーティション2に十分なスペースがないアクセスポイントが特定された場合は、次のいずれかの方法を使用してパーティションのスペースを確保します。

• アクセスポイントのコアファイルの削除：アクセスポイントはコアダンプを/dev/ubivol/part2に保存します。これらのファイルが存在する場合は、削除することで十分な空き領域が確保される可能性があります。削除後、アップグレードプレチェックを再実行して、使用可能なスペースがインストール要件を満たしていることを確認する必要があります。
• アクセスポイントの初期設定へのリセット：初期設定へのリセットを実行すると、アクセスポイントはデフォルト設定に戻ります。このプロセスにより、ストレージからcnssdaemon.logファイルが一時的にクリアされます。通常は、コード/APSPを正常にインストールするために十分な領域がパーティション2（パート2）に提供されます。
• cnssdaemon.logファイル(Access Point devshell)の削除：このプロセスには、Access Points devshellにアクセスしてcnssdaemon.logファイルを手動で削除することが含まれます。 この操作を行うには、管理者権限が必要であり、TACと連携してdevshell環境に入る必要があります。
• ブートパーティションのスワップ：パーティション2(part2)にコード/APSPをインストールするのに十分な空き容量がなく、機能イメージがすでに含まれている場合は、アクセスポイントをpart2からブートし、通常は使用可能な空き容量があるパーティション1(part1)にインストールできます。

要件を理解できるように、各オプションの詳細を確認してください。お客様のネットワーク環境と運用ニーズに最適な方法を選択してください。

アクセスポイントのコアファイルの削除

コアファイルは、SSH経由で各アクセスポイントにアクセスして手動で削除できます。または、WLANPollerを使用してこのプロセスを自動化し、複数のアクセスポイントに対して一括モードで同時に削除を実行することもできます。

手動モード

SSH経由で各アクセスポイントにアクセスし、次のコマンドを実行します。

AP# delete /force cores
AP# reload
Proceed with reload? [confirm] yes

自動モード

WLANPollerアプリケーションを起動し、次の手順を実行します。

操作タイプ：操作タイプWLCおよびAPを選択します。

クレデンシャル:WLCとアクセスポイントのクレデンシャルを入力します。

ワークフロー：選択内容をカスタムCLIコマンドに更新し、[続行]をクリックします。

CLIコマンドリスト：次のアクセスポイントコマンドを、表示されたとおりに入力します。Saveをクリックし、次にProceedをクリックします。

Access Point Filters：環境に特定のフィルタが必要でない限り、すべてのチェックボックスをオフのままにして、Previewをクリックします。

Preview：サマリーを確認し、Confirm and Start WLANPollerをクリックします。

結果：対象となるすべてのアクセスポイントに対するWLANPollerの実行が正常に完了したことを確認します。

回復後、そのセクションの説明に従ってアップグレードのプレチェックを繰り返します。影響を受けるアクセスポイントで引き続き使用可能なスペースが少ないかどうかを確認します。その場合は、使用しているリソースに適した次のオプションのいずれかに進みます。これらのオプションがリストから削除されている場合は、回復が成功し、これらのアクセスポイントのコードまたはAPSPに進むことができます。

アクセスポイントの初期設定へのリセット

アクセスポイントを工場出荷時のデフォルトにリセットすると、cnssdaemon.logファイルが一時的に削除されます。コード/APSPのインストールを確実に成功させるには、工場出荷時設定へのリセットから48時間以内にコード/APSPのインストールに進んでください。

アクセスポイントを工場出荷時の状態にリセットするには、次の3つの方法があります。

• WLC経由（CLIまたはGUI）

• アクセスポイントのCLIを使用して、

• アクセスポイントの物理リセットボタンを使用する。

WLC CLIを使用

WLC# clear ap config <APNAME> keep-ip-config

WLC GUIを使用

Configuration > Wireless > Access Pointsの順に移動します。目的のアクセスポイントを選択し、Advanced > Set to Factory Defaultの順に選択します。Clear Config except Static IPオプションを選択し、Update & Apply to Deviceをクリックします。

アクセスポイントのCLIを使用

AP# capwap ap erase all 
WARNING :" capwap ap erase all" is altered to perform DATA WIPE on COS AP.
The following files will be cleared as part of this process
1) Config ,Bak config files
2) Crashfiles
3) syslogs
4) Boot variables
5) Pktlogs
6) Manually created files
Are you sure you want continue? [confirm] yes
AP# reload 
Proceed with reload command (cold)? [confirm] yes

アクセスポイントモードボタンを使用

1. アクセスポイントを電源から取り外します。

2. Modeボタンを押し続けます。

3. ボタンを押し続けながら電源を接続し直します。

4. アクセスポイントのステータスLEDが赤色に点灯したら、Modeボタンを10秒間押し続けます。

5. ボタンを放します。

6. アクセスポイントが工場出荷時のデフォルト設定でリブートします。

cnssdaemon.logファイルの削除(Access Point devshell)

Technical Assistance Center(TAC)は、該当するアクセスポイント上のdevshellから直接cnssdaemon.logファイルをクリアすることで、手動でリカバリを実行できます。 影響の規模に応じて、次の2つの方法があります。

• 影響を受けるアクセスポイントの少数：影響を受けるアクセスポイントの数が少ない場合、TACは次の2つの方法のいずれかを使用して処理を進めることができます。

  • devshellへの手動アクセス:devshell経由で各アクセスポイントに個別にアクセスし、cnssdaemon.logファイルを手動でクリアします。

  • 自動（バルク）devshellアクセス:RADKitツールを使用して、影響を受けるすべてのアクセスポイントに対するcnssdaemon.logファイルのクリーンアッププロセスを自動化します。

• 影響を受ける多数のアクセスポイント:TACではRADKitツールを使用します。これにより、影響を受けるすべてのアクセスポイントへの一括devshellアクセスが自動化され、クリーンアッププロセスが効率的に実行されます。

次のリンクから、RADKitのダウンロードとインストールの手順にアクセスしてください。

• RADKitダウンロード
• RADKitのインストール

RADKit経由でアクセスポイントのcnssdaemon.logファイルを削除するには、すべてのアクセスポイントがインベントリにリストされていることを確認します。これは管理者専用のタスクであり、TACによってリモートで実行することはできません。アクセスポイントをRADKitインベントリに一括追加するには、次の手順を使用します。

1. RADKit内のWLC:WLCがRADKitインベントリにすでに追加されていることを確認します。このプロセスのサポートが必要な場合は、RADKitの公式ドキュメントの「デバイスの追加」セクションここを参照してください

2. WLCインベントリアイコン: Devicesタブで、WLCを見つけて、Actions列のInventoryアイコンをクリックします。

3. Bulk Import:RADKitへのアクセスポイント追加プロセスを開始するには、Bulk Importボタンを選択します。

4. 一括設定：cnssdaemon.logファイルの削除が必要なすべてのアクセスポイントのチェックボックスをオンにします。Add to Cartアイコン（プラス記号の付いたカート）をクリックして、Bulk Editボタンを選択します。

5. Enable Terminal & Configure SSH:Cart Bulk EditorでDevice Typeにチェックマークを入れて、Cisco AP OSを選択します。Terminalトグルを有効にして、アクセスポイントにSSH設定を許可します。

6. SSHクレデンシャルの設定:SSH（パスワード）をクリックし、アクセスポイントのクレデンシャルを入力します。 Enable Passwordチェックボックスを選択して、パスワードを入力します。 Apply & Clearをクリックしてこれらの設定を保存し、ウィンドウを閉じます。SSHがWLCでAP Join Profileを介して有効になっていることと、ユーザ名とパスワードが最新で正しいことを確認します。

7. リモートユーザの追加：TACのサービスリクエストに割り当てたエンジニアのCisco CCO IDを、RADKitの公式ドキュメントのリモートユーザの追加手順ここを参照して追加します。

8. Targeted Access Point List:ファイル内の該当するアクセスポイントの正確な名前（注：大文字と小文字は区別されます）を収集し、そのファイルをTACサービスリクエストにアップロードします。

アクセスポイント名を使用してセットアップとファイルのアップロードを行った後、Cisco TACには、cnssdaemon.logファイルの一括削除を実行するために必要なRADKit経由のリモートアクセスが提供されます。

アクセスポイントイメージのブートパーティションのスワップ

ブートパーティションの切り替えは、アクセスポイントごとに手動でアクセスポイントを設定するか、WLANPollerを使用してアクセスポイントから一括してアクセスして自動化できます。

手動

アクセスポイントにSSHで接続し、次のコマンドを実行します。

AP# config boot path 2
AP# reload
Proceed with reload? [confirm] yes

自動化

WLANPollerを使用して、さまざまなアクセスポイントに対してboot partコマンドを一括で実行します。

1. 影響を受けるアクセスポイントの分離：影響を受けるアクセスポイントがWLCに接続されていないことを確認します。
   • アクセスポイント参加プロファイルでSSHが有効になっており、アクセスポイントがSSHアクセス可能であることを確認します（またはコンソールを使用します）。
   • アクセスポイントがWLCに接続されていないが、アクセスポイントへのSSHアクセスが可能であることを確認します。これを行うには、ゲートウェイにACLを配置するか、アクセスポイントを隔離VLANに移動します。アクセスポイントがWLCにアクセスすると、アクセスポイントはブートパーティション1（パート1）に戻り、影響を受ける状態に戻ります。

2.ブートパス2を設定し、影響を受けるアクセスポイントをリブートする：影響を受けるアクセスポイントにコマンドラインを介してブート部分を1から2に変更するようにWlanPollerを設定し、その後リブートします。

Operation Type：オプションAP Onlyを選択してから、テキストエディタ（できれば）でアクセスポイントのIPアドレスと名前（大文字と小文字を区別する）を追加し、Browseをクリックして、アクセスポイントのIPアドレスと名前を含むファイルを選択します。次にEnter Credentialsをクリックします。

アクセスポイントリストの形式：

操作タイプの選択：

クレデンシャル：アクセスポイントのクレデンシャルを入力し、SaveをクリックしてからProceedをクリックします。

ワークフロー:カスタムCLIコマンドを選択し、続行をクリックします。

CLIコマンドリスト：アクセスポイントがpart2でブートし、リロードするようにコマンドを設定します。Saveをクリックし、次にProceedをクリックします。

プレビュー：アクセスポイントに対して実行される2つのコマンドがプレビューに表示されます。Confirm and Start WlanPollerをクリックします。

3. Upgrade：現在のコードに必要なAPSPをWLCにインストールします。コードをアップグレードする場合は、新しいコードに移動して、APSPもインストールされていることを確認します。

4.再接続：コントローラのアップグレードが完了したら、アクセスポイントとWLCの間の通信ストッパを取り外します。アクセスポイントがWLCに接続し、新しいイメージと修正されたイメージがブートPart1に自動的にダウンロードされます。

アクセスポイントのブートループ

最初にアップグレードの事前確認に従わずにコード/APSPをインストールした場合、アクセスポイント(AP)がブートループに陥った場合、次の2つのオプションがあります。

1. 「アクセスポイントの工場出荷時のリセット」セクションで説明されているように、モードボタンでアクセスポイントを工場出荷時の状態にリセットします。
2. コンソールアクセスを取得し、TACがアクセスポイントの回復に進むことができるようにTACケースをオープンします。

TACサービスリクエストをオープンするケース

次のいずれかの状況が発生した場合は、TACサービスリクエストをオープンします。

• リカバリ失敗：リカバリ手順を環境に実装できない場合、またはリカバリ手順が失敗している場合。
• 整合性の問題：手動または自動の事前チェックでは、「Image Integrity Check: Bad」が返されます。
• ストレージの枯渇：アップグレード/APSPのインストール後もパーティション「/dev/ubivol/part2」の使用率が非常に高くなっています。

FAQ

Q：この問題はフルコードのアップグレードにのみ該当しますか。それとも、APSPのインストールにも影響しますか。

A：この問題は両方のシナリオに該当します。ご使用の環境がこのバグの基準を満たしている場合、この問題はコードのフルアップグレードまたはAPSPのインストール（バグ修正を含むAPSPを含む）中に発生する可能性があります。 「アップグレードの事前確認」セクションを完了して、アップデートまたはAPSPを適用する前に回復手順を実行する必要があるかどうかを判断してください。

Q:WLCとアクセスポイントが17.9.x（またはそれ以前）にあり、17.12.xにアップグレードする必要があります。どうすればよいのですか。

A:17.9.xから17.12.xへの直接アップグレードを実行できます。ただし、ご使用のアクセスポイントモデルがこの不具合の影響を受けやすい場合は、アップグレードの直後に推奨されるAPSPを必ずインストールしてください。

Q:WLCとアクセスポイントが17.9.x（またはそれ以前）にあり、17.15.x以降にアップグレードする必要があります。

A:次の2つのシナリオが考えられます。

• 直接アップグレード：ご使用の環境で直接アップグレードが可能な場合（ターゲットコードのリリースノートで確認してください）、アップグレードに進んでからそのターゲットコードのAPSPをインストールします。
• 中継アップグレード：アップグレードパス(たとえば、17.9.x → 17.12.x → 17.15.x)に従う必要がある場合、シーケンス全体を同じ日に17.15.xに完了することをお勧めします。cnssdaemon.logファイルは1日に5 MBずつ大きくなるため、アップグレードを完了するとすぐに、ファイルが重要なサイズに達しなくなります。当日アップグレードが不可能な場合は、最終的に17.15.xに進み、それぞれのAPSPをインストールする前に、17.12.x段階でAPSPをインストールする必要があります。

Q：すでに17.15.xを使用しています。つまり、私はこの不具合の影響を受けていないということですか。

A:必ずしも必要ではありません。アクセスポイント(AP)でバージョン17.12.4、17.12.5、または17.12.6/6a(9800-L/40/80/CL)を以前実行していた場合、問題のあるログファイルはすでに生成されており、ストレージに残っている可能性があります。「アップグレードの事前確認」セクションに従って、残ったファイルを確実にクリーンアップすることを強くお勧めします。

Q: 17.15で最初にサポートされた9800-M、9800-H1、または9800-H2プラットフォームを使用していますが、影響を受けますか。

A:次の2つのシナリオが考えられます。

• WLCに初めて加入した場合：アクセスポイントが最初のコントローラとして9800-M/H1/H2に加入している場合、影響はありません。
• 以前に加入していたWLC：これらのアクセスポイントが9800-M/H1/H2に移行する前に、影響を受けるバージョン(17.12.4/5/6/6a)を実行する別のコントローラに以前に加入していた場合、問題のあるファイルを所有している可能性があります。この場合は、「アップグレードの事前確認」セクションに従ってください。

Q:ラボのテスト用と段階的なアップグレード用に別々のWLCがありますが、どのように処理すればよいですか。

A:環境内のすべてのWLCで適切なAPSPが実行されていることを確認します。cnssdaemon.logファイルは1日に5 MBずつ増大するため、影響を受けるコードを実行するWLCに加入しているアクセスポイントは、たとえ一時的にテストを行う場合でも、この不具合の影響を受ける可能性があります。

更新履歴

改定	発行日	コメント
4.0	24-Mar-2026	リカバリメカニズムを更新し、WLANポーラーを使用した自動化の改善を含めました。
3.0	27-Feb-2026	FAQと追加のリカバリシナリオを追加
2.0	23-Feb-2026	アップグレードパスの適用性に関する詳細を追加
1.0	30-Jan-2026	初版