De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document wordt beschreven hoe u het CPU-gebruik op de Catalyst 9800 Wireless LAN-controllers kunt controleren en worden verschillende configuratieaanbevelingen behandeld.
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.
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:
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.
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.
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 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.
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
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 affinity
kan 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 wireless
bestand 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:
Kortom, u kunt de verschillende opties samenvatten in:
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.
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 Type
op 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.
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 sorted
om 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:
show tech wireless
kan 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
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
show 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
Dit is beschikbaar op hetMonitoring/System/CPU Utilization
tabblad.
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.
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 kon pieken van hoog gebruik zien tijdens drukke uren. Rapporteer of het gebruik gedurende enkele minuten voor 95% of meer vastzit. |
Linux_IOSD-Image |
IOS-proces |
Verwacht wordt een hoog gebruik te zien bij het verzamelen van grote CLI-uitvoer (show-tech). 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 |
Gebruik de opdracht |
Ezman |
Chipsetbeheer voor interfaces |
Een aanhoudende hoge CPU kan hier wijzen op een hardwareprobleem of een mogelijk kernelsoftwareprobleem. Het kan worden gemeld. |
DBM |
Databasebeheer |
Een aanhoudende hoge CPU kan hier worden gerapporteerd. |
odm_X |
Operation Data Manager verwerkt geconsolideerde DB in alle processen. |
Hoge CPU verwacht op geladen systemen. |
schurkenstaat |
Verwerkt Rogue-functionaliteit |
Een aanhoudende hoge CPU kan hier worden gerapporteerd. |
smand |
Shell Manager zorgt voor CLI-parsing en interactie tussen verschillende processen. |
Hoge CPU verwacht tijdens het verwerken van grote CLI-uitvoer. Aanhoudende hoge CPU in afwezigheid van belasting kan worden gerapporteerd. |
EMD |
Shell Manager. Zorgt voor CLI-parsing en interactie tussen verschillende processen. |
Hoge CPU verwacht tijdens het verwerken van grote CLI-uitvoer. Aanhoudende hoge CPU op de afwezigheid van belasting kan worden gemeld. |
pubd |
Onderdeel van telemetrie behandeling |
Hoge CPU verwacht voor grote telemetrie abonnementen. Aanhoudende hoge CPU op de afwezigheid van belasting kan worden gemeld. |
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:
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:
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 all
Zoeken naar deze specifieke uitvoer:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
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.
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 cac
voor 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 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:
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:
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.
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:
show tech-support wireless
request platform software trace archive last <days> to-file bootflash:<archive file>
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
06-Jun-2025
|
Bijgewerkte Alt-tekst, stijlvereisten, machinevertaling, brandingvereisten en opmaak om te voldoen aan de richtlijnen van Cisco voor externalisatie |
1.0 |
09-May-2024
|
Eerste vrijgave |