Siemens RUGGEDCOM ROS Benutzerhandbuch Seite 277

RUGGEDCOM ROS
Benutzerhandbuch
Problem
Ein Rechner oder Gerät ist mit einem
Switch verbunden. Nach dem Zurücksetzen
braucht der Switch sehr lange, bis er wieder
hochfährt.
Wird ein Switch durch beabsichtigte
Unterbrechung einer Verbindung getestet,
dauert es sehr lange, bis die dem Switch
nachgeschalteten Geräte abgefragt werden
können.
Das Netzwerk besteht aus einem Ring aus
Bridges, von denen zwei (miteinander
verbundene) gemanagt und der Rest nicht
gemanagt sind. Warum arbeitet das RSTP-
Protokoll bei einem Verbindungsausfall
zwischen gemanagten Bridges schnell und
zwischen ungemanagten Bridges des Rings
langsam?
Beim Starten einer bestimmten Anwendung
wird das Netzwerk instabil. Beim Beenden
dieser Anwendung wird das Netzwerk wieder
stabil.
Wird ein neuer Port hinzugefügt, schaltet
die Quelle auf diesen Port um, statt auf den
eigentlich vorgesehenen umzuschalten oder
auf dem aktuellen zu bleiben.
Ein Intelligent Elektronik Device (IED) oder
eine Steuerung funktioniert nicht mit dem
Gerät.
Abfragen anderer Geräte gehen gelegentlich
verloren.
Spanning-Tree
Lösung
keine Konfigurationsmeldungen über die Verbindung versenden und die Spanning-Tree-
Topologie bricht zusammen. Existiert eine zweite Hauptleitung, aktiviert RSTP diese statt des
überlasteten Ports. Da die Aktivierung eines weiteren Ports den verstopften Port oft entlastet,
nimmt die Überlastung ab und der Port wird wieder belastbar. RSTP setzt den Port sofort
wieder in Betrieb und beginnt den Kreislauf erneut. In diesem Szenario wechselt der Root-
Port zwischen den beiden Ports auf dem Switch hin und her.
Ist es möglich, dass die RSTP-Edge-Einstellung für diesen Port auf Falsch eingestellt ist? Ist
Edge auf Falsch eingestellt, veranlasst die Bridge zwei Weiterleitungsverzögerungszeiten für
den Port, bevor dieser Frames senden oder empfangen kann. Ist Edge auf wahr eingestellt,
stellt die Bridge den Port direkt auf Weiterleitung ein, sobald die Verbindung aktiv ist.
Eine andere mögliche Erklärung ist, dass einige Verbindungen im Netzwerk im
Halbduplexmodus laufen. RSTP verwendet ein Peer-to-Peer-Protokoll mit der Bezeichnung
Proposal-Agreement, um die Übertragung bei einem Verbindungsfehler zu gewährleisten.
Für dieses Protokoll ist Vollduplexbetrieb erforderlich. Erkennt RSTP einen Port, der nicht
im Vollduplexmodus ist, kann es nicht auf das Proposal-Agreement-Protokoll zurückgreifen
und muss die Port-Übertragung langsam ausführen (d.h. STP). Konfigurieren Sie den Port
nach Möglichkeit für Vollduplexbetrieb. Andernfalls konfigurieren Sie die Punkt-zu-Punkt-
Einstellung als wahr.
In beiden Fällen kann das Proposal-Agreement-Protokoll verwendet werden.
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? Ist ein Port über gemeinsame Medien
mit dem LAN-Segment verbunden und sind STP-Bridges mit diesen Medien verschaltet, ist
die Konvergenz nach einem Verbindungsfehler langsam.
Verzögerungen im Bereich von mehreren Zehn oder Hundert Millisekunden können
auftreten, wenn die ausgefallene Verbindung die einzige Verbindung zur Root-Bridge ist und
die sekundäre Root-Bridge nicht gut 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 korrekt funktionierende ungemanagte Bridge ist für STP-Konfigurationsmeldungen
transparent. Die gemanagten Bridges tauschen Konfigurationsmeldungen über die
ungemanagten Bridges des Rings aus, so als würden diese nicht exisitieren. Fällt eine
Verbindung im ungemanagten Teil des Rings jedoch aus, können die gemanagten Bridges
den Fehler nur durch Time-out der Hello-Nachrichten erkennen. Die volle Konnektivität wird
erst durch drei Hello-Nachrichten und zwei Weiterleitungen wiederhergestellt.
RSTP sendet Konfigurationsnachrichten mit der höchstmöglichen Prioritätsstufe aus. Wenn
CoS so konfiguriert ist, dass es Verkehrsströme mit der höchsten Prioritätsstufe erlaubt und
diese Verkehrsströme 100 Prozent der Bandbreite der Leitung dauerhaft überschreiten,
kann STP unterbrochen werden. Deshalb empfehlen wir, nicht die höchste SoC-Stufe zu
verwenden.
Ist es möglich, dass die Port-Kosten nicht korrekt programmiert sind oder dass
Autonegotiation zu einem ungewünschten Wert führt? 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 die Steuerung etwa gleichzeitig mit einem Verbindungsverlust ausfällt, besteht eine
entfernte Möglichkeit, dass Framestörungen oder Duplizierung die Problemursache sind.
Versuchen Sie, den Root-Port der Bridge der ausgefallenen Steuerung auf STP zu stellen.
Prüfen Sie die Netzwerkstatistik, um festzustellen ob die Root-Bridge Benachrichtigungen
über Topologieänderungen (TCNs) zur gleichen Zeit empfängt, wenn Frameverluste
Kapitel 6
Fehlersuche
261