Dieses Dokument bietet einen Überblick über die verschiedenen Zähler für Ethernet-Kollisionen und erläutert, wie Probleme mit Ethernet-Kollisionen, die von diesen Fehlermeldungen gemeldet werden (auf Basis der Plattform), behoben werden:
%AMDP2_FE-5-COLL
%DEC21140-5-COLL
%ILACC-5-COLL
%LANCE-5-COLL
%PQUICC-5-COLL
%PQUICC_ETHER-5-COLL
%PQUICC_FE-5-COLL
%QUICC_ETHER-5-COLL
%AMDP2_FE-5-LATECOLL
%DEC21140-5-LATECOLL
%ILACC-5-LATECOLL
%LANCE-5-LATECOLL
%PQUICC-5-LATECOLL
%PQUICC_ETHER-5-LATECOLL
%PQUICC_FE-5-LATECOLL
%QUICC_ETHER-5-LATECOLL
%SIBYTE-4-SB_EXCESS_COLL
Hinweis: Die Informationen in diesem Dokument gelten nur für Halbduplex-Ethernet. Bei Vollduplex-Ethernet ist die Kollisionserkennung deaktiviert.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
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 Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Eine Kollision ist der Mechanismus, der von Ethernet verwendet wird, um den Zugriff zu steuern und gemeinsam genutzte Bandbreite zwischen Stationen zuzuweisen, die gleichzeitig auf einem gemeinsam genutzten Medium übertragen möchten. Da das Medium gemeinsam genutzt wird, muss ein Mechanismus vorhanden sein, bei dem zwei Stationen erkennen können, dass sie das Medium gleichzeitig übertragen möchten. Dieser Mechanismus ist die Kollisionserkennung.
Ethernet nutzt CSMA/CD (Carrier Sense Multiple Access/Collision Detect) als Kollisionserkennungsmethode. Dies ist ein vereinfachtes Beispiel für den Ethernet-Betrieb:
Station A möchte einen Frame senden. Zunächst wird geprüft, ob das Medium verfügbar ist (Carrier Sense). Ist dies nicht der Fall, wartet er, bis der aktuelle Absender des Mediums fertig ist.
Beispiel: Station A glaubt, dass das Medium verfügbar ist und versucht, einen Frame zu senden. Da das Medium gemeinsam genutzt wird (Multiple Access), können auch andere Absender versuchen, das Medium gleichzeitig zu senden. An diesem Punkt versucht Station B, einen Frame gleichzeitig mit Station A zu senden.
Kurz darauf erkennen Station A und Station B, dass ein anderes Gerät versucht, einen Frame zu senden (Kollisionserkennung). Jede Station wartet eine zufällige Zeit, bevor sie sie erneut sendet. Die Zeit nach der Kollision ist in Zeitschlitze unterteilt. Station A und Station B wählen jeweils einen zufälligen Steckplatz für den Versuch einer erneuten Übertragung aus.
Wenn Station A und Station B versuchen, eine erneute Übertragung im selben Steckplatz durchzuführen, wird die Anzahl der Steckplätze erhöht. Jede Station wählt dann einen neuen Steckplatz aus und verringert so die Wahrscheinlichkeit einer erneuten Übertragung im selben Steckplatz.
Zusammenfassend lässt sich sagen, dass Kollisionen eine Möglichkeit darstellen, die Datenverkehrslast über einen bestimmten Zeitraum zu verteilen, indem sie den Zugriff auf das gemeinsam genutzte Medium beliebig verteilen. Kollisionen sind nicht schlecht. sie sind für die Korrektur des Ethernet-Betriebs unerlässlich.
Nützliche Fakten:
Die maximale Anzahl von Zeitsteckplätzen ist auf 1024 beschränkt.
Die maximale Anzahl von Neuübertragungen für denselben Frame im Kollisionsmechanismus beträgt 16. Wenn er 16 Mal hintereinander ausfällt, wird er als übermäßige Kollision gezählt.
Im Folgenden finden Sie ein Beispiel für die Ausgabe des Befehls show interface:
router#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8) Internet address is 10.200.40.74/22 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:06, output hang never Last clearing of "show interface" counters never Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: random early detection(RED) Output queue :0/40 (size/max) 5 minute input rate 1000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2058015 packets input, 233768993 bytes, 1 no buffer Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles 3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored 0 input packets with dribble condition detected 298036 packets output, 32280269 bytes, 0 underruns 0 output errors, 10 collisions, 0 interface resets 0 babbles, 0 late collision, 143 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
Der Zähler mit Zurückstellung zählt die Anzahl der Male, die die Schnittstelle versucht hat, einen Frame zu senden, fand jedoch den Carrier bei dem ersten Versuch (Carrier Sense) als besetzt. Dies stellt kein Problem dar und ist Teil des normalen Ethernet-Betriebs.
Hier ist ein weiteres Beispiel für die Ausgabe des Befehls show interface:
router#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8) Internet address is 10.200.40.74/22 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:06, output hang never Last clearing of "show interface" counters never Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: random early detection(RED) Output queue :0/40 (size/max) 5 minute input rate 1000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2058015 packets input, 233768993 bytes, 1 no buffer Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles 3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored 0 input packets with dribble condition detected 298036 packets output, 32280269 bytes, 0 underruns 0 output errors, 10 collisions, 0 interface resets 0 babbles, 0 late collision, 143 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
Wie hier erläutert, stellen Kollisionen kein Problem dar. Der Kollisionszähler zählt die Anzahl der Frames an, für die eine oder mehrere Kollisionen aufgetreten sind, als die Frames gesendet wurden.
Der Kollisionszähler kann in einzelne Kollisionen und mehrere Kollisionen unterteilt werden, wie in dieser Ausgabe vom Befehl show controller:
8 single collisions, 2 multiple collisions
Dies bedeutet, dass acht (von zehn) Frames nach einer Kollision erfolgreich übertragen wurden. Bei den beiden anderen Frames waren mehrere Kollisionen erforderlich, um den Zugriff auf das Medium zu beschreiben.
Eine steigende Kollisionsrate (Anzahl der ausgelieferten Pakete geteilt durch die Anzahl der Kollisionen) weist nicht auf ein Problem hin: sondern lediglich ein Hinweis auf eine höhere Netzwerklast. Ein Beispiel hierfür könnte sein, dass dem Netzwerk eine andere Station hinzugefügt wurde.
Es gibt keine feste Grenze für "wie viele Kollisionen sind schlecht" oder eine maximale Kollisionsrate.
Zusammenfassend lässt sich sagen, dass der Kollisionszähler keine sehr nützliche Statistik zur Analyse der Netzwerkleistung oder von Problemen bereitstellt.
Damit die Kollisionserkennung ordnungsgemäß funktioniert, ist der Zeitraum, in dem Kollisionen erkannt werden, begrenzt (512-Bit-Zeiten). Für Ethernet: 51,2 us (Mikrosekunden) und für Fast Ethernet 5,12 us. Bei Ethernet-Stationen können Kollisionen bis zu 51,2 Mikrosekunden nach Beginn der Übertragung oder, anders gesagt, bis zum 512. Bit des Frames erkannt werden.
Wenn eine Kollision von einer Station erkannt wird, nachdem sie das 512. Bit ihres Frames gesendet hat, wird sie als späte Kollision gezählt.
Späte Kollisionen werden durch folgende Fehlermeldungen gemeldet:
%AMDP2_FE-5-LATECOLL: AMDP2/FE 0/0/[dec], Late collision %DEC21140-5-LATECOLL: [chars] transmit error %ILACC-5-LATECOLL: Unit [DEC], late collision error %LANCE-5-LATECOLL: Unit [DEC], late collision error %PQUICC-5-LATECOLL: Unit [DEC], late collision error %PQUICC_ETHER-5-LATECOLL: Unit [DEC], late collision error %PQUICC_FE-5-LATECOLL: PQUICC/FE([DEC]/[DEC]), Late collision %QUICC_ETHER-5-LATECOLL: Unit [DEC], late collision error
Die genaue Fehlermeldung hängt von der Plattform ab. Sie können die Anzahl der übermäßigen Kollisionen in der Ausgabe eines Befehls show interface ethernet [interface number] überprüfen.
router#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8) Internet address is 10.200.40.74/22 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:06, output hang never Last clearing of "show interface" counters never Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: random early detection(RED) Output queue :0/40 (size/max) 5 minute input rate 1000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2058015 packets input, 233768993 bytes, 1 no buffer Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles 3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored 0 input packets with dribble condition detected 298036 packets output, 32280269 bytes, 0 underruns 0 output errors, 10 collisions, 0 interface resets 0 babbles, 0 late collision, 143 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
Hinweis: Die Workstation, die die verspätete Kollision meldet, weist lediglich auf das Problem hin. ist es im Allgemeinen nicht die Ursache des Problems. Mögliche Ursachen sind in der Regel falsche Verkabelung oder eine nicht konforme Anzahl von Hubs im Netzwerk. Schlechte Netzwerkschnittstellenkarten (NICs) können auch zu späten Kollisionen führen.
Wie bereits erwähnt, ist die maximale Anzahl der Wiederholungen im Backoff-Algorithmus auf 16 festgelegt. Dies bedeutet, dass eine Schnittstelle, wenn sie einen Steckplatz nicht zuweist, in dem sie ihren Frame ohne weitere Kollision 16 Mal übertragen kann, aufgibt. Der Frame wird einfach nicht übertragen und als übermäßige Kollision gekennzeichnet.
Übermäßige Kollisionen werden durch folgende Fehlermeldungen gemeldet:
%AMDP2_FE-5-COLL: AMDP2/FE 0/0/[DEC], Excessive collisions, TDR=[DEC], TRC=[DEC] %DEC21140-5-COLL: [chars] excessive collisions %ILACC-5-COLL: Unit [DEC], excessive collisions. TDR=[DEC] %LANCE-5-COLL: Unit [DEC], excessive collisions. TDR=[DEC] %PQUICC-5-COLL: Unit [DEC], excessive collisions. Retry limit [DEC] exceeded %PQUICC_ETHER-5-COLL: Unit [DEC], excessive collisions. Retry limit [DEC] exceeded %PQUICC_FE-5-COLL: PQUICC/FE([DEC]/[DEC]), Excessive collisions, TDR=[DEC], TRC=[DEC] %QUICC_ETHER-5-COLL: Unit [DEC], excessive collisions. Retry limit [DEC] exceeded %SIBYTE-4-SB_EXCESS_COLL : Excessive collisions on mac [dec] (count: [dec])
Die genaue Fehlermeldung hängt von der Plattform ab.
Hinweis: Der TRC-Zähler (Transmit Retry Count) ist ein 4-Bit-Feld, das die Anzahl der Übertragungsversuche des zugeordneten Pakets angibt. Die maximale Anzahl beträgt 15. Tritt jedoch ein Fehler erneut auf, wird der Zähler auf Null umgestellt. Nur in diesem Fall sollte der TRC-Wert Null als sechzehn interpretiert werden. TRC wird vom Controller in den letzten Übertragungsdeskriptor eines Frames geschrieben, oder wenn ein Fehler einen Frame beendet.
Hinweis: Der TDR-Zähler (Time Delay Reflectometer) ist ein interner Zähler, der die Zeit (in Zecken von jeweils 100 Nanosekunden (ns)) vom Beginn einer Übertragung bis zum Auftreten einer Kollision zählt. Da eine Übertragung etwa 10 m pro Zecken verläuft, ist dieser Wert hilfreich, um den ungefähren Abstand zu einem Kabelfehler zu bestimmen.
Sie können die Anzahl der übermäßigen Kollisionen in der Ausgabe eines Befehls show controller ethernet [interface number] überprüfen.
router#show controller ethernet 0 LANCE unit 0, idb 0xFA6C4, ds 0xFC218, regaddr = 0x2130000, reset_mask 0x2 IB at 0x606E64: mode=0x0000, mcfilter 0000/0000/0100/0000 station address 0010.7b36.1be8 default station address 0010.7b36.1be8 buffer size 1524 RX ring with 16 entries at 0x606EA8 Rxhead = 0x606EC8 (4), Rxp = 0xFC244 (4) 00 pak=0x0FCBF4 Ds=0x60849E status=0x80 max_size=1524 pak_size=66 01 pak=0x10087C Ds=0x6133B6 status=0x80 max_size=1524 pak_size=66 02 pak=0x0FDE94 Ds=0x60BA7E status=0x80 max_size=1524 pak_size=203 03 pak=0x100180 Ds=0x611F82 status=0x80 max_size=1524 pak_size=66 04 pak=0x0FD09C Ds=0x609216 status=0x80 max_size=1524 pak_size=66 05 pak=0x0FE590 Ds=0x60CEB2 status=0x80 max_size=1524 pak_size=66 06 pak=0x100AD0 Ds=0x613A72 status=0x80 max_size=1524 pak_size=66 07 pak=0x0FD9EC Ds=0x60AD06 status=0x80 max_size=1524 pak_size=66 08 pak=0x0FF830 Ds=0x610492 status=0x80 max_size=1524 pak_size=348 09 pak=0x1003D4 Ds=0x61263E status=0x80 max_size=1524 pak_size=343 10 pak=0x0FEA38 Ds=0x60DC2A status=0x80 max_size=1524 pak_size=66 11 pak=0x100D24 Ds=0x61412E status=0x80 max_size=1524 pak_size=64 12 pak=0x0FC74C Ds=0x607726 status=0x80 max_size=1524 pak_size=64 13 pak=0x0FD798 Ds=0x60A64A status=0x80 max_size=1524 pak_size=66 14 pak=0x0FE7E4 Ds=0x60D56E status=0x80 max_size=1524 pak_size=64 15 pak=0x0FD2F0 Ds=0x6098D2 status=0x80 max_size=1524 pak_size=66 TX ring with 4 entries at 0x606F68, tx_count = 0 TX_head = 0x606F80 (3), head_txp = 0xFC294 (3) TX_tail = 0x606F80 (3), tail_txp = 0xFC294 (3) 00 pak=0x000000 Ds=0x63491E status=0x03 status2=0x0000 pak_size=332 01 pak=0x000000 Ds=0x634FDA status=0x03 status2=0x0000 pak_size=327 02 pak=0x000000 Ds=0x630A9E status=0x03 status2=0x0000 pak_size=60 03 pak=0x000000 Ds=0x630A9E status=0x03 status2=0x0000 pak_size=60 3 missed datagrams, 0 overruns 0 transmitter underruns, 0 excessive collisions 8 single collisions, 2 multiple collisions 0 dma memory errors, 0 CRC errors 0 alignment errors, 0 runts, 0 giants 0 tdr, 0 spurious initialization done interrupts 0 no enp status, 0 buffer errors, 0 overflow errors 0 TX_buff, 1 throttled, 1 enabled Lance csr0 = 0x73
Übermäßige Kollisionen weisen auf ein Problem hin. Häufige Ursachen sind Geräte, die über ein gemeinsam genutztes Ethernet als Vollduplex-Geräte verbunden sind, defekte NICs oder einfach zu viele Stationen auf dem gemeinsam genutzten Medium. Die übermäßigen Kollisionen können durch die Geschwindigkeit der Hardwarekodierung und durch Duplex gelöst werden.
Bei Cisco Catalyst Switches wird die Meldung %SIBYTE-4-SB_EXCESS_COLL für jedes Auftreten einer übermäßigen Kollision angezeigt, wenn der interne Servicemodus aktiviert ist. Wenn der interne Dienstmodus deaktiviert ist, gibt das System diese Meldung nur aus, wenn die übermäßige Kollision einen bestimmten festgelegten Grenzwert erreicht. In diesem Fall kann die Anzeige dieser Nachricht auf einen echten Kollisionsfall hinweisen. Wenn der interne Dienstmodus eingeschaltet ist, gibt das System diese Meldung aus, wenn eine übermäßige Kollision auftritt. Dies kann durch Hardware-Geräusche verursacht werden. Die gelegentliche Anzeige dieser Nachricht mit aktiviertem Dienstinternem Modus ist ein normales Verhalten. Sie können den Befehl no service internal eingeben, um diese Protokollierung zu deaktivieren und festzustellen, wie sich dies auf Ihre Fehlerprotokolle auswirkt.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
01-Aug-2006 |
Erstveröffentlichung |