Bevor jemand das behauptet muß er sich überlegen wann ein Spanning Tree in 50 Sekunden konvergiert. Er wird versuchen aus der simplen Rechnung 20 + 15 + 15 eine Erklärung herzuleiten.
Er wird an einen Switch denken der ziemlich weit weg von der Root Bridge steht und schon seit 20 Sekunden nichts mehr von der Root gehört hat. Er ignoriert den Einfluß des Message Age dabei, was uns aber im Moment nicht weiter stört. Nachdem dieser Switch am Rande des LAN die Root vergessen hat, ernennt er sich selbst zur Root und schießt aus allen Rohren. Will heißen, er sendet Configuration BPDUs aus allen Ports.
Wenn ihn niemand stoppt, solange er Strom hat. Aber schon nach 15 Sekunden kommt etwas hinzu. Er lauscht auf Source MAC Adressen. Er wechselt also vom Listening in den Learning Mode und nach weiteren 15 Sekunden wechselt er in den Forwarding Mode. So würde es sich entwickeln wenn keiner seiner Nachbarn ihn unterbricht um ihm zu sagen daß die alte Root noch am Leben ist. Die meiste Zeit innerhalb dieser 50 Sekunden warten die Switches auf den Ablauf der Timer. Entschieden haben Sie sich schon vorher, innerhalb weniger Sekunden. Man muß sich nämlich in diesem Fall vergegenwärtigen daß die STP Timer so großzügig ausgelegt sind, daß selbst in stark überlasteten Netzen der Spanning Tree konvergieren kann.
Als einzige Möglichkeiten die Konvergenz erfolgreich zu verhindern, fällt mir nur der Layer 1 ein. Wenn man auf dem Physical Layer ein Problem hat, kann es dazu kommen daß Spanning Tree nicht innerhalb von 50 Sekunden konvergiert. Aber dann ist Spanning Tree auch nicht das Hauptproblem. Ganz tückisch ist das bei LWL Verkabelung, wenn die eine Leitung (z.B. Tx) funktioniert, die andere Leitung (dann Rx) eben nicht. In diesem Fall den Fehler in der Verkabelung zu entdecken ist schwer. Cisco hat dafür ein eigenes Verfahren implementiert: Uni-Directional Link Detection (UDLD). Ein weiterer Klassiker: Duplex Mismatch.
Entweder konvergiert der Spanning Tree Algorithmus innerhalb der vom Protocol definierten Zeit, oder gar nicht, wenn...