Troubleshooting an EX Series Virtual Chassis

Problem

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.

Problem

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.

Problem

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:

1. To change the member ID to 0:

   content_copy zoom_out_map

   user@switch> request virtual-chassis renumber member-id 1 new-member-id 0

2. To rename the interfaces to match the new member ID:

   content_copy zoom_out_map

   [edit virtual-chassis]
   user@switch# replace pattern ge-1/ with ge-0/

Problem

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

Problem

Solution

Reboot the Virtual Chassis to properly detect the converted VCP as a redundant link with the dedicated VCP link.

After the conversion from a network port to a VCP, the egress filter table is not updated and the redundant VCP remains enabled for forwarding, which causes the looping behavior. The reboot process detects the converted port as a VCP and brings it up as disabled for forwarding.

As a result, we do not recommend connecting redundant converted uplink VCP ports between members already connected by dedicated VCPs on an active Virtual Chassis; instead, plan to add redundant uplink VCP connections during a maintenance window that can include a Virtual Chassis reboot cycle. This recommendation also applies when adding a new member to an existing active Virtual Chassis where you are adding redundant VCP links between the new member and one of its neighbors that mix dedicated VCPs and converted uplink VCPs.

Problem

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:

1. Remove the member interface mentioned in the error message from the aggregated Ethernet bundle and commit the configuration.

2. Restart the DCD process by using the restart interface-control command.

3. Verify that the DCD process is running.