Convalida e ripristino dei punti di accesso Catalyst sulla versione 17.12 interessati dall'errore di aggiornamento

Introduzione

Questo documento descrive la procedura di ripristino quando sui punti di accesso viene rilevato l'ID bug Cisco CSCwf25731 e CSCwf37271.

Contesto

Aggiornamenti o APSP applicati ai sistemi che attualmente eseguono 17.12.4/5/6/6a o che hanno eseguito queste versioni in precedenza per un periodo di tempo considerevole possono causare l'ingresso dei modelli AP interessati (controllare l'elenco dei punti di accesso interessati riportato di seguito) nel loop di avvio in determinate condizioni, innescato da un errore di installazione dell'immagine a causa di spazio su disco insufficiente sullo storage AP. Anche se questo non influisce sulle operazioni quotidiane o sulle SMU, è un rischio critico durante l'ISSU, gli aggiornamenti completi del codice del controller o l'installazione dell'APSP, poiché queste procedure implicano l'aggiornamento dell'immagine dei punti di accesso.

Poiché non sono disponibili soluzioni alternative per la configurazione, è necessario eseguire un processo aggiuntivo che richiede l'aggiornamento obbligatorio e la verifica preliminare dei passaggi menzionati in questo documento.

Per risolvere questo problema, è necessario installare la correzione della versione APSP specifica (mostrata nella tabella dei codici fissi riportata di seguito) nel WLC prima che gli AP tentino di aggiornare, oppure utilizzare la correzione APSP (disponibile per 17.15.4d e 17.18.2) se si è già passati a una versione successiva ma si è eseguita una delle versioni interessate. Anche se non si è certi della cronologia del sistema, si consiglia di eseguire controlli di storage prima di qualsiasi aggiornamento o installazione APSP se le versioni interessate sono mai state presenti nell'ambiente.

Dettagli causa principale

I punti di accesso che eseguono le versioni da 17.12.4 a 17.12.6a sono interessati da un bug della libreria che genera un file di log persistente: /storage/cnssdaemon.log. Questo file aumenta di 5 MB al giorno e non viene cancellato dal riavvio, con conseguente esaurimento dello spazio di storage del dispositivo. Di conseguenza, se l'access point è in esecuzione dalla partizione di avvio 1 (Parte1) e la partizione di avvio 2 (Parte2) è piena a causa del file di log, il processo di aggiornamento non riuscirà perché non è in grado di archiviare la nuova immagine nella partizione di avvio 2, con il rischio di generare un loop di avvio. Per evitare questo problema, è necessario cancellare l'archiviazione o accertarsi che l'access point sia stato avviato dalla partizione 2 prima di tentare ulteriori aggiornamenti seguendo le istruzioni riportate in questo documento.

Codici e punti di accesso interessati

Access point interessati

I modelli di Access Point seguenti sono gli unici a essere soggetti a questo problema. Se la rete non utilizza uno di questi modelli specifici, l'ambiente non viene influenzato e non sono necessarie ulteriori azioni.

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

Codici interessati

Per verificare questa condizione in tutta la rete, eseguire il comando seguente da tutti i WLC e verificare se il codice presente nei WLC è elencato nella tabella seguente.

#show version | in Version

In alternativa, è possibile eseguire la stessa operazione dagli access point. Controllare l'output per verificare se l'immagine primaria o di backup esegue un'immagine interessata da quelle elencate nella tabella.

#show version | in Image

Nota: Nota: In generale, se la rete non è in esecuzione e non ha eseguito 17.12.4, 17.12.5, 17.12.6/6a in passato, il problema non è applicabile.

Codici fissi

Nella tabella seguente vengono elencate le versioni del software WLC e i relativi APSP (Access Point Service Pack) corrispondenti che contengono la correzione per questo bug. Si noti che per le versioni elencate di seguito, la correzione è attualmente disponibile solo tramite l'installazione di APSP al momento della scrittura.

Percorso di aggiornamento e applicabilità dei bug

Utilizzare la tabella seguente per determinare se le versioni software dei WLC e degli AP correnti sono valide per questo bug e quali passaggi di aggiornamento eseguire. Se la distribuzione corrente corrisponde a una di queste versioni nella tabella Bug applicabile e percorso di aggiornamento, è necessario eseguire le verifiche preliminari dell'archiviazione descritte nella sezione Controlli preliminari aggiornamento prima di tentare ulteriori aggiornamenti.

Bug non applicabile e percorso di aggiornamento

Nella tabella seguente viene indicato se i WLC e gli AP non sono applicabili al bug:

Bug applicabile e percorso di aggiornamento

Nella tabella seguente viene indicato se i WLC e gli AP sono applicabili al bug:

Aggiorna controlli preliminari

Se l'ambiente è interessato dal bug, seguire le istruzioni obbligatorie per garantire un ripristino e un aggiornamento sicuri:

1. Identifica: Eseguire i controlli preliminari manuali o automatici per identificare i punti di accesso specifici applicabili al bug. La verifica preliminare automatica è consigliata.
2. Ripristina: Per tutti gli access point contrassegnati, seguire le procedure di ripristino menzionate nella sezione Ripristino.
3. Verifica: Eseguire di nuovo i controlli preliminari per verificare che tutti i dispositivi siano integri e che il problema di storage sia stato risolto.
4. Aggiornamento: Procedere con l'aggiornamento alle APSP fisse elencate nella tabella delle versioni fisse.

Precontrollo manuale

1. Dal WLC è possibile controllare le colonne dell'immagine primaria e di backup per verificare se i punti di accesso eseguono le versioni interessate (controllare la sezione Codici interessati sopra).

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

È inoltre possibile eseguire una verifica simile direttamente a livello di punto di accesso eseguendo il comando seguente per controllare entrambe le partizioni dell'immagine:

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

Verificare la partizione di avvio attiva per assicurarsi che l'immagine di backup si trovi nella parte 2. Utilizzare il comando "show boot" e verificare che "BOOT path-list" punti alla parte 1; ciò indica che l'access point è attualmente in esecuzione dalla partizione primaria e sta tentando di eseguire l'aggiornamento nella parte secondaria, il che potrebbe causare il problema.

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

2. Verificare l'utilizzo corrente del file system controllando la partizione /dev/ubivol/part2. Se "Use%" è vicino al 100%, la partizione è esaurita e l'aggiornamento non riesce e potrebbe verificarsi un loop di avvio.

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. Verificare l'integrità dell'immagine per entrambe le partizioni per accertarsi che non siano danneggiate. Lo stato di tutti i campi delle immagini primarie e di backup deve essere "Buono"; se in un campo qualsiasi viene visualizzato diversamente, interrompere la procedura e aprire immediatamente una richiesta 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

Precontrollo automatico

Per il controllo preliminare automatico, usare lo strumento WLAN Poller. Questo strumento consente di eseguire i comandi necessari su tutti i punti di accesso simultaneamente per identificare i punti di accesso interessati; è possibile scaricarlo direttamente dal seguente link: https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/#wlan-poller

Passaggi:

1. Estrazione - Estrarre i file del controller WLAN nella directory preferita.

2. Configuration - Aggiornare il file "config.ini" con i seguenti parametri, accertandosi di immettere le credenziali specifiche e l'indirizzo IP del controller.

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. Preparazione elenco comandi - Commentare (aggiungere il simbolo hash "#") il contenuto predefinito in "cmdlist_cos" e "cmdlist_cos_qca", quindi aggiungere i seguenti comandi a entrambi i file.

# 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. Esecuzione - Eseguire lo strumento utilizzando ".\wlanpoller.exe". Lo strumento collegherà il protocollo SSH a tutti i punti di accesso e raccoglierà gli output del comando.

5. Recupero dati - Al termine, passare alla cartella /data appena creata. Seguire le sottodirectory fino alla cartella finale contenente i singoli file di output AP.

6. Analysis - Scaricare "ap_detection_script.py" dal collegamento ufficiale Box, posizionarlo nella cartella "dati" ed eseguirlo.

7. Esamina risultati - Aprire il file "Status_check_results.log" generato per visualizzare l'elenco degli access point in stato di problema. Prima di procedere con l'aggiornamento, questi dispositivi richiedono delle fasi di ripristino (come spiegato nella sezione Ripristino riportata di seguito). Di seguito è riportata una spiegazione di come interpretare i risultati:

In base alla progettazione, gli access point possono essere avviati dalla partizione 1 o dalla partizione 2. Quando una partizione è attiva, l'altra viene utilizzata per i download di immagini o di file APSP. La partizione di archiviazione logica è mappata in modo permanente alla partizione 2 e non può essere modificata. Questo problema interessa solo i punti di accesso che stanno eseguendo l'avvio dalla partizione 1. È possibile verificarlo controllando la colonna "current_boot_partition_check" per verificare qual è la partizione corrente utilizzata dagli access point. Esempio:

Dall'esempio precedente si può concludere che dai 3 punti di accesso:

• Nome punto di accesso: Test AP1 (azione richiesta): Se nella colonna "current_boot_partition_check" di un punto di accesso è visualizzato part1 "True Senseptible", è necessario controllare la colonna "part2_mem_usage_check". Se anche in questa colonna viene visualizzato "True Susceptible", il punto di accesso ne risente.

  • Esempio: Il test AP1 è interessato (avvio nella parte 1 e nella parte 2 dello spazio disponibile: 51,9 MB) e richiede il ripristino.

• Nome punto di accesso: Test AP2 (partizione 1): Se in un punto di accesso è visualizzato il valore "True Susceptible" per la parte 1, ma in "part2_mem_usage_check" è visualizzato il valore "False Not Susceptible", il punto di accesso è sicuro.

  • Esempio: Il test dell'AP2 non è influenzato dal fatto che dispone di spazio sufficiente nella partizione 2 (parte 2). Tuttavia, si consiglia di installare l'APSP per risolvere problemi futuri, poiché il file cnssdaemon.log continua a esistere nell'AP.

• Nome punto di accesso: Test AP3 (partizione 2): Se un access point visualizza la parte 2 "False Not Subible" nella colonna "current_boot_partition_check", l'operazione non ha alcun effetto. Non sono necessari ulteriori controlli.

Nota: Nota: Il valore numerico visualizzato nella colonna "part2_mem_usage_check" accanto allo stato "Vero/Falso suscettibile" rappresenta la quantità di spazio disponibile nella partizione 2.

• Qualsiasi punto di accesso: Se in un punto di accesso è visualizzato "Controllo integrità immagine: Failed" (Non riuscito) nella colonna "image_integration_check" (Immagine_integrità_controllo). Aprire una richiesta TAC.

Ripristino

In base allo stato specifico di ciascun punto di accesso, lo script consiglierà il metodo di ripristino più efficiente. Attenersi alla procedura dettagliata seguente per i punti di accesso interessati identificati:

Scambio partizione immagine AP

1. Isolate AP (Isolate APs) - verificare che gli AP non abbiano connettività con il WLC:
   1. Verificare che il protocollo SSH sia abilitato nel profilo di join degli access point e che gli access point siano accessibili dal protocollo SSH (o usare la console)
   2. verificare che gli AP non siano collegati al WLC, ma sia comunque possibile accedere al protocollo SSH sugli AP. A tale scopo, è possibile avere un ACL nel gateway o spostare gli AP su una VLAN isolata. Se gli AP ottengono l'accesso al WLC, l'AP potrebbe tornare all'avvio della parte 1 e tornare allo stato interessato.

2. Configurare il percorso di avvio - Sui punti di accesso interessati, impostare il percorso di avvio sulla partizione 2:

AP# config boot path 2

3. Reboot - Riavviare l'access point per caricare l'immagine dalla partizione 2:

AP# reload

4. Upgrade - Installare nel WLC l'APSP necessario nel codice corrente oppure, se si intendeva aggiornare il codice, passare a un nuovo codice e assicurarsi che sia installato anche APSP.

5. Riconnettere - Al termine dell'aggiornamento del controller, rimuovere il dispositivo di arresto della comunicazione tra l'access point e il WLC. L'access point si unirà al WLC e scaricherà automaticamente la nuova immagine fissa nell'avvio della parte 1.

6. Doppio controllo: dopo l'aggiornamento a una versione fissa, verificare entrambe le partizioni degli access point per assicurarsi che lo slot di backup non contenga ancora l'immagine del bug.

7. Manutenzione - Per mantenere la stabilità a lungo termine ed evitare futuri loop di avvio, si consiglia di sovrascrivere la partizione di backup con un'immagine sicuramente valida. Per i gruppi più piccoli, utilizzare l'archivio "download-sw" direttamente sull'access point; per implementazioni più grandi, eseguire un pre-download dell'access point WLC per aggiornare la partizione di backup senza attivare l'immagine AP.

Ripristino dell'accesso alla shell AP

I centri Cisco TAC (Technical Assistance Center) possono eseguire il recupero manuale cancellando il file cnssdaemon.log direttamente dalla shell sui punti di accesso interessati. A seconda della portata dell'impatto, sono disponibili due metodi, descritti di seguito:

• Numero ridotto di access point interessati: Per una piccola quantità di access point interessati, il TAC può procedere con uno dei due seguenti approcci:

  • Accesso manuale alla shell: Accedere a ciascun punto di accesso singolarmente tramite la shell per cancellare manualmente il file di registro.

  • Accesso automatizzato (bulk) alla shell: Utilizzare lo strumento RADKit per automatizzare il processo di pulizia di tutti gli access point interessati.

• Grande numero di punti di accesso interessati: TAC utilizza lo strumento Radkit, che consente l'accesso in blocco a tutti i punti di accesso interessati contemporaneamente per eseguire il processo di pulizia in modo efficiente.

Nota: Si consiglia di utilizzare RADKit per la procedura di recupero dell'accesso alla shell AP per garantire efficienza e coerenza.

Nota: Per scaricare Radkit, utilizzare questo collegamento: Radkit Scarica e scarica la versione più recente. Per installare Radkit, seguire questo video: Installazione di Radkit

Quando aprire una richiesta TAC

Apri immediatamente una richiesta TAC se si verifica una delle seguenti condizioni:

• Ripristino non riuscito: La procedura di scambio della partizione dell'immagine AP (AP Image AP) ha esito negativo o non può essere implementata nell'ambiente in uso.
• Problemi di integrità: I controlli preliminari manuali o automatici restituiscono un "Controllo integrità immagine: Stato "Failed" (Non riuscito) per qualsiasi access point.
• Esaurimento dello storage: Se dopo l'aggiornamento o l'installazione di APSP la partizione "/dev/ubivol/part2" mostra ancora un utilizzo elevato.

Cisco TAC può accedere alla shell dell'access point per cancellare manualmente il file cnssdaemon.log ed eseguire azioni di ripristino avanzate per ripristinare i dispositivi.

Wireless LAN Controller serie 9800

Q: Il problema riguarda solo gli aggiornamenti completi del codice o anche le installazioni di APSP?

A: Questo problema interessa entrambi gli scenari. Se l'ambiente soddisfa i criteri per questo bug, il problema può verificarsi durante un aggiornamento completo del codice o l'installazione di APSP (incluso l'APSP con la correzione del bug). Completare la sezione dei controlli preliminari dell'aggiornamento per determinare se è necessario eseguire la procedura di ripristino prima di applicare qualsiasi aggiornamento o programma di manutenzione delle app.

Q: Il WLC e gli access point sono sulla versione 17.9.x (o precedente) e occorre eseguire l'aggiornamento alla versione 17.12.x. Come si deve procedere?

A: È possibile eseguire un aggiornamento diretto da 17.9.x a 17.12.x. Tuttavia, se i modelli AP in uso sono soggetti a questo bug, assicurarsi di installare l'APSP consigliato subito dopo l'aggiornamento.

Q: Il WLC e gli access point sono sulla versione 17.9.x (o precedente) e devo eseguire l'aggiornamento alla versione 17.15.x o successiva.

A: Esistono due possibili scenari:

• Aggiornamento diretto: Se l'ambiente in uso consente un aggiornamento diretto (verificare tramite le Note sulla versione per il codice di destinazione), procedere con l'aggiornamento e quindi installare l'APSP per il codice di destinazione.
• Aggiornamento intermedio: Se è necessario seguire un percorso di aggiornamento (ad esempio, 17.9.x → 17.12.x → 17.15.x), si consiglia di completare l'intera sequenza fino a 17.15.x entro lo stesso giorno. Poiché il file cnssdaemon.log aumenta di 5 MB al giorno, il completamento dell'aggiornamento consente di evitare che il file raggiunga le dimensioni critiche. Se non è possibile eseguire l'aggiornamento in giornata, è necessario installare l'APSP nella fase 17.12.x prima di procedere alla fase 17.15.x e installare l'APSP corrispondente.

Q: Sono gia' al 17.15. Significa che non sono affetto da questo bug?

A: Non necessariamente. Se in precedenza la versione degli access point era 17.12.4, 17.12.5 o 17.12.6/6a (su 9800-L/40/80/CL), è possibile che il file di log con problemi sia già stato generato e rimanga in memoria. Per garantire la pulizia dei file residui, si consiglia di seguire la sezione Precontrolli di aggiornamento.

Q: Uso le piattaforme 9800-M, 9800-H1 o 9800-H2, supportate per la prima volta nella release 17.15.

A: Esistono due possibili scenari:

• È la prima volta che si unisce al WLC: Se gli access point sono stati collegati a un 9800-M/H1/H2 come primo controller, l'operazione non ha alcun impatto.
• WLC precedenti aggiunti: Se tali access point erano stati precedentemente collegati a un controller diverso che esegue una versione interessata (17.12.4/5/6/6a) prima di passare al 9800-M/H1/H2, potrebbero ancora trasportare il file con problemi. In tal caso, seguire la sezione dei controlli preliminari per l'aggiornamento.

Q: Abbiamo WLC separati per i test di laboratorio e gli aggiornamenti scaglionati, Come dovremmo gestirli?

A: Accertarsi che tutti i WLC nell'ambiente in uso eseguano l'APSP appropriato. Poiché il file cnssdaemon.log aumenta di 5 MB al giorno, qualsiasi access point che entra a far parte di un WLC eseguendo il codice interessato, anche temporaneamente per il test, sarà potenzialmente vulnerabile a questo bug.