Wave 2および11axアクセスポイント(CSCvx32806)でのイメージ破損によるブートループからの回復

はじめに

一部のシスコアクセスポイント(AP)では、CAPWAP(Control and Provisioning of Wireless Access Points)を使用して9800シリーズコントローラから破損したイメージをダウンロードする場合があります。  APのソフトウェアバージョンによっては、APが破損したイメージのブートを試行する場合があり、その結果ブートループが発生します。  この記事では、ブートループに陥ったアクセスポイントを回復する方法について説明します。この問題の影響を受ける製品と展開の詳細、およびブートループの問題を発生させずに安全にアップグレードする方法の詳細については、「アクセスポイントの安全なアップグレード、ブートループを引き起こすイメージ破損の回避」を参照してください。

この問題は、Field Notice:FN74109 - CAPWAPアップグレード中のアクセスポイントのイメージ破損によりブートが失敗する場合がある…に記載されています。

問題の状態

該当しない製品

• ワイヤレスLANコントローラ(WLC):AireOSワイヤレスLANコントローラからダウンロードするAPは影響を受けません
• Mobility Express、組み込みワイヤレスコントローラ

• AP - Aironet 1800/1540/1100ACシリーズWave 2 11ac APおよびWave1 11acアクセスポイント(1700/2700/3700/1570/IW3700)は該当しません（これらのAPが9800 WLCに登録されている場合でも、該当しません）
• 2023年から導入されたWi-Fi 6E AP:IW9167、IW9165、C9163

該当製品

• WLC:Cisco Catalyst 9800シリーズワイヤレスLANコントローラからのAPのダウンロードが影響を受ける可能性
  
• AP:Cisco Catalyst 9800シリーズワイヤレスLANコントローラに登録する次のAPモデルが影響を受けます（一部のモデルについては、ゲスト登録のお客様にはアクセスできない場合があります）。
  • Aironet Wave2 11acアクセスポイント(2800/3800/4800/1560/IW6330/ESW6300)
  • Catalyst 9100シリーズWi-Fi6アクセスポイント(9105/9115/9117/9120/9124/9130/WP-WIFI6/ISR-AP1101AX)
  • Catalyst 9100シリーズWi-FI6Eアクセスポイント(9136/9162/9164/9166)

影響を受けるバージョン：不良イメージ起動現象

APが破損していると認識しているイメージを起動しようとする場合のこの問題は、次のCisco Bug IDで対処されています。CSCvx32806 、 CSCwc72021 、 CSCwd90081 を参照してください。これらは次のリリースで修正されています。

• 8.10.185.0以降
• 17.3.7以降
• 17.6.6以降
• 17.9.3以降
• 17.11.1以降

上記の修正を行ってソフトウェアにアップグレードしたAPでは、破損したイメージがダウンロードされる場合がありますが、イメージのブートは試行されず、成功するまでダウンロードが再試行されます。

症状

AP コンソール：

すでに破損したイメージをダウンロードし、現在ブートループにあるAPでは、次のようなコンソールメッセージが表示されます。

/bootpart/part1/ramfs_data_cisco.cpio.lzmaの署名の確認に失敗しました

または

/bootpart/part2/ramfs_data_cisco.squashfsの署名の確認に失敗しました

メッセージに「part1」と「part2」のどちらが表示されるかをメモします。これは、どのブートパーティションが破損しているかを示します。

SyslogまたはShow logging:

アクセスポイントが外部syslogサーバにログを記録するように設定されている場合、イメージのダウンロードを試行する前に、次のエラーがログに記録されます。

イメージ署名の検証エラー： -3

このエラーメッセージは、AP CLI（コンソールまたはSSH）の「show logging」出力でも確認できます。  イメージの更新を試行した後でロギングバッファが上書きされている場合、APフラッシュに格納されているsyslogファイルにエラーメッセージが表示される場合があります。 成功メッセージも失敗メッセージも表示されない場合 show loggingで、APのいずれかの回復方法を使用して、TFTPまたはSFTP経由で目的のイメージを再インストールします。

Ciscoスイッチポート：

ブートループ状態のAPでは、APのアップリンクスイッチポートのShow出力に、次のようにIEEE PDが表示されます。  （CDPまたはLLDPを使用している場合、APが正常に動作していると、Device列にモデルが表示されます）。

switch#show power inline
Available:195.0(w)  Used:159.9(w)  Remaining:35.1(w)

Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1     auto   on         15.4    Ieee PD             4     30.0
Gi0/2     auto   on         24.1    C9115AXI-B          4     30.0

ブートループにあるAPを回復する方法

APにAlt-boot拡張機能があるかどうかを確認する

APが破損したイメージをダウンロードしてブートしようとしている場合、u-boot（APブートローダ）にAlt-boot（代替ブート）機能拡張が組み込まれているかどうかによって、APには2つの動作のいずれかが発生します

• Alt-bootを使用しない場合：APは破損したイメージのブートを無期限に試行するため、コンソールポート経由で回復する必要があります
• Alt-boot:APは、破損したイメージのブートを5回試行した後、バックアップパーティションからイメージをブートします。  この場合、次に説明するAlt-boot回復方法のいずれかを使用することで、コンソールアクセスなしでAPを回復できます。

Alt-boot u-boot拡張機能は、次のソフトウェアリリースにバンドルされています。

• 9117/9130/9124:8.10.190.0、17.3.8+、17.6.6+、17.9.1+
• 9136: 17.9.1+
• 916x：すべてのユニットにAlt-boot機能拡張が搭載されています。
• 9105/9115/9120/2800/3800/4800/1560/6300:8.10.190.0、17.3.8+、17.6.6+、17.9.4

Alt-boot機能拡張を含むイメージをAPがダウンロードした場合、ランタイムイメージが破損していても、そのAPのu-bootはアップグレードされることに注意してください。  たとえば、次のシナリオについて考えます。

• 9130 APには17.3.4cがインストールされています（Alt-boot拡張機能なし）。
• 次に、17.9.5のイメージをダウンロードしますが、そのイメージはダウンロード中に破損しています。 
• 17.3.4cにはBoot a Bad Image Syndromeに対する修正がないため、APは先に進み、破損したイメージのブートを試みます。 
• 新しいイメージパーティションをブートすると、APは不良なランタイムイメージをブートする前に17.9.5 u-bootにアップグレードします。
• その後、APは破損した17.9.5ランタイムイメージのブートを5回試行します。
• その後、APは現在17.9.5 u-bootを実行しているため、Alt-bootロジックによってAPが切り替えられ、バックアップパーティション内のランタイムイメージがブートされます。
• これで、コンソールアクセスなしでAPを回復できます。

ブートループにあるAPの回復 – Alt-boot機能拡張

APがブートループ状態にあり、U-bootにAlt-boot機能拡張が組み込まれている場合は、次のいずれかの手順を使用してAPを回復します。

SSHがAPでイネーブルかどうか

1. 該当するAPにアクセス可能なTFTPまたはSFTPサーバで目的のAPイメージをステージングします。  必要なCisco IOS® XEバージョンにマッピングする15.3(3)J* APバージョンの『Compatibility Matrix』の表4を参照してください。次に、software.cisco.comから該当するAPモデル用の適切なLightweight APソフトウェアイメージをダウンロードします。
   
   1. たとえば、CW9162用の17.9.5 APイメージはap1g6b-k9w8-tar.153-3.JPN4.tarです。
2. 該当するAPが、破損したパーティションと同じソフトウェアバージョンを実行しているコントローラに加入しないようにします。  したがって、APが再びコントローラに加入するのを防ぐために、APスイッチポートにCAPWAP ACLを追加します。 たとえば、次のようなACLをAPのサブネットのデフォルトゲートウェイのインターフェイスに適用できます。
   

   Router#show running-config | section access-list 133
   access-list 133 deny ip host <wlc_ip> any log
   access-list 133 deny ip any host <wlc_ip> log
   access-list 133 permit ip any any
   
   Router#show running-config interface Vlan6
   [ ... ]
   interface Vlan6
   ip address 192.168.6.1 255.255.255.0
   ip access-group 133 in

3. 破損したイメージを使用してAPを5回リブートし、その後、バックアップパーティションの現用イメージに切り替えます。
   1. APのスイッチでshow cdp neighbor <interface> detailコマンドを使用すると、APのバックアップパーティションにあるコードのバージョンを確認できます。  （APが破損したイメージをブートしている場合、CDPはポートで起動しません）。
4. APが現用バックアップイメージを認識すると、コントローラへの加入を試行しますが、ステップ2で追加したACLにより、接続できなくなります。
5. 該当する各APにSSHで接続します(多数のAPが影響を受ける場合、このステップはWLAN Pollerを使用して自動化できます)。
6. 次に、archive downloadコマンドを使用して、目的のイメージをAPのバックアップパーティションにダウンロードします。
   archive download-sw /no-reload tftp://<ip-address>/<apimage>
   または
   archive download-sw /no-reload sftp://<ip-address>/<apimage>
   これにより、破損したイメージが有効なイメージで上書きされます。  イメージのダウンロードが完了したら、次を発行します。
   CAPWAP再起動のテスト
   これにより、CAPWAPプロセスが再起動し、APが新しくインストールされたイメージを認識します。
   
7. ここでACLを削除し、APをコントローラに加入させます。イメージは再度ダウンロードされません。

SSHがAPでイネーブルになっていないのに、APがAlt-boot拡張機能を備えている場合

1. APが、破損したパーティションと同じソフトウェアバージョンを実行しているコントローラに加入しようとしていないことを確認します。  したがって、APが再びコントローラに加入するのを防ぐために、APスイッチポートにCAPWAP ACLを追加します。
2. APの破損したバージョンとは異なるソフトウェアバージョンを実行しているコントローラを起動します。
   
   1. APのスイッチでshow cdp neighbor <interface> detailコマンドを使用すると、APのバックアップパーティションにあるコードのバージョンを確認できます。  （APが破損したイメージをブートしている間は、CDPはポートで起動しません）。
   2. APのバックアップバージョンを実行するコントローラをステージングできない場合は（9800の場合）、少なくとも「Boot a Bad Image Syndrome」と「Alt-boot」の修正を含むバージョンをステージングします。
   3. AireOSからCAPWAPをダウンロードしてもイメージの破損の影響を受けないため、AireOSコントローラで8.10.190.0以降を実行するという方法もあります。
3. APが代替コントローラを検出できるように、たとえば、DHCPオプション43、IPヘルパーアドレス、またはDNSなどを設定します。
   1. 代替コントローラで、APのバックアップと異なるバージョンのCisco IOS XEが実行されている場合、APは破損したイメージをダウンロードする可能性があるため、新たに破損した可能性があるAPに対してこのプロセスを繰り返し実行する必要があります。
4. APが代替コントローラに加入したら、目的のイメージをAPにダウンロードします。
   1. 該当するAPにアクセス可能なTFTPまたはSFTPサーバで目的のAPイメージをステージングします。  必要なCisco IOS XEバージョンにマッピングする15.3(3)J* APバージョンの『Compatibility Matrix』の表4を参照してから、software.cisco.comから該当するAPモデル用の適切なLightweight APソフトウェアイメージをダウンロードしてください。
      
      1. たとえば、CW9162用の17.9.5 APイメージはap1g6b-k9w8-tar.153-3.JPN4.tarです。
   2. 該当するAPでsshを有効にし、該当する各APにsshで接続します(該当するAPが多数ある場合、この手順はWLAN Pollerを使用して自動化できます)。
      1. 次に、archive downloadコマンドを使用して、目的のイメージをAPのバックアップパーティションにダウンロードします。
         archive download-sw /no-reload tftp://<ip-address>/<apimage>
         または
         archive download-sw /no-reload sftp://<ip-address>/<apimage>
         これにより、破損したイメージが有効なイメージで上書きされます。 
      2. イメージのダウンロードが完了したら、次を発行します。
         CAPWAP再起動のテスト
         これにより、CAPWAPプロセスが再起動し、APが新しくインストールされたイメージを認識します。
   3. APでarchive download-swを実行する代わりに、次のコントローラコマンドを使用して、APがTFTPサーバから目的のイメージをダウンロードするように設定することもできます。
      1. Cisco IOS XEの場合：ap name APNAME tftp-downgrade ip.addr.of.server imagename.tar
      2. AireOSの場合： config ap tftp-downgrade ip.addr.of.server imagename.tar APNAME
         
      3. TFTPサーバのログを監視して、各APがイメージを正常にダウンロードしたことを確認します。  ダウンロードが完了すると、各APがリロードされ、新しくダウンロードしたイメージが実行されます。
         
5. ステップ1でインストールしたACLを削除し、APを目的のコントローラに加入させます。

コンソール経由のリカバリ

APがブートループ中で、APにAlt-boot拡張機能がない場合、APはコンソール経由で回復する必要があります。

すべてのAPモデル：破損しているブートパーティションの特定

まず、どのブートパーティションが破損しているかを確認します。

1. AP コンソールに接続します。
   
2. 次のメッセージが表示されるまで、APのブート試行を確認します
   /bootpart/part1/ramfs_data_cisco.cpio.lzmaの署名の確認に失敗しました
   または
   /bootpart/part2/ramfs_data_cisco.cpio.lzmaの署名の確認に失敗しました
   (メッセージでは「ramfs_data_cisco.cpio.lzma」ではなく「ramfs_data_cisco.squashfs」と表示される場合があります)
   
3. 破損しているパーティション(part1またはpart2)を控えておきます

APモデル用 9117、9124、9130、9136

1. コンソールに接続したまま、APの電源を再投入します。
   

2. ブートアップ中にEscキーを押して自動ブートを停止すると、 escキーを押します
   

3. 次のいずれかのプロンプトが表示されます。

   (BTLDR)番号
   または
   (u-boot)>

4. 次のコマンドを実行します
   

   (u-boot)> or (BTLDR)# setenv mtdids nand0=nand0 && setenv mtdparts mtdparts=nand0:0x40000000@0x0(fs) && ubi part fs
   (u-boot)> or (BTLDR)# ubi remove part1   (or part2 if corrupted image is in part2)
   (u-boot)> or (BTLDR)# ubi create part1   (or part2 if corrupted image is in part2)
   (u-boot)> or (BTLDR)# reset

APモデル2802、3802、4800、9105、9115、9120

1. コンソールに接続したまま、APの電源を再投入します。
   

2. ブートアップ中に「Escキーを押して自動ブートを停止します」と表示されたら、Escキーを押します

3. これにより、(u-boot)>プロンプトが表示されます。

4. 次のコマンドを実行します

(u-boot)> ubi part fs 
(u-boot)> ubi remove part1  (or part2 if corrupted image is in part2) 
(u-boot)> ubi create part1  (or part2 if corrupted image is in part2) 
(u-boot)> boot

よく寄せられる質問（FAQ）

Q1)私のAPはすべて、高速、低遅延、低損失のLAN接続を介して9800に接続されています。  上記を実行する必要がありますか。

この問題が報告されるのは、WAN接続経由でAPをアップグレードする場合だけです。

Q2)新しいアウトオブボックスAPを所有しています。この問題が発生せずに導入するには、どうすればよいですか。

2023年12月より前に製造された新しいアウトオブボックスAPで、損失の大きいWANリンク経由でコードをダウンロードした場合にも、この問題が発生する可能性があります。これらのAPは、まずローカルWLCでステージングすることをお勧めします。

Q3)この問題についてさらに質問があります。  私は彼らを誰に向けても良いですか。

A:fn74109-questions@cisco.comに電子メールを送信してください。