VLAN-Lastverteilung auf Metro-E-Verbindungen zwischen zwei Juniper EX 4200

Wir haben Juniper EX 4200 als Core-Switch an zwei Standorten, die mit Cisco 2960 und Cisco 3560 verbunden sind (Access Layer-Switches). Bei geradzahligen VLANs ist ein Juniper-Switch die Root-Bridge und bei ungeradzahligen VLANs ist der andere Juniper-Switch die Root-Bridge.

Wir haben Cox- und Verizon Metro-E-Verbindungen, die Core-Switches verbinden (Juniper EX 4200 an beiden Standorten).

Ich möchte VLAN Load Sharing mit VSTP durchführen, aber irgendwie funktioniert es nicht wie erwartet. Ich möchte einige VLANs über COX und einige über Verizon weiterleiten. Wenn es Probleme mit Cox gibt, wird der gesamte VLAN-Verkehr über Verizon geleitet und umgekehrt. RSTP ist auch auf beiden Juniper-Switches aktiviert.

Ich sehe, wie MAC in Protokollnachrichten auf allen Cisco Access Layer-Switches flattert, wenn ich beide Metro-E-Links zusammen rufe. Wenn nur Cox angeschlossen ist, funktioniert alles einwandfrei. Wenn nur Verizon verbunden ist, funktioniert alles einwandfrei. Aber wenn BOTH COX und Verizon verbunden sind, wird das Netzwerk unterbrochen und ich sehe, dass MAC auf allen Cisco-Switches flattert. Auf allen Cisco-Switches wird PVST ausgeführt.

Jeder weiß, was passiert und warum VSTP nicht funktioniert, wenn sowohl COX- als auch VERIZON Metro-E-Links aktiv sind?

Update (09.12.2013): =====

Basierend auf Juniper-KBs: KB18291 und KB15138 habe ich Folgendes getan:

1. Ich habe ein gemeinsames natives VLAN 50 (und das Herunterfahren von VLAN 1) auf allen Juniper- und Cisco-Switches aktiviert und die Trunk-Ports konfiguriert, an denen Cisco-Switches eine Verbindung zu Juniper für natives VLAN herstellen. (Dies liegt daran, dass Spanning-Tree-BPDUs über ein natives VLAN zwischen Cisco und Juniper ausgetauscht werden.) Standardmäßig ist das native vlan von Cisco vlan 1 und es gibt kein natives vlan auf Juniper. Daher versteht Juniper die BPDUs nicht und behandelt sie als Broadcast-Verkehr, der sie in das entsprechende VLAN überflutet. Aus diesem Grund konvergiert STP zwischen Cisco und Juniper nicht.

2. Der Cisco Spanning Tree-Modus wurde von PVST auf Rapid-PVST geändert (Juniper empfiehlt, den Cisco Spanning Tree-Modus von Standard - PVST auf Rapid-PVST zu ändern). Rapid-PVST konvergiert gut mit dem Juniper-Spanning-Tree-Protokoll „VSTP“.

3. Gelöschte RSTP-Protokollanweisungen gemäß Juniper-Dokumentation

4. Eingabe des Prioritätsbefehls für die vstp-Schnittstelle für VLANs und native VLANs auf Juniper-Switches

Wenn nun die Cox- und Verizon-Links gleichzeitig aktiv sind, fallen einige Cisco-Switches, die an beiden Standorten an Wacholder-Core-Switches hängen, aus. Ich sehe auch in Juniper (mit dem Befehl "show ethernet-switch interfaces"), dass einige Schnittstellen, an denen Cisco-Switches angeschlossen sind, durch STP blockiert werden.

Kann jemand herausfinden, was passiert?

Regel Nr. 1: In einer gemischten Anbieterumgebung wird die Verwendung herstellereigener Protokolle vermieden

Es gibt (anscheinend) mehrere Komplikationen beim Versuch, VSTP (ein Juniper-Protokoll) mit PVST (RPVST eigentlich ein Cisco-Protokoll) zu verwenden - während beide eine RSTP-Instanz pro VLAN ausführen, tun sie dies nicht genau gleich (etwas) über getaggte / nicht getaggte native vlans usw.)

Am besten verwenden Sie einen offenen, dokumentierten Standard mit Regeln, die jeder befolgt. Das wäre MST (802.1s, jetzt Teil von 802.1q.) Natürlich ist die Einrichtung von MST sehr viel komplizierter. (war dort ... komplexe Hunderte von VLANs bei 4 Anbietern)

All dies setzt voraus, dass die Träger nicht mit dem Verkehr schrauben. Wenn ich Ihrer Beschreibung folge, befinden sich die U-Bahn-Verbindungen zwischen Wacholderschaltern und die Cisco hängen an jedem Standort an den Wacholderschaltern. Wenn das stimmt, gibt es nur einen Pfad von einem Cisco zur anderen Seite, daher sollten Mac-Klappen nicht möglich sein - es sei denn, an jedem Ende befinden sich zwei Wacholder, die den Verkehr zwischen den Standorten umrunden. (oder es gibt Etherchannels, die nicht richtig eingerichtet sind / laufen)

Überholen die Träger Ihre L2-Kontrollrahmen? Sehr oft müssen Sie sie ausdrücklich darum bitten.

Sie können dies überprüfen, indem Sie Ihre auf beiden Switches gesendeten und empfangenen BPDUs überprüfen, wenn beide aktiv sind