Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Control Path Resiliency and High Availability in a Virtual Chassis Fabric

This section discusses control path resiliency and high availability in a VCF, and includes the following sections:

Control Path Resiliency

VCF utilizes an in-band virtual backplane to carry fabric control traffic. The control plane software utilizes the built-in path resiliency to achieve control plane resiliency. VCF topologies can add multiple paths between any two nodes in the fabric by adding spine devices; for instance, a path from leaf node 1 to leaf node 2 has two paths when a VCF is using two spine devices, and four paths when a VCF is using four spines. VCF topologies should be created with the understanding that adding spine devices improves performance by providing multiple paths for traffic to travel and resiliency because additional paths remain available when a spine device fails.

Note:

You should not configure more than 64 VCPs on a single spine device.

Graceful Routing Engine Switchover (GRES)

VCF is a dual Routing Engine architecture that supports graceful Routing Engine switchover (GRES). GRES allows the backup Routing Engine to assume the primary Routing Engine role without interruption to packet forwarding if the primary Routing Engine fails.

GRES preserves interface and kernel information so that traffic is not interrupted during a switchover. GRES alone, however, does not preserve the control plane in the event of a primary Routing Engine failure. Other events, such as protocol timers expiring or neighbor relationships dropping, can happen during a routing engine switchover. These behaviors are mitigated using nonstop active outing (NSR) and nonstop bridging (NSB), which are supported for VCF.

See Configuring Graceful Routing Engine Switchover for additional information on GRES in a VCF.

Nonstop Software Upgrade (NSSU)

Nonstop software upgrade (NSSU) provides a mechanism for upgrading Junos OS on Juniper Networks EX and QFX Series Ethernet Switches in a VCF using a single command-line interface (CLI) command with minimal traffic disruption. For VCFs that support NSSU, the feature requires active redundant Routing Engines to successfully upgrade the VCF, and the VCF must be preprovisioned.

NSSU leverages the underlying high availability features such as GRES, NSR, and NSB to enable upgrading the Junos OS version running on a switch or in a VCF configuration with no disruption to the control plane and minor, sub-second interruption to the data plane. NSSU upgrades member switches individually, permitting traffic to continue to flow through the line card switches that are not being upgraded. By configuring link aggregation groups (LAGs) such that the member links reside on different member switches, it is possible to achieve little to no sub-second traffic disruption on your VCF when performing an NSSU.

See Understanding Nonstop Software Upgrade on a Virtual Chassis Fabric for additional information on NSSU in a VCF.