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 os APs são afetados pela ID de bug Cisco CSCwf25731 e CSCwf37271.

Contexto

Upgrades ou APSPs aplicados a sistemas que executam atualmente 17.12.4/5/6/6a ou executaram anteriormente essas versões por um período considerável de tempo podem fazer com que os modelos de AP afetados (verifique a lista de Pontos de Acesso Afetados abaixo) entrem em loop de inicialização sob certas condições, acionadas por falha de instalação de imagem devido a espaço em disco insuficiente no armazenamento de AP. Embora isso não afete as operações diárias ou SMUs, é um risco crítico durante o ISSU, atualizações completas de código do controlador ou instalações de APSP, já que esses procedimentos envolvem atualizações de imagem de pontos de acesso.

Um processo adicional precisa ser seguido, o que requer as etapas obrigatórias de pré-verificação de atualização mencionadas neste documento, já que não existe nenhuma solução alternativa de configuração.

Para resolver isso, você deve instalar a correção de versão específica do APSP (mostrada na tabela de códigos fixos abaixo) no WLC antes que os APs tentem atualizar, ou usar o APSP de limpeza (disponível para 17.15.4d e 17.18.2) se você já mudou para uma versão posterior, mas executou qualquer uma das versões afetadas. Mesmo que você não tenha certeza do histórico do seu sistema, é altamente recomendável executar verificações de armazenamento antes de qualquer atualização ou instalação de APSP se as versões afetadas estiverem presentes no seu ambiente.

Detalhes da causa raiz

Os APs que executam de 17.12.4 a 17.12.6a são afetados por um bug de biblioteca que gera um arquivo de log persistente: /storage/cnssdaemon.log. Esse arquivo cresce 5 MB diariamente e não é limpo por reinicializações, eventualmente esgotando o espaço de armazenamento do dispositivo. Consequentemente, se o AP estiver sendo executado da partição de inicialização 1 (Parte1) e a partição de inicialização 2 (Parte2) estiver cheia devido ao arquivo de log, o processo de atualização falhará porque não pode armazenar a nova imagem na partição de inicialização 2, levando potencialmente a um loop de inicialização. Para evitar isso, você deve limpar o armazenamento ou verificar se o AP foi inicializado a partir da partição 2 antes de tentar quaisquer atualizações adicionais seguindo as instruções neste documento.

Códigos e pontos de acesso afetados

Pontos de acesso afetados

Os modelos de access point a seguir são os únicos susceptíveis a esse problema. Se sua rede não utilizar nenhum desses modelos específicos, seu ambiente não será afetado e nenhuma ação adicional será necessária.

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

Códigos afetados

Para verificar isso em sua rede, execute o seguinte comando de todas as WLCs e verifique se o código presente nas WLCs está listado na tabela abaixo.

#show version | in Version

Como alternativa, você pode fazer o mesmo a partir dos APs. Verifique a saída para ver se a imagem Principal ou de Backup está executando uma imagem afetada a partir das listadas na tabela.

#show version | in Image

Note: 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.6/6a no passado, o problema não será aplicável.

Códigos fixos

A tabela a seguir lista as versões do software WLC e seus APSPs (Access Point Service Packs) correspondentes que contêm a correção para esse bug. Observe que, para as versões listadas abaixo, a correção está disponível no momento apenas através da instalação do APSP no momento da redação.

Caminho de upgrade e aplicabilidade de bug

Use a tabela abaixo para determinar se suas versões atuais de software de WLCs e APs se aplicam a esse bug e quais etapas de atualização devem ser executadas. Se sua implantação atual corresponder a qualquer uma dessas versões na tabela de caminho de atualização e aplicável a bugs, você deverá executar as pré-verificações de armazenamento explicadas na seção Pré-verificações de atualização antes de tentar qualquer atualização adicional.

Bug não aplicável e caminho de atualização

A tabela a seguir mostra se suas WLCs e APs não se aplicam a este bug:

Bug aplicável e caminho de atualização

A tabela a seguir mostra se suas WLCs e APs se aplicam a este bug:

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

Se o seu ambiente for afetado por esse bug, siga estas etapas obrigatórias para garantir uma recuperação e atualização seguras:

1. Identificar: Execute as pré-verificações manuais ou automatizadas para identificar quais Pontos de acesso específicos são aplicáveis ao bug. A pré-verificação automatizada é altamente recomendada.
2. Recuperar: Para APs sinalizados, siga os procedimentos de recuperação mencionados na seção Recuperação.
3. Verifique: Execute novamente as pré-verificações para confirmar se todos os dispositivos estão íntegros e se o problema de armazenamento foi resolvido.
4. Atualização: Continue com a atualização para os APSPs fixos listados na Tabela de versões fixas.

Pré-verificação Manual

1. Na WLC, você pode verificar as colunas das imagens Principal e de Backup para confirmar se seus Pontos de Acesso estão executando qualquer uma das versões afetadas (verifique a seção Códigos Afetados acima).

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

Você também pode executar uma verificação semelhante diretamente no nível do AP executando o seguinte comando para verificar as duas partições de imagem:

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

Verifique a partição de inicialização ativa para garantir que a imagem de backup esteja na parte 2. Use o comando "show boot" e confirme se a "BOOT path-list" aponta para a parte 1; isso indica que o AP está sendo executado atualmente a partir da partição primária e tentando atualizar para a parte secundária, o que poderia disparar o problema.

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

2. Verifique o uso atual do sistema de arquivos verificando a partição /dev/ubivol/part2. Se o "Use%" estiver próximo a 100%, a partição estará esgotada, o que fará com que a atualização falhe e poderá disparar um loop de inicialização.

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. Verifique a integridade da imagem para ambas as partições para garantir que elas não estejam corrompidas. Todos os campos das imagens Principal e de Backup devem exibir um status "Bom"; se algum campo mostrar o contrário, pare o processo e abra um caso de TAC imediatamente.

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

Pré-verificação Automatizada

Para a pré-verificação automatizada, utilize a ferramenta WLAN Poller. Essa ferramenta permite executar os comandos necessários em todos os Pontos de acesso simultaneamente para identificar os Pontos de acesso afetados; você pode fazer o download diretamente no seguinte link: https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/#wlan-poller

Etapas:

1. Extração - Extraia os arquivos de pesquisa da WLAN para o diretório de sua preferência.

2. Configuração - Atualize o arquivo "config.ini" com os parâmetros a seguir, garantindo que você insira suas credenciais específicas e o endereço IP do controlador.

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. Preparação da Lista de Comandos - Comente (adicione o símbolo de hash "#") o conteúdo padrão em "cmdlist_cos" e "cmdlist_cos_qca" e adicione os seguintes comandos a ambos os arquivos.

# 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. Execução - Execute a ferramenta usando ".\wlanpoller.exe". A ferramenta executará SSH em todos os pontos de acesso e coletará as saídas do comando.

5. Recuperação de Dados - Depois de concluída, navegue até a pasta /data recém-criada. Siga os subdiretórios até a pasta final que contém os arquivos de saída AP individuais.

6. Análise - Faça o download do "ap_detection_script.py" do link Caixa oficial, coloque-o na pasta "dados" e execute-o.

7. Revisar resultados - Abra o "Status_check_results.log" gerado para exibir a lista de APs em um estado problemático. Esses dispositivos requerem etapas de recuperação (explicadas na seção Recuperação abaixo) antes de prosseguir com a atualização, aqui uma explicação de como interpretar os resultados:

Por design, os APs podem inicializar a partir da Partição 1 ou da Partição 2. Quando uma partição está ativa, a outra é usada para downloads de imagens ou APSP. A partição de armazenamento lógico é mapeada permanentemente para a Partição 2 e não pode ser alterada. Esse problema afeta apenas os pontos de acesso que estão sendo inicializados atualmente a partir da Partição 1. Você pode verificar isso marcando a coluna "current_boot_partition_check" para verificar qual é a partição atual usada pelos APs. Exemplo:

A partir do exemplo acima, podemos concluir que dos 3 APs:

• Nome do AP: Testar AP1 (Ação Necessária): Se um AP mostrar part1 "True Susceptible" na coluna "current_boot_partition_check", você deverá verificar a coluna "part2_mem_usage_check". Se essa coluna também mostrar "True Susceptible", o AP será afetado.

  • Exemplo: O teste AP1 é afetado (inicialização na Parte1 e espaço disponível na Parte2: 51,9 MB) e exige recuperação.

• Nome do AP: Testar AP2 (Partição 1): Se um AP mostrar part1 "Verdadeiro Susceptível", mas "part2_mem_utilização_check" mostrar "Falso Não Susceptível", o AP estará seguro.

  • Exemplo: O AP2 de teste não é afetado porque tem espaço suficiente na partição 2 (parte2), no entanto, é recomendável instalar o APSP para cuidar de problemas futuros, já que o arquivo cnssdaemon.log continua existindo no AP.

• Nome do AP: Testar AP3 (Partição 2): Se um AP mostrar part2 "False Not Susceptible" na coluna "current_boot_partition_check", ele não será afetado. Não são necessários mais controlos.

Note: Note: O valor numérico que aparece na coluna "part2_mem_usage_check" ao lado do status "True/False Susceptible" representa a quantidade de espaço disponível na Partição 2.

• Qualquer ponto de acesso: Se qualquer AP mostrar "Verificação da integridade da imagem: Falhou" na coluna "image_integrity_check", continue abrindo um caso no TAC.

Recuperação

Com base no estado específico de cada AP, o script recomendará o método de recuperação mais eficiente. Siga as etapas detalhadas abaixo para os APs afetados identificados:

Troca de partição de imagem AP

1. Isolar APs - certifique-se de que os APs não tenham conectividade com a WLC:
   1. Certifique-se de que o SSH esteja habilitado no perfil de junção de APs e que os APs estejam acessíveis ao SSH (ou use o console)
   2. Certifique-se de que os APs não tenham conectividade com a WLC, mas você ainda tem acesso SSH aos APs. Isso pode ser feito tendo uma ACL no gateway ou movendo os APs para uma VLAN isolada. Se os APs obtiverem acesso à WLC, o AP poderá reverter para a inicialização Part1 e voltará para o estado afetado.

2. Configure Boot Path - Nos APs afetados, defina o caminho de inicialização para a partição 2:

AP# config boot path 2

3. Reboot - Reinicie o AP para carregar a imagem da partição 2:

AP# reload

4. Upgrade - Instale na WLC o APSP necessário em seu código atual, ou, se você fosse atualizar o código, mova-o para um novo código e certifique-se de que o APSP também esteja instalado.

5. Reconectar - Depois que o upgrade do controlador estiver concluído, remova o interruptor de comunicação entre o AP e o WLC. O AP se juntará à WLC e baixará automaticamente a nova imagem fixa na inicialização Part1.

6. Verificação Dupla - Depois de atualizar para uma versão fixa, verifique ambas as partições dos APs para garantir que o slot de backup ainda não contenha a imagem de erro.

7. Manutenção - Para manter a estabilidade a longo prazo e evitar loops de inicialização futuros, recomendamos substituir a partição de backup por uma imagem em boas condições. Para grupos menores, use o arquivo "download-sw" diretamente no AP; para implantações maiores, execute um pré-download de AP de WLC para atualizar a partição de backup sem disparar a ativação da imagem do AP.

Recuperação de acesso ao shell do AP

O Centro de Assistência Técnica (TAC) pode executar a recuperação manual limpando o arquivo cnssdaemon.log diretamente do shell nos Pontos de Acesso afetados. Dependendo da escala do impacto, há dois métodos mencionados abaixo:

• Pequeno número de APs afetados: Para uma pequena quantidade de APs afetados, o TAC pode continuar usando uma das duas abordagens:

  • Acesso manual ao shell: Acesse cada Ponto de acesso individualmente via shell para limpar manualmente o arquivo de log.

  • Acesso automatizado (em massa) ao shell: Use a ferramenta RADKit para automatizar o processo de limpeza para todos os APs afetados.

• Grande número de APs afetados: o TAC deve usar a ferramenta Radkit, que permite o acesso em massa do shell a todos os APs afetados simultaneamente para executar o processo de limpeza de forma eficiente.

Note: Recomendamos o uso do RADKit para o procedimento de recuperação de acesso de shell do AP para garantir eficiência e consistência.

Note: Para fazer o download do Radkit, use este link: Radkit Faça o download e o download da versão mais recente. Para instalar o Radkit, siga este vídeo: Instalação do Radkit

Quando abrir um caso de TAC

Abra um caso TAC imediatamente se ocorrer qualquer uma das seguintes condições:

• Falha na recuperação: O procedimento AP Image AP Image Partition Swap falha ou não pode ser implementado em seu ambiente.
• Problemas de integridade: As pré-verificações manuais ou automatizadas retornam uma "Verificação de integridade da imagem: Falhou" para qualquer AP.
• Esgotamento do armazenamento: Se após a atualização/instalação de APSP a partição "/dev/ubivol/part2" mostra ainda um uso criticamente alto.

O Cisco TAC pode acessar o shell do AP para limpar manualmente o arquivo cnssdaemon.log e executar ações de recuperação avançadas para restaurar seus dispositivos.

Perguntas freqüentes

P: Esse problema se aplica apenas a atualizações completas de código ou também afeta as instalações de APSP?

R: Esse problema afeta ambos os cenários. Se seu ambiente atender aos critérios para esse bug, o problema pode ocorrer durante uma atualização de código completo ou instalação de APSP (incluindo o APSP com a correção de bug). Conclua a seção de pré-verificações de atualização para determinar se você precisa seguir as etapas de recuperação antes de aplicar quaisquer atualizações ou APSPs.

P: Meus WLC e APs estão em 17.9.x (ou anterior) e eu preciso atualizar para 17.12.x. O que devo fazer?

R: Você pode executar uma atualização direta de 17.9.x para 17.12.x. No entanto, se seus modelos de AP são susceptíveis a este bug, certifique-se de instalar o APSP recomendado imediatamente após a atualização.

P: Meus WLCs e APs estão em 17.9.x (ou anterior) e eu preciso atualizar para 17.15.x ou superior.

R: Há dois cenários possíveis:

• Atualização direta: Se o seu ambiente permitir uma atualização direta (verifique através das Notas de versão do seu código de destino), prossiga com a atualização e instale o APSP para esse código de destino.
• Atualização Intermediária: Se você deve seguir um caminho de atualização (por exemplo, 17.9.x → 17.12.x → 17.15.x), recomendamos concluir a sequência inteira para 17.15.x no mesmo dia. Como o arquivo cnssdaemon.log cresce 5 MB diariamente, concluir a atualização rapidamente impede que o arquivo atinja um tamanho crítico. Se uma atualização de mesmo dia não for possível, você deve instalar o APSP na etapa 17.12.x antes de, eventualmente, passar para 17.15.x e instalar seu respectivo APSP.

P: Já estou em 17.15.x. Isso significa que eu não sou afetado por este bug?

R: Não necessariamente. Se seus APs executavam anteriormente a versão 17.12.4, 17.12.5 ou 17.12.6/6a (em 9800-L/40/80/CL), o arquivo de registro problemático pode já ter sido gerado e permanecer no armazenamento. É altamente recomendável seguir a seção Pré-Verificações de Atualização para garantir que todos os arquivos residuais sejam limpos.

P: Eu uso as plataformas 9800-M, 9800-H1 ou 9800-H2, que foram suportadas pela primeira vez na versão 17.15. Sou afetado?

R: Há dois cenários possíveis:

• Primeiro a entrar na WLC: Se seus APs se juntaram a um 9800-M/H1/H2 como seu primeiro controlador, você não será afetado.
• WLCs anteriores ingressaram: Se esses APs foram previamente unidos a uma controladora diferente executando uma versão afetada (17.12.4/5/6/6a) antes de passarem para o 9800-M/H1/H2, eles ainda poderão carregar o arquivo problemático. Nesse caso, siga a seção de pré-verificações de atualização.

P: Temos WLCs separadas para testes de laboratório e atualizações escalonadas. Como devemos lidar com elas?

R: Certifique-se de que todas as WLCs em seu ambiente estejam executando o APSP apropriado. Como o arquivo cnssdaemon.log cresce 5 MB diariamente, qualquer AP que se une a uma WLC executando o código afetado, mesmo temporariamente para teste, se tornará potencialmente susceptível a esse bug.