[EX] Disabling me0 interface may split Virtual Chassis (VC)

 [KB30771] Show Article Properties

SUMMARY:
On EX8200 members operating in virtual-chassis mode on an EX8200-VC, the me0 ports also act as virtual-chassis ports. When
me0 interface is disabled, this may lead to virtual-chassis split on certain releases.

SYMPTOMS:
On EX8200 members operating in virtual-chassis mode on an EX8200-VC, the me0 ports also act as virtual-chassis ports. If the
configuration 'set interfaces me0 disable' is applied on an EX8200-VC, the me0 ports will get disabled only on the EX-
XRE members and not on the EX8200 members. On some releases, Junos OS 12.3, 13.2X51 or 14.1X53, this may lead to a VC
split.

CAUSE:
EX8200-VC can split due to EX8200 members acting as line card may disable me0 interfaces (vcp interfaces) and lose connection to
XREs.

This issue is only seen with the following conditions:

1. Configuration applied in main config:

set interface me0 disable

2. Only seen in certain relases

Junos OS 12.3, 13.2X51 or 14.1X53

Example:

This issue may occur when upgrading between releases 11.4 to 12.3:
Config where interface me0 is disabled in main config (not via group)

root@EX8200-VC> show configuration interfaces me0| display set

set interfaces me0 disable
set interfaces me0 unit 0 disable
set interfaces me0 unit 0 family inet

The issue would be  avoided by configuring "me0 disable" via groups.

XRE output after upgrade from 11.4 to 12.3:

{master:8}
root@EX8200-VC> show virtual-chassis vc-port
member8:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
Slot/PIC/Port
vcp-0/0 Dedicated -1 Down 1000
vcp-1/0 Dedicated -1 Down 1000
vcp-1/1 Dedicated -1 Down 1000
vcp-1/2 Dedicated -1 Down 1000
vcp-1/3 Dedicated -1 Down 1000
vcp-2/0 Dedicated -1 Down 1000
vcp-2/1 Dedicated -1 Down 1000
vcp-2/2 Dedicated -1 Down 1000
vcp-2/3 Dedicated -1 Down 1000

{master:8}
root@EX8200-VC> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: d67a.5715.f941
Virtual Chassis Mode: Enabled
 Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0-15) NotPrsnt xxxxxxxxxxxxxxxxx ex8216
8 (FPC 128-143) Prsnt yyyyyyyyyyyyyyyy ex-xre 129 Master*

{master:8}
root@EX8200-VC> show configuration interfaces me0
disable;
unit 0 {
disable;
family inet;
}

{master:8}
root@EX8200-VC> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: d67a.5715.f941
Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0-15) NotPrsnt xxxxxxxxxxxxxxxxx ex8216
8 (FPC 128-143) Prsnt yyyyyyyyyyyyyyyy ex-xre 129 Master*

{master:8}
root@EX8200-VC> show interfaces terse me0
Interface Admin Link Proto Local Remote
me0 down down
me0.0 down down inet

{master:8}
root@EX8200-VC> show configuration interfaces me0
disable;
unit 0 {
disable;
family inet;
}

EX8200 - member 0 output

{master:0}
root> show virtual-chassis vc-port
member0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
Slot/PIC/Port
vcp-0/0 Dedicated -1 Down 1000
vcp-0/1 Dedicated -1 Up 1000

{master:0}
root> show interfaces terse me0
Interface Admin Link Proto Local Remote
me0 down down
me0.0 down down inet

{master:0}
root> show virtual-chassis vc-port
member0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
Slot/PIC/Port
vcp-0/0 Dedicated -1 Down 1000
vcp-0/1 Dedicated -1 Up 1000

{master:0}
root> show virtual-chassis

Virtual Chassis ID: d67a.5715.f941

Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0-15) Prsnt xxxxxxxxxxxxxxxxx ex8216 0 Linecard*
8 (FPC 128-143) NotPrsnt yyyyyyyyyyyyyyyy ex-xre

SOLUTION:
Workaround: The problem can be avoided by using apply-groups:

set groups member8 system host-name EX8200-VC

set groups member8 interfaces me0 disable
set apply-groups member8

The fix for this issue is implemented in Junos OS 12.3R9, 14.1X53-D15, 15.1R1, 13.2X51-D30 and later releases.

INTERNAL COMMENTS:
There is also fix applied via PR 951508 [Confidential] - FIXX-VC: me0 disable causes all VCP interfaces on XRE to go down and the
whole VC breaks down.

Verifying Virtual Chassis (VC) Member ID's

Avg. Rating:  1

 [KB10478] Show Article Properties

SUMMARY:
A virtual chassis is a scalable switch composed of multiple interconnected EX4200 switches. Up to ten EX4200 switches can be
interconnected as a Virtual Chassis (VC) using Virtual Chassis Cables (VCP). Each member switch can be cabled to one or two other
member switches, using either the dedicated Virtual Chassis Ports (VCP) on the rear panel or an uplink port that has been set as a
VCP.  The members that are cabled together are considered neighbor members.
SOLUTION:
The mastership priorities and member ID's are assigned by the software by default but can be configured manually.  By default the
first member will be member ID=0.  When you interconnect the switches with the dedicated Virtual Chassis Port (VCP) cables and
power on the switches, the VCPs are operational and the mastership priorities and member IDs are assigned by the software. The
role and member ID of the member switches  are displayed on the front-panel LCD (see user manual for member election).

To display the role and member ID assignments using the CLI, issue the "show virtual-chassis status" command and the "show
chassis lcd" command which lists the member switches interconnected as a virtual chassis with the member IDs:

show virtual-chassis status command: 

user@switch> show virtual-chassis status
Virtual Chassis ID: 0000.e255.00e0

                                       Mastership             Neighbor List  

Member ID  Status  Serial No   Model     Priority  Role       ID, Interface

0 (FPC 0)  Prsnt   abc123      ex4200-48p    255  Master*     1 vcp-0

                                                              2 vcp-1

1 (FPC 1)  Prsnt   def456      ex4200-24t    255  Backup      2 vcp-0

                                                              0 vcp-1

2 (FPC 2)  Prsnt   abd231      ex4200-24p    128  Linecard    0 vcp-0

                                                              1 vcp-1
                                                                                                                          
This output verifies that three EX 4200 switches have been interconnected as a virtual chassis using their dedicated VCPs. The
display shows which of the VCPs is connected to which neighbor. The first port (vcp-0) of member 0 is connected to member 1 and
 the second port of member 0 (vcp-1) is connected to member 2. The FPC slots for EX-series switches are the same as the member
IDs.

The Mastership Priority values indicate that the master and backup members have been explicitly configured, because they are not
using the default value (128). 

Output Fields
Virtual Chassis ID - Assigned ID that applies to the entire virtual chassis configuration.

Member ID - Assigned member ID and FPC slot (from 0 through 9).

Status -     
 For a non-provisioned configuration: 
1. Prsnt for a member that is currently connected to the virtual chassis.
2. NotPrsnt for a member ID that has been assigned but is not currently connected.

 For a pre-provisioned configuration:

1. Prsnt for a member that is specified in the preprovisioned configuration file and is currently connected to the virtual
chassis.
2. Unprvsnd for a member that is interconnected with the virtual chassis, but is not specified in the preprovisioned
configuration file.
Serial No - Serial number of the member switch.

Model - Model number of the member switch.

Mastership Priority - Mastership priority value of the member switch.

Role - Role of the member switch.

Neighbor List - Member ID of the neighbor member to which this member’s VCP interface is connected.

show chassis lcd command :

user@switch>show chassis lcd 
FPM Display contents for slot: 1
    00:BK fpc1
    LED:SPD ALARM 00
FPM Display contents for slot: 2
    01:RE fpc2
    LED:SPD ALARM 00
FPM Display contents for slot: 3
    02:LC fpc3
    LED:SPD ALARM 0

[EX] Converting a Virtual Chassis Member Role to Master

 [KB21161] Show Article Properties

SUMMARY:
This article assists you with converting a Virtual Chassis member role to Master. It will help the user who prefers to change any
member in a Virtual Chassis to a Master role.
This article is part of the EX Resolution Guide: KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members are not
all present.

SYMPTOMS:
 How do I change a member to a Master?
 I want to change my Linecard member to a Master Role.
 I want to change my Backup member to Master Role .
 A different member is preferred to be Master.
For example, in the 'show virtual-chassis' output below, FPC 0 - (BR0208233776) is preferred to act as Master.
root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

 Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 127 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 2 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 1 vcp-1

Member ID for next new member: 3 (FPC 3)

SOLUTION:
Increase the mastership-priority of the existing Linecard or Backup to be a  higher value than that of the current Master.

Important: During a change-over of mastership role, a network outage may occur due to a Routing Engine failover. Juniper
recommends making these changes during a maintenance window .

In the example above, the mastership-priority of Member FPC 0 is made higher than the current Master Member FPC 1 with the
following command:
root@EX4100-VC# set virtual-chassis member 0 mastership-priority 129
After changing the mastership-priority, a commit synchronize needs to be executed:
root@EX4100-VC# commit synchronize

Refer to KB12879 for additional information on commit synchronize.

The end result will be as follows:

root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 129 Master* 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Backup 2 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Linecard 1 vcp-1

Member ID for next new member: 3 (FPC 3)

For more information on understanding the Mastership Election process in a Virtual Chassis before making a new member as
Master, refer to the following Techincal Documentation: 
Understanding How the Master in a Virtual Chassis Is Elected 

Collecting Logs from EX series devices using the 'file archive' command
Avg. Rating:  1

 [KB20569] Show Article Properties

SUMMARY:
This article will help you collecting logs from EX series devices which may play a vital role in Root Cause Analysis (RCA).

SYMPTOMS:
Collect all the logs on the EX device using the 'file archive' command.  The 'file archive' command provides a simple
way to zip (tar) files.

SOLUTION:
Collecting logs differs across the EX platforms.  Follow the steps for your particular EX device:
 Collecting Logs from a Stand-alone switch
 Collecting Logs from a Virtual Chassis
 Collecting Logs from 8200 Series - Multiple Routing Engines
 Collecting Logs from a Stand-alone switch

1. Login to the device.

2. Enter the following command to archive the /var/log directory.  The following command will zip (tar) the folder "/var/log"
and name the file (LOGS.tar).  It also pushes the zipped file to the destination folder "/var/tmp".
root@lab> file archive source /var/log destination /var/tmp/LOGS
3. Perform the steps under the section Export the Archived Logs in order to copy the archived logs to your PC or
another source.

IMPORTANT: The archive includes several files.  Therefore, specify the actual date/time of the outage to be analyzed when giving
the archived logs to your technical support representative. This will help speed up the analysis.

Collecting Logs from Virtual Chassis

Note: Collecting the logs should be Initiated from the Master.

1. Login to the Master.  Here we assume FPC0 is the master.

2. Enter the following command to archive the /var/log directory of the Master.  The following command will zip (tar) the
folder "/var/log" and name the file (MASTER-LOG.tar).  It also pushes the zipped file to the Master switch.  The destination folder
remains "/var/tmp".
{master:0}
root@lab> file archive source /var/log destination fpc0:/var/tmp/MASTER-LOG
3. Login to the Backup - Here we assume FPC1 will be the Backup & FPC0 remains Master.
{master:0}
root@lab> request session member <Member ID>    (For FPC1 it will be 1)
root@lab% cli
{backup:1}
4. Enter the following command to archive the /var/log directory of the Backup.  The following command will zip (tar) the
folder "/var/log" and name the file (BACKUP-LOG.tar).  It also pushes the zipped file to the Master switch (FPC0).  The destination
folder remains "/var/tmp".
{backup:1}
root@lab> file archive source /var/log destination fpc0:/var/tmp/BACKUP-LOG
5. Login to the Other Linecard members - Here we assume FPC2 will be the other linecard member and considering FPC0
remains master. (Please replace FPC2 with respective Member ID.)
{backup:1}
root@lab> request session member 2    (For FPC2 it will be 2) 
root@lab% cli
{backup:2}
6. Enter the following command to archive the /var/log directory of the other Linecard members.  The following
command will zip (tar) the folder "/var/log" and name the file (LC-FPC2-LOG.tar).  It also pushes the zipped file to the Master switch. 
The destination folder remains "/var/tmp".
root@lab> file archive source /var/log destination fpc0:/var/tmp/LC-FPC2-LOG
7. Login to the Master and make sure desired files been saved in the /var/tmp directory:
root@lab:RE0% cd /var/tmp
root@lab:RE0% ls
.snap                            LC-FPC2-LOG.tar                   LC-FPC2-LOG.tar
BACKUP-LOG.tar                   MASTER-LOG.tar                    krt_gencfg_filter.txt
root@lab:RE0%      
8. Perform the steps under the section Export the Archived Logs in order to copy the archived logs to your PC or
another source.

IMPORTANT: The archive includes several files. Therefore, specify the actual date/time of the outage to be analyzed when giving
the archived logs to your technical support representative. This will help speed up the analysis.

Collecting Logs from 8200 series - Multiple Routing Engines

Note: Collecting the logs should be Initiated from the Master.

1. Login to the Master Routing Engine.  Here we assume RE0 will be the Master.
root@lab> request routing-engine login master
2. Enter the following command to archive the /var/log directory of RE0.  The following command will zip (tar) the folder
"/var/log" and name the file (RE0-LOG.tar).  It also pushes the zipped file to the Master Routing Engine.  The destination folder
remains "/var/tmp".
{master:0}
root@lab> file archive source /var/log destination re0:/var/tmp/RE0-LOG
3. Login to the Backup Routing Engine - Here we assume RE1 will be the Backup.
{master:0}
root@lab> request routing-engine login backup
root@lab% cli
{backup:1}
4. Enter the following command to archive the /var/log directory of the RE1.  The following command will zip (tar) the
folder "/var/log" and name the file (RE1-LOG.tar).  It also pushes the zipped file to the Master Routing Engine.  The destination folder
remains "/var/tmp".
{backup:1}
root@lab> file archive source /var/log destination re1:/var/tmp/RE1-LOG
5. Perform the steps under the section Export the Archive Logs in order to copy the archived logs to your PC or
another source.

IMPORTANT: The archive includes several files. Therefore, specify the actual date/time of the outage to be analyzed when giving
the archived logs to your technical support representative. This will help speed up the analysis.

Export the Archived Logs saved in  "/var/tmp"

Archived logs can be copied (exported) to your PC or another source using either of the following methods:
 FTP to the Master switch and copy (export) the files from the "/var/tmp" directory
 JWEB into the switch and Download the desired File (Refer the screenshots)

FTP:
Download the saved Logs on the Junos device or switch through FTP services by performing the following:
a. Prerequisite:  FTP services must be enabled on the Junos device or switch.  These services are not enabled by default. 

root@ex# set system service ftp 

root@ex# commit 

b. From the FTP client, login into switch (user: root).

c. Change directory from "/root" to "/var/tmp"

d. Select the saved File. (Note - As per the above example, the filename could be either LOGS or MASTER-LOG )

e. Copy the saved file to the desired location by clicking on transfer.

[EX] Fixing a Virtual Chassis Member with an 'Inactive' status

Avg. Rating:  1

 [KB21133] Show Article Properties

SUMMARY:
This article steps you thru how to reactivate an 'Inactive' Virtual Chassis Member.
This article is part of the EX Resolution Guide: KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members are not
all present.
SYMPTOMS:
Master and Back-up Members have a status of Present.  However, one of the members (FPC 0) reports the status as 'Inactive':
Virtual Chassis ID: 6eb0.0094.e64b
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID
Interface
0 (FPC 0) Inactive BR0208233776 ex4200-24f 128 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0
 0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

Member ID for next new member: 3 (FPC 3)

How do you make the Inactive member active (where the status = Prsnt)?
 
CAUSE:
Typically when a member is Inactive, all the members of the switch are not running the same Junos OS version. The 'show version'
command will display the Junos version for all the members which are physically connected (including Present & Inactive members).
This is confirmed in the following 'show version' output.  In this example, FPC 0 is Inactive because of a Junos version mismatch:
{master:1}[edit]
root@EX4200-VC# run show version 
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-48t
JUNOS Base OS boot [11.1R1.10]
JUNOS Base OS Software Suite [11.1R1.10]
JUNOS Kernel Software Suite [11.1R1.10]
JUNOS Crypto Software Suite [11.1R1.10]
JUNOS Online Documentation [11.1R1.10]
JUNOS Enterprise Software Suite [11.1R1.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.1R1.10]
JUNOS Routing Software Suite [11.1R1.10]
JUNOS Web Management [11.1R1.10]

fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10]
JUNOS Online Documentation [10.2R3.10]
JUNOS Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]

fpc2:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10]
JUNOS Online Documentation [10.2R3.10]
JUNOS Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]
 
 

SOLUTION:
To make the 'Inactive' member active, reinstall Junos version to match the existing Virtual Chassis Master.
There are two ways to achieve this. Both methods are explained in detail below: 

Option 1. Re-install the same Junos OS version running on the active VC members to the inactive member.
Option 2. If this does not form the VC, isolate the inactive member from the VC and upgrade it individually, and then bring it back into
the VC. 
Option-1 - Upgrade the affected member without removing it from the VC 

For example, on a four member EX4300VC running 14.1X53-D30, all the VC members become inactive because one of the
members has a Junos OS version mismatch.
To recover the state, load the Junos image on the affected member to be the same as entire VC, and perform a reboot. The VC
comes up fine once done. 
{master:1}[edit]
root# run show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: e987.b14d.bcbe
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Inactive PE3715170046 ex4300-48t 129 Linecard N VC 2 vcp-255/1/0
1 vcp-255/1/1
1 (FPC 1) Prsnt PD3715220083 ex4300-48p 129 Master* N VC 0 vcp-255/1/0
3 vcp-255/1/1
2 (FPC 2) Inactive PE3715170221 ex4300-48t 0 Linecard N VC 3 vcp-255/1/0
0 vcp-255/1/1
3 (FPC 3) Inactive PE3715210118 ex4300-48t 0 Linecard N VC 1 vcp-255/1/0
2 vcp-255/1/1

root# run show version

fpc0:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]

fpc1:
----------------------------------------------------------- <---------- Affected
member
Model: ex4300-48p
JUNOS EX Software Suite [13.2X51-D26.2]
JUNOS FIPS mode utilities [13.2X51-D26.2]
JUNOS Online Documentation [13.2X51-D26.2]
JUNOS EX 4300 Software Suite [13.2X51-D26.2]
JUNOS Web Management [13.2X51-D26.2]
JUNOS py-base-powerpc [13.2X51-D26.2]

fpc2:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]

fpc3:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]
 After the upgrade and reboot:

{master:1}
root> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: e987.b14d.bcbe
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Prsnt PE3715170046 ex4300-48t 129 Backup N VC 2 vcp-255/1/0
1 vcp-255/1/1
1 (FPC 1) Prsnt PD3715220083 ex4300-48p 129 Master* N VC 0 vcp-255/1/0
3 vcp-255/1/1
2 (FPC 2) Prsnt PE3715170221 ex4300-48t 0 Linecard N VC 3 vcp-255/1/0
0 vcp-255/1/1
3 (FPC 3) Prsnt PE3715210118 ex4300-48t 0 Linecard N VC 1 vcp-255/1/0
2 vcp-255/1/1

Option-2 - Isolate affected switch, upgrade and put it back into the VC

Here is another way to recover the VC: 

Isolate the affected switch (the Inactive member) by unplugging the VCP cables.
Re-active the Virtual Chassis to make that switch a stand-alone switch by using command:
root@EX4200-VC> request virtual-chassis reactivate

Example output:

{Linecard:0}
root@EX4200-VC> show virtual-chassis

Virtual Chassis ID: 684e.e679.9f51

Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-48t 128 Linecard*

Member ID for next new member: 1 (FPC 1)

{Linecard:0}
root@EX4200-VC> request virtual-chassis reactivate

{master:0}
root@EX4200-VC> show virtual-chassis

Virtual Chassis ID: 684e.e679.9f51

Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-48t 128 Master*

Member ID for next new member: 1 (FPC 1)

Once the affected device been isolated as a stand-alone switch (Master role with 1 member), proceed with upgrading. Refer to KB20536 -
Upgrading EX series Devices.  
After a successful upgrade, re-connect the VCP cables.  It should then make FPC 0 an Active member:
root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership
Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0

0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

Member ID for next new member: 3 (FPC 3)

Once Active (status=Prsnt), if you prefer to have FPC 0 as a Backup, refer to KB21115 - Converting a Virtual Chassis Member Role
from Linecard to Backup.

To verify the health of your Virtual Chassis, refer to KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members
are not all present.

Resolution Guide - EX - Troubleshoot Virtual Chassis (VC)

Avg. Rating:  1

 [KB21064] Show Article Properties

SUMMARY:
This is a Resolution Guide which steps you through how to check the Virtual Chassis status and troubleshoot virtual-chassis
members if they are not in an Active/Healthy (Present) State.

SYMPTOMS:
 Understand and interpret Virtual Chassis Member status
 Understand and interpret Virtual Chassis Member roles
 Verify Virtual Chassis is Active (in a healthy/present) state
 Troubleshoot Virtual Chassis members if they are not in a Active (Present) State

Note:  This guide assumes you have the Virtual Chassis configured. 
For examples on how to configure a Virtual Chassis, refer to  http://www.juniper.net/techpubs/en_US/junos/information-
products/pathway-pages/ex-series/virtual-chassis-4200-4500.html#configuration.

CAUSE:

SOLUTION:
This solution includes the following topics:
(Click the link to jump directly to the topic.)
 Definition - Virtual Chassis Member Status
 Definition - Virtual Chassis Member Roles
 Verify your Virtual Chassis is in healthy state, and if not troubleshoot how to make it healthy

Definition - Virtual Chassis Member Status

The output of the command show virtual-chassis status reports the status of each member.

root@EX4200-VC# run show virtual-chassis status

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Int
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Backup 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Linecard 3 vcp-1
3 (FPC 3) Inactive BR0209457019 ex4200-24f 128 Linecard 2 vcp-0
Unprvsnd BP0208180138 ex4200-48t
4 (FPC 4) NotPrsnt BP0208180138 ex4200-48t

Member ID for next new member: 5 (FPC 5)

There are four possible valid Member Status states:

Prsnt (Present):
The status Prsnt indicates that all switches are part of  a single Virtual Chassis. Hence it can be managed as a single logical
device. The status Prsnt states members have established physical & logical connections between them.

NotPrsnt (Not-Present);
The status NotPrsnt indicates that the particular switch has been disconnected from the existing Virtual Chassis. These devices
cannot be managed as a single logical device since they do not have established Physical connection with an existing Virtual
Chassis.

Inactive:
The status Inactive states that those members have established physical connections, but are unable to establish logical
connections. These devices can be managed as a single logical device since they have established physical connection but cannot
be an Active member of the Virtual chassis since they have not established logical connection with an existing Virtual Chassis. 

UnPrvsnd (Not-Provisioned):
Pre-Provisioning is a method for defining Virtual-chassis members and roles. The status UnPrvsndindicates that the particular
switch cannot synchronize with an existing pre-provisioned Virtual Chassis. These devices cannot be managed as a single logical
device since they have not established a physical connection with an existing Virtual Chassis.

For more information on the show virtual chassis status command, refer

to http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/command-summary/show-virtual-chassis-status.html.

Definition - Virtual Chassis Member Roles

The output of the command show virtual-chassis status also reports the role of each member.

root@EX4200-VC# run show virtual-chassis status

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Int
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Backup 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Linecard 3 vcp-1
3 (FPC 3) Inactive BR0209457019 ex4200-24f 128 Linecard 2 vcp-0
Unprvsnd BP0208180138 ex4200-48t
4 (FPC 4) NotPrsnt BP0208180138 ex4200-48t

Member ID for next new member: 5 (FPC 5)

There are three possible valid roles that a switch can be in a Virtual Chassis:

Master:
This member which governs the entire Virtual Chassis:
 Serves as the Master (Preferred) Routing Engine for the Virtual Chassis
 Manages the entire Virtual Chassis
 Runs the chassis management processes and network control protocols
 Calculates and maintains the forwarding table and distributes it to the local CPU, and then to Packet Forwarding Engines
(PFEs) in all member switches
 Receives and transmits routing information
 Represents all member switches (the hostname that was assigned to the master switch during setup apply to all members of
the Virtual Chassis)
 Holds the active and master copy of the entire Virtual Chassis configuration
 Shares Virtual Chassis configuration to his Back-up to maintain Redundancy

Backup:
This member acts as standby to the Master Routing Engine:
  Serves as the Back-up (Standby) Routing Engine for the Virtual Chassis
 Manages the entire Virtual Chassis
 Synchronize with Master to make sure it has update Info shared by Master
 Acquires mastership on Outage
 Calculates and maintains the forwarding table and distributes it to the local CPU, and then to Packet Forwarding Engines
(PFEs) in all member switches; Receives and transmits routing information
 Shares Virtual chassis Configuration to Back-up & maintain Redundancy

Linecard:
These members contributes in multiplying Physical attributes:
 Detects switch error conditions, such as an unplugged cable, on any interfaces that have been configured on it through the
master switch and relays this information to the master switch
 Receives updates about forwarding information from the master switch and programs these updates into the local PFE
 Acquires Back-up’s task on outage

For more information on these roles, refer to Understanding Virtual Chassis Components.

Verify that Virtual Chassis is in a healthy state, and troubleshoot if it is not

Below is a Troubleshooting Guide which verifies that a Virtual Chassis is in a healthy state and rescues an unhealthy Virtual Chassis.

A Virtual Chassis can be identified as 'healthy' based on the roles and the status shown in the show virtual chassis
status output. 

In this article, the definition of a healthy Virtual Chassis is as follows:

 A Virtual Chassis is considered healthy with a minimum of two members: Master and Backup, where one member will act as
Master and the other member will be the Backup Routing Engine.
 A Virtual Chassis can have a maximum of 10 members, where the rest of members have a role of Linecard.
 All the members must have a status of Prsnt
Perform the following steps:

  Run the command 'show virtual chassis status':

root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

Member ID for next new member: 3 (FPC 3)

Do you see both a 'Master' and a 'Backup' with the status Prsnt?

 Yes - Continue to Step 2
 No   - Jump to Step 4

  If you have Linecards, do you see all the Linecard members with the status Prsnt?
 Yes - Continue to Step 3
 No -  Jump to Step 4

 Since all the members are present, your Virtual Chassis is active. Sometimes administrators want a designated member
to be the master. Is your expected master currently the master?
 Yes - At this point your Virtual Chassis is in a healthy state, as all the members have a status of Prsnt.  

Tip: It is strongly recommended to enable GRES on your VC. For more information, see KB21368 - GRES FAQ for EX Virtual
Chassis.
You may also want to perform the following check on the VCPs:  Verifying That the Virtual Chassis Ports (VCPs) Are Operational.
 Doesn’t Matter - At this point your Virtual Chassis is in a healthy state, as all the members have a status of Prsnt.  

Tip: It is strongly recommended to enable GRES on your VC. For more information, see KB21368 - GRES FAQ for EX Virtual
Chassis.
You may also want to perform the following check on the VCPs:  Verifying That the Virtual Chassis Ports (VCPs) Are Operational.

 No - Refer to KB21161 - Converting a Virtual Chassis Member Role to Master.

  What is the status of the member that is not in the Prsnt state?

 Inactive    – Go to Step 5
 Not-Prsnt – Go to Step 7
 Unprvsnd – Go to Step 11

 [Member is Inactive] Run the command ‘show version’.

Typically when a member is inactive, all the members of the switch are not running the same Junos version. This command will
display the Junos version for all the members which are physically connected (including Present and Inactive members). 

{master:1}[edit]
root@EX4200-VC# run show version 
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-48t
JUNOS Base OS boot [11.1R1.10]
JUNOS Base OS Software Suite [11.1R1.10]
JUNOS Kernel Software Suite [11.1R1.10]
JUNOS Crypto Software Suite [11.1R1.10]
JUNOS Online Documentation [11.1R1.10]
JUNOS Enterprise Software Suite [11.1R1.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.1R1.10]
JUNOS Routing Software Suite [11.1R1.10]
JUNOS Web Management [11.1R1.10]

fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10]
JUNOS Online Documentation [10.2R3.10]
JUNOS Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]

fpc2:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10] JUNOS Online Documentation [10.2R3.10] JUNOS
Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]

Are the Junos versions of all the Members the same?

 Yes – If member is still isolated from the Virtual Chassis, collect the information in KB20569, and open a case with your
technical support representative.
 No – The member is Inactive because of a Junos version mismatch. To make the Inactive member active, reinstall Junos
version to match the existing Virtual Chassis Master. For step by step instructions, refer to KB21133 - How to make inactive Virtual
Chassis Member active.

  Then run the command ‘show virtual chassis status’ to see if the switch has joined the other members of the
Virtual-Chassis. Restart at Step 1 to verify the overall health.

 [Member became NotPrsnt or is missing from the Virtual Chassis.] NotPrsnt means loss of Physical connectivity.
Console into the affected switch to troubleshoot the issue. Run the command ‘show virtual-chassis status’.

What is the Role of that particular member?

 Isolated Switch reports Role as Linecard – Continue to Step 8
 Isolated Switch reports Role as Master – Continue to Step 10

 [Isolated switch reports the Role as Linecard.] Re-active the Virtual Chassis to make that switch a stand-alone switch by
running the following command:
root@EX4200-VC# run request virtual-chassis reactivate
Run the command ‘show virtual-chassis status’.  Now has the affected switch joined the other members of the
Virtual Chassis?
 Yes – Restart at Step 1 to verify overall health.
 No – Continue to Step 9

  Try rebooting the affected switch. Run the command 'show virtual-chassis status'. Now has the affected
switch joined the other members of the Virtual Chassis?
 Yes – Restart at Step 1 to verify overall health.
 No – If member is still isolated from the Virtual Chassis, collect the information in KB20569, and open a case with your
technical support representative.

[Isolated Switch reports Role as Master but not joining existing Virtual Chassis]
For example, in the output below, FPC 0 (Expected Back-Up: BR0208233776) Reports Role as Master but the member is not joining
existing Virtual Chassis.
root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Master*

Member ID for next new member: 1 (FPC 1)

Perform the following steps if the switch is an isolated Master:

a. Confirm the Virtual Chassis cables are firmly seated. Then run the command 'show virtual chassis status' to
see if the switch has joined the other members of the Virtual Chassis. If so, restart at Step 1 to verify status.

b. Try a different Virtual Chassis cable. Then run the command 'show virtual chassis status' to see if the switch
has joined the other members of the Virtual Chassis. If so, restart at Step 1 to verify status.

c. Try performing a factory-default on the affected switch, FPC 0 (Expected Back-Up: BR0208233776),

root@Ex4200-VC# load factory-default

For more information, refer to KB11159 - Reverting to the Default Factory Configuration for the EX-series Switch . 

d. Then run the command ‘show virtual chassis status’ to see if the switch has joined the other members of the
Virtual Chassis. If so, restart at Step 1 to verify the overall health.
If still isolated, collect the information mentioned in KB20569, and open a case with your technical support representative.

 [Member became Unprvsnd (Not-provisioned)]

For example in the output below the expected Back-up (BR0208233776) became Not-Provisioned (Unprvsnd):

root@EX4200-VC# run show virtual-chassis

 Preprovisioned Virtual Chassis
Virtual Chassis ID: 6eb0.0094.e64b
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
Unprvsnd BR0208233776 ex4200-24f
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0

2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

The Unprvsnd status means that the member is interconnected with the Virtual Chassis, but is not specified in the preprovisioned
configuration file. 

Verify the Virtual Chassis Pre-Provisioning configuration is correct. In most of the cases, entering the serial number with the incorrect
case is the issue; the Pre-Provision configuration is case sensitive. 

Below is an example pre-provisioning configuration.  Note how the syntax for the serial number is incorrect.
set virtual-chassis preprovisioned
set virtual-chassis member 0 role routing-engine
set virtual-chassis member 0 serial-number br0208233776 <-----incorrect
set virtual-chassis member 1 role routing-engine
set virtual-chassis member 1 serial-number BR0209456997
set virtual-chassis member 2 role line-card
set virtual-chassis member 2 serial-number BR0208233803
set virtual-chassis member 3 role line-card
set virtual-chassis member 3 serial-number BR0209457019
For additional help with pre-provisioning, refer to the following examples in the Technical Documentation:
Example: Adding EX4500 Switches to a Preprovisioned Virtual Chassis 
Example: Configuring an EX4200 Virtual Chassis Using a Preprovisioned Configuration File

After correcting the pre-provisioning, run the command ‘show virtual-chassis status’.  Are any members still showing
the status Unprvsnd?
 No – Restart at Step 1 to verify the overall health
 Yes – If still Unprvsnd, collect the information mentioned in KB20569, and open a case with your technical support
representative

[EX] Fixing a Virtual Chassis Member with an 'Inactive' status

Avg. Rating:  1

 [KB21133] Show Article Properties

SUMMARY:
This article steps you thru how to reactivate an 'Inactive' Virtual Chassis Member.
This article is part of the EX Resolution Guide: KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members are not
all present.
SYMPTOMS:
Master and Back-up Members have a status of Present.  However, one of the members (FPC 0) reports the status as 'Inactive':
Virtual Chassis ID: 6eb0.0094.e64b
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID
Interface
0 (FPC 0) Inactive BR0208233776 ex4200-24f 128 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

Member ID for next new member: 3 (FPC 3)

How do you make the Inactive member active (where the status = Prsnt)?
 
CAUSE:
Typically when a member is Inactive, all the members of the switch are not running the same Junos OS version. The 'show version'
command will display the Junos version for all the members which are physically connected (including Present & Inactive members).
This is confirmed in the following 'show version' output.  In this example, FPC 0 is Inactive because of a Junos version mismatch:
{master:1}[edit]
root@EX4200-VC# run show version 
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-48t
JUNOS Base OS boot [11.1R1.10]
JUNOS Base OS Software Suite [11.1R1.10]
JUNOS Kernel Software Suite [11.1R1.10]
JUNOS Crypto Software Suite [11.1R1.10]
JUNOS Online Documentation [11.1R1.10]
JUNOS Enterprise Software Suite [11.1R1.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.1R1.10]
JUNOS Routing Software Suite [11.1R1.10]
JUNOS Web Management [11.1R1.10]

fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10]
JUNOS Online Documentation [10.2R3.10]
JUNOS Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]

fpc2:
--------------------------------------------------------------------------
Hostname: EX4200-VC
Model: ex4200-24f
JUNOS Base OS boot [10.2R3.10]
JUNOS Base OS Software Suite [10.2R3.10]
JUNOS Kernel Software Suite [10.2R3.10]
JUNOS Crypto Software Suite [10.2R3.10]
JUNOS Online Documentation [10.2R3.10]
JUNOS Enterprise Software Suite [10.2R3.10]
JUNOS Packet Forwarding Engine Enterprise Software Suite [10.2R3.10]
JUNOS Routing Software Suite [10.2R3.10]
JUNOS Web Management [10.2R3.10]
 
 

SOLUTION:
To make the 'Inactive' member active, reinstall Junos version to match the existing Virtual Chassis Master.
There are two ways to achieve this. Both methods are explained in detail below: 

Option 1. Re-install the same Junos OS version running on the active VC members to the inactive member.
Option 2. If this does not form the VC, isolate the inactive member from the VC and upgrade it individually, and then bring it back into
the VC. 

Option-1 - Upgrade the affected member without removing it from the VC 

For example, on a four member EX4300VC running 14.1X53-D30, all the VC members become inactive because one of the
members has a Junos OS version mismatch.
To recover the state, load the Junos image on the affected member to be the same as entire VC, and perform a reboot. The VC
comes up fine once done. 
{master:1}[edit]
root# run show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: e987.b14d.bcbe
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Inactive PE3715170046 ex4300-48t 129 Linecard N VC 2 vcp-255/1/0
1 vcp-255/1/1
1 (FPC 1) Prsnt PD3715220083 ex4300-48p 129 Master* N VC 0 vcp-255/1/0
3 vcp-255/1/1
2 (FPC 2) Inactive PE3715170221 ex4300-48t 0 Linecard N VC 3 vcp-255/1/0
0 vcp-255/1/1
3 (FPC 3) Inactive PE3715210118 ex4300-48t 0 Linecard N VC 1 vcp-255/1/0
2 vcp-255/1/1

root# run show version

fpc0:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]

fpc1:
----------------------------------------------------------- <---------- Affected
member
Model: ex4300-48p
JUNOS EX Software Suite [13.2X51-D26.2]
JUNOS FIPS mode utilities [13.2X51-D26.2]
JUNOS Online Documentation [13.2X51-D26.2]
JUNOS EX 4300 Software Suite [13.2X51-D26.2]
JUNOS Web Management [13.2X51-D26.2]
JUNOS py-base-powerpc [13.2X51-D26.2]

fpc2:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]

fpc3:
--------------------------------------------------------------------------
Model: ex4300-48t
JUNOS EX Software Suite [14.1X53-D30.3]
JUNOS FIPS mode utilities [14.1X53-D30.3]
JUNOS Online Documentation [14.1X53-D30.3]
JUNOS EX 4300 Software Suite [14.1X53-D30.3]
JUNOS Web Management Platform Package [14.1X53-D30.3]
JUNOS py-base-powerpc [14.1X53-D30.3]
After the upgrade and reboot:

{master:1}
root> show virtual-chassis

Preprovisioned Virtual Chassis

Virtual Chassis ID: e987.b14d.bcbe
 Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Prsnt PE3715170046 ex4300-48t 129 Backup N VC 2 vcp-255/1/0
1 vcp-255/1/1
1 (FPC 1) Prsnt PD3715220083 ex4300-48p 129 Master* N VC 0 vcp-255/1/0
3 vcp-255/1/1
2 (FPC 2) Prsnt PE3715170221 ex4300-48t 0 Linecard N VC 3 vcp-255/1/0
0 vcp-255/1/1
3 (FPC 3) Prsnt PE3715210118 ex4300-48t 0 Linecard N VC 1 vcp-255/1/0
2 vcp-255/1/1

Option-2 - Isolate affected switch, upgrade and put it back into the VC

Here is another way to recover the VC: 

Isolate the affected switch (the Inactive member) by unplugging the VCP cables.
Re-active the Virtual Chassis to make that switch a stand-alone switch by using command:
root@EX4200-VC> request virtual-chassis reactivate

Example output:

{Linecard:0}
root@EX4200-VC> show virtual-chassis

Virtual Chassis ID: 684e.e679.9f51

Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-48t 128 Linecard*

Member ID for next new member: 1 (FPC 1)

{Linecard:0}
root@EX4200-VC> request virtual-chassis reactivate

{master:0}
root@EX4200-VC> show virtual-chassis

Virtual Chassis ID: 684e.e679.9f51

Virtual Chassis Mode: Enabled
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-48t 128 Master*

Member ID for next new member: 1 (FPC 1)

Once the affected device been isolated as a stand-alone switch (Master role with 1 member), proceed with upgrading. Refer to KB20536 -
Upgrading EX series Devices.  
After a successful upgrade, re-connect the VCP cables.  It should then make FPC 0 an Active member:
root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership
Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 128 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 3 vcp-0

0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 3 vcp-1

Member ID for next new member: 3 (FPC 3)

 Once Active (status=Prsnt), if you prefer to have FPC 0 as a Backup, refer to KB21115 - Converting a Virtual Chassis Member Role
from Linecard to Backup.

To verify the health of your Virtual Chassis, refer to KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members
are not all present.

[EX] How to enable or disable the Virtual Chassis Port (VCP)

 [KB17821] Show Article Properties

SUMMARY:
This article provides information on how to enable or disable the Virtual Chassis Port ( VCP) on a Virtual Chassis (VC) member of EX
4200, EX 4500, and EX 8200 VC. 
SYMPTOMS:
 In a production environment, you may have to disable a virtual-chassis port for troubleshooting purposes.

 In a production or test environment, you can do the same when performing virtual -chassis active path failover.

 You can also disable the unused VCP ports for security reasons, to ensure that no unauthorized user can connect an EX
switch and make it a part of the virtual chassis.
CAUSE:

SOLUTION:
 To disable the Virtual Chassis Port on a standalone switch: 
root# run request virtual-chassis vc-port set interface vcp-0 disable
root# run request virtual-chassis vc-port set interface vcp-1 disable

 To disable the Virtual Chassis Port on a VC member (in this example, member 1):
root# run request virtual-chassis vc-port set interface member 1 vcp-0 disable
root# run request virtual-chassis vc-port set interface member 1 vcp-1 disable

 To enable a disabled Virtual Chassis Port on a standalone switch : 

root# run request virtual-chassis vc-port set interface vcp-0
root# run request virtual-chassis vc-port set interface vcp-1

 To enable a disabled Virtual Chassis Port on a switch, which is a part of the VC stack: 
root# run request virtual-chassis vc-port set interface member 1 vcp-0 
root# run request virtual-chassis vc-port set interface member 1 vcp-1 

 To disable the VCP port on a EX 8200 Virtual Chassis member:

user@external-routing-engine> request virtual-chassis vc-port set interface vcp-0
member 0 disable 
user@external-routing-engine> request virtual-chassis vc-port set interface vcp-0 member
1 disable 

 To enable the VCP port from EX 8200 Virtual Chassis Member:

user@external-routing-engine> request virtual-chassis vc-port set interface vcp-0 member
0
user@external-routing-engine> request virtual-chassis vc-port set interface vcp-0 member
1

 To disable the 10g LAG network port, acting as a VCP port, on a EX 8200 Virtual Chassis member:
user@external-routing-engine> request virtual-chassis vc-port set fpc-slot 4 pic-slot 0
port 1 member 0 disable
user@external-routing-engine> request virtual-chassis vc-port set fpc-slot 4 pic-slot 0
port 1 member 1 disable

 To enable the 10g LAG network port, acting as a VCP port, on the EX 8200 Virtual Chassis member:
user@external-routing-engine> request virtual-chassis vc-port set fpc-slot 4 pic-slot 0
port 1 member 0
user@external-routing-engine> request virtual-chassis vc-port set fpc-slot 4 pic-slot 0
port 1 member 1

[EX/QFX] How to view the diagnostics data and alarms for Optical VCP Interfaces
from all-member switches in a Virtual Chassis Fabric (VCF)
Avg. Rating:  1

 [KB29502] Show Article Properties

SUMMARY:
This article explains how to run the digital optical monitoring (DOM) scan on the optical ports configured as Virtual Chassis ports
(VCPs) and display the statistics. This article describes the two-step procedure to view the diagnostics on the optical VCP ports.

SYMPTOMS:
The procedure for viewing the diagnostics data and alarms output on optical VCP ports differs on VCF. If we run only the show
virtual-chassis vc-port diagnostics optics command, it will not display the diagnostics output. 

root@VCF# run show virtual-chassis vc-port diagnostics optics 

fpc0:
--------------------------------------------------------------------------
Virtual chassis port: vcp-255/0/100
Optical diagnostics : Not-Avail (run request)
Virtual chassis port: vcp-255/0/90
Optical diagnostics : Not-Avail (run request)

fpc1:
--------------------------------------------------------------------------
Virtual chassis port: vcp-255/0/100
Optical diagnostics : Not-Avail (run request)
Virtual chassis port: vcp-255/0/90
Optical diagnostics : Not-Avail (run request)

fpc2:
--------------------------------------------------------------------------
Virtual chassis port: vcp-255/1/0
Optical diagnostics : Not-Avail (run request)
Virtual chassis port: vcp-255/1/3
Optical diagnostics : Not-Avail (run request)

fpc3:
--------------------------------------------------------------------------
Virtual chassis port: vcp-255/0/48
Optical diagnostics : Not-Avail (run request)

CAUSE:
This is expected as we first need to run a diagnostics scan on the optical interface using a request command. Then we can see
the results of the scan using the show command.
On VCF, the request virtual-chassis vc-port diagnostics optics command must be entered to run a diagnostic
scan before you can gather the show virtual-chassis vc-port diagnostics optics output. This command was
introduced in Junos OS Release 13.2X51-D20 for Virtual Chassis Fabric (VCF).

SOLUTION:
1. Use the following request command to run a digital optical monitoring (DOM) scan on the optical ports configured as
Virtual Chassis Ports (VCPs).

request virtual-chassis vc-port diagnostics optics all-members 

2. Use the following show command to display diagnostics data and alarms for Ethernet optical transceivers installed in ports
configured as Virtual Chassis Ports in VCF.

show virtual-chassis vc-port diagnostics optics output

Example
{master:0}[edit]
root@VCF# run request virtual-chassis vc-port diagnostics optics all-members fpc0:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

fpc1:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

fpc2:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

fpc3:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

fpc4:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

fpc5:
--------------------------------------------------------------------------
vc-port Diagnostics Optics Done (run show)

{master:0}[edit]

root@VCF# run show virtual-chassis vc-port diagnostics optics all-members

fpc0:
--------------------------------------------------------------------------
Virtual chassis port: vcp-255/0/100
Module temperature : 32 degrees C / 90 degrees F
Module voltage : 3.2820 V
Lane 0
Laser bias current : 6.420 mA
Laser receiver power : 0.000 mW / - Inf dBm
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser receiver power high alarm : Off
Laser receiver power low alarm : On
 Procedure for debugging Virtual Chassis (VC) related issues

 [KB12696] Show Article Properties

SUMMARY:
This procedures describes the step-by-step procedure and approach to debugging Virtual Chassis (VC) related issues.
SYMPTOMS:

SOLUTION:
1. Verify the output of 'show virtual-chassis' status and check if all members are being shown correctly.
2. Verify the output of 'show virtual-chassis protocol adjacency' and check if state to all interfaces is up.
3. Make sure all the main daemons are running on *all* the EX 4200's. The list of daemons that must run are;  vccpd,
chassism, sfid, pfem
4. All consoles should go to master, just make sure you are on the master by executing 'sysctl
hw.re.mastership' command on shell. The output should show 1.
5. 'show virtual-chassis status' - should show a formed virtual chassis. If not, the cables are not properly
connected or 'chassism' has a problem and is not indicating the interface status correctly.
6. 'show virtual-chassis protocol adjacency' to see if the adjacencies corresponding to the stack
interfaces are up. On the linecard, enter 'lcdd <slot> vccpd' to go to debug prompt. Then issue 'show vccpd
adjacencies' to show the same output.
7. If the adjacencies are not up or are flapping, then the packet transfer through sfid is not processing correctly. Try killing sfid
process to see if the problem clears.
8. Next step is to make sure the linecard daemons connect to the master.  'netstat' on shell command should show active
connections - we are only interested in TNP connections, there should be 6 connections in OPEN state for each linecard.  If you do
not see them, then try 'tnping 1' on all the boxes. If this fails, do 'ifconfig bme0', to make sure there is a tnp address 16+slot
on all the boxes. For example if the slot number is 0, then tnp address 16 show as follows:
root@user% ifconfig bme0
bme0: encaps: ether; framing: ether
flags=0x3/0x8000 <PRESENT|RUNNING>
curr media: i802 0:b:ca:fe:0:0
bme0.32768: flags=0x0 <UP|MULTICAST>
inet primary mtu 1558 local=128.0.0.1 dest=128.0.0.0/2 bcast=191.255.255.255
a) local=128.0.0.16 dest=128.0.0.0/2 bcast=191.255.255.255
tnp primary mtu 1558 local=16
9. 'tnpdump' command shows the tnp neighbor table and there should be entries corresponding to all boxes in the stack.
10. Next, verify if all the ifds in the virtual chassis are showing up on the master using 'show interfaces terse'. If the interfaces
don't show up there is a problem with connectivity between chassisd, chassism [step 5] or there is a problem in chassisd or
chassism. Look at /var/log/chassisd for clues.
11. If the status of the interfaces [up/down] is not showing as expected then the problem is in the chassism.
12. Traffic debugging - This will essentially be same as that you currently do on a single box. One thing that is different is,
when you connect to pfem on a linecard box, you have to do 'vty <16+slot>' or 'vty fpc<n>' instead of 'vty
pfem'.
[EX] When will current MAC address change in a Virtual Chassis

 [KB17867] Show Article Properties

SUMMARY:
When will current MAC address change in Virtual Chassis
SYMPTOMS:
A customer asked why the MAC address is not changing after they do a switchover. This article describes when the MAC address
changes in a Virtual Chassis.

For information on the MAC address assignment, refer to KB17866 - EX Switch - MAC address assignment in a Virtual Chassis (VC).
SOLUTION:
A MAC address is selected as system MAC base for the virtual chassis. Initially the MAC address of the master is chosen as the
system MAC base. Once chosen, it serves as the system MAC base for the virtual system, as long as the member which contains
this MAC base is part of the VC in any role (Master, Backup, Linecard).

Once the member whose MAC address is being using as system MAC leaves the VC, the current master's MAC address is chosen
as the new system MAC base and all interfaces are reconfigured with new MAC address.

Once the selection is over, the Master pushes the MAC address to all the members as they joined the VC. Every time a member
 leaves, the MAC persistence timer is started and when it expires, the Master checks if the MAC address belongs to VC; if not, it
chooses its own MAC as system MAC and informs all the members.

The default MAC persistence Timer is set to 10 minutes, it can be changed by "set virtual-chassis mac-persistence-timer" commands
as below:

lab@EX4200-24T# set virtual-chassis mac-persistence-timer ?

Possible completions:
<timer> MAC persistence time (minutes) <---
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups

The current MAC address in a Virtual Chassis system will be changed only under the following conditions:
1. The member who has the system base MAC address leaves the VC AND
2. More than 10 minutes (or the value set as mac-persistence-timer) has passed since the member is removed from the VC
After that, the new master's mac address will be selected as system MAC base address for the virtual chassis.

How to collect logs from each member of an EX8200 virtual-chassis (XRE200)

 [KB23584] Show Article Properties

SUMMARY:
This knowledge base article explains one of the ways to collect logs from each member of the EX8200 Virtual Chassis.
Master/Backup XRE, Routing-engine/(s) of member switches (EX8200 with single/dual routing-engines)
SYMPTOMS:
Typically it would be sufficient to collect logs from the following members on an EX8200 Virtual Chassis setup.  However, this article
includes how to log into the line cards of member switches(EX82XX) if required. 

1. Master XRE 
2. Backup XRE
3. Master routing-engine of EX82XX
4. Backup routing-engine of EX82XX 
CAUSE:
 
SOLUTION:
1. Log into the master XRE and check the virtual-chassis topology to identify each member and its member ID. 

{master:8}
root@XRE200-LC-DC-XRE1> show virtual-chassis 

Preprovisioned Virtual Chassis

Virtual Chassis ID: 5f3d.2290.b587
Virtual Chassis Mode: Enabled

                                                                                                              Mastership                         Neighbor               List 

Member ID           Status              Serial No            Model                priority            Role               ID                   Interface
0 (FPC 0-15)        Prsnt            BA0911152292    ex8216                    0             Linecard            8                   vcp-0/0
                                                                                                                                                                  1                   vcp-14/0/6 
                                                                                                                                                                  1                   vcp-14/0/7 
                                                                                                                                                                  1                   vcp-6/0/6 
                                                                                                                                                                  1                   vcp-6/0/7 
1 (FPC 16-31)     Prsnt              BA0909250255   ex8216                    0             Linecard            9                   vcp-0/0
                                                                                                                                                                  8                  vcp-0/1 
                                                                                                                                                                  0                  vcp-14/0/6 
                                                                                                                                                                  0                  vcp-14/0/7 
                                                                                                                                                                  0                  vcp-6/0/6 
                                                                                                                                                                  0                  vcp-6/0/7 
8 (FPC 128-143) Prsnt             122010000100    ex-xre                      129         Master*             0                 vcp-0/0 
                                                                                                                                                                  9                 vcp-1/0 
                                                                                                                                                                  1                 vcp-1/1 
9 (FPC 144-159) Prsnt             122010000078     ex-xre                     129         Backup              1                 vcp-0/0 
                                                                                                                                                                  8                 vcp-1/0
 2. Enter the following command to archive the /var/log directory of master XRE. 
 In this example member 8 is the master XRE. The following command will zip (tar) the folder "/var/log" and name the file
(LOGS-MASTER-XRE.tar). It also pushes the zipped file to the master XRE's destination folder "/var/tmp".
{master:8}
root@XRE200-LC-DC-XRE1>file archive source /var/log destination member8:/var/tmp/LOGS-MASTER-XRE

3. Log into the Backup XRE

In this example member 9 is a backup XRE. 

{master:8}
root@XRE200-LC-DC-XRE1> request session member 9 

root@XRE200-LC-NC-XRE1:BK:9% cli
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.

4. Enter the following command to archive the /var/log directory of the backup XRE. 

The following command will zip (tar) the folder "/var/log" and name the file (LOGS-BACKUP-XRE.tar). It also pushes the zipped file to
the Master XRE's destination folder "/var/tmp". 

{backup:9}
root@XRE200-LC-NC-XRE1>file archive source /var/log destination member8:/var/tmp/LOGS-BACKUP-XRE

5. Type 'exit' to close the backup XRE(member 9) session and go back to master XRE(member 8).

{backup:9}
root@XRE200-LC-NC-XRE1> exit 

root@XRE200-LC-NC-XRE1:BK:9% exit
rlogin: connection closed

{master:8}
root@XRE200-LC-DC-XRE1>  

6. Login to member 0 from Master XRE and collect logs from member0-re0. 

The contents of the entire /var/log folder of member 0's master routing-engine will be zipped and pushed to master XRE's /var/tmp
folder.

{master:8}
root@XRE200-LC-DC-XRE1> request session member 0 
root@:RE:1% cli
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{master:1}
root> file archive source /var/log destination member8:/var/tmp/LOGS-MEM0-RE0

7. Login to backup RE of member 0. 

The contents of the entire /var/log folder of member 0's backup routing-engine will be zipped and pushed to master XRE's /var/tmp
folder.

root> request routing-engine login backup

root@:BK:0% cli
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{backup:0}
root> file archive source /var/log destination member8:/var/tmp/LOGS-MEM0-RE1
 8. Repeat steps 6 & 7 for other members of the FIXX. 

This way you will have all the logs copied to the master XRE /var/tmp folder.

master:8}
root@XRE200-LC-DC-XRE1> file list /var/tmp/ 

/var/tmp/:
.snap/
LOGS-BACKUP-XRE.tar
LOGS-MASTER-XRE.tar
LOGS-MEM0-RE0.tar
LOGS-MEM1-RE0.tar
LOGS-MEM1-RE1.tar
LOGs-MEM0-RE1.tar

9. You can run the following command from any member in case you are required to login to the individual FPCs of the
EX8200s. 

In this example, we are logging into fpc2 of member 0 from master XRE. 

root@XRE200-LC-DC-XRE1:RE:8% rlogin -Ji member0-fpc2

root@fpc2%

10. You can run the following command to copy any file from the line card's FPC to master XRE. 

In this example we are copying a file named 'test1.txt' from member 0 - FPC2 - to the master XRE /var/tmp folder.  
root@fpc2% rcp -Ji /var/tmp/test1.txt member8:/var/tmp/

11. Copy all the archived logs from Master XRE's /var/tmp folder to your PC or another source. 

For more details on this check out the 'Export the Archive Logs' section from the KB20569

[EX] Converting a Virtual Chassis Member Role to Master

 [KB21161] Show Article Properties

SUMMARY:
This article assists you with converting a Virtual Chassis member role to Master. It will help the user who prefers to change any
member in a Virtual Chassis to a Master role.
This article is part of the EX Resolution Guide: KB21064 - Verifying health of Virtual Chassis and troubleshoot if the members are not
all present.

SYMPTOMS:
 How do I change a member to a Master?
 I want to change my Linecard member to a Master Role.
 I want to change my Backup member to Master Role .
 A different member is preferred to be Master.
For example, in the 'show virtual-chassis' output below, FPC 0 - (BR0208233776) is preferred to act as Master.
root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 127 Linecard 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Master* 2 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Backup 1 vcp-1

Member ID for next new member: 3 (FPC 3)

SOLUTION:
 Increase the mastership-priority of the existing Linecard or Backup to be a  higher value than that of the current Master.

Important: During a change-over of mastership role, a network outage may occur due to a Routing Engine failover. Juniper
recommends making these changes during a maintenance window .

In the example above, the mastership-priority of Member FPC 0 is made higher than the current Master Member FPC 1 with the
following command:
root@EX4100-VC# set virtual-chassis member 0 mastership-priority 129
After changing the mastership-priority, a commit synchronize needs to be executed:
root@EX4100-VC# commit synchronize

Refer to KB12879 for additional information on commit synchronize.

The end result will be as follows:

root@EX4200-VC# run show virtual-chassis

Virtual Chassis ID: 6eb0.0094.e64b

Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BR0208233776 ex4200-24f 129 Master* 1 vcp-0
1 (FPC 1) Prsnt BR0209456997 ex4200-24f 128 Backup 2 vcp-0
0 vcp-1
2 (FPC 2) Prsnt BR0208233803 ex4200-24f 128 Linecard 1 vcp-1

Member ID for next new member: 3 (FPC 3)

For more information on understanding the Mastership Election process in a Virtual Chassis before making a new member as
Master, refer to the following Techincal Documentation: 
Understanding How the Master in a Virtual Chassis Is Elected 

Removing a Router from a Virtual Chassis Group

SUMMARY:
Deleting the member ID of a member router in an MX Series Virtual Chassis configuration effectively disables Virtual Chassis mode
on that member router. To delete the member ID, use the request virtual-chassis member-id delete administrative command.

SYMPTOMS:
Deleting the member ID of a member router in an MX Series Virtual Chassis configuration effectively disables Virtual Chassis mode
on that member router. To delete the member ID, use the request virtual-chassis member-id delete administrative command.

Note, the references to RE Mastership roles in this document refer to local Routing Engine (RE) mastership in a single chassis and
not to Protocol Role (VC-M, VC-B, etc.). 

Before you delete the member ID, make sure all of the following requirements are met:
 For member routers with dual REs the following criteria must be met:
o Both REs must be online
o RE mastership must be established.
 The chassisd daemon on both Routing Engines must be exchanging messages.
If these requirements are not met, the software rejects the request virtual-chassis member-id delete command with a negative
acknowledgement (NACK), and the member router remains in Virtual Chassis mode.

Configuration and Behavior

When you delete a member ID by issuing the request virtual-chassis member-id delete command, the software performs the following
actions on the member router:
1. Invalidates the deleted member ID in the SCB EEPROM
2. Deletes the private configuration files in the /config/vchassis directory
3. Synchronizes the information to the standby Routing Engine
4. Reboots the member router
SOLUTION:
To force deletion of the member ID when the master and backup (standby) Routing Engines in a Virtual Chassis member router are
not communicating, you can issue the request virtual-chassis member-id delete force command. The force option is hidden in the
 CLI.

Example:
In an MX Series Virtual Chassis configuration in the field, the standby Routing Engine in a member router is unresponsive. The
system administrator wants to delete the member ID on this router to disable Virtual Chassis mode, but the software rejects (NACKs)
the request virtual-chassis member-id delete command, and the member router remains in Virtual Chassis mode.

regress@fmd> request virtual-chassis member-id delete This command will disable virtual-
chassis mode and reboot the system. Continue? [yes,no] (no) yes error: Command aborted.
Backup RE is unreachable, unable to synchronize VC configuration.
Attempts to bring the unresponsive Routing Engine back online are unsuccessful, and no one is available onsite to remove the faulty
Routing Engine module from the chassis.

To resolve this problem and force deletion of the member ID on the member router, you can issue the request virtual-chassis
member-id delete command with the hidden force option. 

regress@fmd> request virtual-chassis member-id delete force

Updating VC configuration and rebooting system, please wait...

{master:member0-re0}
regress@caelum>
*** FINAL System shutdown message from root@caelum ***
System going down IMMEDIATELY

When you force deletion of a member ID by using the request virtual-chassis member-id delete force command, the software
performs the actions outlined in the “Configuration and Behavior” section. 

Observe the following guidelines when you use the request virtual-chassis member-id delete force command:
 Execute the command on the master RE.
 Do not attempt to use the force option when you issue the request virtual-chassis member-id set administrative command to
create a member ID on a Virtual Chassis member router. The hidden force option is available only for the request virtual-chassis
member-id delete command

[EX] Virtual Chassis behavior when a split occurs

SUMMARY:
This article provides information about the behavior of the Virtual Chassis, when a split occurs. 

SYMPTOMS:
Information about the behavior of the Virtual Chassis, when a split occurs.
CAUSE:

SOLUTION:
Virtual Chassis is a concept, in which multiple switches are stacked together to make them appear as a single switch. Up to 10
EX4200 switches can be interconnected via dedicated Virtual Chassis ports on each device or optional uplink module ports that
are configured as Virtual Chassis ports, with a combined backplane bandwidth of up to 128 Gbps.

Solutions that use the EX4200 line with Virtual Chassis technology combine the scalability and compact form factor of stand-
alone switches with the high availability, high backplane bandwidth characteristics and high port densities of traditional chassis-
based switches.

For resiliency and redundancy, the Virtual Chassis configuration includes a master and a backup switch; both dynamically
elected as part of the Virtual Chassis configuration. Each remaining switch serves as a line card switch; but is ready to be
selected as a backup switch, if the master or backup switch fails.

Outages when upgrading a Virtual Chassis:

There will be outage, because as in a Virtual chassis, multiple switches are stacked and made to work as a single switch; so the
code must be the same on all of the devices. It will not be possible to upgrade a particular member and then upgrade the rest; so
outage occurs, as the switch needs to be rebooted for the new code to be activated on it.

When Master switch fails:

------------------------------------------------------
| |
 | MASTER |
......................................................
| |
-------------------------------------------------------
| |.................... PC-
A
| BACKUP |
........................................................
| |
------------------------------------------------------
| |...................PC-
B
| LINE CARD |
........... ..........................................
In this scenario, all routes and the forwarding state information are maintained by the Master routing engine on enabling GRES.
If the Master switch reboots, then the Backup becomes the next Master switch and it presumes the forwarding traffic; but that
takes some down time. The range is from 4-7 RTO, if a continuous ping is performed from PC-A to PC-B.

The reason is that as the master goes down, the backup switch must become the master and the information must be
synchronized. Similarly, a new Backup must be elected.

When the Line Card fails:

 ------------------------------------------
|                                         |...........PC-A
|           MASTER                        | 
...........................................
        |                 |
--------------------------------------------
|                                          |..........PC-B
|           BACKUP                         | 
............................................
       |                  |
-------------------------------------------
       |                  |
       |    LINE CARD     | 
............................................
In this scenario, nothing happens, as the kernel state information and the forwarding state information are already present in the
Master routing engine and the PC is connected to the Master and the Backup switch.

Here, the linecard is disconnected and this does not cause any interruption for the continuous ping from PC A to PC B.

When the backup is disconnected:

-----------------------------------------
|                                       |................PC-A
|             MASTER                    | 
.........................................
           |             |
------------------------------------------
|                                        |
|             BACKUP                     | 
...........................................
           |             |
-------------------------------------------
|                                         |..............PC-B
|             LINE CARD                   | 
........................................... 
In this scenario, the backup is connected to the Line card and the Master switch and the backup are rebooted. Also, the Master
goes into a linecard’s position that detects a VC split.
 The reason why the Master routing engine takes up the role of a Linecard is to avoid the possibility of dual Master formation in
the topology, in the event of a VC split.

Complete outage will occur.

For this topology:

|.....................................|
| ----------------------------------|
| | |............... PC-A
| | MASTER |
| ...................................
| |
| -----------------------------------
| | |
| | BACKUP |
| ...................................
| |
| ----------------------------------
| | |..............PC-B
| | LINE CARD |
| ..................................
|......................|
For the topology, as depicted above, the VCP cables are connected in this format and two PCs are connected to the Master and
the linecard and if the backup switch reboots, then again, complete network outage will occur; as the Master detects the VC split
condition and it will take up the position of a linecard.

But, if split detection is disabled and even though the Backup switch is rebooted, the Master stills remain the Master and the
packet flows through; without any drops.

The packet flow in a VC is completely dependent on the lowest cost path to the destination. if a ping is performed from PC-
A to PC-B, the packet has two routes to reach the destination; one is via the Backup switch and the other is directly to the
linecard. It will prefer the least cost path, which is the link that connects the linecard and the Master together.

So, if the Backup switch is rebooted, the packet will still continue to flow through the same link and packet loss will not occur.
The question regarding physical disconnect of the LAN cable is not possible, as the link will remain intact; as long as the unit, to
which the PC is connected, is not rebooted.
The deployment of the switches in the stack requires a proper understanding of the above information, so that the minimum
interruption of traffic might occur
[EX] Error reported with Virtual Chassis Preprovisioning
Avg. Rating:  2

 [KB17854] Show Article Properties

SUMMARY:
Virtual Chassis preprovisioning is case sensitive.
SYMPTOMS:
The following commands were performed to configure preprovisioning:

{master:0}[edit]
root# set virtual-chassis preprovisioned member 0 role routing-engine serial-number
bm0208405987

However, when trying to commit, the following error is reported:

{master:0}[edit]
root# commit check 
[edit virtual-chassis]
'member'
Member's information missing from provisioning database
error: configuration check-out 

SOLUTION:
This error is because the serial number is case sensitive, so the serial number needs to be configured as it is shown in the show
virtual-chassis output.

{master:0}[edit]
root# set virtual-chassis preprovisioned member 0 role routing-engine serial-number
BM0208405987

This will resolve the issue.