ON THIS PAGE
A Disconnected Member Switch's ID Is Not Available for Reassignment
Load Factory Default Does Not Commit on a Multimember Virtual Chassis
The Member ID Persists When a Member Switch Is Disconnected From a Virtual Chassis
A Member Switch Is Not Participating in a Mixed Virtual Chassis
Interface-Related Configuration Changes Are Not Applied After Switchover
Troubleshooting an EX Series Virtual Chassis
This topic describes the following troubleshooting issues for a Virtual Chassis:
A Disconnected Member Switch's ID Is Not Available for Reassignment
Problem
Description
You disconnected a switch from the Virtual Chassis, but the disconnected switch’s member ID is still displayed in the status output. You cannot reassign that member ID to another switch.
Solution
When you disconnect a member of a Virtual Chassis configuration, the primary
retains the member ID and member configuration in its configuration database.
Output from the show
virtual-chassis command continues to display the member
ID of the disconnected member with a status of NotPrsnt.
If want to permanently disconnect the member switch, you can free up the member
ID by using the request
virtual-chassis recycle command. This will also clear
the status of that member.
Load Factory Default Does Not Commit on a Multimember Virtual Chassis
Problem
Description
The load factory-default command fails on a multimember
Virtual Chassis.
Solution
The load factory-default command is not supported on a
multimember Virtual Chassis configuration. For information on how to revert the
switches in the Virtual Chassis to factory default settings, see Reverting to the Default Factory Configuration for the EX Series
Switch.
The Member ID Persists When a Member Switch Is Disconnected From a Virtual Chassis
Problem
Description
Gigabit Ethernet interfaces retain their previous slot numbers when a member switch is disconnected from the Virtual Chassis.
Solution
If a switch had been previously connected as a member of a Virtual Chassis configuration, it retains the member ID that it was assigned as a member of that configuration even after it is disconnected and operating as a standalone switch. The interfaces that were configured while the switch was a member of the Virtual Chassis configuration retain the old member ID as the first digit of the interface name.
For example, if the switch was previously member 1, its interfaces are named
ge-1/0/0 and so on.
To change the switch’s member ID, so that its member ID is 0, and to rename the switch’s interfaces accordingly:
To change the member ID to 0:
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
To rename the interfaces to match the new member ID:
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
A Member Switch Is Not Participating in a Mixed Virtual Chassis
Problem
Description
A member switch in a mixed Virtual Chassis is not participating in the
Virtual Chassis. The show virtual-chassis output indicates
the member switch status is Inactive or
NotPrsnt.
This issue is most likely to occur immediately after you have cabled a mixed Virtual Chassis.
Solution
The Virtual Chassis mode on the switch might not be set to mixed
mode. If the member switch is an EX4500 switch and is cabled into the Virtual
Chassis through the dedicated Virtual Chassis port (VCP), the PIC mode might
also be set to Intraconnect instead of
virtual-chassis.
To verify the Virtual Chassis mode:
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
To change the Virtual Chassis mode on a member switch (in this case, member ID 4)
to mixed mode:
user@switch> request virtual-chassis mode mixed member 4
(EX4500 switch only) To verify the PIC mode:
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
To change the PIC mode on an EX4500 switch to virtual-chassis
mode (in this case, member ID 4):
user@switch> request chassis pic-mode virtual-chassis member 4
The member switch must be rebooted for the Virtual Chassis mode or PIC mode setting change to take effect. To reboot the member switch (in this case, member ID 4):
user@switch> request system reboot member 4
Interface-Related Configuration Changes Are Not Applied After Switchover
Problem
Description
After a graceful routing engine switchover, the commit operation for interface-related configuration changes succeeds, but the configuration changes are not applied. No error messages are generated as part of the commit operation.
Solution
When a new member interface is added to an aggregated Ethernet bundle, the validation might fail in case of a speed mismatch between the bundle and the new member interface. After a graceful routing engine switchover, the DCD process exits at startup due to the failed validation. Any interface-related configuration changes are not applied from then on.
Check the logs for any error messages related to speed mismatch between the aggregated Ethernet bundle and the new member interface. If these errors occur during DCD startup, then the DCD process exits.
To fix this:
Remove the member interface mentioned in the error message from the aggregated Ethernet bundle and commit the configuration.
Restart the DCD process by using the
restart interface-controlcommand.Verify that the DCD process is running.