Spanning Tree - Siemens RUGGEDCOM ROS v5.5 Konfigurationshandbuch

14.3

Spanning Tree

Im Folgenden werden allgemeine Probleme im Zusammenhang mit dem Spanning
Tree Protocol (STP) beschrieben.
Das Netzwerk wird gesperrt,
wenn ein neuer Port verbunden
wird und die LEDs für den
Portstatus in rascher Folge
blinken.
Gelegentlich scheinen an den
Ports kurzzeitig erhebliche
Überflutungen aufzutreten.
Ein Switch zeigt seltsames
Verhalten, wo der Root-Port
zwischen zwei Switch-Ports hin-
und herwechselt und niemals
zur Ruhe kommt.
Ein Computer oder Gerät ist mit
einem Switch verbunden. Nach
dem Rücksetzen des Switch
dauert der Wiederanlauf eine
lange Zeit.
RUGGEDCOM ROS v5.5
Konfigurationshandbuch, 10/2020, C79000-G8900-1474-01
Problem
Ist es möglich, dass bei einem der Switches im Netzwerk oder
bei einem der Ports an einem Switch im Netzwerk STP deaktiviert
ist und versehentlich die Verbindung mit einem anderen Switch
hergestellt wird? Ist dieser Fall eingetreten, wurde eine Traffic-
Schleife gebildet.
Scheint das Problem vorübergehend zu sein, ist es möglich, dass
Ports, die Teil des Spanning Tree sind, als Edge-Ports konfiguriert
wurden. Nachdem die Link-Layers auf Edge-Ports gestoßen sind,
werden sie von STP (möglicherweise unangemessen) direkt an
den Weiterleitungszustand weitergegeben. Wird dann eine RSTP-
Konfigurationsnachricht empfangen, wird der Port wieder blockiert.
Möglicherweise wurde für die Zeitdauer, die sich der Port im
Weiterleitungszustand befand, eine Traffic-Schleife gebildet.
Wenn einer der Switches den Root-Port von einem Port zu
einem anderen zu wechseln scheint, kann das Problem in der
Verkehrspriorisierung liegen. Weitere Informationen finden Sie
unter
started." (Seite
Eine weitere mögliche Ursache für unregelmäßigen Betrieb
kann die Nichtabstimmung von Autonegotiation 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
Lösung
"The network becomes unstable when a specific application is
352).
Fehlerbehebung
14.3 Spanning Tree
351