從Wave 2和11ax存取點(CSCvx32806)上因映像損毀所造成的開機回圈中復原

簡介

某些思科存取點(AP)可能會透過CAPWAP （無線存取點的控制與布建）從9800系列控制器下載損毀的映像。  根據AP的軟體版本，AP可能會嘗試引導損壞的映像，從而導致引導循環。  本文說明如何恢復停滯在引導環路中的存取點。要瞭解有關哪些產品和部署容易出現此問題的詳細資訊並瞭解如何安全升級而不出現引導環路問題，請參閱文章安全升級存取點，避免導致引導環路的映象損壞。

此問題已記錄為Field Notice： FN74109 - CAPWAP升級期間的存取點映像損壞可能會導致引導失敗。.。

問題狀況

未受影響的產品

• 無線區域網控制器(WLC)：從AireOS無線區域網控制器下載的存取點不受影響
• Mobility Express、嵌入式無線控制器

• AP - Aironet 1800/1540/1100AC系列Wave 2 11ac和Wave1 11ac存取點(1700/2700/3700/1570/IW3700)不受影響（即使這些AP註冊到9800 WLC，它們也不受影響）
• 自2023年起推出的Wi-Fi 6E AP：IW9167、IW9165、C9163

受影響的產品

• WLC：從Cisco Catalyst 9800系列無線區域網控制器下載的AP可能會受到影響
  
• AP：註冊到Cisco Catalyst 9800系列無線區域網控制器的以下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漏洞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：

如果存取點配置為在嘗試下載映像之前登入到外部系統日誌伺服器，它將記錄以下錯誤：

映像簽名驗證失敗： -3

此錯誤消息還可以從AP CLI（控制檯或SSH）的「show logging」輸出中看到。  如果自映像更新嘗試後日誌記錄緩衝區已被覆蓋，則可在儲存在AP快閃記憶體中的系統日誌檔案中看到此錯誤消息。 如果您在show logging中未看到成功或失敗消息，則在AP上使用一種恢復方法透過TFTP或SFTP重新安裝所需的映象。

思科Switchport：

處於引導環路狀態的AP將顯示如下所示的IEEE PD，如AP的上行鏈路交換機埠的Show輸出所示。  （如果使用CDP或LLDP，運行正常的AP將在「裝置」列中顯示其型號）：

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將表現出兩種行為之一

• 不使用Alt-boot：AP將無限期嘗試啟動損壞的映像，並且需要透過其控制檯埠進行恢復
• 使用Alt-boot：AP將嘗試啟動損壞的映像五次，然後從其備份分割槽啟動映像。  在這種情況下，無需控制檯訪問即可恢復AP，使用下面介紹的其中一種Alt-boot恢復方法。

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

請注意，如果AP已下載具有Alt-boot增強功能的映像，則即使運行時映像已損壞，也會升級其u-boot。  例如，請考慮以下情況：

• 9130 AP已安裝17.3.4c（沒有Alt-boot增強功能）。
• 然後會下載17.9.5映像，但在下載期間該映像已損壞。 
• 由於17.3.4c沒有針對引導不良映像症候群的修復方法，因此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

1. 將所需的AP映像暫存在受影響AP可訪問的TFTP或SFTP伺服器上。  請參閱相容性矩陣中的表4，瞭解對映到所需的Cisco IOS® XE版本的15.3(3)J* AP版本，然後從software.cisco.com下載適用於受影響AP型號的輕量AP軟體映像。
   
   1. 例如，CW9162的17.9.5 AP映像是ap1g6b-k9w8-tar.153-3.JPN4.tar。
2. 防止受影響的AP加入與其損壞分割槽中運行相同軟體版本的控制器。  因此，請在AP交換機埠上增加CAPWAP ACL，以防止AP再次加入控制器。例如，可以在AP子網的預設網關介面上應用如下所示的ACL：
   

   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重新啟動五次損壞的映像，之後應切換到備份分割槽中的工作映像。
   1. 可以在AP的交換機上使用show cdp neighbor <interface> detail命令來檢視AP的備份分割槽中的代碼版本。  （如果AP正在啟動損壞的映像，則CDP不會在其埠上啟動。）
4. 一旦AP提供工作備份映像，它將嘗試加入控制器，但由於步驟2中增加了ACL而無法加入。
5. 使用安全ssh連線到每個受影響的AP(如果大量AP受到影響，則可透過WLAN輪詢器自動完成此步驟。)
6. 現在使用archive download命令將所需的映像下載到AP的備份分割槽：
   archive download-sw /no-reload tftp://<ip-address>/<apimage>
   或
   archive download-sw /no-reload sftp://<ip-address>/<apimage>
   這將用有效映像覆蓋損壞的映像。  映像下載完成後，發出：
   test capwap restart
   這將重新啟動CAPWAP進程，以便AP能夠辨識新安裝的映像。
   
7. 現在移除ACL，並將AP加入控制器。它不會再次下載映像。

如果AP上未啟用SSH，但AP具有Alt-boot增強功能

1. 確保AP不會嘗試加入運行與損壞分割槽中相同軟體版本的控制器。  因此，請在AP交換機埠上增加CAPWAP ACL，以防止AP再次加入控制器。
2. 啟動運行不同於AP損壞版本的軟體版本的控制器。
   
   1. 可以在AP的交換機上使用show cdp neighbor <interface> detail命令來檢視AP的備份分割槽中的代碼版本。  （當AP啟動損壞的映像時，CDP不會在其埠上啟動。）
   2. 如果暫存執行AP備份版本的控制器不可行，則（如果是9800），至少暫存含有錯誤影像綜合症修正程式和Alt-boot的版本。
   3. 另一個選擇是讓運行8.10.190.0或更高版本的AireOS控制器運行，因為AireOS的CAPWAP下載不會出現映像損壞。
3. 設定好裝置以便AP可以發現備用控制器-例如，透過DHCP選項43、IP幫助程式地址或DNS。
   1. 請注意，如果備用控制器運行的Cisco IOS XE版本與AP的備份版本不同，則AP可能會下載損壞的映像，因此請對可能新損壞的任何AP重複此過程。
4. AP加入備用控制器後，將所需的映像下載到AP：
   1. 將所需的AP映像暫存在受影響AP可訪問的TFTP或SFTP伺服器上。  請參閱相容性矩陣中的表4，瞭解對映到所需的Cisco IOS XE版本的15.3(3)J* AP版本，然後從software.cisco.com下載適用於受影響AP型號的輕量AP軟體映像。
      
      1. 例如，CW9162的17.9.5 AP映像是ap1g6b-k9w8-tar.153-3.JPN4.tar。
   2. 在受影響的AP上啟用SSH，並使用SSH連線到每個受影響的AP(如果受影響的AP數量較大，則可透過WLAN輪詢器自動完成此步驟。)
      1. 現在使用archive download命令將所需的映像下載到AP的備份分割槽：
         archive download-sw /no-reload tftp://<ip-address>/<apimage>
         或
         archive download-sw /no-reload sftp://<ip-address>/<apimage>
         這將用有效映像覆蓋損壞的映像。 
      2. 映像下載完成後，發出：
         test capwap restart
         這將重新啟動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.squashfs」而不是「ramfs_data_cisco.cpio.lzma」
   
3. 記下哪個分割槽part1或part2已損壞

對於AP型號9117、9124、9130、9136

1. 連線到控制檯時，請重新啟動AP。
   

2. 在啟動過程中，當出現Hit ESC key to stop autoboot時，請按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. 在啟動過程中，當出現Hit ESC key to stop autoboot時，請按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

常見問題

問題1：我的AP都透過高速、低延遲、低丟失的LAN連線連線到其9800。  我是否仍需要執行上述操作？

僅當透過WAN連線升級AP時，才會報告此問題。

問題2：我擁有全新的開箱即用AP。如何部署它們而不遇到此問題？

如果AP是在2023年12月之前製造的，則透過有損WAN鏈路下載代碼的新開箱即用AP也會容易出現此問題。建議首先使用本地WLC安裝這些AP。

問題3：我對這個問題有更多疑問。  我可以把他們引向誰？

答：傳送電子郵件到fn74109-questions@cisco.com。