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

簡介

本檔案介紹當AP受到思科錯誤ID CSCwf25731和CSCwf37271影響時的復原程式。

上下文

如果升級或APSP應用於當前運行17.12.4/5/6/6a或以前運行這些版本的系統且運行了相當長的時間，則會導致受影響的AP型號（請檢查下面受影響的接入點清單）在某些情況下進入引導循環，該啟動循環由映像安裝失敗觸發，因為AP儲存上的磁碟空間不足。雖然這不會影響日常操作或SMU，但在ISSU、完整控制器代碼升級或APSP安裝期間，這是一個重大風險，因為這些過程涉及接入點映像升級。

需要遵循其他流程，該流程需要執行本文檔中提到的強制升級預檢查步驟，因為不存在任何配置變通辦法。

要解決此問題，在AP嘗試升級之前，必須在WLC中安裝特定的APSP版本修補程式（顯示在下面的「固定代碼」表中），或者，如果您已經移至更高版本，但運行了任何受影響的版本，則使用清除的APSP（可用於17.15.4d和17.18.2）。即使您不確定系統的歷史記錄，強烈建議您在升級或APSP安裝之前執行儲存檢查，前提是您的環境中存在受影響的版本。

根本原因詳細資訊

運行17.12.4到17.12.6a的AP受生成持久日誌檔案的庫錯誤的影響：/storage/cnssdaemon.log。此檔案每天增長5MB，並且不會通過重新啟動來清除，最終會耗盡裝置的儲存空間。因此，如果AP從引導分割槽1(Part1)運行，並且引導分割槽2(Part2)由於日誌檔案已滿，則升級過程將失敗，因為它無法將新映像儲存在引導分割槽2中，這可能導致引導循環。為防止發生這種情況，您必須按照本文檔中的說明清除儲存或確保AP已從分割槽2引導，然後嘗試任何其他升級。

受影響的代碼和接入點

受影響的接入點

以下接入點型號是唯一易受此問題影響的型號。如果您的網路不使用任何特定型號，您的環境不會受到影響，無需進一步操作。

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

受影響的代碼

若要在網路中驗證這一點，請從所有WLC執行以下命令，並驗證WLC中存在的代碼是否列在下表中。

#show version | in Version

或者，您也可以從AP執行相同操作。檢查輸出，檢視主映像或備份映像是否正在運行表中列出的受影響映像。

#show version | in Image

附註：附註：通常，如果網路未運行，並且過去沒有運行17.12.4、17.12.5、17.12.6/6a，則問題不適用。

固定代碼

下表列出包含此錯誤修正的WLC軟體版本及其對應的APSP(Access Point Service Pack)。請注意，對於下面列出的版本，在撰寫本文時，當前只能通過APSP安裝進行修復。

升級路徑和錯誤適用性

使用下表可以確定您目前的WLC和AP軟體版本是否適用於此錯誤，以及執行哪些升級步驟。如果目前的部署與錯誤適用和升級路徑表中的任何版本相符，則您必須先執行升級預檢查一節中說明的儲存預檢查，然後嘗試任何進一步的升級。

Bug not applicable and upgrade path（錯誤不適用，升級路徑）

下表顯示您的WLC和AP是否不適用於此錯誤：

適用錯誤和升級路徑

下表顯示您的WLC和AP是否適用於此錯誤：

升級預檢查

如果您的環境受此錯誤影響，請依照以下強制步驟操作，以確保安全復原和升級：

1. 識別：執行手動或自動預檢查，以確定哪些特定存取點適用於錯誤。強烈建議使用自動預檢查。
2. 恢復：對於標籤的任何AP，請按照「恢復」部分中提到的恢復過程操作。
3. 驗證:重新運行預檢查，以確認所有裝置都運行正常，並且儲存問題已解決。
4. 升級:繼續升級到固定版本表中列出的固定APSP。

手動預檢查

1.在WLC中，您可以檢查「主要」和「備份」映像列，以確認您的存取點是否正在執行任何受影響的版本（請檢查上面的「受影響的代碼」部分）。

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
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap117.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap217.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap317.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap417.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

驗證活動的啟動分割槽以確保備份映像在第2部分。使用「show boot」命令並確認「BOOT path-list」指向第1部分；這表示AP當前正從主分割槽運行，並嘗試升級到可能觸發問題的輔助部分。

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:

2.通過檢查/dev/ubivol/part2分割槽來驗證當前檔案系統使用情況。如果「Use%」接近100%，則分割槽已用盡，這將導致升級失敗並可能觸發引導循環。

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

3.驗證兩個分割槽的映像完整性，以確保它們未損壞。主映像和備份映像的所有欄位必須顯示「良好」狀態；如果有任何欄位顯示其他情況，請停止該進程並立即開啟TAC案例。

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

自動預檢查

對於自動預檢查，請使用WLAN輪詢器工具。此工具允許您同時在所有接入點上運行所需的命令，以確定受影響的接入點；您可以從以下連結直接下載：https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/

步驟:

1.提取 — 將WLAN Poller檔案提取到您的首選目錄。

2.組態 — 使用以下引數更新「config.ini」檔案，以確保輸入特定憑證和控制器IP位址。

wlc_type: 2
mode: ssh
ap_mode: ssh

; set global WLC credentials
wlc_user: 
wlc_pasw: 
wlc_enable: 

; set global AP credentials
ap_user: 
ap_pasw: 
ap_enable: 

[WLC-1]
active: True
ipaddr: 
mode: ssh

3. Command List Preparation — 註釋（新增雜湊符號「#」）在「cmdlist_cos」和「cmdlist_cos_qca」中的預設內容，然後將以下命令新增到這兩個檔案中。

# 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"運行工具。 該工具將通過SSH連線到所有接入點並收集命令輸出。

5.數據檢索 — 完成後，導航到新建立的/data資料夾。從子目錄轉到包含各個AP輸出檔案的最終資料夾。

6. Analysis — 從官方Box連結下載「ap_detection_script.py」，將其放在「data」資料夾中，然後執行。

7.查看結果 — 開啟生成的「Status_check_results.log」，以檢視處於有問題狀態的AP清單。在繼續升級之前，這些裝置需要恢復步驟（在下面的「恢復」部分中說明），下面說明如何解釋結果：

根據設計，AP可以從分割槽1或分割槽2啟動。當一個分割槽處於活動狀態時，另一個分割槽用於映像或APSP下載。邏輯儲存分割槽永久對映到分割槽2，無法更改。此問題僅影響當前從分割槽1引導的接入點。您可以通過檢查「current_boot_partition_check」列來驗證這一點，以驗證AP使用的當前分割槽是什麼。範例：

從上面的示例我們可以得出結論，從3個AP中：

• AP名稱：測試AP1（需要操作）：如果AP在「current_boot_partition_check」列中顯示part1「True Visible」，則必須檢查「part2_mem_utilization_check」列。如果該列還顯示「真正易受攻擊」，AP會受到影響。

  • 範例：測試AP1受到影響(在第1部分和第2部分可用空間中啟動：51.9 MB)，需要恢復。

• AP名稱：測試AP2（分割槽1）：如果AP顯示part1「True Visible」，但「part2_mem_utilization_check」顯示「False Not Visible」，則AP是安全的。

  • 範例：測試AP2不會受到影響，因為它在分割槽2(part2)中具有足夠的空間，但是，建議安裝APSP以解決將來的問題，因為cnssdaemon.log檔案在AP中繼續存在。

• AP名稱：測試AP3（分割槽2）：如果AP在「current_boot_partition_check」列中顯示第2部分「False Not Suspect」，則不會受到影響。無需進一步檢查。

附註：附註：顯示在「True/False Reliability」狀態旁列「part2_mem_utilization_check」中的數值表示分割槽2中的可用空間量。

• 任何接入點：如果任何AP顯示「映像完整性檢查：Failed」（在「image_integrity_check」列下），請繼續開啟TAC案例。

復原

根據每個AP的特定狀態，指令碼將推薦最有效的恢複方法。對確定的受影響的AP執行以下詳細步驟：

AP映像分割槽交換

1. 隔離AP — 確保AP沒有與WLC的連線：
   1. 確保在AP加入配置檔案中啟用了SSH，並且AP可以通過SSH訪問（或使用控制檯）
   2. 確保AP沒有與WLC的連線，但是，您仍然可以通過SSH訪問AP。這可以通過在網關中設定ACL或將AP移動到隔離Vlan來實現。如果AP能夠訪問WLC，則AP可能會恢復為引導第1部分，並返回受影響的狀態。

2.配置啟動路徑 — 在受影響的AP上，將啟動路徑設定為分割槽2:

AP# config boot path 2

3. Reboot — 重新啟動AP以從分割槽2載入映像：

AP# reload

4. Upgrade — 將當前代碼中所需的APSP安裝到WLC中；或者，如果您要升級代碼，請移動到一個新代碼並確保同時安裝了APSP。

5.重新連線 — 控制器升級完成後，拆除AP和WLC之間的通訊制動器。AP將加入WLC並在引導部分1中自動下載新的固定映像。

6. Double Check — 升級到固定版本後，驗證AP的兩個分割槽，以確保備份插槽不包含有錯誤的映像。

7. 維護 — 為了保持長期穩定性並防止將來出現引導環路，我們建議使用已知良好的映像覆蓋備份分割槽。對於較小的組，請直接在AP上使用存檔「download-sw」；對於較大型的部署，請執行WLC AP預下載以更新備份分割槽，而不會觸發AP映像啟用。

AP外殼訪問恢復

Technical Assistance Center(TAC)可以通過直接從受影響接入點上的shell中清除cnssdaemon.log檔案來執行手動恢復。根據影響的規模，下面提到兩種方法：

• 少數受影響AP:對於少量的受影響AP，可以使用以下兩種方法之一進行TAC:

  • 手動外殼訪問:通過shell單獨訪問每個接入點以手動清除日誌檔案。

  • 自動（批次）外殼訪問:使用RADKit工具對所有受影響的AP自動執行清理過程。

• 大量受影響的AP:TAC應使用Radkit工具，這允許批次外殼同時訪問所有受影響的AP，以高效執行清理過程。

附註：我們建議將RADKit用於AP外殼訪問恢復過程，以確保效率和一致性。

附註：要下載Radkit，請使用以下連結：Radkit下載並下載最新版本。要安裝Radkit，請按照以下影片操作：Radkit安裝

何時建立TAC案例

如果出現以下任何情況，請立即開啟TAC案例：

• 恢復失敗：AP映像AP映像分割槽交換過程失敗或無法在您的環境中實施。
• 完整性問題：手動或自動預檢查返回「映像完整性檢查：任何AP的「失敗」狀態。
• 儲存耗盡：如果在升級/APSP安裝分割槽後，「/dev/ubivol/part2」仍顯示使用率非常高。

Cisco TAC可以訪問AP shell以手動清除cnssdaemon.log檔案並執行高級恢復操作以恢復裝置。

常見問題

Q:此問題是否只適用於完全代碼升級，或者是否也會影響APSP安裝？

A:此問題同時影響兩種情況。如果您的環境滿足此錯誤的標準，則可能會在完全代碼升級或APSP安裝（包括具有錯誤修復程式的APSP）期間發生此問題。 請完成升級預檢查部分，以確定您是否需要在執行任何更新或APSP之前執行恢復步驟。

Q:我的WLC和AP位於17.9.x（或更低版本）上，我需要升級到17.12.x，我該怎麼做？

A:您可以直接從17.9.x升級到17.12.x。但是，如果您的AP型號易受此錯誤的干擾，請確保在升級後立即安裝建議的APSP。

Q:我的WLC和AP位於17.9.x（或更低版本）上，我需要升級到17.15.x或更高版本。

A:有兩種可能情況：

• 直接升級：如果您的環境允許直接升級（請通過「發行說明」驗證您的目的碼），請繼續升級，然後安裝該目的碼的APSP。
• 中間升級：如果必須按照升級路徑操作(例如，17.9.x → 17.12.x → 17.15.x)，我們建議您在同一天內完成到17.15.x的整個序列。由於cnssdaemon.log檔案每天增長5 MB，因此完成升級可以快速阻止檔案達到臨界大小。如果無法進行當天升級，您必須先在17.12.x階段安裝APSP，然後才能最終繼續到17.15.x並安裝其各自的APSP。

Q:我已在17.15.x上。這是否表示我不受此錯誤影響？

A:不一定。如果您的AP先前運行的是17.12.4、17.12.5或17.12.6/6a（在9800-L/40/80/CL上），則有問題的日誌檔案可能已經生成並保留在儲存中。我們強烈建議按照Upgrade Prechecks（升級預檢查）部分進行操作，以確保清除所有殘留檔案。

Q:我使用9800-M、9800-H1或9800-H2平台（17.15中首次支援這些平台），我是否受到影響？

A:有兩種可能情況：

• 首次加入WLC:如果您的AP將9800-M/H1/H2作為他們的第一個控制器加入，則不會受到影響。
• 之前加入的WLC:如果在移至9800-M/H1/H2之前，這些AP之前已連線到運行受影響版本(17.12.4/5/6/6a)的其他控制器，則它們可能仍然攜帶有問題的檔案。在這種情況下，請按照Upgrade prechecks部分操作。

Q:我們有單獨的WLC用於實驗室測試和交錯升級，我們應如何處理它們？

A:確保您環境中的所有WLC都運行適當的APSP。由於cnssdaemon.log檔案每天增長5 MB，因此，任何加入運行受影響代碼的WLC的AP（即使是暫時用於測試），都可能受到此錯誤的攻擊。