Fehlerbehebung bei Catalyst 9800 Wireless LAN Controllern

Einleitung

In diesem Dokument werden alle Funktionen und Leistungsmerkmale von Cisco IOS® XE zur Fehlerbehebung bei Catalyst 9800 beschrieben und beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse der Wireless LAN Controller (WLC).
• Grundkenntnisse der an der Nutzung eines WLC beteiligten Anwendungsfälle

Verwendete Komponenten

Dieses Dokument basiert auf den folgenden Software- und Hardwareversionen:

Dieses Dokument umfasst die Controller 9800-CL, 9800-L, 9800-40 und 9800-80. Es basiert hauptsächlich auf der Version 17.3 von Cisco IOS® XE.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen

Hintergrundinformationen

Cisco IOS® XE auf 9800 WLCs besteht im Wesentlichen aus einem Linux-Kernel (binOS) mit Cisco IOS® und allen Wireless-Prozessen, die als Daemons implementiert sind.

Alle Prozess-Daemons können unter dem Oberbegriff Control Plane (CP) gebündelt werden und sind für Control and Provisioning of Access Points (CAPWAP), Mobility, Radio Resource Management (RRM) zuständig. Rogue Management, Network Mobility Service Protocol (NMSP), die für und vom 9800 WLC bestimmt sind.

Datenebene (DP) bezieht sich auf die Komponenten, die Daten des 9800 WLC weiterleiten.

Bei allen Iterationen von 9800 (9800-40, 9800-80, 9800-CL, 9800-SW,9800-L) bleibt die Kontrollebene recht häufig.

Die Datenebene variiert jedoch je nach den Standards 9800-40 und 9800-80, die einen Hardware-Quantum Flow-Prozessor (QFP) verwenden, der dem ASR1k ähnlich ist, während 9800-CL und 9800-L die Implementierung von Cisco Packet Processor (CPP) verwenden. 9800-SW nutzt einfach den Doppler. Chipsatz auf Catalyst Switches der Serie 9k für die Datenweiterleitung.

Paketfluss innerhalb des 9800 WLC

 

Wenn ein Paket über physische Ports in den 9800 WLC eingeht und als Kontrolldatenverkehr erkannt wird, wird es an die entsprechenden Kontrollebenenprozesse gesendet.

Bei einem AP-Beitritt sind dies alle vom AP stammenden CAPWAP- und DTLS-Austauschvorgänge. Im Fall einer Client-Anmeldung ist dies der gesamte Datenverkehr, der vom Client stammt, bis der Client den Status "RUN" erhält.

Während die verschiedenen Daemons den eingehenden Datenverkehr verarbeiten, wird der resultierende Rückverkehr (Capwap-Antwort, dot11, dot1x, dcp-Antwort) von 9800 WLC, der an den Client gesendet werden soll, zurück in die Datenebene injiziert, um vom physischen Port gesendet zu werden.

Während der Verarbeitung von AP-Joins, Client-Joins, Mobilitätsübertragungen und Datenebenen muss die Datenverkehrsweiterleitung programmiert werden.

Dies geschieht, indem mehrere Komponenten sequenziell über den im Bild angegebenen Programmierpfad programmiert werden.

Cisco IOS® XE bietet ein vielseitiges Tool-Set, mit dem das Paket vom Eingang beim 9800 WLC bis zum Verlassen des Pakets verfolgt werden kann.

Im nächsten Abschnitt werden diese Tools zusammen mit den Befehlen vorgestellt, die zum Aufrufen dieser Tools über die Befehlszeilenschnittstelle (CLI) verwendet werden.

Verfolgung auf Kontrollebene

In diesem Abschnitt werden die verfügbaren Befehle und Tools beschrieben, mit denen die Verarbeitung durch die Prozesse auf der Steuerungsebene angezeigt werden kann, nachdem das für den 9800 WLC bestimmte Paket vom DP durchsucht wurde oder bevor das Antwortpaket vom 9800 WLC zum DP eingespeist wird, um die physische Schnittstelle zu senden.

Syslog

Die vom 9800 WLC generierten Protokolle sind das erste Mittel zur Überprüfung des allgemeinen Systemzustands.

Jeder Verstoß gegen den vordefinierten Grenzwert für Systemressourcen wie CPU, Speicher und Puffer wird in das Protokoll aufgenommen.

Außerdem werden alle Fehler, die von Subsystemen generiert werden, in Protokolle geschrieben. Um die Protokolle anzuzeigen, navigieren Sie zu Troubleshooting > Syslog (Fehlerbehebung > Syslog).

Führen Sie den CLI-Befehl aus:

# show logging

Diese Ausgabe zeigt allgemeine Protokolle sowie einige Wireless-spezifische Protokolle an. Im Gegensatz zu Cisco IOS® wird bei der Protokollierung jedoch in der Regel kein Wireless-Debugging durchgeführt.

Anmerkung: Wenn der WLC9800 so konfiguriert ist, dass diese Protokolle an einen externen Syslog-Server umgeleitet werden, müssen Sie auch die Protokolle auf dem externen Syslog-Server überprüfen.

Stets verfügbare Ablaufverfolgung

Jeder Prozess auf der Kontrollebene des WLC9800 protokolliert fortlaufend die Protokollierungsebene von Notice an seinen eigenen dedizierten Puffer. Dies wird als Always-On-Tracing bezeichnet.

Dies ist eine einzigartige Funktion, mit der Sie kontextbezogene Daten zu einem aufgetretenen Fehler abrufen können, ohne dass die Fehlerbedingung reproduziert werden muss.

Wenn Sie z. B. mit AireOS vertraut sind, müssen Sie für die Behebung von Client-Verbindungsproblemen Debugs aktivieren und den Client-Verbindungsproblemstatus reproduzieren, um die Ursache zu identifizieren.

Mit der stets verfügbaren Ablaufverfolgung können Sie auf bereits erfasste Ablaufverfolgungen zurückblicken und feststellen, ob es sich um eine gemeinsame Ursache handelt.  Je nach Umfang der generierten Protokolle können wir mehrere Stunden bis mehrere Tage zurückblicken.

Nun, während die Traces pro individuellem Prozess protokolliert werden, ist es möglich, sie ganzheitlich für einen bestimmten Kontext von Interesse wie Client-MAC oder AP-MAC oder AP-IP-Adresse zu betrachten. Führen Sie dazu den Befehl

# show logging profile wireless filter mac  to-file bootflash:

Standardmäßig geht dieser Befehl nur 10 Minuten zurück, um die Protokolle zu generieren und zu dekodieren. Sie können wählen, weiter in die Zeit zurückzugehen mit:

# show logging profile wireless start last <number> [minutes|hours|days] filter mac  to-file bootflash:

Führen Sie den folgenden Befehl aus, um prozessspezifische Protokolle anzuzeigen:

# show logging process  to-file bootflash:

Anmerkung: Für diese CLIs stehen mehrere Filteroptionen zur Verfügung, darunter Modul, Protokollierungsebene, Start-Zeitstempel usw. Um diese Optionen anzuzeigen und zu erkunden, führen Sie den Befehl

# show logging profile wireless ?
# show logging process  ?

Bedingtes Debuggen und RadioActive Tracing

Bedingtes Debuggen ermöglicht es, die Protokollierung der Debugebene für bestimmte Features für die gewünschten Bedingungen zu aktivieren.

Die RadioActive-Ablaufverfolgung geht noch einen Schritt weiter, indem sie die Möglichkeit hinzufügt, Debuginformationen bedingt über Prozesse und Threads hinweg für die interessierende Bedingung zu drucken.

Das bedeutet, dass die zugrunde liegende Architektur vollständig abstrahiert ist.

Anmerkung: Am 16.12.2012 wird die radioaktive Nachverfolgung nur für die Fehlerbehebung von AP-Joins mit AP-Funk- und Ethernet-MAC-Adressen, Client-Joins mit Client-MAC-Adressen sowie von Mobilitätsproblemen mit Mobility-Peer-IP- und CMX-Verbindungen mit der CMX-IP-Adresse implementiert.

Anmerkung: Die MAC-Adresse und die IP-Adresse als Bedingung liefern unterschiedliche Ausgänge, da verschiedene Prozesse unterschiedliche Bezeichner für dieselbe Netzwerkeinheit (Access Point, Client oder Mobility Peer) erkennen.

Bei der Client-Konnektivität als Beispiel für die Fehlerbehebung wird bedingtes Debugging ausgeführt, damit die Client-MAC eine End-to-End-Ansicht auf der Kontrollebene erhält.

Radioaktive Spuren über die Web-Benutzeroberfläche

Navigieren Sie zum Seitenmenü Fehlerbehebung, und wählen Sie Radioactive Tracing aus.

Klicken Sie auf Hinzufügen, und geben Sie eine Client- oder AP-MAC-Adresse ein, die Sie beheben möchten.  Ab 16.12 können über die GUI nur noch MAC-Adressen hinzugefügt werden. Sie können die IP-Adresse über die CLI hinzufügen.

Sie können mehrere MAC-Adressen für die Nachverfolgung hinzufügen. Wenn Sie bereit sind, die radioaktive Verfolgung zu starten, klicken Sie auf Start.

Nach dem Start werden die Debug-Protokolle über die Verarbeitung der verfolgten MAC-Adressen auf die Festplatte geschrieben.

Wenn Sie das Problem reproduziert haben, das Sie beheben möchten, klicken Sie auf Beenden.

Für jede debuggte MAC-Adresse können Sie eine Protokolldatei erstellen, in der alle Protokolle zu dieser MAC-Adresse aufgelistet sind. Klicken Sie dazu auf Generate (Generieren).

Wählen Sie aus, wie lange die sortierte Protokolldatei zurückgehen soll, und klicken Sie auf Auf Gerät anwenden.

Sie können die Datei jetzt herunterladen, indem Sie auf das kleine Symbol neben dem Dateinamen klicken. Diese Datei befindet sich im Bootflash-Laufwerk des Controllers und kann auch über die CLI kopiert werden.

Radioaktive Spuren über CLI

Um das bedingte Debuggen zu aktivieren, führen Sie den Befehl

# debug wireless {mac | ip} {aaaa.bbbb.cccc | x.x.x.x } {monitor-time} {N seconds}

Um die aktuell aktivierten Bedingungen anzuzeigen, führen Sie den Befehl

# show debugging

Bei diesen Debugs wird keine Ausgabe in einer Terminalsitzung ausgegeben, sondern die Debugausgabedatei wird als Flash-Datei gespeichert, die anschließend abgerufen und analysiert werden kann. Die Datei wird mit der Namenskonvention ra_trace_* gespeichert

Für die MAC-Adresse aaaa.bbb.cccc lautet der generierte Dateiname z. B. ra_trace_MAC_aaabbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log.

Ein Vorteil besteht darin, dass der gleiche Befehl zur Behebung von AP-Join-Problemen (Input-AP-Funk-MAC und Ethernet-MAC), Client-Verbindungsproblemen (Input-Client-MAC), Mobility-Tunnel-Problemen (Input-Peer-IP) und Client-Roaming-Problemen (Input-Client-MAC) verwendet werden kann.

Mit anderen Worten, Sie müssen sich nicht an mehrere Befehle wie debug capwap, debug client, debug mobility erinnern und so weiter.

Anmerkung: debug wireless erlaubt auch, auf einen FTP-Server zu verweisen und eine noch ausführlichere Protokollierung mit internem Schlüsselwort auszuführen. Es wird nicht empfohlen, diese zu diesem Zeitpunkt zu verwenden, da einige Probleme ausgebügelt werden.

Führen Sie den folgenden Befehl aus, um die Ausgabedatei in einer Terminalsitzung zu debuggen:

# more bootflash:ra_trace_MAC_*.log 

Führen Sie den folgenden Befehl aus, um die Debugausgabe zur Offlineanalyse an einen externen Server umzuleiten:

# copy bootflash:ra_trace_MAC_*.log ftp://username:password@FTPSERVERIP/path/RATRACE_FILENAME.txt

Es gibt eine viel ausführlichere Ansicht derselben Debug-Protokollstufen. Führen Sie den folgenden Befehl aus, um diese ausführliche Ansicht anzuzeigen:

# show logging profile wireless internal filter mac  to-file 

Führen Sie den Befehl aus, um das Debuggen für bestimmte Kontexte oder vor Ablauf der konfigurierten oder standardmäßigen Überwachungszeit zu deaktivieren.

# no debug wireless mac <aaaa.bbbb.cccc>

Vorsicht: Das bedingte Debugging ermöglicht die Protokollierung des Debugging-Levels, wodurch sich wiederum die Menge der generierten Protokolle erhöht. Wenn Sie diese Option aktivieren, wird der Zeitaufwand für das Anzeigen von Protokollen reduziert. Daher wird empfohlen, das Debuggen immer am Ende der Fehlerbehebungssitzung zu deaktivieren.

 Führen Sie die folgenden Befehle aus, um das Debuggen vollständig zu deaktivieren:

# clear platform condition all
# undebug all

Nicht bedingtes prozessbasiertes Debuggen

Für die Anwendungsfälle und Prozesse, die nicht für die radioaktive Nachverfolgung implementiert sind, können Sie Ablaufverfolgungen auf Debugebene abrufen. Um die Debugging-Ebene für einen bestimmten Prozess festzulegen, verwenden Sie den folgenden Befehl:

# set platform software trace <PROCESS_NAME> wireless chassis active R0 { module_name | all-modules } 

Führen Sie den folgenden Befehl aus, um die Ablaufverfolgungsebenen der verschiedenen Module zu überprüfen:

# show platform software trace level <PROCESS_NAME> chassis active R0

Führen Sie den folgenden Befehl aus, um die gesammelten Ablaufverfolgungen anzuzeigen:

# show logging process  to-file 

Paketverfolgung auf Datenebene

Wenn ein Paket erstmals über den 9800 WLC eingeht, findet eine Verarbeitung auf Datenebene statt, um zu identifizieren, ob es sich bei dem Datenverkehr um die Kontroll- oder Datenebene handelt.

Die Packet-Trace-Funktion bietet eine detaillierte Ansicht dieser Cisco IOS® XE-Verarbeitung, die in dataplane durchgeführt wird, sowie die Entscheidung, ob das Paket gelockt, weitergeleitet, verworfen oder verbraucht werden soll. Diese Funktion auf dem WLC 9800 funktioniert genau wie die Implementierung auf dem ASR!k.

Packet Tracer auf dem 9800 WLC bietet drei Prüfungsebenen, die mit denen von ASR1K identisch sind.

• Statistik - Zeigt die Anzahl der Pakete an, die in den Netzwerkprozessor eintreten und diesen verlassen.
• Zusammenfassung-
  • Diese wird für eine begrenzte Anzahl von Paketen gesammelt, die spezifischen Bedingungen von Interesse entsprechen.
  • Die zusammengefasste Ausgabe zeigt die Eingangs- und Ausgangsschnittstellen, die auf Datenebene getroffenen Nachschlageentscheidungen sowie die Verfolgung von Punt-, Drop- und Injection-Paketen an, falls vorhanden.
  • Diese Ausgabe bietet eine prägnante Ansicht der Datenebenenverarbeitung.
• Path Data (Pfaddaten) - Diese Funktion bietet die detaillierteste Ansicht der DP-Paketverarbeitung. Sie wird für eine begrenzte Anzahl von Paketen gesammelt und enthält eine bedingte Debugging-ID, die verwendet werden kann, um DP-Pakete mit Debugging-Prozessen auf der Kontrollebene, Zeitstempel und funktionsspezifische Pfad-Ablaufverfolgungsdaten zu korrelieren. Diese Detailansicht verfügt über zwei optionale Funktionen.
  • Mit Paketkopie können Sie Eingangs- und Ausgangspakete auf verschiedenen Paketschichten (Layer 2, Layer 3 und Layer 4) kopieren.
  • Feature Invocation Array (FIA) ist die sequenzielle Liste von Funktionen, die auf dem Paket von der Datenebene ausgeführt werden. Diese Funktionen stammen aus der Standardkonfiguration und der benutzerdefinierten Konfiguration des WLC 9800.

Eine detaillierte Beschreibung der Funktion und der Unteroptionen finden Sie unter Cisco IOS XE Datapath Packet Trace Feature.

Bei Wireless-Workflows wie der AP-Verbindung, der Client-Verbindung usw. wird der Uplink bidirektional nachverfolgt.

Vorsicht: Der dataplane Packet-Tracer parst nur den äußeren CAPWAP-Header. Bedingungen wie Wireless-Client-Mac liefern also keine nützliche Leistung.

 Schritt 1: Definieren Sie die Zinsbedingung.

# debug platform condition { interface | mac | ingress | egress | both | ipv4 | ipv6 | mpls | match }

Warnung: Sowohl die Befehle debug platform condition feature als auch debug platform condition mac aaaa.bbb.cccc sind für die Paketverfolgung auf der Kontrollebene bestimmt und geben keine Datenflugzeug-Paketverfolgungen zurück.

Schritt 2: Führen Sie den folgenden Befehl aus, um die aktuell aktivierten Bedingungen anzuzeigen:

# show platform conditions

Schritt 3: Aktivieren Sie die Paketverfolgung für eine begrenzte Anzahl von Paketen. Diese Paketnummer wird als eine Potenz von 2 im Bereich von 16-8192 definiert. Standardmäßig werden sowohl die Zusammenfassung als auch die Funktionsdaten erfasst. Optional können Sie festlegen, dass nur eine Sammelansicht angezeigt wird, wenn Sie die Unteroption "Nur Zusammenfassung" verwenden. Darüber hinaus stehen Ihnen Unteroptionen zum Abrufen der endgültigen Ablaufverfolgung, Definieren der Paketgröße in Byte, Durchsuchen, Einschleusen oder Verwerfen von Paketen zur Verfügung. usw.

# debug platform packet-tracer packet <packet-number> {fia-trace}

Schritt 4: (Optional) Sie können die verfolgten Pakete kopieren und auslesen.

# debug platform packet-trace copy packet both size 2048 { l2 | l3 | l4 }

Schritt 5: Aktivieren Sie das bedingte Debuggen.

# debug platform condition start

Schritt 6: Überprüfen Sie die Statistiken, um festzustellen, ob die Paketverfolgung eine Ausgabe erfasst.

# show platform packet-trace statistics

Schritt 7: Führen Sie den folgenden Befehl aus, um die Ausgabe der Paketverfolgung anzuzeigen:

# show platform packet-tracer summary

 Schritt 8: (Optional) Sie können Packet Dump zur Offline-Analyse durch das Cisco TAC exportieren.

# show platform packet-trace packet all | redirect { bootflash: | tftp: | ftp: } pactrac.txt

Integrierte Paketerfassung

Embedded Packet Capture (EPC) ist eine Funktion zur Paketerfassung, mit der Pakete erfasst werden können, die an die Catalyst 9800 WLCs gerichtet sind, von diesen stammen und diese durchlaufen. Diese Aufzeichnungen können zur Offline-Analyse mit Wireshark exportiert werden.

Weitere Einzelheiten zu dieser Funktion finden Sie im EPC-Konfigurationsleitfaden.

Im Vergleich zu AireOS ermöglicht der 9800 WLC die Erfassung von Paketen und die Spiegelung des Datenverkehrs auf dem Uplink-Switch und nicht auf dem Gerät selbst.

Auf dem 9800 kann diese Erfassung sowohl über die Befehlszeilenschnittstelle (CLI) als auch über die grafische Benutzeroberfläche (GUI) eingerichtet werden.

Um die Konfiguration über die GUI vorzunehmen, navigieren Sie zu Troubleshooting > Packet Capture > +Add.

Schritt 1: Definieren Sie den Namen der Paketerfassung... Es sind maximal 8 Zeichen zulässig.

Schritt 2. Definieren Sie ggf. Filter

Schritt 3: Aktivieren Sie das Kontrollkästchen Monitoring Control Traffic (Kontrolldatenverkehr überwachen), wenn der Datenverkehr zur System-CPU geleitet und zurück in die Datenebene geleitet werden soll.

Schritt 4: Puffergröße festlegen. Es sind maximal 100 MB zulässig.

Schritt 5: Definieren Sie einen Grenzwert, entweder nach Dauer, die einen Bereich von 1 bis 1000000 Sekunden zulässt, oder nach Anzahl der Pakete, die einen Bereich von 1 bis 100000 Paketen zulassen, wie gewünscht.

Schritt 6. Wählen Sie die Schnittstelle aus der Liste der Schnittstellen in der linken Spalte und wählen Sie den Pfeil, um sie in die rechte Spalte zu verschieben

Schritt 7: Speichern und auf Gerät anwenden.

Schritt 8: Um die Erfassung zu starten, wählen Sie Starten.

Schritt 9: Sie können die Erfassung bis zum definierten Limit laufen lassen. Um die Erfassung manuell zu stoppen, wählen Sie Stopp.

Schritt 10. Nach dem Beenden wird eine Export-Schaltfläche verfügbar, auf die Sie klicken können, um die Erfassungsdatei (.pcap) über den HTTPS- oder TFTP-Server, den FTP-Server, die Festplatte oder den Flash-Speicher des lokalen Systems auf den lokalen Desktop herunterzuladen.

Anmerkung: Die CLI bietet eine etwas detailliertere Auswahl an Optionen, z. B. "Limit by". Die GUI ist ausreichend, um Pakete für gängige Anwendungsfälle zu erfassen.

Konfiguration über CLI:

Erstellen Sie die Monitorerfassung:

monitor capture uplink interface <uplink_of_the_9800> both

Zuordnen eines Filters Der Filter kann inline angegeben werden, oder es kann auf eine ACL oder Klassenzuordnung verwiesen werden.

In diesem Beispiel entspricht die ACL dem Datenverkehr zwischen den beiden IP-Adressen des 9800 und einem anderen WLC 5520. Typisches Szenario für die Fehlerbehebung von Mobilitätsproblemen:

conf t

ip access-list extended mobilitywlcs
permit ip host <5520_ip_address> host <9800_ip_address>
     permit ip host <9800_ip_address> host <5520_ip_address>
end

monitor capture uplink access-list mobilitywlcs

Wenn Sie die Erfassung in einem Zirkelpuffer ausführen möchten, haben Sie einige Zeit, um das Problem zu bemerken. Anschließend können Sie die Erfassung beenden und speichern.

Wenn Sie es zum Beispiel auf 50MB Puffer einstellen. Es dauert maximal 50MB Festplatte auf dem 9800 und seine ziemlich groß, um mehrere Minuten von Daten in der Hoffnung, dass Sie das Auftreten des Problems zu erfassen.

monitor capture uplink buffer circular size 50

Erfassung starten. Sie können ihn über die GUI oder CLI anrufen:

monitor capture uplink start

Die Erfassung ist jetzt aktiv.

Erlauben Sie die Erfassung der erforderlichen Daten.

Erfassung beenden. Dies ist über die grafische Benutzeroberfläche oder die Kommandozeile möglich:

monitor capture uplink stop

Sie können die Aufzeichnung aus der GUI abrufen > Troubleshooting > Packet Capture > Export.

Oder von CLI auf einen Server hochladen. Beispiel via ftp:

monitor capture uplink export ftp://x.x.x.x/MobilityCAP.pcap

Sobald die erforderlichen Daten erfasst wurden, entfernen Sie die Erfassung:

no monitor capture uplink

Alarm-LED und Alarmmeldungen bei kritischen Plattformen

Alle Geräte der Serie 9800 (9800-L, 9800-40 und 9800-80) verfügen über eine ALM-LED auf der Vorderseite. Wenn die LED rot leuchtet, bedeutet dies, dass auf der Plattform ein kritischer Alarm ausgelöst wird.

Mit dem Befehl show facility-alarm status (Gebäudealarmstatus anzeigen) können Sie überprüfen, welche Alarme die LED auf Rot setzen.

WLC#show facility-alarm status
System Totals  Critical: 2  Major: 0  Minor: 0

Source                     Time                   Severity      Description [Index]
------                     ------                 --------      -------------------
TenGigabitEthernet0/1/0    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]
TenGigabitEthernet0/1/1    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
8.0	01-Sep-2026	Rezertifizierung - Aktualisierter Alternativtext, Zielverknüpfungen, Grammatik und Formatierung.
7.0	24-Apr-2026	Hinweis zur maximalen Anzahl von MAC-Adressen hinzugefügt, die gleichzeitig verfolgt werden können
6.0	20-Aug-2024	Titelgröße entsprechend Cisco.com Style Guide reduziert.
5.0	29-Mar-2024	Trace-on-Failure-Abschnitt aufgrund von Wertverlust entfernt
4.0	12-Jul-2023	Rezertifizierung
3.0	22-Jun-2022	Ändern Sie den Wert in trace-on-failure. Option "start last x" zum Anzeigen des Protokollierungsprofils hinzugefügt
2.0	20-Feb-2022	Geringfügige Änderungen bei Rechtschreibung und Titel
1.0	04-Oct-2021	Erstveröffentlichung