はじめに
このドキュメントでは、Cisco Bug ID CSCwf25731
およびCSCwf37271
影響を受けるアクセスポイント
次のアクセスポイントモデルは影響を受けます。以下のモデルを使用していない場合は影響を受けず、それ以上の操作は必要ありません。
- Catalyst 9166(I/D1)
- Catalyst IW9167(I/E)
CONTEXT
17.12.4/5/6aにあるシステムから任意のリリースにアップグレードすると、特定の条件下で特定のアクセスポイントモデルがブートループに入る可能性があります。これは、ターゲットデバイスのストレージ上のディスク領域が不足しているためにイメージのインストールが失敗したことが原因です。このシナリオは、ISSU、フルコントローライメージのインストール、APSPなど、アクセスポイントに関連するアップグレード操作中にのみ発生し、通常のサービス、日常的な操作、またはSMUのインストールには影響しません。
影響を受ける可能性のあるアクセスポイントでアップグレードを実行する前に、追加の手順を実行する必要があります。この問題には回避策がなく、設定、導入タイプ、コントローラモデルに依存しません
この問題は、17.12.4より前のバージョンには影響しません。また、アクセスポイントで17.12.6aより後のリリース(17.15.xなど)が実行されており、影響を受けるバージョンがインストールされていない場合も影響を受けません。
Cisco IOS XEリリース17.12.4、17.12.5、17.12.6aについては、それぞれのAPSPの形式で修正が利用可能です。また、影響を受けるリリースを使用していて、すでに新しいバージョンにアップグレードされている導入の場合、17.15.4dと17.18.2で失われたスペースを回復するために、クリーンアップAPSPを使用できます。
いずれかの時点でネットワークが該当リリースにアップグレードされている場合、またはネットワークがそれらのバージョンを以前に使用したことがあるかどうかわからない場合は、予防策として、アップグレードの前にチェックを実行することを推奨します
根本原因の詳細
コード17.12.4 ~ 17.12.6aを実行する該当モデルのアクセスポイントでは、永続的なファイル「/storage/cnssdaemon.log」を作成します。このファイルは1日あたり5 MBまで拡張でき、そのディスクパーティション上の使用可能な領域をすべて使用できます。このファイルは再起動時にクリアされません。 パーティションが完全に使用されると、新しいファイルバージョンを保存するための重要な手順が完了しないため、アップグレードが失敗する可能性があります。
この問題は、内部コンポーネントのログの宛先を変更したライブラリの更新によって発生しました。デバイスの操作にログファイルは必要ありません
アップグレード障害が発生するのは、APがパーティション1から実行されており、パーティション2のスペースが使い果たされている場合だけです。十分な空き容量がある場合、またはAPがパーティション2から起動した場合、アップグレードは成功します
アップグレードチェック手順
WLCが現在17.12.4、17.12.5、17.12.6a上にある場合は、次の手順を実行する際に、修正を含むソフトウェアバージョンへのアップグレードが必須になります。 WLCにインストールされている他のバージョンで、アップグレードを計画している場合、次の手順に従うことを強く推奨します。
ステップ1:アクセスポイントが影響を受ける可能性があるかどうかを確認します(表1を参照)。 影響を受けない場合は、事前チェック/リカバリプロセスは不要です。最新リリースへのアップグレードに直接進むことができます。
ステップ2:影響を受ける場合は、プレチェックを実行して、プレチェックセクションで影響を受けるAPの数を識別します。
ステップ3:特定したAPで、「リカバリ」セクションに記載されているリカバリ手順を実行します。
ステップ4:事前チェックを再実行して、他のAPが影響を受けていないことを確認します。
ステップ5:修正済みバージョンの表に記載されている各APSPまたはソフトウェアバージョンへのアップグレードに進みます。
この通知がご自分に当てはまるかどうかを確認するには、次の表を参照してください。
表1:アップグレードパスの適用性
|
現在のバージョン
|
target
|
問題の適用性
|
アップグレード前に事前チェックが必要
|
ターゲット/アップグレードパス
|
アップグレードの事前チェック
|
注釈
|
|
17.3.x / 17.6.x / 17.9 x
|
17.12.x
|
いいえ
|
いいえ
|
17.12.4 + APSPx 17.12.5 + APSPx
17.12.6a + APSPx
17.12.7
|
いいえ
|
インストール先のリリースノートを確認
|
|
17.9.x
|
任意(17.12.4/5/6aを除く)
|
いいえ
|
いいえ
|
アップグレード先のパスに従う
|
いいえ
|
17.9.1から。5への直接アップグレードはサポートされていません。17.9.6以降を使用してください。
詳細については、リリースノートを参照してください。
|
|
17.12.1 ~ 17.12.3
|
任意(17.12.4/5/6a以外)
|
いいえ
|
いいえ
|
アップグレード先のパスに従う
|
通常のプロセス
|
インストール先のリリースノートを確認
|
|
17.12.4/5/6a
|
17.12.x(4、5、6aなど)、APSP
|
Yes
|
Yes
|
17.12.4 + APSPx 17.12.5 + APSPx
17.12.6a + APSPx
17.12.7
|
Yes
|
修正済みのAPSPをインストールした後は、将来の17.12アップグレードのために追加の事前確認は必要ありません
|
|
17.12.4/5/6a
|
17.15.x / 17.18.x
|
Yes
|
Yes
|
それぞれの17.12.x APSPをアップグレードしてから、17.15.x + APSPxまたは17.18.x + APSPxにアップグレード
|
最初の17.12 APSPアップグレードでは「はい」で、それ以降のアップグレードでは「いいえ」です。
|
|
|
どのリリースでも、以前のイメージは17.12.4/5/6aのいずれかでした。
|
17.15.x
|
Yes
|
Yes
|
17.15.x + APSPx
|
Yes
|
|
|
どのリリースでも、以前のイメージは17.12.4/5/6aのいずれかでした。
|
17.18.x
|
Yes
|
Yes
|
17.18.x + APSPx
|
Yes
|
|
|
17.15+
新規導入
|
[Any]
|
いいえ
|
いいえ
|
[Any]
|
いいえ
|
|
|
17.18.
新規導入
|
[Any]
|
いいえ
|
いいえ
|
[Any]
|
いいえ
|
|
注:一般に、ネットワークが稼働しておらず、過去に17.12.4、17.12.5、17.12.6aが稼働していない場合、この問題は該当しません
注:「現在」の列に明示的に記載されていない他のリリースは、推奨アップグレードパスに従います。
修正済みリリース
|
コントローラ
|
APイメージバージョン
|
|
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.15.3 + APSP12
|
17.15.3.212
|
|
17.15.4b + APSP6
|
17.15.4.206
|
|
17.15.4d + APSP1
|
17.15.4.225
|
|
17.18.1 + APSP3
|
17.18.1.203
|
|
17.18.2 + APSP1
|
17.18.2.201
|
事前チェック
ネットワークがこの問題の影響を受けやすいかどうかを確認するには、現在の手順に従います。これらの手順は概要を説明するのに役立ちますが、APの実際の検出については、「プレチェックスクリプト」の項を使用してこのプロセスを自動化してください。
- 影響を受けるリリースの場合は、プライマリイメージ列またはバックアップイメージ列でアクセスポイントイメージが一致しているかどうかを確認します。
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
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap1 17.12.5.41 17.12.4.201 None 0.0.0.0 N/A 0 N/A
Ap2 17.12.5.41 17.12.4.201 None 0.0.0.0 N/A 0 N/A
Ap3 17.12.5.41 17.12.4.201 None 0.0.0.0 N/A 0 N/A
Ap4 17.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
Primary Boot Image Hash: 93ef1e703a5e7c5a4f97b8f59b220f52d94dd17c527868582c0048caad6397a9f3526c644f94a52bb70a104385690065ad0d652aa3fed607f24920d7e5ed5b5c
Backup Boot Image Hash: 4bbe4a0d9edc3cad938a7de399d3c2e08634643a2623bae65973ef00deb154b8eb7c7917eeecdd46e3e2ddc7be80139475e19fb3040b08aa715de196a733252b
1 Multigigabit Ethernet interfaces
Any Boot Image is one of the following:
- 17.12.4.0 to 17.12.4.212
- 17.12.5.0 to 17.12.5.208
- 17.12.6.0 to 17.12.6.200
AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:
The “BOOT path-list:” should be part1, suggesting that the Backup partition is running on part2.
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
The “Use%” for “/dev/ubivol/part2” is close to 100%.
- 両方のパーティションのイメージの整合性を確認します。
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
The image integrity should be “Good” for all fields in both the partitions. If not Good open a TAC case.
次のセクションでは、すべてのAPのプレチェックプロセスを自動化するスクリプトについて説明します。
事前確認スクリプト
WLANポーラー(こちらからダウンロードできます)
ステップ1:WLANポーラーを目的のファイルの場所に抽出します
ステップ2:「config.ini」ファイルの次の値を変更します。
wlc_type: 2
mode: ssh
ap_mode: ssh
; set global WLC credentials
wlc_user: username
wlc_pasw: password
wlc_enable: enable_password
; set global AP credentials
ap_user: ap_username
ap_pasw: ap_password
ap_enable: ap_enable_password
[WLC-1]
active: True
ipaddr:
mode: ssh
ステップ3:残りのデフォルトの内容と下記のコマンドリストを、「cmdlist_cos」および「cmdlist_cos_qca」ファイルにコメント化します。
show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity
次に例を示します。
# 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」を使用してwlanpollerを実行します。WLANポーラーが実行され、すべてのAPにSSHで接続され、それらすべてのAPに対するこれらのコマンドの出力が取得されます。
ステップ5:実行後、「data」フォルダが作成されます。フォルダを入力し、各AP用に複数のファイルを作成した最後まで移動します。
ステップ6:このフォルダに個別に提供された「ap_detection_script.py」をコピー/ペーストして実行します。スクリプトは、次のボックスのリンクにあります。
https://pubhub.devnetcloud.com/media/wireless-troubleshooting-tools/docs/9800-scripts/ap_detection_script.zip
これにより、同じフォルダに「Status_check_results.log」という名前でファイルが作成されます。このリストには、問題が発生する可能性のあるAPのリストが含まれており、アップグレードを開始する前に回復や追加の手順が必要になります。
リカバリプロセス:
問題があると判断された各アクセスポイントの現在の状態に基づいて、これらのAPを回復するために最も最適化される方法に関するガイダンスを提供します。 各オプションで実行する必要がある詳細な手順を次に示します。
オプション1:パーティションスワップ
ステップ1:APが以前のパーティションまたはバージョンに戻らないようにするために、APがコントローラと通信できないことを確認します。これは、コントローラゲートウェイ上のアクセスリストによって実現できます。
ステップ2:影響を受ける可能性のあるAPから、パーティション2のブートを設定します。
AP# config boot path 2
ステップ3:APをリブートして、パーティション2のイメージでAPが起動するようにします。
AP# reset
ステップ4:コントローラのアップグレードが完了した後に、APをコントローラに加入させます。APが加入し、新しいイメージをダウンロードします。
注:このオプションが何らかの理由で実行できない場合は、いつでもTACケースをオープンし、このAPセットに対してもオプション2に進むことができます。
オプション2:TACケースを開いて、TACがルートシェルからAPをクリーンアップするようにする(このプロセスの後で、通常のアップグレードを行います)
オプション3:安全な状態だが、バックアップパーティションのAPのイメージがバグしている
APは、ほとんどの場合、修正済みバージョンへのアップグレードが完了した後、この状態になります。この状態は、APが修正済みバージョンを実行しているが、バックアップバージョンはまだバグがあることを示しています。注意が必要な場合は、APのバックアップを適切なイメージ(この問題が発生しないバージョン)に置き換えることをお勧めします。対象のAPの数に応じて、APにイメージをアーカイブしてダウンロードするか、または実際にアクティブ化せずに事前ダウンロードを実行します。
オプション4:これらのAPのイメージ整合性チェックが失敗した
アップグレードを進める前に、TACのサービスリクエストをオープンし、TACエンジニアにこれらのAPを修正してもらいます。
オプション5:これらのAPのイメージ整合性チェックが失敗した
現在のパーティションは影響を受けませんが、フラッシュストレージが少なくなっています。TACを開き、ストレージからdevshellを介してcnssdaemon.logをクリーンアップすることをお勧めします。