Erläuterung wichtiger Informationen zu Debug-Befehlen
Inhalt
Einleitung
In diesem Dokument werden allgemeine Richtlinien zur Verwendung von Debug-Befehlen beschrieben, einschließlich des auf Cisco IOS®-Plattformen verfügbaren Befehls „debug ip packet“.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
-
Herstellen einer Verbindung zum Router über die Konsolen-, Aux- und VTY-Ports
-
Allgemeine Konfigurationsprobleme mit Cisco IOS
-
Interpretieren der Cisco IOS-Debugausgaben
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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
Dieses Dokument enthält allgemeine Richtlinien für die Verwendung von Debug-Befehlen auf Cisco IOS®-Plattformen. Es enthält auch Beispiele und eine Übersicht über bedingtes Debuggen.
Die Befehle debug privileged EXEC bieten Diagnoseinformationen zu Netzwerkereignissen, Protokollstatus, Paketverarbeitung und allgemeinen Netzwerkaktivitäten. Mithilfe dieser Befehle können Sie die Ursache bestimmter Probleme bei der Fehlerbehebung ermitteln.
Debug-Befehle können jedoch eine große Menge an Ausgabeinformationen generieren und die Geräteleistung beeinflussen, insbesondere auf Routern, die bereits hohen Datenverkehr oder eine hohe CPU-Auslastung verarbeiten. Führen Sie daher Debug-Befehle sorgfältig und nur dann aus, wenn dies zur Fehlerbehebung erforderlich ist.
Anmerkung: In diesem Dokument wird nicht erläutert, wie bestimmte Debugbefehle und deren Ausgabe verwendet oder interpretiert werden. Weitere Informationen zu einzelnen Debug-Befehlen finden Sie in der entsprechenden Cisco Debug Command Reference-Dokumentation.
Warnungen
Führen Sie Debug-Befehle mit Vorsicht aus. Verwenden Sie diese Befehle im Allgemeinen nur unter Anleitung Ihres technischen Supports, wenn Sie bestimmte Probleme beheben möchten.
Die Aktivierung des Debuggens kann den Router-Betrieb stören, insbesondere wenn das Netzwerk stark ausgelastet ist. Wenn die Protokollierung aktiviert ist, kann sich der Zugriffsserver zeitweilig aufhängen, wenn der Konsolenport mit Protokollmeldungen überlastet wird.
Bevor Sie einen debug-Befehl ausführen, berücksichtigen Sie die Menge der Ausgabe, die der Befehl generieren kann, und wie lange die Debugsitzung ausgeführt werden kann.
Bei einem Router mit einer Schnittstelle mit einfacher Übertragungsrate wirkt sich debug isdn q931 wahrscheinlich nicht auf das System aus. Wenn jedoch derselbe Debug-Befehl auf einem AS5800 mit einer vollständigen E1-Konfiguration ausgeführt wird, kann ausreichend Ausgabe generiert werden, damit das Gerät hängen bleibt oder nicht mehr reagiert.
Überprüfen Sie vor dem Debuggen die CPU-Last, indem Sie den Befehl show processes cpu ausführen. Stellen Sie sicher, dass genügend CPU-Kapazität verfügbar ist, bevor Sie das Debuggen aktivieren.
Wenn beispielsweise ein Cisco 7200-Router mit einer ATM-Schnittstelle Bridging ausführt, kann ein Neustart des Routers je nach Anzahl der konfigurierten Subschnittstellen erhebliche CPU-Ressourcen in Anspruch nehmen. Für jede virtuelle Verbindung (VC) muss ein Bridge Protocol Data Unit (BPDU)-Paket generiert werden. Wenn Sie das Debuggen in diesem kritischen Zeitraum aktivieren, kann die CPU-Auslastung drastisch ansteigen, was zu einem Geräteausfall oder einem Verlust der Netzwerkverbindung führen kann.
Anmerkung: Wenn Debugs ausgeführt werden, wird normalerweise die Router-Eingabeaufforderung nicht angezeigt, insbesondere wenn das Debuggen sehr intensiv ist. In den meisten Fällen können Sie jedoch no debug all ausführen oder alle Befehle deaktivieren, um das Debuggen zu beenden.
Vor dem Debuggen
Stellen Sie zusätzlich zu den oben genannten Punkten sicher, dass Sie die Auswirkungen von Debugs auf die Stabilität der Plattform verstehen. Vor der Aktivierung eines Debug-Befehls müssen Sie sich überlegen, welche Schnittstelle des Routers Sie verbinden müssen.
Abrufen von Debug-Ausgaben
Router können Debug-Ausgaben für verschiedene Schnittstellen anzeigen, einschließlich der Konsolen-, Aux- und VTY-Ports. Router können Meldungen auch in einem internen Puffer auf einem externen Unix-Syslog-Server protokollieren.
Konsolen-Port
Wenn Sie unter normalen Konfigurationen mit der Konsole verbunden sind, sind keine zusätzlichen Arbeiten erforderlich. Die Debug-Ausgabe muss automatisch angezeigt werden. Stellen Sie jedoch sicher, dass die Protokollierungskonsolenebene wie gewünscht festgelegt ist und dass die Protokollierung nicht mit dem Befehl no logging console deaktiviert wurde.
Warnung: Übermäßige Fehlerbehebungen am Konsolen-Port eines Routers können dazu führen, dass dieser hängen bleibt. Der Grund hierfür ist, dass der Router die Konsolenausgabe automatisch gegenüber anderen Routerfunktionen priorisiert. Wenn der Router eine große Debug-Ausgabe am Konsolen-Port verarbeitet, kann er hängen bleiben. Wenn die Debug-Ausgabe zu hoch ist, verwenden Sie die vty-Ports (telnet) oder die Protokollpuffer, um Ihre Debug-Meldungen abzurufen.
Anmerkung: Standardmäßig ist die Protokollierung auf dem Konsolenport aktiviert. Der Konsolen-Port verarbeitet stets die Debug-Ausgabe, selbst wenn Sie einen anderen Port oder eine andere Methode (z. B. aux, vty oder buffer) zum Erfassen der Ausgabe verwenden. Cisco empfiehlt, unter normalen Betriebsbedingungen den Befehl "no logging console" auszuführen, ihn jederzeit zu aktivieren und andere Methoden zur Erfassung von Debugging-Meldungen zu verwenden. In Situationen, in denen Sie die Konsole verwenden müssen, schalten Sie die Protokollierungskonsole vorübergehend wieder ein.
AUX-Port
Wenn Sie über einen Hilfsport verbunden sind, führen Sie den Befehl terminal monitor aus. Stellen Sie außerdem sicher, dass der Befehl logging on auf dem Router nicht aktiviert ist.
Anmerkung: Wenn Sie den Router über den aux-Port überwachen, berücksichtigen Sie, dass der aux-Port die Ausgabe der Bootreihenfolge nicht anzeigt, wenn der Router neu gestartet wird. Stellen Sie eine Verbindung zum Konsolenport her, um die Bootreihenfolge anzuzeigen.
VTY-Ports
Wenn Sie über einen Hilfsport oder über Telnet verbunden sind, geben Sie den Befehl terminal monitor ein. Überprüfen Sie außerdem, ob der Befehl no logging on nicht verwendet wird.
Protokollieren von Nachrichten an einen internen Puffer
Das Standardprotokollierungsgerät ist die Konsole. Alle Meldungen werden auf der Konsole angezeigt, sofern nicht anders angegeben.
Um Nachrichten in einem internen Puffer zu protokollieren, führen Sie den Konfigurationsbefehl des protokollierten gepufferten Routers aus. Dies ist die vollständige Syntax dieses Befehls:
logging buffered no logging buffered
Der Befehl logging buffered kopiert Protokollmeldungen in einen internen Puffer, anstatt sie in die Konsole zu schreiben. Der Puffer ist kreisförmig, sodass neuere Nachrichten ältere Nachrichten überschreiben.
Um die im Puffer protokollierten Meldungen anzuzeigen, verwenden Sie den Befehl show logging des privilegierten EXEC-Modus. Die erste Meldung ist die älteste Meldung im Puffer. Sie können die Größe des Puffers und den Schweregrad der zu protokollierenden Nachrichten festlegen.
Anmerkung: Vergewissern Sie sich, dass genügend Speicher im Feld vorhanden ist, bevor Sie die Puffergröße eingeben. Verwenden Sie den Befehl show proc mem, um den verfügbaren Speicher anzuzeigen.
Der Befehl no logging buffered bricht die Verwendung des Puffers ab und schreibt Meldungen in die Konsole (Standard).
Protokollieren von Nachrichten auf einem UNIX-Syslog-Server
Führen Sie den Konfigurationsbefehl logging router aus, um Nachrichten am Syslog-Serverhost zu protokollieren. Vollständige Syntax dieses Befehls anzeigen:
loggingno logging
Der Befehl logging identifiziert einen Syslog-Serverhost, der Protokollmeldungen empfangen soll. Das <ip-address>-Argument ist die IP-Adresse des Hosts. Wenn Sie diesen Befehl mehrmals eingeben, erstellen Sie eine Liste der Syslog-Server, die Protokollierungsmeldungen empfangen.
Der Befehl o logging löscht den Syslog-Server mit der angegebenen Adresse aus der Liste der Syslogs.
Weitere Aufgaben vor dem Debuggen
-
Richten Sie die Terminal-Emulator-Software so ein, dass die Debug-Ausgabe in einer Datei erfasst wird. Weitere Informationen finden Sie in der Dokumentation Ihres Software-Terminal-Emulators.
-
Millisekunde (ms)-Zeitstempel aktivieren, die den Befehl service timestamps ausführen:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Diese Befehle fügen Zeitstempel zu debugs im Format MMM DD HH:MM:SS hinzu, die Datum und Uhrzeit entsprechend der Systemuhr angeben. Wenn die Systemuhr nicht eingestellt wurde, sind Datum und Uhrzeit mit einem Sternchen (*) gekennzeichnet, um anzuzeigen, dass Datum und Uhrzeit möglicherweise falsch sind.
Im Allgemeinen ist es ratsam, Millisekundenzeitstempel zu konfigurieren, da dies ein hohes Maß an Klarheit beim Überprüfen von Debugausgaben bietet. Millisekunden-Zeitstempel bieten eine bessere Anzeige des Timings verschiedener Debug-Ereignisse relativ zueinander. Wenn der Konsolen-Port jedoch viele Meldungen ausgibt, können diese nicht mit dem tatsächlichen Zeitpunkt des Ereignisses korrelieren.
Wenn Sie z. B. x25all auf einem Gerät mit 200 VCs aktivieren und die Ausgabe im Puffer protokolliert wird (ohne Protokollierungskonsole und gepufferte Protokollierungsbefehle), kann der in der Debugausgabe (im Puffer) angezeigte Zeitstempel nicht die genaue Zeit sein, zu der das Paket die Schnittstelle passiert. Verwenden Sie daher keine msec-Zeitstempel, um Leistungsprobleme nachzuweisen, sondern um relative Informationen zum Zeitpunkt des Eintretens von Ereignissen zu erhalten.
Debuggen beenden
Um ein Debugging zu beenden, verwenden Sie no debug all oder undebug all Befehle. Vergewissern Sie sich, dass die Debugging-Funktionen mit dem Befehl show debug deaktiviert wurden.
Denken Sie an die Befehle no logging console und terminal no monitor verhindern nur die Ausgabe auf der Konsole, aux bzw. vty. Das Debuggen wird nicht gestoppt, und Router-Ressourcen werden verbraucht.
Verwenden des Befehls debug ip packet
Auf klassischen Cisco IOS®-Routern erkennt das debug-IP-Paket hauptsächlich prozessgesteuerten Datenverkehr. Datenverkehr, der über Fast Switching oder CEF weitergeleitet wird, wird nur angezeigt, wenn eine Weiterleitung in den Prozess-Switching-Pfad erzwungen wird. Da jedoch für jedes Paket eine Ausgabe generiert wird, kann die Ausgabe umfangreich sein und dazu führen, dass der Router hängen bleibt. Führen Sie daher das debug-IP-Paket nur unter den strengsten Kontrollen aus, wie in diesem Abschnitt beschrieben.
Die beste Möglichkeit, die Ausgabe von debug ip packet einzuschränken, besteht darin, eine Zugriffsliste zu erstellen, die mit dem debug verknüpft ist. Nur Pakete, die die Kriterien der Zugriffsliste erfüllen, können dem debug-IP-Paket unterliegen. Diese Zugriffsliste muss nicht auf eine Schnittstelle angewendet werden, sondern wird auf den Debugvorgang angewendet.
Bevor Sie das Debugging-IP-Paket ausführen, beachten Sie, dass der Router standardmäßig Fast-Switching verwendet oder CEF-Switching verwenden kann, wenn dies konfiguriert ist. Das bedeutet, dass das Paket, sobald diese Techniken implementiert sind, nicht mehr an den Prozessor übermittelt wird, und dass das Debuggen nichts mehr anzeigt. Damit dies funktioniert, müssen Sie das schnelle Switching auf dem Router ohne IP-Routen-Cache (für Unicast-Pakete) oder ohne IP-Routen-Cache (für Multicast-Pakete) deaktivieren. Dies muss auf die Schnittstellen angewendet werden, auf denen der Datenverkehr fließen soll. Überprüfen Sie dies mit dem Befehl show ip route.
Anmerkung: Auf neueren Plattformen wird die Weiterleitung in der Regel über CEF oder hardwarebasiertes Switching abgewickelt. Daher ist die Deaktivierung von Fast Switching nicht mehr relevant oder empfehlenswert. Daher kann debug ip packet den Transitverkehr nicht zuverlässig anzeigen, und die moderne Fehlerbehebung beruht in der Regel auf plattformspezifischen Erfassungs- oder Hardware-Tools.
Bedingt ausgelöste Debugs
Wenn die Funktion für bedingt ausgelöstes Debuggen aktiviert ist, generiert der Router Debugmeldungen für Pakete, die in den Router an einer angegebenen Schnittstelle eingehen oder diesen verlassen. Der Router erzeugt keine Debugging-Ausgabe für Pakete, die über eine andere Schnittstelle ein- oder ausgehen.
Sehen Sie sich eine einfache Implementierung von bedingten Debugging an. Betrachten wir folgendes Szenario: Der als Nächstes dargestellte Router (Trabol) verfügt über zwei Schnittstellen (seriell 0 und seriell 3), auf denen beide HDLC-Kapselung ausgeführt wird.
Sie können den Befehl normaldebug serial interface ausführen, um die auf allen Schnittstellen empfangenen HDLC-Keepalives zu beobachten. Sie können die Keepalives auf beiden Schnittstellen beobachten:
traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- HDLC keeplaive on interface Serial 0 *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- HDLC keeplaive on interface Serial 3 *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up
Aktivieren Sie bedingtes Debuggen für die serielle Schnittstelle 3, d. h. es werden nur Debugging-Meldungen für die serielle Schnittstelle 3 angezeigt. Führen Sie den Befehl debug interface <interface_type interface_number> aus:
traxbol#debug interface serial 3 Condition 1 set
Führen Sie den Befehl show debug condition aus, um zu überprüfen, ob das bedingte Debuggen aktiv ist (eine Bedingung für die serielle Schnittstelle 3 ist aktiv):
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
Jetzt werden nur noch die Fehlermeldungen für die serielle Schnittstelle 3 angezeigt:
*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up
Führen Sie den Befehl undebug interface <interface_type interface_number> aus, um das bedingte Debugging zu entfernen. Es wird empfohlen, die Debugs zu deaktivieren (z. B. mit underbug all), bevor Sie den bedingten Trigger entfernen. Dadurch soll eine Flut von Debugausgaben vermieden werden, wenn die Bedingung entfernt wird.
traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol
Sie können die Fehlersuche sowohl für die serielle 0 als auch für die serielle 3 Schnittstelle beobachten:
*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
Warnung: Einige Debugvorgänge sind von selbst bedingt. Ein Beispiel ist ATM-Debugging. Bei ATM-Debugging müssen Sie explizit die Schnittstelle angeben, für die Debugging aktiviert werden muss, anstatt Debugging auf allen ATM-Schnittstellen zu aktivieren und eine Bedingung anzugeben.
In diesem Abschnitt wird die richtige Vorgehensweise zum Beschränken des Debuggens von ATM-Paketen auf eine Subschnittstelle beschrieben:
arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- Note that you explicitly specify the sub-interface to be used for debugging ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#
Wenn Sie versuchen, das ATM-Debugging auf allen Schnittstellen (mit einer angewendeten Bedingung) zu aktivieren, kann der Router hängen bleiben, wenn er über eine große Anzahl von ATM-Subschnittstellen verfügt. Ein Beispiel für die falsche Methode zum ATM-Debuggen wird angezeigt.
In diesem Fall können Sie sehen, dass eine Bedingung angewendet wird, aber Sie sehen auch, dass dies keine Auswirkungen hat. Sie können das Paket immer noch von der anderen Schnittstelle aus sehen.
In diesem Übungsszenario haben Sie nur zwei Schnittstellen und sehr wenig Datenverkehr. Wenn die Anzahl der Schnittstellen hoch ist, ist auch die Debug-Ausgabe für alle Schnittstellen extrem hoch und kann dazu führen, dass der Router hängen bleibt:
arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- A condition for a specific interface. arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1 VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- You also see debugs for interface ATM0/0/0.1 as you wanted. VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
22-Jun-2026
|
Aktualisierter Einführungsabstand, anderer Abstand innerhalb des Artikels, Grammatik, Rechtschreibung, Einrückung. |
4.0 |
19-Aug-2024
|
Rezertifizierung |
2.0 |
29-Apr-2022
|
Beschädigte Links wurden aktualisiert und entfernt. |
1.0 |
02-Dec-2013
|
Erstveröffentlichung |
Feedback