- play_arrow Virtual Chassis Configuration
- Virtual Chassis Cabling
- Configuring an EX2300, EX3400, EX4100, EX4100-F, EX4300, or EX4400 Virtual Chassis
- Configuring EX4600 Switches in a Mixed or Non-Mixed Virtual Chassis
- Configuring an EX4650 or a QFX Series Virtual Chassis
- Adding a New Switch to an Existing EX2300, EX3400, EX4300, or EX4400 Virtual Chassis
- Adding an EX4600 Switch to a Mixed or Non-mixed Virtual Chassis
- Adding a New Switch to an Existing EX4650 or QFX Series Virtual Chassis
- Removing or Replacing a Member Switch of a Virtual Chassis Configuration
- Configuring Primary Role of a Virtual Chassis
- Configuring the Timer for the Backup Member to Start Using Its Own MAC Address as Primary of a Virtual Chassis
- Setting an Uplink Port on an EX Series or QFX Series Switch as a Virtual Chassis Port
- Disabling Split and Merge in a Virtual Chassis
- Configuring Automatic Software Update on Virtual Chassis Member Switches
- Assigning the Virtual Chassis ID to Determine Precedence During a Virtual Chassis Merge
- Configuring Graceful Routing Engine Switchover in a Virtual Chassis
- play_arrow Virtual Chassis Routine Monitoring and Troubleshooting
- Command Forwarding Usage with EX Series and QFX Series Virtual Chassis
- Verifying the Member ID, Role, and Neighbor Member Connections of a Virtual Chassis Member
- Verifying That Virtual Chassis Ports Are Operational
- Verifying That Graceful Routing Engine Switchover Is Working in the Virtual Chassis
- Troubleshooting an EX Series Virtual Chassis
- play_arrow Upgrading Software on a Virtual Chassis
- Understanding Software Upgrades in a Virtual Chassis
- Upgrading a QFX5100 Switch with a USB Device to Join a QFX5110 Virtual Chassis or Virtual Chassis Fabric
- Understanding Nonstop Software Upgrade on a Virtual Chassis and Mixed Virtual Chassis
- Configuring Line-Card Upgrade Groups for Nonstop Software Upgrade
- Upgrading Software on a Virtual Chassis and Mixed Virtual Chassis Using Nonstop Software Upgrade
- play_arrow Configuration Statements and Operational Commands
- play_arrow Knowledge Base
Understanding High Availability on an EX Series Virtual Chassis
You increase your network’s high availability (HA) when you interconnect a Juniper Networks EX Series Ethernet switch into a Virtual Chassis. A Virtual Chassis is more fault tolerant then a standalone EX series switch because it remains up when a single member switch fails, and provides sub-second convergence in the case of a device or link failure.
You can further improve HA by configuring the HA features available for your EX Series Virtual Chassis. You can, for instance, configure Link Aggregation Groups (LAG) bundles to include member links on multiple member switches in the same Virtual Chassis. This configuration increases fault tolerance because traffic traversing the LAG can be redirected to an active member switch when a single member switch fails.
A Virtual Chassis has dual Routing Engines—the switch in the primary role and the switch in the backup role—and therefore supports many HA features not supported on standalone EX Series switches, such as Graceful Routing Engine Switchover (GRES) for hitless failover. For information on which of the High Availability features listed in Table 1 are supported in your EX Series Virtual Chassis, see Feature Explorer.
Many HA features for the EX Series Virtual Chassis are designed to improve network resiliency after a Routing Engine switchover. Table 1 describes the effects of a Routing Engine switchover when no high availability features are enabled and when some High Availability features are enabled.
High Availability Feature | Effect of Routing Engine Switchover |
|---|---|
No HA features enabled | Kernel and forwarding state information is not preserved to the backup Routing Engine. A convergence process that requires all interfaces on the Virtual Chassis to be taken offline has to be performed before the Virtual Chassis returns online. The switchover can take several minutes and the Virtual Chassis does not send or receive traffic until the switchover is complete. |
Graceful Routing Engine switchover (GRES) enabled | Kernel and forwarding state information is preserved on both Routing Engines, so the convergence process does not occur and the switchover happens quickly with minimal traffic loss. |
Nonstop active routing (NSR), Nonstop bridging (NSB), or both enabled | Layer 2 protocols that are supported by NSB are not disrupted by a Routing Engine switchover when NSB is enabled. Layer 2 protocol information for all active Layer 2 protocols is stored on both Routing Engines when NSB is enabled. Layer 3 protocols that are supported by NSR are not disrupted by a Routing Engine switchover when NSR is enabled. Layer 3 protocol information for all active Layer protocols is stored on both Routing Engines when NSR is enabled. |
Graceful Protocol Restart enabled | Traffic is not interrupted during the switchover. Interface and kernel information is preserved. Graceful restart protocol extensions quickly collect and restore routing information for supported protocols from the neighboring devices. |
