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

はじめに

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

CONTEXT

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

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

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

根本原因の詳細

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

#show version | in Version

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

#show version | in Image

注：一般に、ネットワークが稼働しておらず、17.12.4、17.12.5、17.12.6/6aが稼働していない場合、この問題は該当しません。

固定コード

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

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

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

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

次の表は、使用しているWLCとAPがこの不具合に該当しないかどうかを示しています。

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

次の表に、ご使用のWLCとAPがこの不具合に該当するかどうかを示します。

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

ご使用の環境がこのバグの影響を受ける場合は、安全な回復とアップグレードを行うために、次の必須ステップに従ってください。

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

手動による事前確認

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

9800-l#show ap image
Total number of APs  : 4

Number of APs
        Initiated                  : 0
        Downloading                : 0
        Predownloading             : 0
        Completed downloading      : 0
        Completed predownloading   : 0
        Not Supported              : 0
        Failed to Predownload      : 0
        Predownload in progress    : No

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レベルで同様の検証を直接実行することもできます。

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209
Primary Boot Image Hash: 93ef1e703a5e7c5a4f97b8f59b220f52d94dd17c527868582c0048caad6397a9f3526c644f94a52bb70a104385690065ad0d652aa3fed607f24920d7e5ed5b5c
Backup Boot Image Hash: 4bbe4a0d9edc3cad938a7de399d3c2e08634643a2623bae65973ef00deb154b8eb7c7917eeecdd46e3e2ddc7be80139475e19fb3040b08aa715de196a733252b
1 Multigigabit Ethernet interfaces

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

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:

2. /dev/ubivol/part2パーティションをチェックして、現在のファイルシステムの使用状況を確認します。「Use%」が100%に近い場合は、パーティションが使い果たされているため、アップグレードが失敗し、ブートループが発生する可能性があります。

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

自動プレチェック

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

手順：

1.抽出:WLANポーラーファイルを任意のディレクトリに抽出します。

2.設定：次のパラメータで「config.ini」ファイルを更新し、特定のクレデンシャルとコントローラのIPアドレスを入力したことを確認します。

wlc_type: 2
mode: ssh
ap_mode: ssh

; set global WLC credentials
wlc_user: 
wlc_pasw: 
wlc_enable: 

; set global AP credentials
ap_user: 
ap_pasw: 
ap_enable: 

[WLC-1]
active: True
ipaddr: 
mode: ssh

3. コマンドリストの準備:「cmdlist_cos」と「cmdlist_cos_qca」のデフォルトコンテンツをコメントアウト（ハッシュ記号「#」を追加）してから、両方のファイルに次のコマンドを追加します。

# snippet to download the Debug image on COS APs
# show version | in Compiled
# archive download-sw /reload tftp:///
# 
show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity

4. 実行:「。\wlanpoller.exe」を使用してツールを実行します。 このツールはすべてのアクセスポイントにSSHで接続し、コマンド出力を収集します。

5.データの取得 – 完了したら、新しく作成された/dataフォルダに移動します。サブディレクトリを移動して、個々のAP出力ファイルを含む最終フォルダに移動します。

6. 分析：公式のボックスリンクから「ap_detection_script.py」をダウンロードし、「data」フォルダに配置して実行します。

7.結果の確認：生成された「Status_check_results.log」を開き、問題のある状態のAPのリストを表示します。これらのデバイスでは、アップグレードを開始する前にリカバリ手順（下記の「リカバリ」セクションで説明）が必要です。次に、結果の解釈方法を説明します。

設計上、APはパーティション1またはパーティション2からブートできます。一方のパーティションがアクティブな場合、もう一方のパーティションはイメージまたはAPSPのダウンロードに使用されます。論理ストレージパーティションはパーティション2に永続的にマップされており、変更できません。この問題の影響を受けるのは、現在パーティション1からブートしているアクセスポイントだけです。これを確認するには、「current_boot_partition_check」列をチェックして、APで使用されている現在のパーティションを確認します。例：

上記の例から、3つのAPから次のように結論付けることができます。

• AP名：Test AP1(Action Required):APの「current_boot_partition_check」列にpart1「True Perspective」が表示されている場合は、「part2_mem_utilization_check」列を確認する必要があります。この列にも「True Persibility」と表示されている場合は、APが影響を受けます。

  • 例：テストAP1が影響を受け（パート1およびパート2の空き領域での起動：51.9 MB）、回復が必要です。

• AP名：Test AP2（パーティション1）:APでpart1「True Persibility」が表示されているが、「part2_mem_utilization_check」で「False Not Persibility」が表示されている場合、APは安全です。

  • 例：テストAP2は、パーティション2（パート2）に十分な領域があるため、影響を受けませんが、cnssdaemon.logファイルがAPに引き続き存在するため、今後の問題に対処するためにAPSPをインストールすることをお勧めします。

• AP名：テストAP3（パーティション2）:APの「current_boot_partition_check」列にpart2「False Not Perspective」と表示されている場合、影響はありません。これ以上のチェックは必要ありません。

注:「True/False Persibility」ステータスの横の「part2_mem_utilization_check」列に表示される数値は、パーティション2の空き容量を表します。

• いずれかのアクセスポイント：「image_integrity_check」列の下に「Image Integrity Check: Failed」と表示されているAPがある場合は、TACケースをオープンしてください。

リカバリ

各APの特定の状態に基づいて、スクリプトは最も効率的な回復方法を推奨します。該当するAPを特定するには、次の詳細な手順に従います。

APイメージのパーティション交換

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

2.ブートパスの設定 – 影響を受けるAPで、ブートパスをパーティション2に設定します。

AP# config boot path 2

3. Reboot：パーティション2からイメージをロードするためにAPを再起動します。

AP# reload

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

5.再接続 – コントローラのアップグレードが完了したら、APとWLC間の通信ストッパーを取り外します。APはWLCに接続し、ブートPart1で新しい修正済みイメージを自動的にダウンロードします。

6. ダブルチェック：修正済みリリースにアップグレードした後、バックアップスロットにまだバグイメージが含まれていないことを確認するためにAPの両方のパーティションを確認します。

7. メンテナンス：長期的な安定性を維持し、将来のブートループを防止するために、既知の正常なイメージでバックアップパーティションを上書きすることをお勧めします。小規模なグループの場合は、アーカイブ「download-sw」をAP上で直接使用します。大規模な展開の場合は、WLC APの事前ダウンロードを実行して、APイメージのアクティベーションをトリガーせずにバックアップパーティションを更新します。

APシェルアクセスリカバリ

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

• 少数の該当AP：少数の該当APについて、TACは次の2つの方法のいずれかを使用して処理を進めることができます。

  • 手動シェルアクセス:各アクセスポイントに個別にシェル経由でアクセスし、ログファイルを手動でクリアします。

  • 自動（バルク）シェルアクセス:RADKitツールを使用して、影響を受けるすべてのAPに対するクリーンアッププロセスを自動化します。

• 影響を受けるAPの数が多い:TACはRadkitツールを使用します。これにより、影響を受けるすべてのAPへの一括シェルアクセスが同時に可能になり、クリーンアッププロセスが効率的に実行されます。

注：効率性と一貫性を確保するために、APシェルアクセスの回復手順ではRADKitを使用することを推奨します。

注：Radkitをダウンロードするには、次のリンクを使用してください。Radkit最新バージョンをダウンロードしてダウンロードします。Radkitをインストールするには、次のビデオに従ってください： Radkitのインストール

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

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

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

Cisco TACはAPシェルにアクセスして、cnssdaemon.logファイルを手動でクリアし、デバイスを復元するための高度な回復操作を実行できます。

FAQ

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

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

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

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

Q:WLCとAPが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に初めて加入した場合:APが最初のコントローラとして9800-M/H1/H2に加入している場合、影響はありません。
• 以前に加入していたWLC：これらのAPが9800-M/H1/H2に移行する前に、該当するバージョン(17.12.4/5/6/6a)が稼働する別のコントローラに以前に加入していた場合、問題のあるファイルを維持している可能性があります。この場合は、「アップグレードの事前確認」セクションに従ってください。

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

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