Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Fehlerbehebung bei einem Virtual Chassis der EX-Serie

In diesem Thema werden die folgenden Probleme bei der Problembehandlung für ein Virtual Chassis beschrieben:

Die ID eines getrennten Mitglieds-Switches kann nicht neu zugewiesen werden

Problem

Beschreibung

Sie haben einen Switch vom Virtual Chassis getrennt, aber die Mitglieds-ID des getrennten Switches wird weiterhin in der Statusausgabe angezeigt. Sie können diese Mitglieds-ID nicht einem anderen Switch zuweisen.

Lösung

Wenn Sie ein Mitglied einer Virtual Chassis-Konfiguration trennen, behält das primäre Mitglied die Mitglieds-ID und die Mitgliedskonfiguration in seiner Konfigurationsdatenbank bei. In der Ausgabe des show virtual-chassis Befehls wird weiterhin die Element-ID des getrennten Mitglieds mit dem Status angezeigt.NotPrsnt

Wenn Sie den Member-Switch dauerhaft trennen möchten, können Sie die Member-ID mit dem request virtual-chassis recycle Befehl freigeben. Dadurch wird auch der Status dieses Mitglieds gelöscht.

Die werkseitige Standardeinstellung für Load Factory wird auf einem Virtual Chassis mit mehreren Mitgliedern nicht festgeschrieben.

Problem

Beschreibung

Der load factory-default Befehl schlägt auf einem Virtual Chassis mit mehreren Mitgliedern fehl.

Lösung

Der load factory-default Befehl wird in einer Virtual Chassis-Konfiguration mit mehreren Mitgliedern nicht unterstützt. Informationen zum Zurücksetzen der Switches im Virtual Chassis auf die Werkseinstellungen finden Sie unter Zurücksetzen auf die werkseitige Standardkonfiguration für den Switch der EX-Serie.

Die Mitglieds-ID bleibt bestehen, wenn ein Mitglieds-Switch von einem Virtual Chassis getrennt wird

Problem

Beschreibung

Gigabit-Ethernet-Schnittstellen behalten ihre vorherigen Steckplatznummern bei, wenn ein Mitglieds-Switch vom Virtual Chassis getrennt wird.

Lösung

Wenn ein Switch zuvor als Mitglied einer Virtual Chassis-Konfiguration verbunden war, behält er die Mitglieds-ID, die ihm als Mitglied dieser Konfiguration zugewiesen wurde, auch dann bei, wenn er getrennt wurde und als eigenständiger Switch betrieben wird. Die Schnittstellen, die konfiguriert wurden, während der Switch Mitglied der Virtual Chassis-Konfiguration war, behalten die alte Mitglieds-ID als erste Ziffer des Schnittstellennamens bei.

Wenn der Switch beispielsweise zuvor Mitglied 1 war, werden seine Schnittstellen benannt ge-1/0/0 usw.

So ändern Sie die Mitglieds-ID des Switches, sodass die Mitglieds-ID 0 ist, und benennen die Schnittstellen des Switches entsprechend um:

  1. So ändern Sie die Mitglieds-ID in 0:

  2. So benennen Sie die Schnittstellen entsprechend der neuen Mitglieds-ID um:

Ein Mitglieds-Switch nimmt nicht an einem gemischten Virtual Chassis teil

Problem

Beschreibung

Ein Mitgliedsswitch in einem gemischten Virtual Chassis ist nicht am Virtual Chassis beteiligt. Der show virtual-chassis Ausgang gibt an, dass der Status des Member-Switches oder ist Inactive NotPrsnt.

Dieses Problem tritt höchstwahrscheinlich unmittelbar nach dem Verkabeln eines gemischten Virtual Chassis auf.

Lösung

Der Virtual Chassis-Modus auf dem Switch ist möglicherweise nicht auf mixed Modus eingestellt. Wenn es sich bei dem Mitglieds-Switch um einen EX4500-Switch handelt und er über den dedizierten Virtual Chassis-Port (VCP) mit dem Virtual Chassis verkabelt ist, kann der PIC-Modus auch auf Intraconnect anstelle von eingestellt werden.virtual-chassis

So überprüfen Sie den Virtual Chassis-Modus:

So ändern Sie den Virtual Chassis-Modus auf einem Mitglieder-Switch (in diesem Fall Mitglieds-ID 4) in mixed den Modus:

(Nur EX4500-Switch) So überprüfen Sie den PIC-Modus:

So ändern Sie den PIC-Modus auf einem EX4500-Switch in virtual-chassis den Modus (in diesem Fall Mitglieds-ID 4):

Der Member-Switch muss neu gestartet werden, damit die Einstellungsänderung für den Virtual Chassis-Modus oder den PIC-Modus wirksam wird. So starten Sie den Member-Switch neu (in diesem Fall Mitglieds-ID 4):

Schnittstellenbedingte Konfigurationsänderungen werden nach der Umstellung nicht übernommen

Problem

Beschreibung

Nach einem ordnungsgemäßen Umschalten der Routing-Engine ist der Commitvorgang für schnittstellenbezogene Konfigurationsänderungen erfolgreich, die Konfigurationsänderungen werden jedoch nicht angewendet. Im Rahmen des Commitvorgangs werden keine Fehlermeldungen generiert.

Lösung

Wenn eine neue Member-Schnittstelle zu einem aggregierten Ethernet-Bundle hinzugefügt wird, schlägt die Validierung möglicherweise fehl, wenn eine Geschwindigkeitsdiskrepanz zwischen dem Bundle und der neuen Member-Schnittstelle vorliegt. Nach einem ordnungsgemäßen Umschalten der Routing-Engine wird der DCD-Prozess beim Start aufgrund der fehlgeschlagenen Validierung beendet. Schnittstellenbedingte Konfigurationsänderungen werden ab diesem Zeitpunkt nicht mehr übernommen.

Prüfen Sie die Protokolle auf Fehlermeldungen im Zusammenhang mit Geschwindigkeitsinkonsistenzen zwischen dem aggregierten Ethernet-Bundle und der neuen Mitgliederschnittstelle. Wenn diese Fehler beim DCD-Start auftreten, wird der DCD-Prozess beendet.

So beheben Sie dieses Problem:

  1. Entfernen Sie die in der Fehlermeldung erwähnte Memberschnittstelle aus dem aggregierten Ethernet-Bundle, und bestätigen Sie die Konfiguration.

  2. Starten Sie den DCD-Prozess mithilfe des restart interface-control Befehls neu.

  3. Stellen Sie sicher, dass der DCD-Prozess ausgeführt wird.