目錄

簡介

受影響的接入點

上下文

根本原因詳細資訊

升級檢查程式

已修復版本

預先檢查

預檢查指令碼

WLAN輪詢器（可從此處下載）

恢復過程：

選項 1:分割槽交換

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

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

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

選項 5:這些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.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.15，請使用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

是

是

17.12.4 + APSPx 17.12.5 + APSPx

17.12.6a + APSPx

17.12.7

是

安裝固定APSP後，無需對未來17.12升級進行額外預檢查

17.12.4/5/6a

17.15.x / 17.18.x

是

是

升級各自的17.12.x APSP，然後升級到17.15.x + APSPx或17.18.x + APSPx

對於第一個17.12 APSP升級為「是」，對於後續升級為「否」。

任何版本，以前的映像是17.12.4/5/6a之一

17.15.x

是

是

17.15.x + APSPx

是

任何版本，以前的映像是17.12.4/5/6a之一

17.18.x

是

是

17.18.x + APSPx

是

17.15+

新部署

任意

否

否

任意

否

17.18.

新部署

任意

否

否

任意

否

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

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

已修復版本

控制器

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，請使用「預檢指令碼」部分自動完成此過程：

- 如果受影響的版本，在「主映像」或「備份映像」列下確認接入點映像是否為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。