Problemen oplossen met de belasting van de CPU van de draadloze LAN-controller
Inhoud
Inleiding
In dit document wordt beschreven hoe u het CPU-gebruik op Catalyst 9800 Wireless LAN Controllers kunt controleren en worden verschillende configuratieaanbevelingen behandeld.
CPU-gebruik begrijpen
Voordat u zich verdiept in het oplossen van problemen met CPU-belasting, moet u de basisprincipes begrijpen van hoe CPU's worden gebruikt in Catalyst 9800 Wireless LAN Controllers en enkele details over de softwarearchitectuur.
In het algemeen definieert het Catalyst 9800 Best Practices-document een reeks configuratie-instellingen die problemen op toepassingsniveau kunnen voorkomen. Bijvoorbeeld door locatiefiltering voor mDNS te gebruiken of ervoor te zorgen dat clientuitsluiting altijd is ingeschakeld. Het is raadzaam om deze aanbevelingen toe te passen samen met de onderwerpen die hier worden besproken.
Basisprincipes van het platform
Catalyst 9800-controllers zijn ontworpen als een flexibel platform dat zich richt op verschillende netwerkbelastingen en zich richt op horizontale schaling. De interne ontwikkeling naamgeving was eWLC met de "e" voor elastisch, om aan te geven dezelfde software architectuur zou lopen van een kleine enkele CPU embedded systeem naar meerdere CPU / core grootschalige apparaten.
Elke WLC heeft twee verschillende kanten:
- Control Plane: Alle beheerinteracties zoals CLI, UI, Netconf en alle onboarding-processen voor clients en AP's afhandelen.
- Data Plane: Verantwoordelijk voor het daadwerkelijk doorsturen van pakketten en ontcijfering van CAPWAP, AVC-beleidshandhaving, naast andere functionaliteiten.
Besturingsplane
- De meeste Cisco IOS®-processen worden uitgevoerd onder BinOS (Linux Kernel) met zijn eigen gespecialiseerde planner- en bewakingsopdrachten.
- Er is een set van belangrijke processen, genaamd Wireless Network Control Daemon (WNCD), elk heeft een lokale in-memory database, die het grootste deel van de draadloze activiteit verwerkt. Elke CPU heeft een WNCD om de belasting over alle beschikbare CPU-cores naar elk systeem te spreiden
- De lastverdeling over de WNCD's wordt voltooid tijdens een AP-verbinding. Wanneer een toegangspunt een CAPWAP-verbinding met de controller uitvoert, verdeelt een interne taakverdeler het toegangspunt met behulp van een reeks mogelijke regels, om een correct gebruik van alle beschikbare CPU-bronnen te garanderen.
- Cisco IOS® code draait op zijn eigen proces genaamd IOSd en heeft zijn CPU-planner. Dit zorgt voor specifieke functionaliteit, bijvoorbeeld CLI, SNMP, multicast en routing.
In een vereenvoudigde weergave heeft de controller communicatiemechanismen tussen het besturings- en gegevensvlak, punt, stuurt verkeer van het netwerk naar het besturingsvlak, injectie en duwt frames van het besturingsvlak in het netwerk.
Als onderdeel van een mogelijk onderzoek naar problemen met de hoge CPU, moet u het puntmechanisme controleren om te evalueren welk verkeer het controlevlak bereikt en tot een hoge belasting kan leiden.
Dataplane
Voor de Catalyst 9800-controller wordt dit uitgevoerd als onderdeel van de Cisco Packet Processor (CPP), een softwarekader voor de ontwikkeling van pakketforwardingengines die worden gebruikt voor meerdere producten en technologieën.
De architectuur maakt het mogelijk om een gemeenschappelijke functie in te stellen voor verschillende hardware- of software-implementaties. Het maakt bijvoorbeeld vergelijkbare functies mogelijk voor 9800CL versus 9800-40 op verschillende doorvoerschalen.
AP-taakverdeling
De WLC voert taakverdeling uit over CPU's tijdens het CAPWAP AP-verbindingsproces, waarbij de belangrijkste differentiator de AP-sitetagnaam is. Het idee is dat elk toegangspunt een specifieke toegevoegde CPU-belasting vertegenwoordigt, afkomstig van de clientactiviteit en het toegangspunt zelf. Er zijn verschillende mechanismen om deze balancering uit te voeren:
- Als het toegangspunt een standaardtag gebruikt, wordt deze op een round-robin-manier verdeeld over alle CPU's/WNCD's, waarbij elke nieuwe AP-join naar de volgende WNCD gaat. Dit is de eenvoudigste methode, maar het heeft een paar implicaties:
- Dit is het suboptimale scenario, aangezien AP's in hetzelfde RF-roamingdomein vaak Inter-WNCD-roaming hebben, wat extra communicatie tussen processen inhoudt. Roaming over instanties is met een klein percentage langzamer.
- Voor de FlexConnect-sitetag (op afstand) is geen PMK-sleutelverdeling beschikbaar. Dit betekent dat u snelle roaming voor de Flex-modus niet kunt voltooien, wat gevolgen heeft voor de OKC/FT-roamingmodi.
In het algemeen kan de standaardtag worden gebruikt voor scenario's met een lagere belasting (bijvoorbeeld minder dan 40% van het toegangspunt en de clientbelasting van het 9800-platform) en voor FlexConnect-implementatie alleen wanneer snel roamen geen vereiste is.
- Als het toegangspunt een aangepaste sitetag heeft, wordt de sitetag de eerste keer dat een toegangspunt tot de sitetagnaam behoort, toegewezen aan een specifieke WNCD-instantie. Alle volgende aanvullende AP-verbindingen met dezelfde tag worden toegewezen aan dezelfde WNCD. Dit zorgt ervoor dat roaming over AP's in dezelfde sitetag plaatsvindt in de ene WCND-context. Dit zorgt voor een meer optimale flow, met een lager CPU-gebruik. Roaming via WNCD's wordt ondersteund, maar niet zo optimaal in intra-WNCD-roaming.
- Standaardtaakverdelingsbesluit: wanneer een tag aan een WNCD is toegewezen, selecteert de taakverdeler de instantie met de laagste sitetagtelling op dat moment. De totale belasting die de site-tag kan hebben is onbekend, het kan leiden tot suboptimale balanceerscenario's. Dit is afhankelijk van de volgorde waarin het toegangspunt wordt toegevoegd, hoeveel site-tags zijn gedefinieerd en of het aantal toegangspunten asymmetrisch is.
- Statische taakverdeling: om onevenwichtige toewijzing van sitetags aan WNCD te voorkomen, werd de opdracht voor het laden van de site geïntroduceerd in versie 17.9.3 en hoger. Hiermee kunnen beheerders de verwachte belasting van elke sitetag vooraf definiëren. Dit is handig bij het afhandelen van campusscenario's of meerdere filialen, elk toegewezen aan verschillende AP-tellingen om ervoor te zorgen dat de belasting gelijkmatig over WNCD wordt verdeeld.
Als u een 9800-40 hebt die één hoofdkantoor afhandelt, plus 5 filialen met verschillende AP-tellingen, kan de configuratie er als volgt uitzien:
wireless tag site office-main
load 120
wireless tag site branch-1
load 10
wireless tag site branch-2
load 12
wireless tag site branch-3
load 45
wireless tag site branch-4
load 80
wireless tag site branch-5
load 5
In dit scenario wilt u niet dat de hoofdkantoortag op dezelfde WNCD staat als branch-3 en branch-4. Er zijn in totaal 6 site-tags en het platform heeft 5 WNCD's en er is een kans dat de hoogst geladen site-tags op dezelfde CPU terechtkomen. Door de opdracht laden uit te voeren, kunt u een voorspelbare AP-taakverdelingstopologie maken.
De opdracht laden is een verwachte grootte. Het hoeft niet exact overeen te komen met het aantal toegangspunten, maar het is normaal gesproken ingesteld op de verwachte toegangspunten die kunnen deelnemen.
- In scenario's waarbij grote gebouwen door één controller worden afgehandeld, is het gemakkelijker om zoveel sitetags te maken als WNCD's voor dat specifieke platform (bijvoorbeeld C9800-40 heeft 5, C9800-80 heeft 8). Wijs AP's in hetzelfde gebied of roaming-domein toe aan dezelfde sitetags om communicatie tussen WNCD's te minimaliseren.
- RF-taakverdeling: hiermee worden AP's in evenwicht gebracht tussen WNCD-instanties, met behulp van de RF-buurrelatie van RRM, en worden subgroepen gemaakt, afhankelijk van hoe dicht de AP's bij elkaar staan. Het moet worden voltooid nadat toegangspunten een tijdje actief zijn geweest en de noodzaak om statische instellingen voor de taakverdeling te configureren wordt verwijderd. Deze is beschikbaar vanaf 10.12 en hoger.
Hoe om te achterhalen hoeveel WNCD's aanwezig zijn
Voor hardwareplatforms is de WNCD-telling vast: 9800-40 heeft 5, 9800-80 heeft 8. Voor 9800CL (virtueel) is het aantal WNCD's afhankelijk van het sjabloon voor de virtuele machine dat tijdens de eerste implementatie is gebruikt.
Als algemene regel geldt dat als u wilt bepalen hoeveel WNCD's in het systeem worden uitgevoerd, u deze opdracht kunt uitvoeren voor alle typen controllers:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
In het geval van 9800-CL kunt u het softwaresysteem voor het showplatform alle opdrachten uitvoeren om gegevens op het virtuele platform te verzamelen:
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
Toezicht op taakverdeling AP
De toewijzing van AP naar WNCD wordt toegepast tijdens het proces van AP CAPWAP-aansluiting en er wordt niet verwacht dat deze verandert tijdens bewerkingen, ongeacht de balanceermethode. Tenzij er een CAPWAP-reset-gebeurtenis voor het hele netwerk plaatsvindt waarbij alle toegangspunten de verbinding verbreken en zich opnieuw aansluiten.
Als u de opdracht CLI show wireless loadbalance tag affinity uitvoert, kunt u de huidige status van de AP-loadbalance eenvoudig weergeven in alle WNCD-instanties:
98001#show wireless loadbalance tag affinity
Tag Tag type No of AP's Joined Load Config Wncd Instance
---------------------------------------------------------------------------------------------
Branch-tag SITE TAG 10 0 0
Main-tag SITE TAG 200 0 1
default-site-tag SITE TAG 1 NA 2
Als u de AP-distributie wilt correleren met het aantal clients en de CPU-belasting, kunt u de WCAE-ondersteuningstool gebruiken en een show tech wireless laden die tijdens drukke tijden is genomen. Het hulpprogramma vat het aantal WNCD-clients samen, afkomstig van elk toegangspunt dat eraan is gekoppeld.
Dit is een voorbeeld van een goed uitgebalanceerde controller, tijdens laag gebruik en aantal clients:
Een ander voorbeeld is voor een meer geladen controller, die normaal CPU-gebruik toont:
Wat is het aanbevolen AP Load-Balancing Mechanism?
Kortom, u kunt de verschillende opties samenvatten in:
- Kleine netwerken, geen snelle roaming nodig, minder dan 40% van de controllerbelasting: standaardtag.
- Als snel roamen vereist is (OKC, FT, CCKM), of een groot aantal clients:
- Eén gebouw: maak evenveel sitetags als CPU's (afhankelijk van het platform).
- Vóór 19.12, of minder dan 500 AP-telling: Meerdere gebouwen, filialen of grote campussen: maak een site-tag per fysieke RF-locatie en configureer de load-opdracht per site.
- 15.12 en hoger met meer dan 500 toegangspunten: gebruik RF-taakverdeling.
Deze drempel van 500 toegangspunten is bedoeld om te markeren wanneer het effectief is om het taakverdelingsmechanisme toe te passen, omdat het standaard AP's groepeert in blokken van 100 eenheden.
AP WNCD-distributievisualisatie
Er zijn scenario's waarin u geavanceerde AP-balancering kunt toepassen en het is wenselijk om gedetailleerde controle te hebben over hoe AP's worden verspreid over CPU's. Bijvoorbeeld scenario's met een zeer hoge dichtheid waarbij de belangrijkste belastingsmaatstaf het aantal clients is versus de focus op het aantal toegangspunten dat in het systeem aanwezig is.
Een goed voorbeeld van deze situatie zijn grote evenementen waarbij een gebouw duizenden klanten over meerdere honderden toegangspunten kan hosten, en u de belasting over zoveel mogelijk CPU's moet verdelen, maar tegelijkertijd roaming moet optimaliseren. U zwerft niet over WNCD tenzij het nodig is. U wilt situaties voorkomen waarin meerdere toegangspunten in verschillende WNCD's/sitetags op dezelfde fysieke locatie met elkaar zijn vermengd.
Om de distributie te helpen verfijnen en visualiseren, kunt u de WCAE-tool gebruiken en profiteren van de AP RF View-functie:
Hiermee kunt u de verdeling van het toegangspunt/de WNCD bekijken en het weergavetype instellen op WNCD. Elke kleur vertegenwoordigt een WNCD/CPU en u kunt het RSSI-filter instellen op -85 om lage signaalverbindingen te vermijden. Deze worden ook gefilterd door het RRM-algoritme in de controller.
In het vorige voorbeeld, dat overeenkomt met Ciscolive EMEA 24, kunt u zien dat de meeste aangrenzende toegangspunten zijn geclusterd over dezelfde WNCD met zeer beperkte cross-overlapping. Site-tags die aan dezelfde WNCD zijn toegewezen, krijgen dezelfde kleur.
CPU-gebruik van controlevlak
Het is belangrijk om het concept van Cisco IOS XE-architectuur te onthouden en in gedachten te houden dat er twee hoofdweergaven van CPU-gebruik zijn. De ene komt van historische Cisco IOS-ondersteuning en de belangrijkste met een holistische weergave van de CPU in alle processen en kernen.
In het algemeen kunt u de opdracht tonen processen CPU platform gesorteerd om gedetailleerde informatie te verzamelen voor alle processen in Cisco IOS XE uitvoeren:
9800cl-1#show processes cpu platform sorted
CPU utilization for five seconds: 8%, one minute: 14%, five minutes: 11%
Core 0: CPU utilization for five seconds: 6%, one minute: 11%, five minutes: 5%
Core 1: CPU utilization for five seconds: 2%, one minute: 8%, five minutes: 5%
Core 2: CPU utilization for five seconds: 4%, one minute: 12%, five minutes: 12%
Core 3: CPU utilization for five seconds: 19%, one minute: 23%, five minutes: 24%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19953 19514 44% 44% 44% S 190880 ucode_pkt_PPE0
28947 8857 3% 10% 4% S 1268696 linux_iosd-imag
19503 19034 3% 3% 3% S 247332 fman_fp_image
30839 2 0% 0% 0% I 0 kworker/0:0
30330 30319 0% 0% 0% S 5660 nginx
30329 30319 0% 1% 0% S 20136 nginx
30319 30224 0% 0% 0% S 12480 nginx
30263 1 0% 0% 0% S 4024 rotee
30224 8413 0% 0% 0% S 4600 pman
30106 2 0% 0% 0% I 0 kworker/u11:0
30002 2 0% 0% 0% S 0 SarIosdMond
29918 29917 0% 0% 0% S 1648 inet_gethost
Er zijn verschillende belangrijke punten om te benadrukken:
- Het proces ucode_pkt_PPE0 verwerkt het gegevensvlak op 9800L- en 9800CL-platforms. De verwachting is dat het gebruik de hele tijd hoog zal zijn, zelfs hoger dan 100%. Dit maakt deel uit van de uitvoering en vormt geen probleem.
- Het is belangrijk om het piekgebruik te onderscheiden van een aanhoudende belasting en te isoleren wat in een bepaald scenario wordt verwacht. Het verzamelen van een zeer grote CLI-uitvoer, zoals show tech wireless, kan bijvoorbeeld een piekbelasting genereren op IOSd-, smand- en pubd-processen, omdat een zeer grote tekstuitvoer wordt verzameld met honderden CLI-opdrachten uitgevoerd. Dit is geen probleem en de belasting neemt af zodra de uitvoer is voltooid.
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19371 19355 62% 83% 20% R 128120 smand
27624 27617 53% 59% 59% S 1120656 pubd
4192 4123 11% 5% 4% S 1485604 linux_iosd-imag
- Het piekgebruik voor WNCD-kernen wordt verwacht tijdens hoge tijden van clientactiviteit. Het is mogelijk om pieken van 80% te zien zonder functionele impact, en ze veroorzaken normaal gesproken geen probleem.
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
21094 21086 25% 25% 25% S 978116 wncd_0
21757 21743 21% 20% 20% R 1146384 wncd_4
22480 22465 18% 18% 18% S 1152496 wncd_7
22015 21998 18% 17% 17% S 840720 wncd_5
21209 21201 16% 18% 18% S 779292 wncd_1
21528 21520 14% 15% 14% S 926528 wncd_3
- Een aanhoudend hoog CPU-gebruik op een proces van meer dan 90% gedurende meer dan 15 minuten moet worden onderzocht.
- U kunt het CPU-gebruik van IOSd controleren door de opdracht Show Processes CPU Sorted uit te voeren. Dit komt overeen met de activiteit in het linux_iosd-imag-procesgedeelte van de Cisco IOS XE-lijst.
9800cl-1#show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
215 81 88 920 1.51% 0.12% 0.02% 1 SSH Process
673 164441 7262624 22 0.07% 0.00% 0.00% 0 SBC main process
137 2264141 225095413 10 0.07% 0.04% 0.05% 0 L2 LISP Punt Pro
133 534184 21515771 24 0.07% 0.04% 0.04% 0 IOSXE-RP Punt Se
474 1184139 56733445 20 0.07% 0.03% 0.00% 0 MMA DB TIMER
5 0 1 0 0.00% 0.00% 0.00% 0 CTS SGACL db cor
6 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
2 198433 726367 273 0.00% 0.00% 0.00% 0 Load Meter
7 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
10 3254791 586076 5553 0.00% 0.11% 0.07% 0 Check heaps
4 57 15 3800 0.00% 0.00% 0.00% 0 RF Slave Main Th
8 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
- U kunt de 9800 GUI gebruiken voor een snelle weergave van de belasting van IOSd, per kerngebruik en de belasting van het gegevensvlak:
Dit is beschikbaar op het tabblad Bewaking/Systeem/CPU-gebruik.
Wat is elk proces
De proceslijst varieert afhankelijk van het controllermodel en de Cisco IOS XE-versie. Dit is een lijst van enkele belangrijke processen en het is niet bedoeld om alle mogelijke vermeldingen te dekken.
| Procesnaam |
Wat doet het |
evaluatie |
| WNCD_X |
Verwerkt de meeste draadloze bewerkingen. Afhankelijk van het 9800-model kunt u tussen de 1 en 8 exemplaren hebben. |
Je kunt pieken van hoge bezettingsgraad zien tijdens drukke uren. Meld als het gebruik gedurende enkele minuten voor 95% of meer vastloopt. |
| Linux_IOSD-IMAG |
Cisco IOS-proces |
Verwacht een hoog gebruik als u grote CLI-uitvoer verzamelt (technologie weergeven). Grote of te frequente SNMP-bewerkingen kunnen leiden tot een hoge CPU. |
| Nginx |
webserver |
Dit proces kan pieken vertonen en kan alleen worden gerapporteerd bij een aanhoudende hoge belasting. |
| ucode_pkt_PPE0 |
Gegevensvlak in 9800CL/9800L |
Voer de opdracht show platform hardware chassis active qfp datapath utilisation uit om deze component te bewaken. |
| ezman |
Chipsetbeheer voor interfaces |
Een aanhoudend hoge CPU kan wijzen op een hardwareprobleem of een mogelijk kernelsoftwareprobleem (het kan worden gemeld). |
| dbm |
Databasebeheer |
Een aanhoudende hoge CPU kan hier worden gemeld. |
| odm_X |
Operation Data Manager verwerkt geconsolideerde DB over processen heen |
Hoge CPU verwacht op geladen systemen. |
| bedrieglijk |
Verwerkt malafide functionaliteit |
Een aanhoudende hoge CPU kan hier worden gemeld. |
| smeden |
Shell Manager zorgt voor CLI parsing en interactie tussen verschillende processen. |
Hoge CPU verwacht bij het verwerken van grote CLI-uitvoer. Aanhoudende hoge CPU bij afwezigheid van belasting kan worden gemeld. |
| EMD |
Shell Manager - Verwerkt CLI-parsen en interacties tussen verschillende processen |
Hoge CPU verwacht bij het verwerken van grote CLI-uitvoer. Aanhoudend hoge CPU bij afwezigheid van belasting kan worden gemeld. |
| pubd |
Onderdeel van de telemetrie behandeling |
Hoge CPU verwacht voor grote telemetrie-abonnementen. Aanhoudend hoge CPU bij afwezigheid van belasting kan worden gemeld. |
Hoge CPU-beschermingsmechanismen
Catalyst 9800 Wireless LAN-controllers hebben uitgebreide beschermingsmechanismen rond netwerk- of draadloze clientactiviteit om hoge CPU te voorkomen als gevolg van onbedoelde of opzettelijke scenario's. Er zijn verschillende belangrijke functies die zijn ontworpen om problematische apparaten te helpen bevatten:
Uitsluiting van client
Deze optie is standaard ingeschakeld en maakt deel uit van het beleid voor draadloze beveiliging. Deze optie kan per beleidsprofiel worden ingeschakeld of uitgeschakeld. Dit kan verschillende gedragsproblemen detecteren, de client uit het netwerk verwijderen en in een tijdelijke uitsluitingslijst plaatsen. Hoewel de client zich in deze uitgesloten staat bevindt, praten de toegangspunten niet met hen, waardoor verdere acties worden voorkomen.
Nadat de uitsluitingstimer is verstreken (standaard 60 seconden), mag de client opnieuw koppelen.
Er zijn verschillende triggers voor cliëntuitsluiting:
- Het genereren van een ARP overstroming
- Herhaalde associatiefouten
- 3 of meer verificatiefouten voor webauth, PSK of 802.1x
- Herhaalde time-outs voor verificatie (geen reactie van de client)
- Proberen een IP-adres te hergebruiken, al geregistreerd bij een andere client
Uitsluiting van clients beschermt uw controller, toegangspunt en AAA-infrastructuur (Radius) tegen verschillende soorten hoge activiteit die kunnen leiden tot een hoge CPU. Het is niet raadzaam om uitsluitingsmethoden uit te schakelen, tenzij dit vereist is voor een probleemoplossingsoefening of compatibiliteitsvereiste.
De standaardinstellingen werken voor bijna alle gevallen en alleen in enkele uitzonderlijke scenario's zijn vereist om de uitsluitingstijd te verhogen of bepaalde specifieke trigger (s) uit te schakelen. Sommige bestaande of gespecialiseerde clients (IOT/Medical) moeten bijvoorbeeld de oorzaak van de associatiefout hebben uitgeschakeld als gevolg van defecten aan de clientzijde die niet eenvoudig kunnen worden gepatcht
U kunt de triggers aanpassen in de gebruikersinterface: Configuration/Wireless Protection/Client Exclusion Policies:
De ARP-uitsluitingstrigger is ontworpen om permanent op mondiaal niveau te worden ingeschakeld, maar kan op elk beleidsprofiel worden aangepast. U kunt de status controleren door de opdracht sh wireless profile policy all uit te voeren en naar deze specifieke uitvoer te zoeken:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Control Plane Protection tegen dataverkeer
Dit is een geavanceerd mechanisme in het gegevensvlak om ervoor te zorgen dat het verkeer dat naar het controlevlak wordt verzonden een vooraf gedefinieerde reeks drempels niet overschrijdt. Deze functie wordt Punt Policers genoemd en in bijna alle scenario's is het niet nodig om ze aan te raken, en zelfs dan moet deze alleen worden gebruikt bij het werken met Cisco Support.
Het voordeel van deze bescherming is dat het gedetailleerd inzicht biedt in het netwerk en of er een specifieke activiteit is met een verhoogd tarief of onverwachte hoge pakketten per seconde.
Dit wordt alleen weergegeven via CLI, omdat ze normaal gesproken deel uitmaken van geavanceerde functionaliteit die zelden hoeft te worden gewijzigd.
Om een overzicht van alle puntbeleid te ontvangen:
9800-l#show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 33 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
5 CLNS IS-IS Control 8738 2185 0 0 0 0 8738 2185 Off Off
6 HDLC keepalives 437 1000 0 0 0 0 437 1000 Off Off
7 ARP request or response 437 1000 0 330176 0 0 437 1000 Off Off
8 Reverse ARP request or repso 437 1000 0 24 0 0 437 1000 Off Off
9 Frame-relay LMI Control 437 1000 0 0 0 0 437 1000 Off Off
10 Incomplete adjacency 437 1000 0 0 0 0 437 1000 Off Off
11 For-us data 40000 5000 442919246 203771 0 0 40000 5000 Off Off
12 Mcast Directly Connected Sou 437 1000 0 0 0 0 437 1000 Off Off
Dit kan een grote lijst zijn met meer dan 160 vermeldingen, afhankelijk van de softwareversie. Controleer op de tabeluitvoer de kolom met het gedropte pakket samen met elke vermelding die een niet-nulwaarde heeft op de hoge valtelling. Om het verzamelen van gegevens te vereenvoudigen, kunt u de opdracht show platform software punt-policer drop-only uitvoeren om alleen te filteren voor politie-items met druppels.
Deze functie kan handig zijn om te identificeren of er ARP-stormen of 802.11-probe overstromingen zijn (ze gebruiken wachtrij 802.11-pakketten naar LFTS en LFTS staat voor Linux Forwarding Transport Service.)
toegangscontrole voor draadloze oproepen
In alle recente onderhoudsreleases heeft de controller een activiteitsmonitor om dynamisch te reageren op hoge CPU en ervoor te zorgen dat AP CAPWAP-tunnels actief blijven in het licht van niet-duurzame druk. Deze functie controleert de belasting van de WNCD en begint nieuwe clientactiviteit te vertragen om ervoor te zorgen dat er voldoende bronnen beschikbaar blijven om bestaande verbindingen aan te kunnen en om CAPWAP-stabiliteit te beschermen. Dit is standaard ingeschakeld en er zijn geen configuratieopties.
Er zijn drie beschermingsniveaus gedefinieerd, L1 bij 80% belasting, L2 bij 85% belasting en L3 bij 89%. Elk van de triggers van verschillende inkomende protocollen valt als beschermingsmechanismen. De beveiliging wordt automatisch verwijderd zodra de belasting afneemt.
In een gezond netwerk kun je geen L2- of L3-belastingsgebeurtenissen zien en als ze vaak voorkomen, kan het worden onderzocht.
Voer de opdracht cac (status van draadloze verbinding) uit om de monitor uit te voeren:
9800-l# show wireless stats cac
WIRESLESS CAC STATISTICS
---------------------------------------------
L1 CPU Threshold: 80 L2 CPU Threshold: 85 L3 CPU Threshold: 89
Total Number of CAC throttle due to IP Learn: 0
Total Number of CAC throttle due to AAA: 0
Total Number of CAC throttle due to Mobility Discovery: 0
Total Number of CAC throttle due to IPC: 0
CPU Throttle Stats
L1-Assoc-Drop: 0 L2-Assoc-Drop: 0 L3-Assoc-Drop: 0
L1-Reassoc-Drop: 0 L2-Reassoc-Drop: 0 L3-Reassoc-Drop: 0
L1-Probe-Drop: 12231 L2-Probe-Drop: 11608 L3-Probe-Drop: 93240
L1-RFID-Drop: 0 L2-RFID-Drop: 0 L3-RFID-Drop: 0
L1-MDNS-Drop: 0 L2-MDNS-Drop: 0 L3-MDNS-Drop: 0
mDNS-beveiligingen
mDNS als protocol maakt een zero-touch benadering mogelijk om services op verschillende apparaten te ontdekken, maar tegelijkertijd kan het zeer actief zijn en de belasting van het station aanzienlijk verhogen als het niet goed is geconfigureerd.
mDNS, zonder enige filtering, kan het gebruik van de WNCD-CPU gemakkelijk verhogen, afkomstig van verschillende factoren:
- mDNS beleid met onbeperkt leren, de controller verkrijgt alle diensten aangeboden door alle apparaten. Dit kan leiden tot grote servicelijsten, met honderden vermeldingen.
- Beleidsregels die zijn ingesteld zonder te filteren, zorgen ervoor dat de controller die grote servicelijsten naar elke client stuurt die vraagt wie een bepaalde service levert.
- Sommige mDNS-specifieke services worden geleverd door alle draadloze clients, wat leidt tot een hoger aantal services en een hogere activiteit met variaties hierop per OS-versie.
U kunt de grootte van de mDNS-lijst per service controleren door deze opdracht uit te voeren:
9800-l# show mdns-sd service statistics
Service Name Service Count
-----------------------------------------------------------------------------
_ipp._tcp.local 84
_ipps._tcp.local 52
_raop._tcp.local 950
_airplay._tcp.local 988
_printer._tcp.local 13
_googlerpc._tcp.local 12
_googlecast._tcp.local 70
_googlezone._tcp.local 37
_home-sharing._tcp.local 7
_cups._sub._ipp._tcp.local 26
Dit kan een idee geven van hoe groot een bepaalde query kan worden. Het duidt niet op een probleem op zichzelf, maar op een manier om te controleren wat er wordt gevolgd. Er zijn enkele belangrijke aanbevelingen voor de configuratie van mDNS:
- Stel mDNS-transport in op één protocol:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
Standaard maakt het gebruik van IPv4-transport en voor prestaties is het raadzaam om IPv6 of IPv4 te gebruiken, maar niet beide.
- Stel altijd een locatiefilter in het mDNS-servicebeleid in om ongebonden vragen/antwoorden te voorkomen. Over het algemeen wordt aanbevolen om site-tag te gebruiken, maar andere opties kunnen werken, afhankelijk van uw behoeften.
Ik heb meer hulp nodig
Als u een hoge CPU-belasting ziet en geen van de voorgaande stappen helpt, neemt u contact op met Customer Experience (CX) via een case en voegt u deze gegevens toe als startpunt:
- Basisgegevens, zoals AP/Controller-configuratie, netwerk- en RF-operationele waarden:
show tech-support wireless
- Archief voor alle controlesporen. Dit is een groot bestand dat lijkt op een blackbox-concept dat kan worden verzameld door deze opdracht uit te voeren:
request platform software trace archive last <days> to-file bootflash:<archive file>
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
03-Aug-2026
|
Bijgewerkte inleiding, spelling, grammatica, ingevoegde horizontale lijnen om secties / leesbaarheid te scheiden, vaste CCW-fouten. |
2.0 |
06-Jun-2025
|
Bijgewerkte alt-tekst, stijlvereisten, machinevertaling, merkvereisten en opmaak om te voldoen aan de richtlijnen van Cisco voor externalisatie |
1.0 |
09-May-2024
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)