Contents

Introdução

Pontos de acesso afetados

Contexto

Detalhes da causa raiz

Procedimento de verificação de atualização

Versões fixas

Pré-verificações

Script de pré-verificação

Pesquisa de WLAN(Pode ser baixado aqui)

Processo de recuperação:

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

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

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

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

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

Versão atual

Destino

Aplicabilidade do Problema

Antes de atualizar, é necessário Pré-verificar

Caminho de Destino/Atualização

Pré-verificação de Atualização

Comentários

17.3.x / 17.6.x / 17.9 x

17.12.x

No

No

17.12.4 + APSPx 17.12.5 + APSPx

17.12.6a + APSPx

17.12.7

No

Verificar destino Notas de versão

17,9.x

Qualquer um (exceto 17.12.4/5/6a)

No

No

Siga o caminho de atualização de destino

No

17.9.1 a .5 não oferecem suporte à atualização direta para 17.15, use 17.9.6 ou superior

Para obter mais informações, verifique as notas de versão

17.12.1 a 17.12.3

Qualquer (Exceto 17.12.4/5/6a)

No

No

Siga o caminho de atualização de destino

Processo regular

Verificar destino Notas de versão

17.12.4/5/6a

17.12.x(4,5,6a etc.), APSP

Yes

Yes

17.12.4 + APSPx 17.12.5 + APSPx

17.12.6a + APSPx

17.12.7

Yes

Depois de instalar um APSP fixo, não são necessárias pré-verificações adicionais para atualizações futuras do 17.12

17.12.4/5/6a

17.15.x/17.18.x

Yes

Yes

Atualize o respectivo APSP 17.12.x e depois atualize para 17.15.x + APSPx ou 17.18.x + APSPx

Sim para a primeira atualização do APSP 17.12 e Não para as atualizações subsequentes.

Qualquer versão, a imagem anterior era uma das 17.12.4/5/6a

17.15.x

Yes

Yes

17.15.x + APSPx

Yes

Qualquer versão, a imagem anterior era uma das 17.12.4/5/6a

17.18.x

Yes

Yes

17.18.x + APSPx

Yes

17,15+

Nova implantação

qualquer um

No

No

qualquer um

No

17.18.

Nova implantação

qualquer um

No

No

qualquer um

No

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

Controlador

Versão da imagem do 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

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.