Siemens SIMATIC NET RUGGEDCOM RX5000 Konfigurationshandbuch Seite 1329

Fehlerbehebung
18.4 Spanning Tree
Ein Computer oder Gerät ist mit
einem Switch verbunden. Nach
dem Rücksetzen des Switch
dauert der Wiederanlauf eine
lange Zeit.
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.
1284
Problem
Wenn einer der Switches den Root-Port von einem Port zu einem
anderen zu wechseln scheint, kann das Problem in der Traffic-
Priorisierung liegen. Weitere Informationen finden Sie unter
The network becomes unstable when a specific application is
started (Seite
Eine weitere mögliche Ursache für unregelmäßigen Betrieb
kann die Nichtabstimmung von Auto-Negotiation sein. Wenn
ein Ende der Verbindung auf Vollduplexmodus eingestellt ist
und der Verbindungspartner auf Autonegotiation, wird das
Autonegotiation-Ende auf Halbduplexmodus zurückgesetzt. Bei
geringerem Traffic-Volumen zeigt der Link, wenn überhaupt,
dann wenige Fehler an. Bei ansteigendem Traffic-Volumen treten
auf der Seite mit der festen Negotiation verworfene Pakete auf,
während es auf der Seite mit der Auto-Negotiation zu Kollisionen
kommt. Wenn die Verkehrslast schließlich 100 % erreicht, wird die
Verbindung völlig unbrauchbar. Zu diesem Zeitpunkt kann RSTP
keine Konfigurationsnachrichten über den Link senden, und die
Spanning-Tree-Topologie bricht zusammen. Ist ein alternativer
Trunk vorhanden, aktiviert RSTP statt des blockierten Ports diesen
Trunk. Da die Aktivierung des alternativen Ports dem blockierten
Port häufig seinen Traffic abnimmt, wird der blockierte Port erneut
zuverlässig. RSTP setzt ihn umgehend wieder ein, womit der Zyklus
von vorn beginnt. Der Root-Port wechselt zwischen zwei Ports am
Switch hin und her.
Ist es möglich, dass die RSTP-Edge-Einstellung für diesen
Port auf False gesetzt ist? Wenn für Edge der Wert False
eingestellt ist, veranlasst die Bridge, dass der Port zwei
Weiterleitungsverzögerungszeiten durchlaufen muss, bevor der
Port Frames senden oder empfangen kann. Wenn für Edge der
Wert True eingestellt ist, gibt die Bridge den Port direkt an die
Weiterleitung bei Link-up weiter.
Eine weitere mögliche Erklärung ist, dass einige Links im Netzwerk
im Halbduplexmodus betrieben werden. RSTP verwendet ein Peer-
to-Peer-Protokoll, das als Proposal-Agreement bezeichnet wird,
und den Übergang bei Link-Ausfall sicherstellen soll. Für dieses
Protokoll ist der Vollduplexbetrieb erforderlich. Wenn RSTP einen
Port erkennt, der nicht im Vollduplexmodus ist, kann es sich nicht
auf Proposal-Agreement verlassen und muss den Port-Übergang
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 für einige Ports in der Topologie der STP-Modus
konfiguriert wurde oder dass der Punkt-zu-Punkt-Parameter des
Ports auf False gesetzt ist? STP- und Multipoint-Ports zeigen nach
Auftreten von Fehlern nur sehr langsame Konvergenz.
Ist es möglich, dass der Port nach STP migriert 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. Die schlimmste
aller möglichen Strukturen tritt auf, wenn sich die sekundäre Root-
Lösung
1285).
Konfigurationshandbuch, 05/2022, C79000-G8900-1534-02
RUGGEDCOM ROX II v2.15 Weboberfläche