Monday, April 20, 2015

Intro to Juniper's Virtual Chassis aka VC

In networking and system administration redundancy and high uptime is one of the most important requirements. I have already covered about SRX (Juniper's firewall) redundancy in a previous article(link at the end). This post helps to configure redundancy for a very important piece of network equipment- switch. Juniper provides an exciting feature called the Virtual Chassis (VC).

What is a Virtual Chassis?


Suppose you have a switch which is directly connected to the router. As the organisation grows the switch runs of ports. Another scenario will be a datacenter where you have servers in another rack. So now one has to buy another switch. All these servers are similar and need to be connected to the router. Traditionally one would need to have these independent switches connected to the router. Each switch will have its own management ip and connectivity.

But why should this be the case? Logically all switches are supposed to behave similarly. Why cannot we have a situation where we configure all the switches in such a way to make it work as one unit?  Under such a scneario all these switches across different racks function as one big logical unit. And this is the core tenet of a Virual Chassis. And on top of that you get additional features such as:

Additional features of Virtual Chassis (VC)


1) No layer-2 loop between different switches. (STP ceases to exist)
1) Single management ip
2) High capacity backplane (128 Gbps full duplex links)
3) Easier management and scalable

Juniper Virtual Chassis (VC) in Daisy Chain


This article will quickly go through the points mentioned. Refer to the diagram. If the switches were independent then connecting them will mean a chance for layer 2 loops which means a broadcast storm! Without VC enabled Sw1 connects to Sw2 which connects to Sw3, while Sw3 connects to Sw1 as well. This will mean STP will kick in and block a few ports. This is highly undesirable.

Again, when the switches are independent all of them will have a management ip which means managing them becomes a pain.

The links connecting all the switches have chances of failing bringing down the network

What if we end up having 8 or 10 such racks, each having a switch and needing interconnectivity? The topology becomes highly complex.

With Virtual Chassis, VC enabled all the switches behave as one switch. Hence there is no loop! All the switches have one management ip and all the member switches can be controlled from that single ip.

All the members are connected using dedicated links which give a 64 Gbps full duplex throughput (128 Gbps) giving robust interconnectivity between the switches. Since these are dedicated links they are much more reliable.

Even a 8 switch VC behaves like one logical unit and only one switch describes the topology.

This is a highly desirable feature which has been lauded by the network industry.

Virtual Chassis and its components


Virtual Chassis follows a Master Slave paradigm. In it, one switch acts as the Master member which runs the routing, firewalling and manages the control plane. Another switch acts as the backup which continuously synchs this data and keeps a copy. It becomes active when the active switch fails.

All the other switches run in the "line card" mode. These switches are dumb and DO NOT run the routing engine. They are responsible for switching the packets and act as line cards/ports of the mega logical switch. Think of those switches as just additional line cards/ports attached to the Master switch.

NOTE: Each switch regardless of master or line card state has a its PFE active.

VCP port/cable

Each EX 4200 and above have 2 vcp ports while in EX2200 a ge port needs to be configured as a vcp port. A VCP port is exclusively used by all the members of a Virtual Chassis to synch data with each other. There is a dedicated VCP cable available which gives high speed connectivity. The cables need to be connected in such a way that all the members have multiple connectivity so that even if a switch fails the path is not broken to other switches. There are two ways to achieve it- Braided ring and Daisy chain. This will be discussed in the next part of this series.

NOTE: The VC utilizes VCCP to make sure that there are no loops formed in VCP cable connectivity. Infact it uses ISIS protocol and assigns 128.x.x.x series ip to all member switches.

Traffic flow in a VC


Let us assume a 3 member Virtual Chassis. Switch0 is master, SW1 is backup and SW2 is in line card mode. The uplink is connected to SW2 on port 0. The virtual chassis is the gateway for all the devices connected to it. 

Note: The exact configuration will be discussed in another part

Scenario 1: Intra switch traffic

Suppose there is a server connected to SW2 and it wants to communicate with a server in SW1. The traffic flow works exactly the way it would assuming this is one mega switch. The SW2 on receiving this traffic will realise that the destination resides on the same switch and the path is via the VCP cable.

The packet will be forwarded through the VCP cable connecting SW2 and SW1. SW1 on receiving will then forward it to the appropriate egress port. 

Scenario 2: Inter switch traffic

Suppose the server now wants to connect to the internet. The packet will come to SW2 ingress port and if there is no route it will expected move to the routing engine which will reside on SW0, just the way it works for a single switch


Daisy Chained vs Braided Ring

Finally, let us move to two different type of topologies,

1) Daisy Chained


The above diagram is in daisy chain. It does not really provide any additional capabilities but comes with a certain limitation. Since the first and the last VCs have to be connected one needs to have a cable that is long enough to cover the distance. The longest cable in market is 5m long.
Thus the VC is constrained to 5 m in length, which is around 3/4 switch VC.

2) Braided Ring


In braided ring, the VC's connect themselves alternately which allows for longer VC members (the maximum allowed limit). The following diagram will help understand why.

Juniper's Virtual Chassis (VC) in braided ring


Quick facts:


1) EX 2200 does not have dedicated VCP ports
2) EX 4200 has a 64gbps (one way) VCP ports
3) You can extend a VC across locations (buildings/datacenters) using a concept called extended VC.


In the next article of this series, I will cover the actual configuration, and basic troubleshooting steps

Important Links:


1) Different Virtual Chassis components
2) In depth article on Virtual Chassis
3) Switch Design
4) HA for SRX
5) Juniper VC topolgies

3 comments: