Switching

 View Only
last person joined: yesterday 

Ask questions and share experiences about EX and QFX portfolios and all switching solutions across your data center, campus, and branch locations.
  • 1.  Master RE becomes Linecard when Backup RE is rebooted

    Posted 07-09-2010 03:44

    Running into an issue with a virtual chassis.  There are only 2 members in the VC and we have set the mastership priority of master to 255 and backup to 254.  If I reload the backup RE the master RE goes into lincecard but retains the 255 priority, all forwarding stops once this happens.  If I reload the master RE the backup RE becomes master and forwarding works as expected.

     

    Running on 10.2R1 and use VCP ports to stack.


    #ex4200
    #virtual
    #chassis


  • 2.  RE: Master RE becomes Linecard when Backup RE is rebooted
    Best Answer

    Posted 07-09-2010 04:36

    Seems this is due to the split detection mechanism built into JUNOS and becuase it is only a 2 member stack.

     

     
    Virtual Chassis Split
    In rare cases, Virtual Chassis configurations can be “split” when a single switch, cable or Virtual Chassis port in a chained topology fails, or when two or more adjacent switch members lose connectivity in a ring topology. Prior to Junos OS 9.3, such a split would initiate a new Master re-election process in each of the new segments, resulting in two or more identical, active Virtual Chassis configurations unaware of each other’s presence. This could create problems at the network level when, for example, each of the new Virtual Chassis segments contain the same routing information, resulting in two or more “routers” in the network with identical IDs, networks, advertisements, etc.
    To alleviate this problem, beginning with Junos OS 9.3, an enhancement option called Virtual Chassis “split-detection” has been added so that, following a Virtual Chassis split, no more than one segment would remain active and operational under the original configuration. All other segments created by the split are forced into an “inactive” Virtual Chassis state, with all switch members assuming a line card role with no Master or Backup. Users must either manually reload the factory default configuration on the inactive switch members or resolve the faults that caused the split (e.g. repair or replace the broken Virtual Chassis cables or member switches) before the switches can rejoin the active Virtual Chassis configuration. Beginning with Junos OS 9.3, Virtual Chassis split detection is enabled by default; for more details about Virtual Chassis split detection and split rules, please refer to the appropriate Juniper EX4200 switch product manual.
     
    While the Virtual Chassis split detection implementation is desirable in most cases, there are rare situations that could lead to all parts of a Virtual Chassis split being rendered inactive. For example, if a split occurs and the resulting segments have an equal number of Virtual Chassis members, the original Master and Backup switches do not fall into the same split segment, and the original Backup switch is part of the failure that triggers the split, the resulting split parts would have no “active” members. A real-world example of such a situation would be a two-member Virtual Chassis configuration. If the backup switch fails for some reason, the remaining Master switch would interpret this as a Virtual Chassis split and would put itself into an “inactive” state based on the Virtual Chassis split rules, bringing the entire Virtual Chassis down. In such cases, the Virtual Chassis split-detection option would not be desirable and should be disabled with the following CLI command:
    set virtual-chassis no-split-detection