Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

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
• 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
• Unknown Traffic Looping Occurs After Configuring an Uplink Port as a Redundant VCP with a Dedicated VCP

A Disconnected Member Switch's ID Is Not Available for Reassignment

Problem

Solution

When you disconnect a member of a Virtual Chassis configuration, the master 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

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

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.

1. To change the member ID to 0:
   user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
2. 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

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:

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:

(EX4500 switch only) To verify the 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):

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):

Unknown Traffic Looping Occurs After Configuring an Uplink Port as a Redundant VCP with a Dedicated VCP

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.