Fehlerbehebung
14.3 Spanning Tree
Wenn der Switch getestet wird,
indem ein Link absichtlich
unterbrochen wird, dauert
es sehr lange, bis Geräte auf
der anderen Seite des Switch
abgefragt werden können.
Das Netzwerk besteht aus einem
Ring aus Bridges, von denen
zwei (miteinander verbundene)
gemanagt und der Rest nicht
gemanagt sind. Weshalb arbeitet
das RSTP-Protokoll schnell, wenn
zwischen den managed Bridges
ein Link unterbrochen ist, jedoch
nicht in dem Teil des Rings mit
den unmanaged Bridges?
Das Netzwerk wird instabil,
wenn eine spezifische
Anwendung gestartet wird.
Das Netzwerk kehrt zum
Normalzustand zurück, wenn die
Anwendung gestoppt wird.
Wenn ein neuer Port eingebracht
wird, wechselt der Root-Port zu
diesem Port, statt zu dem Port,
zu dem er wechseln oder auf
dem er bleiben soll.
Ein Intelligent Elektronik Device
(IED) oder eine Steuerung
funktioniert nicht mit dem Gerät.
Abfragen an andere Geräte
gehen gelegentlich verloren.
352
Problem
langsam (d.h. STP) gestalten. Konfigurieren Sie den Port nach
Möglichkeit für Vollduplexbetrieb. Andernfalls setzen Sie die Punkt-
zu-Punkt-Einstellung des Ports auf True.
Durch beide Verfahren erreichen Sie, dass das Proposal-Agreement-
Protokoll verwendet wird.
Ist es möglich, dass einige Ports der Topologie für STP-Modus
konfiguriert wurden oder dass die Punkt-zu-Punkt-Parameter
auf falsch eingestellt wurden? Beim Auftreten von Fehlern
konvergieren STP-Ports und Mehrpunkt-Ports nur langsam.
Ist es möglich, dass der Port zu STP übergegangen ist? Wenn der
Port über gemeinsame Medien an das LAN-Segment angeschlossen
ist und STP-Bridges an diese Medien angeschlossen sind, ist die
Konvergenz nach einem Link-Fehler sehr langsam.
Verzögerungen in der Ordnung von zehntel oder hundertstel
Millisekunden können zu Umständen führen, in denen der
unterbrochene Link die einzige Verbindung zur Root-Bridge ist und
die sekundäre Root-Bridge schlecht gewählt ist. Das ungünstigste
Szenario tritt auf, wenn sich eine sekundäre Root-Bridge am
äußersten Rand eines Netzwerks, also am weitesten von der Quelle
weg, befindet. In diesem Fall muss eine Konfigurationsmeldung bis
zum äußersten Ende und wieder zurück gesendet werden, um die
Topologie wiederherzustellen.
Eine einwandfrei arbeitende unmanaged Bridge ist gegenüber
STP-Konfigurationsnachrichten transparent. Die managed Bridges
tauschen in dem Teil des Rings mit den unmanaged Bridges
Konfigurationsnachrichten so aus, als ob dieser Teil nicht existent
wäre. Wenn jedoch ein Link im ungemanagten Teil des Rings
ausfällt, können die managed Bridges den Ausfall nur durch
Timeout von Hello-Nachrichten erkennen. Zur Wiederherstellung
der vollständigen Konnektivität sind drei Hello-Nachrichten plus
zwei Weiterleitungszeiten erforderlich.
RSTP sendet seine Konfigurationsnachrichten mit der
größtmöglichen Prioritätsstufe. Wenn CoS konfiguriert ist, um
Datenverkehrsflüsse mit größtmöglicher Prioritätsstufe zuzulassen,
und diese Datenverkehrsflüsse schwellen kontinuierlich auf 100 %
der Leitungsbandbreite an, kann STP unterbrochen werden. Von
daher ist es nicht ratsam, den höchsten CoS-Wert zu verwenden.
Ist es möglich, dass die Portkosten fehlerhaft programmiert sind
oder dass die Auto-Negotiation einen unerwünschten Wert erlangt?
Prüfen Sie den Port und die Pfadkosten für jeden Port, wenn er als
Quelle aktiv ist.
Einige Steuerungen mit geringer CPU-Bandbreite haben sich für
den Empfang von unerwartetem Datenverkehr als ungeeignet
herausgestellt. Versuchen Sie, STP für den Port zu deaktivieren.
Wenn der Controller zum Zeitpunkt eines Link-Ausfalls ausfällt,
besteht die entfernte Möglichkeit, dass Frame-Unordnung oder
-Duplizierung die Ursache des Problems sein kann. Versuchen
Sie, für den Root-Port der Bridge des ausfallenden Controllers STP
einzustellen.
Prüfen Sie die Netzwerkstatistik, um festzustellen ob die Root-
Bridge Benachrichtigungen über Topologieänderungen (TCNs)
zur gleichen Zeit empfängt, wenn Frameverluste auftreten. Es ist
Lösung
RUGGEDCOM ROS v5.5
Konfigurationshandbuch, 10/2020, C79000-G8900-1474-01