http://www.juniper.net/techpubs/en_US/junos/topics/concept/virtual-chassis-mx-series-split-detection.html
Understanding Split and Merge in a Virtual Chassis Configuration
In a Virtual Chassis configuration, two or more EX 4200 series switches are connected together to form a unit that is managed as a single chassis. If there is a disruption to the Virtual Chassis configuration due to member switches failing or being removed from the configuration, the Virtual Chassis configuration splits into two separate Virtual Chassis. This situation could cause disruptions in the network if the two separate configurations share common resources, such as global IP addresses. The split and merge feature provides a method to prevent the separate Virtual Chassis configurations from adversely affecting the network and also allows the two parts to merge back into a single Virtual Chassis configuration.
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