Validar e recuperar APs Catalyst em 17.12 Afetados pela Falha de Atualização

Introdução

Este documento descreve o procedimento de recuperação quando você é afetado pelo bug da Cisco ID CSCwf25731 e CSCwf37271  

Pontos de acesso afetados

Esses modelos de pontos de acesso são afetados. se não estiver usando os modelos abaixo, você não será afetado e não serão necessárias mais ações:

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

Contexto

Os upgrades de sistemas que estiveram em 17.12.4/5/6a para qualquer versão podem fazer com que modelos específicos de pontos de acesso entrem em um loop de inicialização sob determinadas condições, acionados por falha de instalação da imagem devido a espaço em disco insuficiente no armazenamento do dispositivo de destino. Esse cenário ocorre somente durante uma operação de atualização envolvendo pontos de acesso, por exemplo, ISSU, instalação de imagem de controlador completo ou APSP, e não afeta nenhum serviço normal, operações diárias ou instalações SMU.

Etapas adicionais são necessárias antes de executar qualquer atualização nos pontos de acesso possivelmente afetados. Esse problema não tem solução alternativa e não depende de configuração, tipo de implantação ou modelo de controlador

Esse problema não afeta as versões anteriores à 17.12.4, ou se o Ponto de acesso estiver executando qualquer versão posterior à 17.12.6a, por exemplo, 17.15.x e nunca tiver instalado nenhuma das versões afetadas.

Uma correção está disponível para as versões 17.12.4, 17.12.5 e 17.12.6a do Cisco IOS XE, na forma dos respectivos APSPs. Além disso, um APSP de limpeza está disponível para 17.15.4d e 17.18.2, para recuperar o espaço perdido, para as implantações que estavam usando a versão impactada, e já atualizaram para uma versão posterior.

Se sua rede esteve em alguma das versões afetadas em algum momento ou se você não tiver certeza se a rede usou essas versões anteriormente, é recomendável executar as verificações antes de qualquer atualização como precaução

Detalhes da causa raiz

Os pontos de acesso dos modelos afetados, que executam os códigos 17.12.4 a 17.12.6a, criam um arquivo persistente "/storage/cnssdaemon.log", que pode crescer até 5 MB por dia, e usam todo o espaço disponível nessa partição de disco. Este arquivo não é limpo na reinicialização.  Quando a partição estiver totalmente usada, os upgrades podem falhar, pois uma etapa crítica no armazenamento da nova versão do arquivo não é concluída. 

O problema foi introduzido por uma atualização de biblioteca, que modificou o destino de log de um componente interno. O arquivo de log não é necessário para a operação do dispositivo

A falha de atualização só acontece se o AP estiver sendo executado da partição 1 e o espaço da partição 2 tiver sido esgotado. Se houver espaço suficiente ou se o AP tiver sido inicializado da partição 2, a atualização será bem-sucedida

Procedimento de verificação de atualização

Se a WLC estiver atualmente em17.12.4, 17.12.5, 17.12.6a, a atualização é obrigatória para uma versão de software com a correção enquanto segue as etapas abaixo. Para qualquer outra versão instalada na WLC, se estiver planejando atualizar,é altamente recomendável seguir estas instruções:

Passo 1: Verifique se os pontos de acesso são potencialmente afetados (consulte a Tabela 1). Se não for afetado, nenhum processo de pré-verificação/recuperação será necessário e você poderá prosseguir diretamente para atualizar para qualquer uma das versões mais recentes.

Passo 2: Se você for afetado, execute pré-verificações para identificar o número de APs afetados na seção Pré-verificações.

Passo 3: Nos AP identificados, execute as etapas de recuperação descritas na seção de recuperação.

Passo 4: Execute novamente a pré-verificação para confirmar que nenhum outro AP seja afetado.

Passo 5: Continue a atualizar para os respectivos APSPs ou versões de software mencionados na Tabela de versões fixas.  

Consulte esta tabela para verificar se este aviso é aplicável a você: 

Tabela 1 - Aplicabilidade do caminho de atualização

Note: Em geral, se a rede não estiver em execução e não tiver executado 17.12.4, 17.12.5, 17.12.6a no passado, o problema não será aplicável

Note: Qualquer outra versão não mencionada explicitamente na coluna "Atual" segue o caminho de atualização recomendado.

Versões fixas

Pré-verificações 

Para avaliar se a rede é susceptível a esse problema, execute as etapas atuais. Essas etapas ajudam a fornecer uma visão geral, mas para a detecção real de APs, use a seção "Scripts de pré-verificação" para automatizar esse processo:

• Confirme se as imagens do ponto de acesso são uma das versões afetadas, nas colunas de imagem Principal ou de Backup:

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

• Uma verificação semelhante pode ser realizada no 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

• Verifique a partição de inicialização atual:

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.

• Verifique o uso atual do sistema de arquivos:

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%.

• Verifique a integridade da imagem para ambas as partições:

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.

Na próxima seção, o guiaremos pelos scripts que automatizam o processo de pré-verificação para todos os APs. 

Script de pré-verificação

Pesquisa de WLAN(Pode ser baixado aqui )

Passo 1: Extraia a pesquisa de WLAN para o local de arquivo desejado

Passo 2: Modifique estes valores no arquivo "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

 Etapa 3: comente o restante do conteúdo padrão e a lista de comandos abaixo para os arquivos "cmdlist_cos" e "cmdlist_cos_qca".

show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity

Amostra abaixo:

# 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

 Etapa 4: execute o wlanpoller usando ".\wlanpoller.exe". A pesquisa da WLAN é executada, SSH para todos os APs e obtém as saídas desses comandos para todos eles.

Passo 5: Após a execução, uma pasta de "dados" é criada. Insira a pasta e vá até o final, onde você tem vários arquivos criados para cada um dos APs.

Passo 6: Copie/cole o "ap_detection_script.py" fornecido separadamente nesta pasta e execute-o. Você pode encontrar o script no link da caixa abaixo:

https://pubhub.devnetcloud.com/media/wireless-troubleshooting-tools/docs/9800-scripts/ap_detection_script.zip

Isso cria um arquivo na mesma pasta chamado "Status_check_results.log". Essa lista contém os APs que poderiam estar em um estado problemático e precisariam de algumas etapas de recuperação/extras antes de prosseguir com a atualização.

Processo de recuperação:

Com base no estado atual de cada ponto de acesso considerado problemático, o script forneceria orientação sobre qual seria a maneira mais otimizada de recuperar esses APs.  Aqui estão as etapas detalhadas que você precisaria executar para cada uma das opções.

Opção 1: Troca de Partição

Passo 1: Certifique-se de que o AP não tenha comunicação com a controladora para evitar que o AP reverta para sua partição/versão anterior. Isso pode ser obtido por meio de uma lista de acesso no gateway do controlador.

Passo 2: A partir dos APs potencialmente afetados, configure a inicialização para a partição 2:

AP# config boot path 2

Passo 3: Reinicialize o AP para inicializá-lo com a imagem na partição 2:

AP# reset

 Passo 4: Faça com que o AP se junte ao controlador após a atualização ser concluída no controlador. O AP entra e faz o download da nova imagem.

NOTE: Se essa opção não for viável por qualquer motivo, você sempre poderá abrir um caso de TAC e continuar com a Opção 2 para esse conjunto de APs também.

Opção 2: Abra um caso de TAC para que o TAC limpe o AP do shell raiz (depois desse processo, você prossegue com a atualização normal)

Opção 3: Estado seguro, mas o AP tem uma imagem com bugs na partição de backup

Os APs terminam nesse estado principalmente após a atualização para uma versão fixa ter sido concluída. Esse estado sugere que o AP está executando uma versão fixa, mas a versão de backup ainda está com problemas. Para agir com cautela, recomendamos substituir o backup dos APs por uma boa imagem, ou seja, uma versão em que esse problema não seja visto. Dependendo do número de APs em questão, arquive o download de uma imagem para o AP ou apenas faça um pré-download sem ativá-lo.

Opção 4: A verificação de integridade da imagem falhou para esses APs

Abra um caso de TAC para que o engenheiro do TAC corrija esses APs antes de continuar com a atualização.

Opção 5: A verificação de integridade da imagem falhou para esses APs

A partição atual não é susceptível, mas o armazenamento em flash está baixo. É recomendável abrir um TAC para limpar o cnssdaemon.log do armazenamento através do devshell.