AUF DIESER SEITE
Die ID eines getrennten Mitglieds-Switches kann nicht neu zugewiesen werden
Die Mitglieds-ID bleibt bestehen, wenn ein Mitglieds-Switch von einem Virtual Chassis getrennt wird
Ein Mitglieds-Switch nimmt nicht an einem gemischten Virtual Chassis teil
Schnittstellenbedingte Konfigurationsänderungen werden nach der Umstellung nicht übernommen
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:
So ändern Sie die Mitglieds-ID in 0:
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
So benennen Sie die Schnittstellen entsprechend der neuen Mitglieds-ID um:
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
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:
user@switch> show virtual-chassis mode fpc0: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc1: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc2: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc3: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc4: -------------------------------------------------------------------------- Mixed Mode: Disabled fpc5: -------------------------------------------------------------------------- Mixed Mode: Enabled
So ändern Sie den Virtual Chassis-Modus auf einem Mitglieder-Switch (in diesem Fall Mitglieds-ID 4) in mixed den Modus:
user@switch> request virtual-chassis mode mixed member 4
(Nur EX4500-Switch) So überprüfen Sie den PIC-Modus:
user@switch> show chassis pic-mode
fpc0:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc1:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc2:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc3:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc4:
--------------------------------------------------------------------------
Pic Mode: PIC 3: Intraconnect
fpc5:
--------------------------------------------------------------------------
Pic Mode: PIC 3: virtual-chassis
So ändern Sie den PIC-Modus auf einem EX4500-Switch in virtual-chassis den Modus (in diesem Fall Mitglieds-ID 4):
user@switch> request chassis pic-mode virtual-chassis member 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):
user@switch> request system reboot member 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:
Entfernen Sie die in der Fehlermeldung erwähnte Memberschnittstelle aus dem aggregierten Ethernet-Bundle, und bestätigen Sie die Konfiguration.
Starten Sie den DCD-Prozess mithilfe des
restart interface-controlBefehls neu.Stellen Sie sicher, dass der DCD-Prozess ausgeführt wird.