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

简介

本文档介绍受Cisco Bug ID CSCwf影响时的恢复过程25731 和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的受影响型号的接入点会创建永久文件“/storage/cnssdaemon.log”，该文件每天最多可增加5 MB，并且会使用该磁盘分区上的所有可用空间。重新启动时不会清除此文件。  一旦分区被完全使用，升级可能会失败，因为存储新文件版本的关键步骤尚未完成。 

库更新导致此问题，修改了内部组件的日志目标。设备操作不需要日志文件

只有当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，则问题不适用

注意：“当前”列中未明确提及的任何其他版本都遵循推荐的升级路径。

已修复版本

预检查 

要评估网络是否易受到此问题的影响，请执行当前步骤。这些步骤有助于提供概述，但是要对AP进行实际检测，请使用“预检脚本”部分自动执行此过程：

• 如果受影响的版本，请确认接入点映像是否为其中之一，位于“主映像”(Primary)或“备份映像”(Backup image)列下：

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.

在下一节中，我们将带您了解自动执行所有AP的预检查流程的脚本。 

预检查脚本

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轮询器运行，对所有AP执行SSH，并获取所有这些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加入并下载新映像。

NOTE:如果由于任何原因此选项不可行，您可以始终打开TAC案例并继续执行此AP集的选项2。

选项 2：打开TAC案例，让TAC从根外壳中清除AP（在此过程之后，您将进行正常升级）

选项3：安全状态，但AP在备份分区中有错误映像

AP主要是在完成到固定版本的升级后处于此状态。此状态表明AP运行的是固定版本，但备份版本仍然有漏洞。为了防止出错，我们建议使用良好的映像（即未发现此问题的版本）替换AP备份。根据有问题的AP数量，归档文件会将映像下载到AP，或者仅执行预下载而不实际激活映像。

选项 4：这些AP的映像完整性检查失败

打开TAC案例，让TAC工程师在继续升级之前修正这些AP。

选项 5：这些AP的映像完整性检查失败

当前分区不易受影响，但闪存存储较低。建议打开TAC以通过devshell从存储中清除cnssdaemon.log。