Virtual Chassis Fabric – Part I – Overview

In this post I will cover the basics of Virtual Chassis Fabric technology that Juniper recommends to deploy small and medium-sized datacenters.

Virtual Chassis Fabric(VCF) allows to build a plug-and-play Ethernet fabric that scales up to 32 members and provides deterministic latency and over-subscription with an internal 3-stage Clos topology.

A VCF is constructed using a spine-and-leaf architecture. In the spine-and-leaf architecture, each spine device is interconnected to each leaf device. A VCF supports up to 32 total devices and up to four devices can be configured as spine devices.

The middle stage crossbar switch from the Clos architecture is the spine switch and ingress/egress crossbar switches from the Clos architecture are the leaf switches.

Let’s see few key points like architecture, components, member roles, provisioning, comparison with Virtual chassis and best practices.

VCF Architecture

• Each leaf is connected to each spine(this means that each leaf is always two nodes away from the other leaf nodes and that there are multiple paths between two leaf nodes)
• No physical connection between spine nodes(spine to spine traffic has to go through leaf nodes)
• The traffic is automatically load balanced across the multiple paths resulted from point 1
• The unicast traffic take the same path based on a hashing algorithm

VCF Components:

• Spine node:
  • Has to be QFX5100
  • At least two and up to four spine nodes(although a VCF can be built with only one spine node)
  • Is directly connected to every leaf node
  • Recommended to be configured as Routing Engine(although you can configure four spine nodes as Routing Engines, only two Routing Engines are active at the time)
  • Recommended to connect it to a router
• Leaf node:
  • Can be a QFX5100, QFX3500 or EX4300
  • Connected to end devices: servers, PCs
  • Connected to every spine node
  • Typically configured as linecard

Member Roles:

• Routing Engine(RE): recommended to be a spine node
  • Master RE:
    • Must be a spine node
    • Manages the member devices
    • Controls the protocols
  • Backup RE:
    • Synchronizes with the master RE in terms of forwarding and protocols states for a RE failover without service impact
• Line card:
  • Any node that do not assume the role of Routing Engine
  • Runs a limited subset of Junos
  • Detects error conditions on the interfaces configured
  • Can be a spine node
  • If it is a spine node, it performs all spine related functions without any limitation

VCF Provisioning

There are three provisioning options :

• Pre-provisioned
  • All nodes are pre-provisioned
  • Static assignment roles for each node
• Auto-provisioned
  • Pre-provision only the spine nodes
  • Leaf nodes will join VCF automatically
• Non-provisioned
  • VCP enabled and RE election algorithm decides the roles for the nodes

VCF and VC

• Why VCF is similar to VC:
  • Uses VCCP to discover the topology
  • Supports pre-provisioned and non-provisioned modes of enablement
  • Console and IP connections are redirected to the master RE
  • When there are multiple links between two nodes, the links are placed automatically in a LAG
• Why VCF is different than VC:
  • Can support up to 32 members
  • Uses spine and leaf concepts instead of ring topology
  • When multiple paths exist between members, then the traffic is balanced between the paths
  • Supports auto-provisioned mode

VCF Best Practices

• Spine nodes should be QFX5100
• RE roles should be assigned only to spine nodes
• All spine nodes should be configured as RE
• All leaf nodes should be configured as line cards
• Every leaf node should be connected to every spine node
• Use same types of interface speeds for VCP
• Use two or four spine nodes

And this is an overview of Virtual Chassis Fabric and now you should know the key components and how it is similar and different in the same time than the Virtual Chassis.

The following two tabs change content below.

• Bio
• Latest Posts

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Latest posts by Paris ARAU (see all)

• Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
• Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
• Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
• Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
• Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018