验证并恢复17.12上受升级故障影响的Catalyst AP

简介

本文档介绍当AP受Cisco Bug ID CSCwf25731和CSCwf37271影响时的恢复过程。

情景

应用于当前运行17.12.4/5/6/6a或以前运行这些版本的系统的APSP升级或运行时间相当长时，会导致受影响的AP型号（请检查下面受影响的接入点列表）在某些情况下进入启动循环，这些情况由因AP存储上的磁盘空间不足而导致的映像安装故障触发。虽然这不会影响日常操作或SMU，但在ISSU、完全控制器代码升级或APSP安装过程中仍存在重大风险，因为这些过程涉及接入点映像升级。

需要遵循其他流程，该流程需要执行本文档中提到的强制升级预检查步骤，因为不存在任何配置变通方法。

要解决此问题，您必须在AP尝试升级之前在WLC中安装特定APSP版本修补程序（显示在下面的“固定代码”表中），或者使用清理APSP（适用于17.15.4d和17.18.2）（如果您已移至更高版本，但运行了任何受影响的版本）。即使您不确定您的系统历史记录，强烈建议您在升级或APSP安装之前执行存储检查，以确定环境中是否存在受影响的版本。

根本原因详细信息

运行17.12.4到17.12.6a的AP受到生成持久日志文件的库Bug的影响：/storage/cnssdaemon.log。此文件每天增长5 MB，并且无法通过重新启动进行清除，最终耗尽设备的存储空间。因此，如果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，则问题不适用。

固定代码

下表列出了包含此Bug的修复程序的WLC软件版本及其相应的APSP（接入点服务包）。请注意，对于下面列出的版本，在撰写本文时，修复程序目前只能通过APSP安装提供。

升级路径和漏洞适用性

使用下表来确定当前的WLC和AP软件版本是否适用于此Bug，以及采取什么升级步骤。如果当前部署与Bug applicable and upgrade path表中的任何这些版本匹配，则必须在尝试任何进一步升级之前执行Upgrade Prechecks部分中说明的存储预检查。

Bug not applicable and upgrade path

下表显示您的WLC和AP是否不适用于此Bug:

Bug适用和升级路径

下表显示您的WLC和AP是否适用于此Bug:

升级预检查

如果您的环境受此Bug的影响，请按照以下强制步骤进行操作，以确保安全恢复和升级：

1. 识别：执行手动或自动预检查，以确定哪些特定接入点适用于此Bug。强烈建议进行自动预检查。
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/#wlan-poller

步骤:

1.提取 — 将WLAN轮询器文件提取到您的首选目录。

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. 分析 — 从官方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 Susceptible”，则必须选中“part2_mem_utilization_check”列。如果该列还显示“真正易受攻击”，则AP受到影响。

  • 示例：测试AP1受到影响(在第1部分和第2部分可用空间中启动：51.9 MB)并需要恢复。

• AP 名称:测试AP2（分区1）：如果AP显示part1“True Susceptible”，但“part2_mem_utilization_check”显示“False Not Susceptible”，则AP是安全的。

  • 示例：测试AP2不会受到影响，因为它在分区2(part2)中具有足够的空间，但是，建议安装APSP以解决将来的问题，因为cnssdaemon.log文件继续存在于AP中。

• AP 名称:测试AP3（分区2）：如果AP在“current_boot_partition_check”列中显示第2部分“False Not Suspect”，则它不会受到影响。无需进一步检查。

注意：注意：显示在“True/False Susceptible”状态旁列“part2_mem_utilization_check”中的数值表示分区2中的可用空间量。

• 任何接入点：如果任何AP显示“Image Integrity Check:“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外壳访问恢复

技术支持中心(TAC)可以通过直接从受影响接入点上的shell清除cnssdaemon.log文件来执行手动恢复。根据影响的规模，下面将介绍两种方法：

• 受影响的AP数量少:对于少量受影响AP，TAC可以使用以下两种方法之一继续操作：

  • 手动外壳访问:通过外壳分别访问每个接入点以手动清除日志文件。

  • 自动（批量）外壳访问:使用RADKit工具自动清除所有受影响的AP。

• 大量受影响的AP:TAC应使用Radkit工具，这样可以对所有受影响的AP同时进行批量外壳访问，从而高效地执行清理过程。

注意：我们建议将RADKit用于AP外壳访问恢复过程，以确保效率和一致性。

注意：要下载Radkit，请使用此链接：Radkit下载并下载最新版本。要安装Radkit，请观看此视频：Radkit安装

何时创建TAC案例

如果出现以下任何情况，请立即打开TAC案例：

• 恢复失败：AP映像AP映像分区交换过程失败或无法在您的环境中实施。
• 完整性问题：手动或自动预检查返回“映像完整性检查：任何AP的“失败”状态。
• 存储耗尽：如果在升级/APSP安装后分区“/dev/ubivol/part2”仍显示使用率极高。

Cisco TAC可以访问AP外壳以手动清除cnssdaemon.log文件并执行高级恢复操作以恢复设备。

常见问题解答

问:此问题是否只适用于完全代码升级，或者是否也影响APSP安装？

A：此问题同时影响这两种情况。如果您的环境满足此Bug的条件，则问题可能会在完全代码升级或APSP安装（包括带有错误修复的APSP）期间发生。 请完成升级预检查部分，以确定您是否需要在执行任何更新或APSP之前执行恢复步骤。

问:我的WLC和AP在17.9.x（或更早版本）上，我需要升级到17.12.x，我该做什么？

A：您可以执行从17.9.x到17.12.x的直接升级。但是，如果您的AP型号容易感染此漏洞，请确保在升级后立即安装推荐的APSP。

问:我的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。

问:我已经在17.15.x上。这是否意味着我不受此漏洞的影响？

A：不必要。如果AP以前运行版本17.12.4、17.12.5或17.12.6/6a（在9800-L/40/80/CL上），则问题日志文件可能已经生成并保留在存储中。我们强烈建议按照Upgrade Prechecks（升级预检查）部分进行操作，以确保清除所有残留文件。

问:我使用9800-M、9800-H1或9800-H2平台（17.15中首次支持这些平台），是否受到影响？

A：有两种可能的方案：

• 首次加入WLC:如果AP加入9800-M/H1/H2作为其第一个控制器，则不会受到影响。
• 以前加入的WLC:如果这些AP在迁移到9800-M/H1/H2之前已连接到运行受影响版本(17.12.4/5/6/6a)的其他控制器，则它们可能仍然携带有问题的文件。在这种情况下，请按照升级预检查部分操作。

问:我们有单独的WLC用于实验室测试和交错升级，我们应如何处理它们？

A：确保您环境中的所有WLC都运行相应的APSP。由于cnssdaemon.log文件每天增长5 MB，因此任何加入运行受影响代码的WLC的AP（即使临时进行测试）都有可能受到此Bug的影响。