Problemen oplossen bij belasting van draadloze LAN-controller CPU

Inleiding

In dit document wordt beschreven hoe u het CPU-gebruik op de Catalyst 9800 Wireless LAN-controllers kunt controleren en worden verschillende configuratieaanbevelingen behandeld.

Inzicht in CPU-gebruik

Voordat u zich verdiept in het oplossen van problemen met de CPU-belasting, moet u de basis begrijpen van hoe CPU's worden gebruikt in Catalyst 9800 Wireless LAN-controllers en enkele details over de softwarearchitectuur.

In het algemeen definieert het document Best Practices van Catalyst 9800 een reeks goede configuratie-instellingen die problemen op toepassingsniveau kunnen voorkomen. Bijvoorbeeld door locatiefiltering voor mDNS te gebruiken of door ervoor te zorgen dat clientuitsluiting altijd is ingeschakeld. Het wordt aanbevolen dat u deze aanbevelingen samen met de hier besproken onderwerpen toepast.

Basisbeginselen 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 naamgeving van de ontwikkeling was eWLC met de e voor elastic, om aan te geven dat dezelfde softwarearchitectuur in staat zou zijn om van een klein geïntegreerd CPU-systeem naar meerdere grootschalige CPU / core-apparaten te lopen.

Elke WLC heeft twee verschillende kanten:

• Control plane: het afhandelen van alle beheerinteracties zoals CLI, UI, Netconf en alle onboarding-processen voor klanten en toegangspunten.
• Data plane: verantwoordelijk voor het daadwerkelijk doorsturen van pakketten, en de decapsulatie van CAPWAP, AVC-beleidshandhaving, naast andere functionaliteiten.

Besturingsplane

• De meeste Cisco IOS XE-processen worden uitgevoerd onder BinOS (Linux Kernel), met een eigen gespecialiseerde planner en controleopdrachten.
• Er is een set van belangrijke processen, genaamd Wireless Network Control Daemon (WNCD), die elk een lokale in-memory database hebben, die het grootste deel van de draadloze activiteit afhandelen. Elke CPU bezit een WNCD, om de belasting over alle beschikbare CPU-kernen naar elk systeem te verdelen
• De verdeling van de belasting over de WNCD's vindt plaats tijdens de AP-join. Wanneer een toegangspunt een CAPWAP-verbinding met de controller uitvoert, verdeelt een interne taakverdeler het toegangspunt met behulp van een reeks mogelijke regels om ervoor te zorgen dat alle beschikbare CPU-bronnen correct worden gebruikt.
• Cisco IOS®-code wordt uitgevoerd op een 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 en injectie, duwt frames van het besturingsvlak in het netwerk.

Als onderdeel van een mogelijk onderzoek naar hoge CPU-problemen, moet u het puntmechanisme bewaken 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 softwareframework voor de ontwikkeling van packet forwarding-engines, die worden gebruikt voor meerdere producten en technologieën.

De architectuur maakt een gemeenschappelijke functieset mogelijk voor verschillende hardware- of software-implementaties. Bijvoorbeeld, het toestaan van soortgelijke functies voor 9800CL vs 9800-40, op verschillende doorvoerschalen.

AP-taakverdeling

De WLC voert taakverdeling uit over CPU's tijdens het CAPWAP AP-joinproces, waarbij de belangrijkste onderscheidende factor de naam van de AP-sitetag is. Het idee is dat elk AP een specifieke CPU-belasting vertegenwoordigt die is toegevoegd, afkomstig van de clientactiviteit en het AP zelf. Er zijn verschillende mechanismen om deze balancering uit te voeren:

• Als het toegangspunt standaard-tag gebruikt, wordt het op een round-robin manier verdeeld over alle CPU's/WNCD's, waarbij elke nieuwe toegangspunt naar de volgende WNCD gaat. Dit is de eenvoudigste methode, maar het heeft weinig implicaties:
  • Dit is het suboptimale scenario, aangezien toegangspunten in hetzelfde RF-roamingdomein frequente roaming tussen WNCD's zouden doen, waarbij sprake is van aanvullende communicatie tussen processen. Roaming over instanties is langzamer met een klein percentage.
  • Voor de FlexConnect-sitetag (extern) is geen PMK-sleuteldistributie beschikbaar. Dit betekent dat u geen snelle roaming kunt uitvoeren voor de Flex-modus, waardoor de OKC / FT-roamingmodi worden beïnvloed.
    
    Over het algemeen kan de standaardtag worden gebruikt voor scenario's met een lagere belasting (bijvoorbeeld minder dan 40% van de AP- en 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 dat behoort tot de naam van de sitetag aan de controller wordt toegevoegd, toegewezen aan een specifieke WNCD-instantie. Alle volgende extra AP-verbindingen met dezelfde tag worden toegewezen aan dezelfde WNCD. Dit zorgt ervoor dat roaming over AP's in dezelfde site-tag plaatsvindt in de ene WCND-context, wat een meer optimale flow biedt, met een lager CPU-gebruik. Zwerven tussen WNCD's wordt ondersteund, maar niet zo optimaal als zwerven binnen WNCD's.
  
  
• Standaardlastverdelingsbeslissing: wanneer een tag aan een WNCD wordt toegewezen, selecteert de lastverdeler de instantie met het laagste aantal sitetags op dat moment. Omdat de totale belasting die die site-tag kan hebben niet bekend is, kan dit leiden tot suboptimale balanceringsscenario's. Dit is afhankelijk van de volgorde van de AP-joins, het aantal site-tags dat is gedefinieerd en of het aantal AP-joins asymmetrisch is
  
  
• Statische taakverdeling: om onevenwichtige toewijzing van site-tags aan WNCD te voorkomen, werd de opdracht site-load geïntroduceerd in 17.9.3 en hoger, zodat beheerders de verwachte belasting van elke site-tag vooraf kunnen definiëren. Dit is vooral handig bij het hanteren 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 bijvoorbeeld een 9800-40 hebt die één hoofdkantoor en vijf filialen met verschillende aantallen toegangspunten beheert, 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 sitetags en het platform heeft 5 WNCD's, dus er kan een kans zijn dat de hoogst geladen sitetags op dezelfde CPU terechtkomen. Met de opdracht load kunt u een voorspelbare taakverdelingstopologie voor toegangspunten maken.

De opdracht load is een verwachte grootte. Deze hoeft niet exact overeen te komen met het aantal toegangspunten, maar wordt normaal ingesteld op de verwachte toegangspunten waaraan kan worden deelgenomen.

• In scenario's waarbij grote gebouwen door één controller worden afgehandeld, is het eenvoudiger en eenvoudiger om net zoveel site-tag te maken als WNCD's voor dat specifieke platform (bijvoorbeeld C9800-40 heeft er vijf, C9800-80 heeft er 8). AP's in hetzelfde gebied of zwervend domein toewijzen aan dezelfde sitetags om communicatie tussen WNCD's te minimaliseren.
• RF-taakverdeling: hiermee worden AP's over WNCD-instanties in evenwicht gebracht, waarbij gebruik wordt gemaakt van de RF-buurrelatie van RRM, en worden subgroepen gemaakt afhankelijk van hoe dicht de AP's bij elkaar staan. Dit moet worden gedaan nadat de toegangspunten al enige tijd actief zijn en het is niet meer nodig om statische instellingen voor de taakverdeling te configureren. Deze is beschikbaar vanaf 10 .12 en hoger.

Hoe te achterhalen hoeveel WNCD's aanwezig zijn

Voor hardwareplatforms staat het aantal WNCD's vast: 9800-40 heeft 5, 9800-80 heeft 8. Voor 9800CL (virtueel) hangt het aantal WNCD's af van het sjabloon voor virtuele machines dat tijdens de eerste implementatie wordt gebruikt.

Als algemene regel geldt dat als u wilt weten hoeveel WNCD's in het systeem worden uitgevoerd, u deze opdracht voor alle controllertypen kunt gebruiken:

9800-40#show processes cpu platform sorted  |  count wncd
Number of lines which match regexp = 5

In het specifieke geval van 9800-CL kunt u de opdracht gebruiken om gegevens op het virtuele platform  show platform software system all  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 van toegangspunt

De toewijzing van AP aan WNCD wordt toegepast tijdens het AP CAPWAP-joinproces, dus het wordt niet verwacht dat deze verandert tijdens bewerkingen, ongeacht de balanceringsmethode, tenzij er een netwerkbrede CAPWAP-resetgebeurtenis is waarbij alle AP's de verbinding verbreken en opnieuw toetreden.

De CLI-opdrachtshow wireless loadbalance tag affinitykan een eenvoudige manier bieden om de huidige status van de werklast van het toegangspunt te zien voor 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, is de eenvoudigste manier om de WCAE-ondersteuningstool te gebruiken en eenshow tech wirelessbestand te laden dat tijdens drukke tijden is gemaakt. De tool vat het aantal WNCD-clients samen, afkomstig van elk toegangspunt dat eraan is gekoppeld.

Voorbeeld van een goed uitgebalanceerde controller, bij laag gebruik en een laag aantal clients:

Een ander voorbeeld, voor een meer geladen controller, met normaal CPU-gebruik:

Wat is het aanbevolen AP-loadbalancing-mechanisme

Kortom, u kunt de verschillende opties samenvatten in:

• Klein netwerk, geen behoefte aan snelle roaming, minder dan 40% van de controllerbelasting: standaardtag.
• Als snel roamen nodig is (OKC, FT, CCKM) of een groot aantal clients:
  • Single building: maak evenveel site-tags als CPU's (afhankelijk van het platform).
  • Vóór 10 .12, of minder dan 500 AP-telling: Meerdere gebouwen, vestigingen of grote campus: Maak een site-tag per fysieke RF-locatie en configureer de opdracht load per site.
  • 10 .12 en hoger met meer dan 500 AP's: gebruik RF-taakverdeling.

Deze drempel van 500 AP geeft aan wanneer het loadbalancing-mechanisme van toepassing is, omdat AP's standaard in blokken van 100 eenheden worden gegroepeerd.

AP WNCD-distributievisualisatie

Er zijn scenario's waarin u een meer geavanceerde AP-balancering wilt uitvoeren en het is wenselijk om gedetailleerde controle te hebben over hoe AP's over CPU's worden verspreid. Bijvoorbeeld scenario's met een zeer hoge dichtheid waarbij de belangrijkste belastingsmaatstaf het aantal clients is versus alleen maar focussen op het aantal AP's dat in het systeem aanwezig is.

Een goed voorbeeld van deze situatie zijn grote evenementen: een gebouw zou duizenden clients kunnen hosten, meer dan enkele honderden AP's, en je zou de belasting over zoveel mogelijk CPU's moeten verdelen, maar tegelijkertijd roaming moeten optimaliseren. U zwerft dus niet over WNCD tenzij het nodig is. U wilt zout- en pepersituaties voorkomen waarbij meerdere AP's in verschillende WNCD's / site-tags op dezelfde fysieke locatie worden gemengd.

Om te helpen bij het afstemmen en visualiseren van de distributie, kunt u de WCAE-tool gebruiken en profiteren van de functie RF-weergave van AP:

Hiermee kunt u de AP/WNCD-distributie zien, alleen ingesteldView Typeop WNCD. Elke kleur vertegenwoordigt hier een WNCD/CPU. U kunt het RSSI-filter ook instellen op -85, om verbindingen met lage signalen te vermijden, die ook worden gefilterd door het RRM-algoritme in de controller.

In het vorige voorbeeld, dat overeenkwam met Ciscolive EMEA 24, kunt u zien dat de meeste aangrenzende toegangspunten mooi geclusterd zijn in dezelfde WNCD, met zeer beperkte overlappingen.

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 er rekening mee 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 gebruikenshow processes cpu platform sortedom gedetailleerde informatie te verzamelen voor alle processen in Cisco IOS XE:

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 hier te benadrukken:

• Het proces ucode_pkt_PPE0 behandelt het gegevensvlak op 9800L- en 9800CL-platforms en verwacht wordt dat het de hele tijd een hoog gebruik zal zien, zelfs hoger dan 100%. Dit maakt deel uit van de tenuitvoerlegging en vormt geen probleem.
• Het is belangrijk om piekgebruik te onderscheiden van een aanhoudende belasting en te isoleren wat er in een bepaald scenario wordt verwacht. Bijvoorbeeld, het verzamelen van een zeer grote CLI-uitvoer, zoalsshow tech wirelesskan een piekbelasting genereren op IOSd-, smand-, pubd-processen, omdat een zeer grote tekstuitvoer wordt verzameld, waarbij honderden CLI-opdrachten worden uitgevoerd. Dit is geen probleem en de belasting daalt nadat 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 de hoge activiteitstijden van de client. Het is mogelijk om pieken van 80% te zien, zonder enige functionele impact, en ze vormen 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 langdurig hoog CPU-gebruik op een proces, hoger dan 90%, gedurende meer dan 15 minuten, moet worden onderzocht.
  
  
• U kunt het CPU-gebruik van IOSd bewaken met de opdrachtshow processes cpu sorted. Dit komt overeen met de activiteit in het linux_iosd-image-procesdeel 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 IOSd-belasting, per kerngebruik en de belasting van het gegevensvliegtuig:

Dit is beschikbaar op hetMonitoring/System/CPU Utilizationtabblad.

Wat is elk proces

De exacte proceslijst zou variëren, afhankelijk van het controllermodel en de Cisco IOS XE-versie. Dit is een lijst van enkele van de belangrijkste processen, en het is niet de bedoeling om alle mogelijke vermeldingen te dekken.

Hoge CPU-beveiligingsmechanismen

Catalyst 9800 draadloze LAN-controllers hebben uitgebreide beveiligingsmechanismen rond netwerk- of draadloze clientactiviteiten om een hoge CPU te voorkomen als gevolg van onbedoelde of opzettelijke scenario's. Er zijn verschillende belangrijke functies die zijn ontworpen om u te helpen problematische apparaten te bevatten:

Clientuitsluiting

Dit is standaard ingeschakeld en maakt deel uit van het beleid voor draadloze beveiliging. Het kan worden in- of uitgeschakeld volgens het beleidsprofiel. Dit kan verschillende gedragsproblemen detecteren, de client uit het netwerk verwijderen en deze in een tijdelijke uitsluitingslijst plaatsen. Terwijl 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 uitsluiting van klanten:

• Herhaalde associatiefouten
• 3 of meer webauth-, PSK- of 802.1x-verificatiefouten
• Herhaalde time-outs voor verificatie (geen reactie van client)
• Proberen een IP-adres te hergebruiken dat al bij een andere client is geregistreerd
• Het genereren van een ARP overstroming

Uitsluiting van clients beschermt uw controller, toegangspunt en AAA-infrastructuur (Radius) tegen verschillende typen activiteiten met een hoge activiteit die kunnen leiden tot een hoge CPU. In het algemeen is het niet raadzaam om een van de uitsluitingsmethoden uit te schakelen, tenzij dit nodig is voor een probleemoplossingsoefening of compatibiliteitsvereiste.

De standaardinstellingen werken voor bijna alle gevallen, en alleen voor sommige uitzonderlijke scenario's, is het nodig om de uitsluitingstijd te verlengen of een specifieke trigger uit te schakelen. Sommige bestaande of gespecialiseerde klanten (IOT/Medical) moeten bijvoorbeeld de oorzaak van het falen van de associatie hebben om te worden uitgeschakeld, vanwege gebreken aan de clientzijde die niet gemakkelijk kunnen worden gepatcht

U kunt de triggers aanpassen in de gebruikersinterface: Configuratie/Draadloze beveiliging/Beleid voor clientuitsluiting:

ARP Exclusion Trigger is ontworpen om permanent ingeschakeld te zijn op mondiaal niveau, maar kan worden aangepast op elk beleidsprofiel. U kunt de status controleren met de opdrachtsh wireless profile policy allZoeken naar deze specifieke uitvoer:

ARP Activity Limit
  Exclusion                          : ENABLED
  PPS                                : 100
  Burst Interval                     : 5

Besturingsvlak Bescherming tegen dataverkeer

Dit is een geavanceerd mechanisme in het gegevensvlak om ervoor te zorgen dat het verkeer dat naar het controlevlak wordt gestuurd, een vooraf bepaalde reeks drempels niet overschrijdt. De functie wordt Punt Policers genoemd en in bijna alle scenario's is het niet nodig om ze aan te raken, en zelfs dan moet alleen worden gedaan terwijl u samenwerkt met Cisco Support.

Het voordeel van deze bescherming is dat het een zeer gedetailleerd inzicht geeft in wat er in het netwerk gebeurt, en of er een specifieke activiteit is die een verhoogde snelheid heeft, of onverwacht hoge pakketten per seconde.

Dit wordt alleen zichtbaar gemaakt via CLI, omdat ze normaal gesproken deel uitmaken van geavanceerde functionaliteit die zelden hoeft te worden gewijzigd.

Om een overzicht te krijgen van alle puntenbeleid:

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. 

Op de tabeluitvoer wilt u de gedropte pakketkolom controleren, samen met elk item dat een niet-nulwaarde heeft op het hoge aantal druppels.

Om het verzamelen van gegevens te vereenvoudigen, kunt u de opdracht gebruikenshow platform software punt-policer drop-only, om te filteren op alleen policer-items met druppels.

Deze functie kan nuttig zijn om te identificeren of er ARP-stormen of 802.11-sondeoverstromingen zijn (ze gebruiken wachtrij 802.11 Packets to LFTS. LFTS staat voor Linux Forwarding Transport Service.

draadloze gesprekstoegangscontrole

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, ondanks onhoudbare druk. De functie controleert de WNCD-belasting en begint nieuwe clientactiviteiten af te remmen om ervoor te zorgen dat er voldoende bronnen overblijven om de bestaande verbindingen te verwerken en de CAPWAP-stabiliteit te beschermen. Dit is standaard ingeschakeld en er zijn geen configuratieopties.

Er zijn drie niveaus van bescherming gedefinieerd, L1 bij 80% belasting, L2 bij 85% belasting en L3, bij 89%, waarbij elk een ander inkomend protocol als beschermingsmechanismen wordt geactiveerd. De beveiliging wordt automatisch verwijderd zodra de belasting afneemt.

In een gezond netwerk kunt u L2- of L3-belastinggebeurtenissen niet zien en als ze vaak voorkomen, kan dit worden onderzocht.

Gebruik de opdrachtwireless stats cacvoor bewaking zoals in de afbeelding wordt weergegeven.

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 erg actief zijn en de drive aanzienlijk laden, als het niet goed is geconfigureerd.

mDNS, zonder enige filtering, kan eenvoudig het gebruik van de WNCD-CPU verhogen, afkomstig van verschillende factoren:

1. mDNS-beleid met onbeperkt leren, de controller krijgt alle diensten aangeboden door alle apparaten. Dit kan leiden tot zeer grote servicelijsten, met honderden vermeldingen.
2. Beleid ingesteld zonder te filteren: dit zorgt ervoor dat de controller die grote servicelijsten doordrukt, naar elke klant die vraagt wie een bepaalde service levert.
3. 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 met deze opdracht:

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 zoekopdracht kan worden. Het duidt niet op een probleem op zich, maar alleen op een manier om te controleren wat er wordt bijgehouden.

Er zijn een aantal belangrijke mDNS configuratie aanbevelingen:

• 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. 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 het 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 vorige stappen helpt, neem dan contact op met CX via een case en voeg deze gegevens toe als startpunt:

• Basisgegevens, zoals de configuratie van de AP/Controller en de operationele waarden van het netwerk en de RF:

show tech-support wireless 

• Archief voor alle controllersporen. Dit is een groot bestand, vergelijkbaar met een blackbox-concept, dat kan worden verzameld met de opdracht:

request platform software trace archive last <days> to-file bootflash:<archive file>