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

Juniper SRX High Availability (HA) & clustering: Part 2

In Juniper SRX High Availability (HA) & clustering: Part 1 I discussed the theory of the key terms and concepts used in configuring reth groups, fab links and clustering in general. In this part we actually dive deep into the actual configuration.

The broad steps that will be covered in this part:

1) Setting up control links
2) Setting up fab links
3) Creating a redundancy group
4) Configuring reth interfaces
5) Enabling clustering


Pre-config steps:

1) Make sure both SRX have the same junos.
2) Both have the same additional licenses configured

Control links

In SRX 550 and SRX 650 there can be only one control link. All the control plane data is synced over this link. In the aforementioned models ge-0/0/1 of the two SRX's have to be connected with each other.

When we enable clustering, the ge-0/0/1 of the secondary SRX will automatically reconfigure itself as ge-9/0/1, This is a hardcoded value and cannot be modified.

Fab links

To configure fab links, connect ge-0/0/2 of both the SRX. You can use any port except ge-0/0/0 and ge-0/0/1.

Remember that we have not enabled clustering yet. To do that run the following commands:

On SRX A: >set chassis cluster cluster-id 1 node 0 reboot 
On SRX B: >set chassis cluster cluster-id 1 node 1 reboot

Note: 1) This has to be run in operational mode and not in configure mode.
2) You cannot assign 0 as cluster-id. The range is 1 to 15

This will enable clustering and ge-0/0/0 will become fxp0 on both the SRX. This will be used for management traffic of both the SRX.

ge-0/0/1 of both SRX will become fxp1

All the interfaces in SRX - secondary will become ge-9/0/<> (in SRX 550 and 650)

If clustering has been successful running show chassis cluster status will display redundancy group 0 information.

At this moment it is important to understand the special role of redundancy group 0.

Redundancy group 0

You can define any number of redundancy groups. Each group has the SRX's with one acting as master and the other as backup. All the properties and objects associated with a redundancy group point to one master and one backup.

For example I can map a couple of interfaces with redundancy group 1 and specify SRX B as master. For a couple of other interfaces i can specify redundancy group 2 with SRX A as the master.

Redundancy group 0 has the routing engine. The active SRX in this redundancy group determines which SRX has an active routing engine. 

As soon as you enable clustering the redundancy group 0 becomes active and need not be configured. ( you can set the priority which will be discussed later)

Setting up fab links

Fabric links are responsible for carrying the transit traffic. For example, if an uplink from an SRX goes down it will seamlessly start sending traffic to the other SRX using this link.

It is advised to connect ge-0/0/2--> ge-9/0/2 and ge-0/0/3 --> ge-9/0/3. 

Yes, fab links can be bundled. Post configuration, one link acts to send internal messages while the other is used purely to send transit traffic.

set interfaces fab0 fabric-options member-interfaces ge-0/0/2 
set interfaces fab0 fabric-options member-interfaces ge-0/0/3
set interfaces fab1 fabric-options member-interfaces ge-9/0/2 
set interfaces fab1 fabric-options member-interfaces ge-9/0/3 

NOTE: fab0 will have one/two interfaces on SRX A and fab1 will have corresponding interfaces in SRX B. Unlike aggregation where an ae0 will have interfaces from two switches.

set chassis cluster redundancy-group 0 node 0 priority 100 
set chassis cluster redundancy-group 0 node 1 priority 1

Creating a redundancy group and reth interfaces

You can assign interfaces to a particular redundancy group. In this simple scenario, we will configure the downlinks to SRX as reth0 with redundancy group 1 and reth0 in redundancy group 1.

We can put both the reth interface in the same group if we want to.We will configure so that SRX A will have primary link as its downlink while SRX B will be the primary for reth1.

set chassis cluster redundancy-group 2 node 0 priority 100 
set chassis cluster redundancy-group 2 node 1 priority 1
set chassis cluster reth-count 2
set interfaces ge-2/0/1 gigether-options redundant-parent reth0  //assigning a physical port to reth0
set interfaces ge-11/0/1 gigether-options redundant-parent reth0 //assigning a similar port in SRX B to reth0
set interfaces ge-2/0/2 gigether-options redundant-parent reth1 
set interfaces ge-11/0/2 gigether-options redundant-parent reth1
set interfaces reth0 redundant-ether-options redundancy-group 0 //mapping reth0 to redundancy group 1
set interfaces reth1 redundant-ether-options redundancy-group 1 //mapping reth1 to redundancy group 1
set security zones security-zone trust interfaces reth0.0
set security zones security-zone untrust interfaces reth1.0

We have basically configure redundancy group 0 node 0 (ie SRX A) to be primary (higher priority leads), while for redundancy group 1 node 1 (SRX B) acts as primary.

Commit your changes and clustering is enabled

Traffic analysis

All the traffic from internal network will hit SRX A since it is the primary interface for downlink. To go out it will pass through fab link, to SRX B and exit from it. This is because we have configured SRX B to be the primary for the outbound link.

Our model SRX architecture

This is just a simple configuration and complexities can arise when the topology becomes complex. Moreover interesting features like link monitoring have not been discussed. This will form part 3 of this series.

Interesting links:

1) Juniper page SRX config

2)  KB based on SRX model

3) Interesting case on reth

4) Basic troubleshooting steps from Juniper
5) Clustering Part 1