Virtual Chassis Setup

These notes are for JunOS 12.3R3.4. You do not need an enhanced license to use Virtual Chassis on 12.3; I know that you do for some versions of JunOS 11.

Reading the relevant section in book-software-ex-series-123-all.pdf, particularly the example starting page 1927, is highly recommended.

Pre-setup notes:

• When two switches are joined together into a VC, the switch that has been up the longest becomes the master.
• When configuring the out-of-band management interface, define it as vme, not me. If you use me, all members of the stack will think that their physical management interface has the same IP address and you will (practically) never be able to talk to the only one that matters, the master. If you use vme, then only the current master will respond to the management IP; if that master switch dies, then the switch that takes over will respond to the management IP.

Setup

edit
set virtual-chassis member 0 mastership-priority 255
set virtual-chassis member 1 mastership-priority 255
set virtual-chassis no-split-detection
commit

Note: the no-split-detection is recommended for two-member VCs.

Reboot the next candidate switch to ensure it doesn't pick up member ID 0.

In this example we are going to use four vc-ports, ge-0/0/44 through /47. Adjust this example as required.

On each switch, including the master:

edit
delete interfaces ge-0/0/44
delete interfaces ge-0/0/45
delete interfaces ge-0/0/46
delete interfaces ge-0/0/47
commit
exit
request virtual-chassis vc-port set pic-slot 0 port 44
request virtual-chassis vc-port set pic-slot 0 port 45
request virtual-chassis vc-port set pic-slot 0 port 46
request virtual-chassis vc-port set pic-slot 0 port 47

As soon as you request virtual-chassis, the member switch will identify it as master:0, which it is -- it is effectively the master of a 1-member virtual chassis.

Once you have defined all the vc-ports, you can connect the switches together, vc-port to vc-port. I've only done two-switch VCs so far, so I would do port 44 to port 44, etc.

The switches will go off into space for a period of time, up to two minutes sometimes. After that, the master should respond on the vme address you assigned earlier. You can check your chassis configuration as so:

{master:0}
root@sa4-38> show virtual-chassis
Virtual Chassis ID: 54ba.174b.63b1
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    CU02xxxxxxxx ex2200-48t-4g 255 Master*   NA  1  vcp-255/0/44
                                                                 1  vcp-255/0/45
                                                                 1  vcp-255/0/46
                                                                 1  vcp-255/0/47
1 (FPC 1)  Prsnt    CU02xxxxxxxx ex2200-48t-4g 255 Backup    NA  0  vcp-255/0/44
                                                                 0  vcp-255/0/45
                                                                 0  vcp-255/0/46
                                                                 0  vcp-255/0/47

To see what vc-port is connected to what:

{master:0}
root@sa4-38> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
0/44        Configured          5    Up           1000         1   vcp-255/0/44
0/45        Configured          5    Up           1000         1   vcp-255/0/45
0/46        Configured          5    Up           1000         1   vcp-255/0/46
0/47        Configured          5    Up           1000         1   vcp-255/0/47
fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
0/44        Configured          5    Up           1000         0   vcp-255/0/44
0/45        Configured          5    Up           1000         0   vcp-255/0/45
0/46        Configured          5    Up           1000         0   vcp-255/0/46
0/47        Configured          5    Up           1000         0   vcp-255/0/47

Now you should be good to go.

Note that ports on fpc1 are ge-1/x/y instead of ge-0/x/y. Also note that by default these ports have no definition at all, so if you show configuration none of them will be listed; they are present though, you just have to configure them.

Failures

If a switch dies (ie by having its power inputs yanked) then the surviving member(s) of the chassis will deal with it. However in our experiments, the chassis goes off into space for about 60 seconds, during which time no packets flow anywhere.

When you bring the failed switch back:

• if the failed switch was configured so that it had a higher mastership priority than the active master, you get a master failback when you put it back in. This takes about 60 seconds, during which time no packets flow anywhere.
• if the failed switch has the same or lower mastership priority than the active master, the chassis just goes off into space for 20 seconds, again with no packet flow.
• if the failed switch is powered on and then returned into the chassis by reconnecting the vc-ports, this is the same as the initial connection of the switches and the chassis goes off into space for 60 seconds.

So on the EX2200 virtual chassis configurations are for management simplicity and for some redundancy; however they are not suitable for HA deployments where loss of network tone for up to 60 seconds is undesirable. If faster recovery is required, you are recommended to either look at EX4200/EX4500 switches, or step up to a real chassis switch. On the EX4200/EX4500 the mastership negotiation takes about 10 seconds; my understanding is that layer-2 operations continue to happen while the members negotiate master ownership.

My understanding is that the EX3300 virtual-chassis feature-set is between the EX2200 and EX4200/EX4500 feature set, but closer to the EX2200.

How Many VC-Ports Do I Need?

Dunno.

If you think about it, the vc-ports are being used to extend the switch's backplane between the fpc members. The vc-ports will always be slower than the backplane, so this ends up being a bottleneck between potential "local" port members.

I have not found any guides online that might direct this like of inquiry and Juniper support was very hand-wavey.

Here's why I picked four: I'm using this for redundancy on a VM cluster that has ae devices spread across the two fpc modules. Each VM host has a storage ae that is four wires, two to each fpc. My storage is two redundant filer heads, each with a four-port ae for storage traffic, also spread across fpc members. So I wanted to ensure that if a member fpc failed, I got a usable amount of traffic through the survivor. And I reasoned that the maximum amount of traffic that was likely to be crossing the vc-ports would total about 4Gb/s (due to the limitations of the NetApp filers on the back end) more than four would be overkill.

A better solution would be EX4500s with 10Gb line cards everywhere instead of ae'd ge devices, but I don't have that kind of budget.

Based on my experience with the virtual chassis for the VM cluster, I ended up doing the exact same thing when it came to building in redundancy into my concentrator switch -- four vc-ports connecting two switches.

Member Interaction

Going interactive with a stack member:

request session member $ID