The r/Juniper post is familiar: a preprovisioned three-member EX3400 Virtual Chassis is rebooted, and afterwards one member shows up as missing or as a linecard, with the rest of the fabric behaving strangely. Juniper documents this class of failure under split and merge — and knowing how the mechanism works turns a scary state into a routine fix.

What Split and Merge Actually Is

A Virtual Chassis presents several physical switches as one logical device with one master Routing Engine. If the VC interconnect (VCP) links fail in a way that isolates members into two groups, the VC splits: each side elects its own master and runs independently. When the VCP links heal, the two sides merge — and the losing master reloads its members to join the winner. Merge behavior, not voodoo, is also why a rebooted member sometimes comes back in an unexpected role.

Step 1: Establish Ground Truth

show virtual-chassis status
show virtual-chassis vc-port
show virtual-chassis mode

Read three things from the status output: how many members are present, who is Master/Backup/Linecard, and whether the member IDs match your preprovisioned virtual-chassis member stanzas. A member showing as NotPrsnt is absent from the ring entirely — cabling or boot problem. A member present but stuck as linecard is the classic preprovisioning mismatch.

Cause 1: Preprovisioned Serial Number Mismatch

In preprovisioned mode, membership is keyed to the serial number. If a replacement switch (RMA!) is inserted, its serial is unknown, and depending on auto-conversion and mixed-mode settings it either sits as linecard or fails to join at all:

show virtual-chassis status member 2
show configuration virtual-chassis

Fix: add the new serial to the correct member ID, or reassign the ID, then restart the member's chassis control:

request virtual-chassis renumber member 2 new-member 2
request virtual-chassis recycle member 2

Missing members after a reboot are usually a VCP problem, not a software one:

show virtual-chassis vc-port
show interfaces vcp-255/1/2 extensive

Every member should have two VCP links (a ring, not a line — the ring is what makes split detection possible). The community threads on EX3400 preprovisioned VCs with missing members usually end with a VCP cable seated in the wrong port pair or one end converted to a network port and never converted back. If a port lost its VCP conversion, reconvert it:

request virtual-chassis vc-port delete pic-slot 1 port 2 member 1
request virtual-chassis vc-port set pic-slot 1 port 2 member 1

Cause 3: Two Masters After a Split (Split Brain)

After a split, two masters may coexist with different configurations. When they merge, the winner is decided by masterity rules (configured priority, then uptime, then member ID). Verify who won and reconcile:

show virtual-chassis status
show virtual-chassis advertise

If the wrong side won, correct the routing-engine priority per member in virtual-chassis configuration and let the next election settle it. Juniper's split and merge documentation describes exactly these election rules.

Prevention: Design and Hardening

  • Always cable two VCP links forming a ring across members — split detection needs it.
  • Use preprovisioned configuration so member IDs are deterministic, and record serials for future RMAs.
  • Set distinct member 0/member 1 routing-engine priorities so election outcomes are predictable.
  • Never configure no-split-detection without understanding that it exists only for single-VC-port lab topologies; in production it invites exactly the two-master state you fear.

For the switching concepts beneath a VC (MAC learning across members, VLAN/VNI mapping), our EX MAC flapping and flooding guide covers the layer-2 side, and if your VC runs the EVPN-VXLAN leaf role described in the EX3400/EX4300 leaf configuration guide, a VC split will manifest as the overlay symptoms in the EVPN-VXLAN host ping troubleshooting method — check VC health first.