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

はじめに

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

問題の状態

該当しない製品

• ワイヤレス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シリーズWireless LAN Controllerに登録する次の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)

該当バージョン：Boot a Bad Image症候群

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症候群に対する修正がないため、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ブートにAlt-boot拡張機能が組み込まれている場合は、次のいずれかの手順を使用して回復します。

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

1. 該当するAPにアクセス可能なTFTPまたはSFTPサーバで目的のAPイメージをステージングします。  適切なIOS-XEバージョンにマッピングする15.3(3)J* APバージョンの『互換性マトリクス』の表4を参照し、該当するAPモデルに適したLightweight APソフトウェアイメージをsoftware.cisco.comからダウンロードしてください。
   
   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コントローラで8.10.190.0以降を実行する方法もあります。これは、AireOSからCAPWAPをダウンロードしてもイメージが破損する可能性がないためです。
3. APが代替コントローラを検出できるように、たとえば、DHCPオプション43、IPヘルパーアドレス、またはDNSなどを設定します。
   1. 代替コントローラで、APのバックアップと異なるバージョンのIOS XEが実行されている場合、APは破損したイメージをダウンロードする可能性があるため、新たに破損した可能性があるAPについてはこのプロセスを繰り返し実行する必要があります。
4. APが代替コントローラに加入したら、目的のイメージをAPにダウンロードします。
   1. 該当するAPにアクセス可能なTFTPまたはSFTPサーバで目的のAPイメージをステージングします。  適切なIOS-XEバージョンにマッピングする15.3(3)J* APバージョンの『互換性マトリクス』の表4を参照し、該当するAPモデルに適したLightweight APソフトウェアイメージをsoftware.cisco.comからダウンロードしてください。
      
      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. 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. ブートアップ中に「Hit ESC key to stop autoboot, press the Esc key」が表示されたら、キーを押します
   

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. ブートアップ中に「Hit ESC key to stop autoboot, press the Esc key」が表示されたら、キーを押します

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があります。この問題が発生せずに導入するには、どうすればよいですか。

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