Recently while working on a Juniper deployment, I configured three EX4500’s in a Virtual-Chassis configuration as the (temporary) distributed core of a temporary network for an event. I’ve detailed an easy configuration to get VC up and running using any of the 40x 10G interfaces. This allows you to use the appropriate optics and spread your switches over longer distances, be it at only 10G per link, however multiple links are supported natively on virtual chassis ethernet ports, so no need to configure link aggregation. The method I used this time is known as Nonprovisioned. This means that nodes can dynamically join & leave the VC stack.
Configure the SFP / SFP+ ports to be used as Virtual Chassis Ethernet Ports (VCEP). In my case I had two ports linking each switch in a triangle topology. *This command is issued in Operation Mode. Apply this to all switches operating in the VC stack.
> request virtual-chassis vc-port set pic-slot 0 port 36
> request virtual-chassis vc-port set pic-slot 0 port 37
> request virtual-chassis vc-port set pic-slot 0 port 38
> request virtual-chassis vc-port set pic-slot 0 port 39
Verify your port configurations at any time.
> show virtual-chassis vc-port
Choose the VC member that you would like to use as your Master Routing Engine (RE).
# set member 0 mastership-priority 255
Choose the VC member that you would like to use as your Back-Up RE (BK RE)
# set member 1 mastership-priority 250
Then configure the remaining switches as Line Cards (LC)
# set member 2 mastership-priority 128
Juniper has a great document explaining in more detail about configuring the mastership priority here if your looking for more information.
Now connect the switches once you have committed the configuration on each node. Once all the switches have established links, issue the following command to verify your Virtual Chassis configuration. The CLI output will be fairly obvious if your virtual chassis stack is running.
> show virtual-chassis
Set a virtual management interface for the VC stack. This will be available from any MGMT interface on any switch in your stack.
# set interfaces vme unit 0 family inet address 10.0.0.1/24
Remember to commit, however once you have established a virtual chassis, you will want to use the commit synchronize command to make sure all nodes commit the configuration change.
# commit synchronize
If your topology is like mine was, with only 2 – 3 switches acting as the core, high availability, fail-over speed & constant connectivity is critical. You may want to use the following command to guarantee the behavior of split detection. For more information regarding this, check Junipers documentation here.
# set virtual-chassis no-split-detection
# commit synchronize
To save typing commit synchronize every time in the future (as well as mistakes), there is an option to set the standard commit command to always synchronize across all nodes.
# set system commit synchronize
# commit synchronize (for the last time)