Das Verhalten von Hubs und Switchen mit Schleifen

Grundsätzlich unterscheidet sich das Verhalten von Hubs (Multiport-Repeatern) und Switchen (Multiport-Bridges) in Bezug auf Schleifen (Loops) grundlegend.

 

Switch (Multiport-Bridge) / Layer 2

Wird ein Loop (Schleife) gesteckt, also ein Switchport mit einem weiteren Switchport (desselben VLANs) verbunden, entsteht sehr leicht ein sogenannter Broadcast-Sturm. Dazu reicht ein einziges Broadcastpaket, welches in den Switch (bzw. das „geloopte“ VLAN) eingeht. Dieses wird über die beiden verbunden Ports gesendet und vom Switch selbst empfangen.

 

Beispiel eines Broadcasts, ETH1 ist mit ETH2 verbunden:

1. Broadcast-Frame geht über ETHx ein
2. ETH1 sendet den Frame an ETH2 und ETH2 sendet den Frame an ETH1
3. Nun sendet der Switch den auf ETH2 empfangenen Frame wieder auf allen Ports (außer ETH2) aus
   und zeitgleich (Vollduplex) oder zeitversetzt (Halbduplex) den auf ETH1 empfangenen Frame ebenfalls auf allen Ports (außer ETH1) aus
4. Die Frames werden wieder vom jeweiligen „Gegenport“ der Schleife empfangen und das Spiel beginnt erneut…

So schaukelt sich der Effekt auf, bis der Zwischenspeicher des Switches vollgelaufen, bzw. die CPU komplett ausgelastet ist. Das Netzwerk wird zudem mit Broadcast-Frames überflutet, was nahezu die gesamte Konnektivität in Sekunden zum Erliegen bringen. Somit streut ein solcher Switch auch auf das weitere Netz aus. Auch wenn prinzipiell nur das „geloopte“ VLAN betroffen ist, brechen i. d. R. auch Verbindungen aller weiterer VALNs zusammen, da der Switch keine/kaum Forwarding-Kapazitäten mehr hat.

 

Dabei unterscheidet sich Halbduplex von Vollduplex nur minimal.

• Halbduplex: Die Frames werden zeitversetzt übertragen (Tx Deferred)
• Vollduplex: Die Frames werden zeitgleich übertragen

 

 

 

Hubs (Multiport-Repeater) / Layer 1

Das Verhalten von Hubs ist dahingehend anders, als dass Loops i. d. R. keine Auswirkung haben!
Zu unterscheiden ist grundlegend ob es sich um einen 10MBit/Sek. Hub oder 100MBit/Sek. Hub handelt.

 

10MBit/Sek.

Der IEEE 802.3 Standard definiert eine „Transmit Recovery Time“.
Diese definiert einen kurzen Zeitraum, in der ein Port nicht empfängt, nachdem er gesendet hat.

9.5.6.4 Transmit recovery time
It is essential that the repeater unit not monitor a port for input for a short time after the repeater stops transmitting to that port. This recovery time prevents the repeater from receiving its own transmission as a new receive activity. The minimum recovery time allowable for a repeater is implementation-dependent, but must be greater than the sum of the delays in the transmit and receive paths for the port. In all cases the recovery time must be less than 10 bit times from the last transition on the transmitting AU interface. – Quelle: IEEE 802.3-2018

 

Weiter gibt es eine optionale „Partitions“ Funktion, die Ports deaktiviert:

9.6.6.1 Overview
In large multisegment networks it may be desirable that the repeater unit protect the network from some fault conditions that would halt all network communication. A potentially likely cause of this condition could be due to a cable break, a faulty connector, or a faulty or missing termination. – Quelle: IEEE 802.3-2018

 

9.6.6.2 Detailed auto-partition/reconnection algorithm state diagram
Repeater sets with 10BASE-T MAUs shall implement an auto-partition/reconnection algorithm on those parts.
[…]
The algorithm […] shall isolate a segment from the network when one of the following two conditions has occurred on the segment:
a) When a consecutive collision count has been reached; or
b) When a single collision duration has exceeded a specific amount of time. – Quelle: IEEE 802.3-2018

 

Zu a: Müssen mehr als 30 aufeinanderfolgende Kollisionen detektiert werden:

CCLimit
The number of consecutive collisions that must occur before a segment is partitioned. The value shall be greater than 30. – Quelle: IEEE 802.3-2018

Zu b: Oder eine Überlange-Kollision detektiert wird:

Tw6
Wait Timer for excessive length of collision. Its value shall be between 1000 and 30 000 bit times.
It is started by StartTw6. Tw6Done is satisfied when the timer has expired. – Quelle: IEEE 802.3-2018

 

---

 

100MBit/Sek.

IEEE 802.3 kennt für die Geschwindigkeiten 100MBit/Sek. keine „Transmit Recovery Time“ mehr.
Dafür verpflichtend eine „Partitions“ Funktion, die Ports deaktiviert:

27.3.1.6 Partition functional requirements
In large multisegment networks it may be desirable that the repeater set protect the network from some fault conditions that would disrupt network communications. A potentially likely cause of this condition could be due to a cable fault.

Each repeater PMA interface shall contain a self-interrupt capability, […] to prevent a faulty segment’s carrier activity from reaching the repeater unit and hence propagating through the network. The repeater PMA interface shall count collisions. The count shall be incremented on each transmission that suffers a collision. […] If this count reaches the value CCLimit (see 27.3.2.1.1), the Partition condition shall be detected. – Quelle: IEEE 802.3-2018

 

Dazu müssen mehr als 60 aufeinanderfolgende Kollisionen detektiert werden:

27.3.2.1.1 Constants
CCLimit
The number of consecutive collisions that must occur before a segment is partitioned.
Values: Positive integer greater than 60. – Quelle: IEEE 802.3-2018

Oder optional der „Jabber-Timer“ überschritten wurde:

NOTE — It is possible that under some network conditions the partition state diagram will partition a port due to normal network collisions rather than a fault condition. It is also possible that some double fault conditions will remain undetected. To reduce the likelihood of these events occurring, the following optional measures, […], are recommended: – Quelle: IEEE 802.3-2018

 

c2) The Partition condition is additionally detected due to a carrier event of duration in excess of jabber_timer (see 27.3.1.7) in which a collision has occurred. – Quelle: IEEE 802.3-2018

 

jabber_timer
Timer for length of carrier that must be present before the Jabber state (27.3.1.7), and optionally during a collision the Partition state (27.3.1.6), is entered. The timer is done when it reaches 40 000 – 75 000 BT. – Quelle: IEEE 802.3-2018

 

---

 

Wird ein Hub über ein gekreuztes Kabel mit sich selbst verbunden (oder über den Uplink-Port mit einem Access Port und einem 1:1 belegten Kabel – anders würde kein Link entstehen), wird ein eingehender Frame ebenfalls über beide Ports weitergeltet. Hierbei entstehen Kollisionen auf dem Medium, 100MB/Sek. Hubs deaktivieren solche Ports nach 64 (manche 10MBit/Sek. Hubs auch nach 32) Kollisionen in Folge. Diese Funktion wird „Partitioning“ genannt.

 

 

Testaufbau

100MBit/Sek-Hub:

Hier sind Port 1 und 2 gegenseitig verbunden (Loop), über Port 5 empfängt der Hub Frames. Diese werden über Port 1 an 2 und von Port 2 an 1 geleitet. Was Kollisionen zur Folge hat. Nach 64 Kollisionen werden die beiden Ports aus der Übertragung ausgenommen („partitioniert“). Die Link/ACT-Led bleibt bei Port 1 und 2 konstant an, während die von Port 5 weiter blinkt.

Pro empfangen Frame blinkt die „Col“ LED ebenfalls einmal (hier entstehen 16 Kollisionen pro Übertragung). Nach 64 Kollisionen (4x blinken der COL-LED) ist das Limit erreicht:

 

Auszug der Statistik, hier wurden 5 Frames an den Hub übertragen, bei 4 Frames traten 64 Kollisionen auf:

Die angezeigten 64 Kollisionen ergeben sich aus den sogenannten „Excessive Collisions“, je Frame 16 aufeinanderfolgende Kollisionen.
Nach 16 Kollisionen hintereinander wird die Übertragung (je Frame) abgebrochen. Hier sichtbar als „Tx Drop“ (4 x 16 = 64).

 

4.2.8 Frame transmission
[…] The code excessiveCollisionError indicates that the transmission attempt was aborted due to excessive collisions, because of heavy traffic or a network failure. […] – Quelle: IEEE 802.3-2018

 

30.3.1.1.11 aFramesAbortedDueToXSColls
[…] BEHAVIOUR DEFINED AS:
A count of the frames that, due to excessive collisions, are not transmitted successfully. This counter is incremented when the value of the attempts variable equals attemptLimit during a transmission. […] – Quelle: IEEE 802.3-2018

Schlussfolgerung:

Ein Schleifeneffekt war dahingehend zu beobachten, dass eine erfolgreiche Übertragung erst nach der Partitionierung möglich war! Zuvor entstanden jeweils die maximal 16 Kollisionen pro Übertragung/Frame, was zu einem Verwerfen der Frames (Tx Drop) führte.

 

---

 

10MBit/Sek-Hub:

Ein 10MBit/Sek.-Hub verhält sich etwas anders. Dieser erkennt bereits nach der ersten Kollision den Loop und partitioniert entsprechend.
Hier sind Port 7 und 8 gegenseitig verbunden (Loop), über Port 5 wird ein Frame an den Hub gesendet:

 

Statistik: Es wurde nur eine Kollision und ein Kollisionsfragment empfangen:

 

Schlussfolgerung:

Da nur eine (1) Kollision empfangen wurde, ist davon auszugehen, dass der Hub eine Überlange-Kollision detektiert hat (gemäß IEEE 802.3, 9.6.6.2, Bedingung b bzw. tw6). Schleifeneffekte waren deshalb nicht zu beobachten. Es ist aber zu vermuten, dass Schleifeneffekte (analog zum 100MBit/Sek. Hub) auch bei 10MBit/Sek. möglich wären.

Welchen Effekt die „Transmit Recovery Time“ darauf hätte, kann nicht abschließend beurteilt werden, da kein 10MBit/Sek. Hub ohne Auto-Partitions-Funktion zur Verfügung stand. Da eine Kollision detektiert wurde, ist aber anzunehmen, dass sie keinen großen Effekt auf das Schleifenverhalten hat.