Siemens SIMATIC NET RUGGEDCOM RX5000 Konfigurationshandbuch Seite 1330

Das Netzwerk besteht aus einem
Ring aus Bridges, von denen
zwei (miteinander verbundene)
gemanagt sind, alle anderen
sind unmanaged. 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 IED/Controller funktioniert
mit dem Gerät nicht.
Abfragen an andere Geräte
gehen gelegentlich verloren.
Der Root empfängt eine Anzahl
von TCNs. Woher kommen
diese?
18.5 VLANs
Im Folgenden werden allgemeine Probleme im Zusammenhang mit VLANs
beschrieben.
RUGGEDCOM ROX II v2.15 Weboberfläche
Konfigurationshandbuch, 05/2022, C79000-G8900-1534-02
Problem
Bridge am von der Root entferntesten Rand des Netzwerks befindet.
In diesem Fall muss eine Konfigurationsnachricht bis zum Rand und
zurück propagiert werden, um die Topologie neu aufzubauen.
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?
Untersuchen Sie den Port und die Pfadkosten und aktivieren Sie
dabei jeden Port als Root-Port.
Es wurde festgestellt, dass sich bestimmte Controller mit
niedriger CPU-Bandbreite weniger als perfekt verhalten, wenn sie
unerwarteten Traffic empfangen. 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.
Überprüfen Sie die Netzwerkstatistik und ermitteln Sie, ob die Root-
Bridge um den Zeitpunkt herum, zu dem Frame-Verlust beobachtet
wird, TCNs empfängt. Es kann möglich sein, dass es Probleme mit
zeitweise unterbrochenen Links im Netzwerk gibt.
Untersuchen Sie die RSTP-Portstatistik und ermitteln Sie den Port,
von dem die TCNs kommen. Melden Sie sich an dem Switch an, der
sich am anderen Ende des Links dieses Ports befindet. Wiederholen
Sie diesen Schritt, bis der Switch, der die TCNs erzeugt, gefunden
ist (d.h. der Switch, der selbst keine große Anzahl von TCNs
empfängt). Stellen Sie die Ursache für das Problem am Switch fest.
Fehlerbehebung
18.5 VLANs
Lösung
1285