- play_arrow Understanding How Virtual Chassis Provides Interchassis Redundancy
- play_arrow Understanding How a Virtual Chassis Works
- play_arrow Configuring a Virtual Chassis
- Configuring Interchassis Redundancy for MX Series 5G Universal Routing Platforms Using a Virtual Chassis
- Preparing for a Virtual Chassis Configuration
- Creating and Applying Configuration Groups for a Virtual Chassis
- Configuring Preprovisioned Member Information for a Virtual Chassis
- Configuring Enhanced IP Network Services for a Virtual Chassis
- Configuring Enhanced LAN Mode for a Virtual Chassis
- Enabling Graceful Routing Engine Switchover and Nonstop Active Routing for a Virtual Chassis
- Configuring Member IDs for a Virtual Chassis
- Configuring an MX2020 Member Router in an Existing MX Series Virtual Chassis
- Switching the Global Primary and Backup Roles in a Virtual Chassis Configuration
- Deleting Member IDs in a Virtual Chassis Configuration
- Example: Replacing a Routing Engine in a Virtual Chassis Configuration for MX Series 5G Universal Routing Platforms
- Deleting a Virtual Chassis Configuration for MX Series 5G Universal Routing Platforms
- Example: Deleting a Virtual Chassis Configuration for MX Series 5G Universal Routing Platforms
- Upgrading an MX Virtual Chassis SCB or SCBE to SCBE2
- play_arrow Configuring Virtual Chassis Ports to Interconnect Member Devices
- play_arrow Configuring Locality Bias to Conserve Bandwidth on Virtual Chassis Ports
- play_arrow Configuring Class of Service for Virtual Chassis Ports
- play_arrow Configuring Redundancy Mechanisms on Aggregated Ethernet Interfaces in a Virtual Chassis
- Redundancy Mechanisms on Aggregated Ethernet Interfaces in a Virtual Chassis
- Configuring Module Redundancy for a Virtual Chassis
- Configuring Chassis Redundancy for a Virtual Chassis
- Multichassis Link Aggregation in a Virtual Chassis
- Targeted Traffic Distribution on Aggregated Ethernet Interfaces in a Virtual Chassis
- Understanding Support for Targeted Distribution of Logical Interface Sets of Static VLANs over Aggregated Ethernet Logical Interfaces
- play_arrow Upgrading Junos OS in a Virtual Chassis Configuration for MX Series 5G Universal Routing Platforms by Rebooting the Routing Engines
- play_arrow Upgrading Junos OS in an MX Series Virtual Chassis by Performing a Unified In-Service Software Upgrade (ISSU)
- play_arrow Upgrading Junos OS in an MX Series Virtual Chassis by Performing a Sequential Upgrade
- play_arrow Tracing Virtual Chassis Operations for Troubleshooting Purposes
- Tracing Virtual Chassis Operations for MX Series 5G Universal Routing Platforms
- Configuring the Name of the Virtual Chassis Trace Log File
- Configuring Characteristics of the Virtual Chassis Trace Log File
- Configuring Access to the Virtual Chassis Trace Log File
- Using Regular Expressions to Refine the Output of the Virtual Chassis Trace Log File
- Configuring the Virtual Chassis Operations to Trace
- play_arrow Configuration Statements and Operational Commands
Determining GRES Readiness in a Virtual Chassis Configuration
Depending on the configuration, a variable amount of time is required before a router or switch is ready to perform a graceful Routing Engine switchover (GRES). Attempting a GRES operation before the device is ready can cause system errors and unexpected behavior.
To determine whether the member routers or switches in a Virtual
Chassis configuration are ready for a GRES operation from a database
synchronization perspective, you can issue the request virtual-chassis
routing-engine master switch check
command from the Virtual
Chassis primary router or switch (VC-Pp) before you initiate the GRES
operation. Using the request virtual-chassis routing-engine master
switch check
command before you initiate the GRES operation
ensures that the subscriber management and kernel databases on both
member routers or switches are synchronized and ready for the GRES
operation.
To determine whether the member routers or switches are ready for GRES from a database synchronization perspective: