驗證並恢復受升級失敗影響的17.12上的Catalyst AP

簡介

本檔案介紹受Cisco錯誤ID CSCwf25731影響時的復原程式 和CSCwf37271  

受影響的接入點

這些接入點型號會受到影響。如果不使用以下模型，則不會受到影響，無需進一步操作：

• 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)

上下文

將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 ，建立了一個可每天增長高達5 MB的永久檔案「/storage/cnssdaemon.log」 ，並使用該磁碟分割槽上的所有可用空間。重新啟動時不會清除此檔案。  一旦完全使用分割槽，升級可能會失敗，因為儲存新檔案版本的關鍵步驟尚未完成。 

此問題是由庫更新引起的，該更新修改了內部元件的日誌目標。裝置操作不需要日誌檔案

只有當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 — 升級路徑適用性

附註：一般來說，如果網路並未執行，且過去並未執行17.12.4、17.12.5、17.12.6a，則問題不適用

附註：「Current」（當前）列中未明確提及的任何其他版本都遵循推薦的升級路徑。

已修復版本

預先檢查 

要評估網路是否易受到此問題的影響，請執行當前步驟。這些步驟有助於提供概述，但是要實際檢測AP，請使用「預檢指令碼」部分自動完成此過程：

• 如果受影響的版本，在「主映像」或「備份映像」列下確認接入點映像是否為1:

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中執行類似的驗證：

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.

在下一部分中，我們將指導您完成對所有接入點的預檢查流程自動化的指令碼。 

預檢查指令碼

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輪詢器運行SSH到所有AP，並獲取所有這些AP的命令輸出。

步驟 5:執行後，將建立「資料」資料夾。輸入資料夾，一直轉到為每個AP建立多個檔案的結尾。

步驟 6:複製/貼上此資料夾中單獨提供的「ap_detection_script.py」並執行它。您可以在下面的Box連結中找到指令碼：

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# reset

 步驟 4:在控制器上完成升級後，讓AP加入控制器。AP加入並下載新映像。

附註：如果您由於任何原因無法使用此選項，則您始終可以為此組AP開啟TAC案例並繼續使用選項2。

選項 2:開啟TAC案例，以讓TAC從根shell清除AP（在此流程之後，繼續正常升級）

選項3：安全狀態，但AP在備份分割槽中有錯誤映像

AP在升級到固定版本後大部分會進入此狀態。此狀態表明AP正在運行固定版本，但備份版本仍然有漏洞。為了有失謹慎，我們建議使用良好的映像（也就是未發現此問題的版本）替換AP備份。根據有問題的AP數量，檔案檔案會將映像下載到AP或只進行預下載而不實際啟用它。

選項 4:這些AP的映像完整性檢查失敗

開啟一個TAC案例，讓TAC工程師在繼續升級前修正這些AP。

選項 5:這些AP的映像完整性檢查失敗

當前分割槽不易受影響，但快閃記憶體儲存較低。建議開啟TAC，通過devshell從儲存中清除cnssdaemon.log。