Catalyst-AP's valideren en herstellen op 12 .12 die zijn beïnvloed door een upgradefout

Inleiding

Dit document beschrijft de validatie- en herstelprocedure wanneer toegangspunten worden beïnvloed door Cisco bug ID CSCwf25731 en CSCwf37271.

Interactieve ondersteuning

Als u zich aanmeldt met uw CCO-referenties, kan Cisco AI Assistant for Support helpen om interactief te bepalen of deze bug van toepassing is op uw netwerk en of het vervolgens is om herstelopties te bepalen. Aan de slag:

1. Klik op het pictogram Cisco AI Assistant for Support rechtsonder in het document.
   • 
2. Log in met uw Cisco-referenties.
3. Eenmaal ingelogd, vernieuw je de tab/het document van je browser.
4. Klik op het pictogram van de bot in de rechterbenedenhoek om vragen te stellen met betrekking tot dit document.
   
   • 

Begin voor het beste resultaat met eenvoudige vragen en verhoog geleidelijk de complexiteit. Als een reactie niet bevredigend is, klik dan op het pictogram met de duimen omlaag om ons feedback te geven. U kunt altijd naar dit document terugverwijzen als de antwoorden van Cisco AI Assistant for Support onduidelijk zijn.

context

Upgrades of APSP's die worden toegepast op systemen die momenteel worden uitgevoerd op 17.12.4/5/6/6a of die deze versies eerder gedurende een aanzienlijke tijd hebben uitgevoerd, kunnen ertoe leiden dat de betreffende Access Point-modellen (raadpleeg de lijst met getroffen toegangspunten hieronder) onder bepaalde omstandigheden in de opstartlus terechtkomen, veroorzaakt door een storing in de installatie van het image als gevolg van onvoldoende schijfruimte op Access Point-opslag. Hoewel dit geen invloed heeft op dagelijkse activiteiten of SMU's, is het een kritiek risico tijdens ISSU, upgrades van de volledige controllercode of APSP-installaties, omdat deze procedures gepaard gaan met upgrades van het Access Points-image.

Er moet een extra proces worden gevolgd waarvoor verplichte stappen voor het vooraf controleren van upgrades nodig zijn die in dit document worden vermeld, omdat er geen configuratie-oplossing bestaat.

Om dit op te lossen, moet u de specifieke APSP-versiefix installeren (weergegeven in de tabel Vaste codes hieronder) in de WLC voordat de toegangspunten proberen te upgraden, of de opruimings-APSP gebruiken (beschikbaar voor 17.15.4d en 17.18.2) als u al naar een latere release bent verhuisd maar een van de getroffen versies hebt uitgevoerd. Zelfs als u niet zeker bent van uw systeemgeschiedenis, wordt het ten zeerste aanbevolen om opslagcontroles uit te voeren voordat een upgrade of APSP-installatie wordt uitgevoerd als de getroffen versies ooit in uw omgeving aanwezig waren.

Root Cause Details

Toegangspunten die lopen van 17.12.4 tot en met 17.12.6a worden beïnvloed door een bibliotheekbug die een persistent logbestand genereert: /storage/cnssdaemon.log. Dit bestand groeit dagelijks met 5 MB en wordt niet gewist door opnieuw op te starten, waardoor de opslagruimte van het apparaat uiteindelijk wordt uitgeput. Als het toegangspunt wordt uitgevoerd vanaf opstartpartitie 1 (deel 1) en opstartpartitie 2 (deel 2) vol is vanwege het logbestand, zal het upgradeproces mislukken omdat het nieuwe image niet kan worden opgeslagen in opstartpartitie 2, wat mogelijk leidt tot een opstartlus. Om dit te voorkomen, moet u de opslag wissen of ervoor zorgen dat het toegangspunt is opgestart vanaf partitie 2 voordat u verdere upgrades probeert uit te voeren door de instructies in dit document uit te voeren.

Betrokken codes en toegangspunten

Betrokken toegangspunten

De volgende Access Point-modellen zijn de enige die gevoelig zijn voor dit probleem. Als uw netwerk geen gebruik maakt van een van deze specifieke modellen, wordt uw omgeving niet beïnvloed en is er geen verdere actie vereist.

• Katalysator 9124 (I/D/E)
• Katalysator 9130 (I/E)
• Katalysator 9136I
• Katalysator 9162I
• Katalysator 9163E
• Katalysator 9164I
• Katalysator 9166 (I/D1)
• Katalysator IW9167 (I/E)

Betrokken codes

Als u dit in uw netwerk wilt verifiëren, voert u de volgende opdracht uit vanuit alle WLC's en controleert u of de code die in uw WLC's aanwezig is, in de onderstaande tabel wordt vermeld.

WLC# show version | in Version

Als alternatief kunt u hetzelfde doen vanaf de toegangspunten. Controleer de uitvoer om te zien of op het primaire image of het back-upimage een beïnvloed image wordt uitgevoerd van de images die in de tabel worden vermeld.

AP# show version | in Image

Door controller beïnvloede code	Afbeelding met invloed op toegangspunt
17.12.4	Van 17.12.4.0 tot 17.12.4.212
17.12.5	Van 17.12.5.0 tot 17.12.5.208
17.12.6/6a	Van 17.12.6.0 tot 17.12.6.200

Vaste codes

In de volgende tabel staan de WLC-softwareversies en de bijbehorende APSP's (Access Point Service Packs) die de oplossing voor deze bug bevatten. Houd er rekening mee dat voor de onderstaande versies de oplossing momenteel alleen beschikbaar is via APSP-installatie op het moment van schrijven.

Vaste controller en APSP-code	Vaste afbeelding van toegangspunt
17 12,4 + APSP13	17.12.4.213
17 12,5 + APSP9	17.12.5.209
17 12,6 bis + APSP1	17.12.6.201
17.12.7 bis	17.12.7.13
17 15,3 + APSP12	17.15.3.212
17,15,4 b + APSP6	17.15.4.206
17.15.4d + APSP1	17.15.4.225
17.15.5	17.15.5.36
17 18 1 + APSP3	17.18.1.203
17 18,2 + APSP1	17.18.2.201

Upgradepad en toepasselijkheid van bugs

Gebruik de onderstaande tabel om te bepalen of uw huidige WLC's en Access Points-softwareversies van toepassing zijn op deze bug en welke upgradestappen u moet nemen. Als uw huidige implementatie overeenkomt met een van deze versies in de tabel met het toepasselijke bug- en upgradepad, moet u de voorcontroles voor opslag uitvoeren die worden uitgelegd in het gedeelte Upgrade Prechecks voordat u verdere upgrades probeert.

Bug niet van toepassing en upgradepad

De volgende tabel laat zien of uw WLC's en toegangspunten niet van toepassing zijn voor deze bug:

Huidige code	Doelcode	Toepasselijkheid van bug	Vóór upgrade - voorcontrole vereist	Doel-/upgradepad	Upgrade precheck	Opmerkingen
17,3,x / 17,6,x / 17,9 x	17,12 x	Nee	Nee	17.12.4 + APSPx 17.12.5 + APSPx17.12.6a + APSPx17.12.7	Nee	Releasebrieken bestemming controleren
17,9,x	Alle (behalve 17.12.4/5/6/6a)	Nee	Nee	Upgradepad voor bestemming volgen	Nee	17.9.1 tot .5 Ondersteunt geen directe upgrade naar 17.15, gebruik 17.9.6 of hoger voor meer informatie Controleer de release notes
17.12.1 tot en met 17.12.3	Alle (behalve 17.12.4/5/6/6a)	Nee	Nee	Upgradepad voor bestemming volgen	regulier proces	Releasebrieken bestemming controleren
17.15+Nieuwe implementatie	Alle	Nee	Nee	Alle	Nee
17.18.+Nieuwe implementatie	Alle	Nee	Nee	Alle	Nee

Toepasselijk bug- en upgradepad

De volgende tabel laat zien of uw WLC's en toegangspunten wel van toepassing zijn voor deze bug:

Huidige code	Doelcode	Toepasselijkheid van bug	Vóór upgrade - voorcontrole vereist	Doel-/upgradepad	Upgrade precheck	Opmerkingen
17.12.4/5/6/6a	17.12.x (4,5,6,6a enz.), APSP	Ja	Ja: raadpleeg het gedeelte Voorcontrole bijwerken	17.12.4 + APSP, 17.12.5 + APSP, 17.12.6a + APSP, 17.12.7	Ja	Na het installeren van een vaste APSP zijn er geen extra voorcontroles nodig voor toekomstige 10 .12 upgrades
17.12.4/5/6/6a	17,15 x / 17,18 x	Ja	Ja: raadpleeg het gedeelte Voorcontrole bijwerken	Upgrade de respectieve 17.12.x APSP en upgrade vervolgens naar 17.15.x + APSP of 17.18.x + APSP	Ja voor de eerste 10 .12 APSP-upgrade en nee voor de volgende upgrades.
Elke release, maar vorige afbeelding was er een van 17.12.4/5/6/6a	17 15 x	Ja	Ja: raadpleeg het gedeelte Voorcontrole bijwerken	17.15.x + APSP	Ja
Elke release, maar vorige afbeelding was er een van 17.12.4/5/6/6a	17,18 x	Ja	Ja: raadpleeg het gedeelte Voorcontrole bijwerken	17.18.x + APSP	Ja

Upgrade voorcontroles

Om ervoor te zorgen dat toegangspunten voldoende vrije ruimte hebben in partitie 2 (deel 2) voor code- of APSP-installatie, moeten de volgende stappen worden gevolgd om de opslagruimte veilig te herstellen:

1. Identificeren: Voer de handmatige of geautomatiseerde voorcontroles uit om te bepalen welke specifieke toegangspunten van toepassing zijn op de bug. Automatische precheck wordt sterk aanbevolen.
2. Herstellen: Voor toegangspunten die in deel 2 zijn gemarkeerd met weinig ruimte, volgt u de herstelprocedures die worden vermeld in het gedeelte Space Recovery.
3. Verifiëren: Voer de voorcontroles opnieuw uit om te bevestigen dat alle apparaten gezond zijn en dat het probleem met de beschikbare ruimte in deel 2 is opgelost.
4. Upgrade: ga verder met de upgrade naar de vaste APSP's die worden vermeld in het gedeelte Vaste codes.

Er zijn 2 methoden voor prechecks:

• manueel
• geautomatiseerd

De aanbevolen methode is de geautomatiseerde methode, omdat het tijd bespaart en menselijke fouten voorkomt.

Handmatige voorcontrole

1. Vanuit de WLC kunt u de kolommen Primaire back-up en Image Backup controleren om te bevestigen of uw toegangspunten een van de getroffen releases uitvoeren (raadpleeg het gedeelte Affected Codes hierboven).

WLC# show ap image
Total number of APs  : 4

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

U kunt een soortgelijke verificatie ook rechtstreeks op het niveau van het toegangspunt uitvoeren door de volgende opdracht uit te voeren om beide afbeeldingspartities te controleren:

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209

Controleer de actieve opstartpartitie. Gebruik de opdracht "show boot" en bevestig dat de "BOOT path-list" naar deel 1 verwijst; dit geeft aan dat het toegangspunt momenteel wordt uitgevoerd vanaf de primaire partitie en probeert te upgraden naar het secundaire deel (deel 2), wat het probleem zou kunnen veroorzaken.

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1

2. Controleer het huidige bestandssysteemgebruik door de partitie /dev/ubivol/part2 te controleren. Als de kolom "Beschikbaar" minder dan 85M weergeeft, heeft de partitie niet genoeg ruimte om de APSP te installeren, waardoor de upgrade mislukt en mogelijk een opstartlus wordt geactiveerd.

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. Controleer de integriteit van het image voor beide partities om te controleren of deze niet beschadigd zijn. In alle velden voor zowel primaire images als back-upimages moet de status "Goed" worden weergegeven. Als in een veld anders wordt aangegeven, stopt u het proces en gaat u naar de sectie Wanneer een TAC-kwestie openen.

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

Maak een lijst van alle toegangspunten die vanaf deel 1 opstarten en die minder dan 85M tonen die beschikbaar zijn in /dev/ubivol/part2, omdat ze ruimteherstel nodig hebben. U kunt naar het herstelgedeelte van dit document gaan.

Automatische voorcontrole

Gebruik het gereedschap WLANPoller voor de automatische voorcontrole. Met deze tool kunt u de benodigde opdrachten tegelijkertijd uitvoeren op al uw toegangspunten om de getroffen toegangspunten te identificeren; u kunt deze rechtstreeks downloaden via de volgende link: https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/

Stappen:

1.Extractie – Unzip het WLANPoller-bestand naar uw voorkeursdirectory. Na het uitpakken vindt u twee mappen en een toepassing met de volgende naam:

• gegevens
• toevertrouwen
• WlanPollerGUI

2. Configuratie - Start de WlanPollerGUI-toepassing en configureer de instellingen als volgt:

Type bewerking: Selecteer WLC en AP. Upload voor de optie Access PointOnly een ".txt"-bestand met uw toegangspunten in een kommagescheiden indeling (bijvoorbeeld 192.168.166.105, Timpadil9166). Klik vervolgens op Inloggegevens invoeren.

In de modus Alleen toegangspunt moet u ervoor zorgen dat het ".txt"-bestand dit voorbeeld volgt:

Inloggegevens: voer het WLC IP-adres en de referenties in. Voeg de gebruikersnaam, het wachtwoord en het wachtwoord van het toegangspunt toe aan het profiel voor deelname. Klik op Opslaan gevolgd door Doorgaan.

Werkstroom: Kies de Flash Checker-werkstroom van Access Point om de vereiste diagnostische opdrachten uit te voeren. Klik vervolgens op Doorgaan.

CLI Cmd-lijst: deze stap wordt automatisch overgeslagen; de lijst met vereiste opdrachten is al opgenomen in de Flash Checker-workflow van toegangspunt (stap 3).

Toegangspuntfilters: met deze optionele stap kunt u filteren op een specifieke site. Als u het gebruikt, schakelt u het selectievakje in en voert u de naam van de sitetag in (hoofdlettergevoelig). Als u klaar bent of deze stap overslaat, klikt u op Voorbeeld.

Voorbeeld: bekijk hier uw WLANPoller-instellingen. De vereiste CLI-opdrachten zijn vooraf ingevuld vanaf de vorige werkstroomstap. Nadat u de gegevens hebt bevestigd, klikt u op Bevestigen en WLANPoller starten om te beginnen met SSH-verbinding en gegevensverzameling.

3. Resultaten: De tool maakt SSH-verbindingen met uw toegangspunten om de nodige opdrachten uit te voeren. De resultaten worden weergegeven om u te helpen toegangspunten te identificeren die moeten worden hersteld. Een record van deze gegevens wordt automatisch opgeslagen in de submap data binnen uw WLANPoller extractie directory.

Resultaten vooraf controleren

Op basis van de scan categoriseert WLANPoller de getroffen toegangspunten in een van de volgende opties:

• Veilige status, maar Access Point heeft een buggy-image in de back-uppartitie: het toegangspunt is momenteel veilig om te upgraden en u kunt doorgaan met de installatie van de code/APSP. Houd er echter rekening mee dat de back-uppartitie nog steeds een gevoelige afbeelding bevat.
• Herstellen met image partition swap: Het toegangspunt wordt momenteel opgestart vanaf partitie 1, maar partitie 2 heeft onvoldoende ruimte voor de upgrade. Een opstartpartitieswap voor Access Point is vereist.
• Herstellen met devshell: Het toegangspunt vereist herstel via devshell omdat er onvoldoende ruimte is in beide partities om de nieuwe code of APSP te installeren.
• Controle van de integriteit van het image is mislukt voor dit toegangspunt: het image in partitie 1 of partitie 2 heeft de integriteitscontrole niet doorstaan. Handmatig ingrijpen kan noodzakelijk zijn.

herstel

Op basis van de resultaten van de voorcontrole kunt u als volgt de juiste hersteloptie selecteren die het beste bij uw netwerk past:

resultaat	Herstelopties
Veilige status, maar Access Point heeft een fout-image in de back-uppartitie	Ter informatie kunt u doorgaan met de installatie van de code/APSP
Herstellen met image partition swap	Er zijn 4 opties: 1. Hoofdbestanden van toegangspunten verwijderen. 2. De toegangspunten in de fabriek resetten. 3. Opstartpartitieswap voor Access Point-image. 4. Consdaemon.log-bestand verwijderen (Access Point devshell). Kies de hersteloptie die het meest geschikt is voor uw omgeving en de beschikbaarheid van bronnen.
Herstellen met devshell	Er zijn 2 opties: 1. Consdaemon.log-bestand verwijderen (Access Point devshell). 2. De toegangspunten in de fabriek resetten. Kies de hersteloptie die het meest geschikt is voor uw omgeving en de beschikbaarheid van bronnen.
Controle van de integriteit van het image is mislukt voor dit toegangspunt	Volg de procedure: Wanneer een TAC-zaak openen

Er zijn twee herstelpaden, afhankelijk van de huidige status van uw toegangspunten. De status van de toegangspunten kan zijn:

1. Lage beschikbaarheid van ruimte in partitie 2: Dit gebeurt tijdens de pre-upgrade fase (gevonden tijdens Upgrade Prechecks) bij het proberen van een code/APSP-installatie.
2. Bootloop van toegangspunt: Dit gebeurt na de upgrade als de installatie van de code/APSP is geprobeerd ondanks onvoldoende ruimte.

Gedetailleerde herstelstappen voor elk van de mogelijke toestanden van de toegangspunten worden hieronder beschreven.

Weinig ruimte beschikbaar in partitie 2

Als de Upgrade Precheck aangeeft dat toegangspunten worden opgestart met partitie 1 en onvoldoende ruimte hebben in partitie 2, gebruikt u een van de volgende methoden om ruimte te maken in de partitie.

• Kernbestanden van toegangspunten verwijderen: toegangspunten slaan kerndumps op in /dev/ubivol/part2. Als deze bestanden bestaan, kan het verwijderen ervan voldoende ruimte vrijmaken. Na verwijdering moet u de Upgrade-precheck opnieuw uitvoeren om te bevestigen dat de beschikbare ruimte voldoet aan de installatievereisten.
• Het toegangspunt in de fabriek opnieuw instellen: Als u een fabrieksreset uitvoert, wordt de standaardconfiguratie van het toegangspunt hersteld. Dit proces wist tijdelijk het bestand cnsdaemon.log uit de opslag en biedt doorgaans voldoende ruimte in partitie 2 (deel 2) om de code/APSP met succes te installeren.
• Bestand cnssdaemon.log verwijderen (Access Point devshell): Dit proces omvat het openen van het Access Points devshell om het bestand cnssdaemon.log handmatig te verwijderen. Merk op dat dit administratieve toegang en coördinatie met TAC vereist om de ontwikkelomgeving te betreden.
• Opstartpartitieswap: als partitie 2 (deel 2) niet genoeg ruimte heeft om de code/APSP te installeren, maar al een functioneel image bevat, kunt u het toegangspunt opstarten vanaf deel 2 en de installatie richten op partitie 1 (deel 1), die over het algemeen beschikbare ruimte heeft.

Bekijk de details voor elk van de opties om ervoor te zorgen dat u de vereisten begrijpt. Selecteer de methode die het beste aansluit bij uw netwerkomgeving en operationele behoeften.

Kernbestanden van toegangspunten verwijderen

Kernbestanden kunnen handmatig worden verwijderd door elk toegangspunt via SSH te openen. Als alternatief kunt u WLANPoller gebruiken om dit proces te automatiseren en verwijderingen in bulkmodus uit te voeren voor meerdere toegangspunten tegelijkertijd.

Handmatige modus

Toegang tot elk toegangspunt via SSH en voer de volgende opdrachten uit:

AP# delete /force cores
AP# reload
Proceed with reload? [confirm] yes

Geautomatiseerde modus

Start de WLANPoller-toepassing en volg de volgende stappen:

Soort bewerkingen: Selecteer bewerkingstype WLC & AP.

Inloggegevens: Voer WLC- en Access Point-referenties in.

Werkstroom: Werk de selectie bij naar Aangepaste CLI-opdrachten en klik op Doorgaan.

CLI Cmd-lijst: voer de volgende opdrachten van het toegangspunt precies in zoals wordt weergegeven. Klik op Opslaan en klik vervolgens op Doorgaan.

Toegangspuntfilters: Laat alle selectievakjes niet geselecteerd, tenzij een specifiek filter voor uw omgeving is vereist, en klik vervolgens op Voorbeeld.

Voorbeeld: bekijk het overzicht en klik op Bevestigen en WLANPoller starten.

Resultaten: Controleer of de WLANPoller-uitvoering voor alle beoogde toegangspunten met succes is voltooid.

Herhaal na herstel de precheck voor upgrade zoals beschreven in die sectie. Controleer of de betreffende toegangspunten nog steeds een lage beschikbaarheid van ruimte laten zien. Als dat het geval is, gaat u naar een van de volgende opties die beter bij uw bronnen passen; als ze uit de lijst zijn verwijderd, is het herstel succesvol en kunt u doorgaan met de code / APSP in die toegangspunten.

De toegangspunten in de fabriek opnieuw instellen

Als u het toegangspunt opnieuw instelt op de fabrieksinstellingen, wordt het bestand cnsdaemon.log tijdelijk verwijderd. Ga binnen 48 uur na de fabrieksreset door met de installatie van de code/APSP om te zorgen voor een geslaagde installatie van de code/APSP.

Er zijn drie manieren om de toegangspunten in de fabriek opnieuw in te stellen:

• Via de WLC (CLI of GUI).

• Via het toegangspunt CLI,

• Via de fysieke resetknop van het toegangspunt.

Via WLC CLI

WLC# clear ap config <APNAME> keep-ip-config

Via WLC GUI

Ga naar Configuratie > Draadloos > Toegangspunten. Selecteer het gewenste toegangspunt en navigeer naar Geavanceerd > Instellen op fabrieksinstellingen. Kies de optie Config wissen behalve Statisch IP en klik op Bijwerken en toepassen op apparaat.

Via Access Point CLI

AP# capwap ap erase all 
WARNING :" capwap ap erase all" is altered to perform DATA WIPE on COS AP.
The following files will be cleared as part of this process
1) Config ,Bak config files
2) Crashfiles
3) syslogs
4) Boot variables
5) Pktlogs
6) Manually created files
Are you sure you want continue? [confirm] yes
AP# reload 
Proceed with reload command (cold)? [confirm] yes

Knop Via Access Point-modus

1. Koppel het toegangspunt los van de stroombron.

2. Houd de knop Modus ingedrukt.

3. Sluit de voedingsbron weer aan terwijl u de knop ingedrukt houdt.

4. Houd de knop Modus nog eens 10 seconden ingedrukt zodra de statuslampje van het toegangspunt roodgekleurd wordt.

5. Laat de knop los.

6. Het toegangspunt wordt opnieuw opgestart met de fabrieksinstellingen.

Bestand cnssdaemon.log verwijderen (Access Point devshell)

Het Technical Assistance Center (TAC) kan handmatig herstel uitvoeren door het bestand censdaemon.log rechtstreeks van devshell op de betreffende toegangspunten te verwijderen. Afhankelijk van de omvang van de impact zijn er twee methoden:

• Klein aantal getroffen toegangspunten: voor een klein aantal getroffen toegangspunten kan de TAC worden voortgezet met behulp van een van de volgende twee benaderingen:

  • Handmatige toegang tot devshell: Toegang tot elk toegangspunt afzonderlijk via devshell om handmatig het bestand cnssdaemon.log te wissen.

  • Geautomatiseerde (bulk) devshell-toegang: gebruik de RADKit-tool om het opruimproces van het bestand cnsdaemon.log naar alle getroffen toegangspunten te automatiseren.

• Groot aantal getroffen toegangspunten: TAC maakt gebruik van RADKit-tool, dit maakt bulktoegang mogelijk tot alle getroffen toegangspunten op een geautomatiseerde manier om het opruimproces efficiënt uit te voeren.

Toegang tot RADKit download- en installatie-instructies via de onderstaande koppelingen:

• RADKit Downloaden
• RADKit-installatie

Als u het bestand cnsdaemon.log in de toegangspunten via RADKit wilt verwijderen, moet u ervoor zorgen dat alle toegangspunten in de inventaris worden vermeld. Dit is een taak die alleen door de beheerder wordt uitgevoerd en kan niet op afstand worden uitgevoerd door TAC. Voer de volgende stappen uit om toegangspunten in bulk toe te voegen aan de RADKit-inventaris:

1. WLC in RADKit: Zorg ervoor dat de WLC al is toegevoegd aan de RADKit-inventaris. Als u hulp nodig hebt bij dit proces, volgt u de sectie Apparaten toevoegen hier uit de officiële RADKit-documentatie

2. WLC-inventarispictogram: Zoek op het tabblad Apparaten uw WLC en klik op het inventarispictogram in de kolom Acties.

3. Bulkimport: Selecteer de knop Bulkimport om het proces voor het toevoegen van toegangspunten aan RADKit te starten.

4. Bulkconfiguratie: Schakel de selectievakjes in voor alle toegangspunten waarvoor het bestand cndaemon.log moet worden verwijderd. Klik op het pictogram Toevoegen aan winkelwagentje (winkelwagentje met een plusteken) en selecteer vervolgens de knop Bulksgewijs bewerken.

5. Terminal inschakelen en SSH configureren: Controleer in de winkelwageneditor Bulk het apparaattype en selecteer Cisco AP OS. Schakel de schakelaar Terminal in om SSH-configuratie voor de toegangspunten toe te staan.

6. SSH-referenties configureren: klik op SSH (Password) en voer de referenties van het toegangspunt in. Selecteer het selectievakje Wachtwoord inschakelen en voer het wachtwoord in. Klik op Toepassen en wissen om deze instellingen op te slaan en het venster te sluiten. Bevestig dat SSH is ingeschakeld in de WLC via AP Join Profile en dat de gebruikersnaam en het wachtwoord up-to-date en correct zijn.

7. Externe gebruiker toevoegen: voeg de Cisco CCO-ID van de technicus toe die aan uw TAC-geval is toegewezen door de stappen Externe gebruikers toevoegen hier in de officiële RADKit-documentatie te volgen.

8. Lijst met beoogde toegangspunten: Verzamel de exacte namen van de getroffen toegangspunten (let op: deze zijn hoofdlettergevoelig) in een bestand en upload het bestand naar uw TAC-geval.

Na de installatie en het uploaden van bestanden met de namen van de toegangspunten, heeft Cisco TAC de benodigde externe toegang via RADKit om de bulk-verwijdering van de bestanden van cnssdaemon.log uit te voeren.

Opstartpartitieswap voor Access Point-image

De opstartpartitieswap kan handmatig worden uitgevoerd via toegangspunt of automatisch via toegangspunt in bulk met WLANPoller.

manueel

SSH naar de toegangspunten en voer de volgende opdrachten uit:

AP# config boot path 2
AP# reload
Proceed with reload? [confirm] yes

geautomatiseerd

Gebruik WLANPoller om het opstartonderdeel in bulk uit te voeren naar verschillende toegangspunten.

1. Betrokken toegangspunten isoleren – zorg ervoor dat de betreffende toegangspunten geen verbinding met de WLC hebben:
   • Zorg ervoor dat SSH is ingeschakeld in het Access Points join-profiel en dat Access Points toegankelijk zijn voor SSH (of console gebruiken)
   • Zorg ervoor dat de toegangspunten geen connectiviteit hebben met de WLC, maar dat u wel SSH-toegang hebt tot de toegangspunten. Dit kan worden bereikt door een ACL in de gateway te hebben of de toegangspunten naar een geïsoleerd VLAN te verplaatsen. Als de toegangspunten toegang krijgen tot de WLC, kan het toegangspunt terugkeren naar opstartpartitie 1 (deel 1) en wordt het teruggezet naar de betreffende status.

2. Configureer het opstartpad2 en start de betreffende toegangspunten opnieuw op – Configureer WlanPoller om de betreffende toegangspunten via de opdrachtregel te instrueren het opstartgedeelte van 1 naar 2 te wijzigen en vervolgens opnieuw op te starten.

Bewerkingstype: Selecteer de optie Alleen toegangspunt, en voeg in een teksteditor (bij voorkeur) het IP-adres en de naam van het toegangspunt toe (hoofdlettergevoelig), klik op Bladeren en selecteer het bestand met het IP-adres en de namen van het toegangspunt. Klik vervolgens op Inloggegevens invoeren.

Indeling Access PointList:

Selectie van bewerkingstype:

Inloggegevens: voer de toegangspunten in, klik op Opslaan en ga verder.

Werkstroom: Selecteer Aangepaste CLI-opdrachten en klik op Doorgaan.

CLI Cmd List: Configureer de opdrachten om het toegangspunt op te starten met deel 2 en opnieuw te laden. Klik vervolgens op Opslaan en doorgaan.

Voorbeeld: in het voorbeeld ziet u de 2 opdrachten die worden uitgevoerd op de toegangspunten. Klik op Bevestigen en WlanPoller starten.

3. Upgrade – Installeer in de WLC de benodigde APSP in uw huidige code, of, als u de code wilt upgraden, verplaats dan naar een nieuwe code en zorg ervoor dat APSP ook is geïnstalleerd.

4. Opnieuw verbinden – Nadat de upgrade van de controller is voltooid, verwijdert u de communicatiestop tussen het toegangspunt en de WLC. Het toegangspunt wordt lid van de WLC en downloadt automatisch het nieuwe en vaste image in het opstartgedeelte van deel 1.

bootloop van toegangspunt

Als u een code / APSP-installatie hebt uitgevoerd zonder eerst de Upgrade Prechecks te volgen en uw toegangspunten in een bootloop terechtkwamen, zijn er 2 opties om te volgen:

1. Stel het toegangspunt in de fabriek opnieuw in met de knop Modus, zoals uitgelegd in het gedeelte Fabrieksinstellingen de toegangspunten opnieuw instellen.
2. Krijg consoletoegang en open een TAC-geval zodat TAC kan doorgaan met het herstellen van het toegangspunt.

Wanneer een TAC-zaak openen

Open een TAC-geval als een van de volgende omstandigheden zich voordoet:

• Mislukt herstel: als de herstelprocedures niet kunnen worden geïmplementeerd in uw omgeving, of als ze falen.
• Integriteitsproblemen: handmatige of geautomatiseerde voorcontroles geven een "Image Integrity Check: Bad" terug.
• Uitputting van opslagcapaciteit: als na de upgrade/APSP-installatie de partitie "/dev/ubivol/part2" nog steeds een kritiek hoog gebruik vertoont.

Veelgestelde vragen

Vraag: Geldt dit probleem alleen voor upgrades van volledige code of heeft het ook invloed op APSP-installaties?

A: Dit probleem heeft gevolgen voor beide scenario's. Als uw omgeving voldoet aan de criteria voor deze bug, kan het probleem optreden tijdens een volledige code-upgrade of APSP-installatie (inclusief de APSP met de bugfix). Vul het gedeelte Voorcontroles bijwerken in om te bepalen of u de herstelstappen moet volgen voordat u updates of APSP's toepast.

V: Mijn WLC en toegangspunten staan op 17.9.x (of eerder) en ik moet upgraden naar 17.12.x, wat moet ik doen?

A: U kunt een directe upgrade uitvoeren van 17.9.x naar 17.12.x. Als uw Access Point-modellen echter gevoelig zijn voor deze bug, moet u ervoor zorgen dat u de aanbevolen APSP onmiddellijk na de upgrade installeert.

V: Mijn WLC en toegangspunten staan op 17.9.x (of eerder) en ik moet upgraden naar 17.15.x of hoger.

A: Er zijn twee mogelijke scenario’s:

• Directe upgrade: als uw omgeving een directe upgrade toestaat (controleer dit via de Release Notes voor uw doelcode), gaat u verder met de upgrade en installeert u de APSP voor die doelcode.
• Tussentijdse upgrade: Als u een upgradepad moet volgen (bijvoorbeeld 17.9.x → 17.12.x → 17.15.x), raden we u aan de volledige reeks binnen dezelfde dag tot 17.15.x te voltooien. Omdat het bestand cndaemon.log dagelijks met 5 MB groeit, voorkomt het voltooien van de upgrade snel dat het bestand een kritieke grootte bereikt. Als een upgrade op dezelfde dag niet mogelijk is, moet u de APSP installeren in de 17.12.x-fase voordat u uiteindelijk doorgaat naar 17.15.x en de bijbehorende APSP installeert.

V: Ik ben al op 17.15.x. Betekent dit dat ik geen last heb van deze bug?

A: Niet noodzakelijk. Als uw toegangspunten eerder versie 17.12.4, 17.12.5 of 17.12.6/6a (op 9800-L/40/80/CL) hebben uitgevoerd, is het problematische logbestand mogelijk al gegenereerd en blijft het opgeslagen. We raden u ten zeerste aan om de sectie Upgrade Prechecks te volgen om ervoor te zorgen dat alle resterende bestanden worden opgeruimd.

Vraag: Ik gebruik de 9800-M-, 9800-H1- of 9800-H2-platforms, die voor het eerst werden ondersteund in 17.15, ben ik getroffen?

A: Er zijn twee mogelijke scenario’s:

• Eerste ooit lid geworden van WLC: als uw toegangspunten zich bij een 9800-M/H1/H2 hebben aangesloten als hun eerste controller ooit, wordt u niet beïnvloed.
• Vorige WLC's zijn toegevoegd: Als die toegangspunten eerder waren gekoppeld aan een andere controller met een getroffen versie (17.12.4/5/6/6a) voordat ze naar de 9800-M/H1/H2 gingen, kunnen ze nog steeds het problematische bestand bevatten. Volg in dat geval de sectie Voorcontroles bijwerken.

V: We hebben afzonderlijke WLC's voor Lab-tests en gespreide upgrades, hoe ze te behandelen?

A: Zorg ervoor dat alle WLC's in uw omgeving de juiste APSP uitvoeren. Omdat het bestand cnsdaemon.log dagelijks met 5 MB groeit, wordt elk toegangspunt dat zich aansluit bij een WLC met getroffen code, zelfs tijdelijk voor testen, mogelijk vatbaar voor deze bug.

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
4.0	24-Mar-2026	Bijgewerkt herstelmechanisme en inclusief verbeterde automatisering met behulp van WLAN-poller.
3.0	27-Feb-2026	Veelgestelde vragen en aanvullende herstelscenario's toegevoegd
2.0	23-Feb-2026	Toegevoegde details voor toepasselijkheid van upgradepad
1.0	30-Jan-2026	Eerste vrijgave