- 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 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 Monitoring an MX Series Virtual Chassis
- Accessing the Virtual Chassis Through the Management Interface
- Verifying the Status of Virtual Chassis Member Routers or Switches
- Verifying the Operation of Virtual Chassis Ports
- Verifying Neighbor Reachability for Member Routers or Switches in a Virtual Chassis
- Verifying Neighbor Reachability for Hardware Devices in a Virtual Chassis
- Determining GRES Readiness in a Virtual Chassis Configuration
- Viewing Information in the Virtual Chassis Control Protocol Adjacency Database
- Viewing Information in the Virtual Chassis Control Protocol Link-State Database
- Viewing Information About Virtual Chassis Port Interfaces in the Virtual Chassis Control Protocol Database
- Viewing Virtual Chassis Control Protocol Routing Tables
- Viewing Virtual Chassis Control Protocol Statistics for Member Devices and Virtual Chassis Ports
- Verifying and Managing the Virtual Chassis Heartbeat Connection
- Inline Flow Monitoring for Virtual Chassis Overview
- Managing Files on Virtual Chassis Member Routers or Switches
- Virtual Chassis SNMP Traps
- Virtual Chassis Slot Number Mapping for Use with SNMP
- Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat Connection with Member Routers in the Same Subnet
- Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat Connection with Member Routers in Different Subnets
- 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
Locality Bias in a Virtual Chassis
By default, member routers in an MX Series Virtual Chassis distribute egress traffic equally across all egress port links. Starting with Junos OS Release 14.1, if you want to conserve bandwidth across the internal Virtual Chassis ports, you can use locality bias to direct unicast transit traffic to egress links on the same (local) member router.
How Locality Bias Works
Locality bias conserves Virtual Chassis port bandwidth in a two-member MX Series Virtual Chassis by directing unicast transit traffic for equal-cost multipath (ECMP) groups and aggregated Ethernet bundles to egress links in the same (local) member router, provided that the local member router has an equal or larger number of available egress links than the remote member router. Because locality bias directs all of the traffic towards the local member router, Virtual Chassis ports do not use bandwidth.
However, if the number of available remote member router egress links exceeds the number of available local member router egress links, the system reduces the amount of traffic in the local member router by using a ratio that is based on the number of remote versus local links. The amount of traffic that the system does not direct toward egress links on the local member router is then split evenly across the egress links in the remote member router.
If either the local member router or remote member router do not have available egress links, then the traffic forwarding state across the Virtual Chassis ports does not change.
Locality Bias Percentages
The router uses the following algorithms to determine the percentage of traffic that is directed toward the local member router egress links, where L is the number of egress links on the local member router and R is the number of egress links on the remote member router.
To avoid possible traffic loss and oversubscription on egress interfaces, make sure you understand the utilization requirements, such as total and available bandwidth, for the local links in your network before changing the locality bias configuration.
If L >= R, then Locality Bias Percentage = 100 percent and the local member router receives all egress traffic.
For example, if the local member router and remote member router each contain one egress link, then the locality bias is 100 percent. The router directs all unicast transit traffic that is destined for an ECMP group or aggregated Ethernet bundle to the local member router.
If L < R, then Locality Bias Percentage = 200 * (L / ( R + L ))
For example, if the local member router (L) contains one link and the remote member router (R) contains two links, the locality bias percentage calculation is
200 * ( 1 / ( 2 + 1)) = 66
This means that the system directs 66 percent of the unicast transit traffic destined for an ECMP group or aggregated Ethernet bundle toward the local member router. The system splits the remaining 34 percent of the unicast transit traffic equally between the remote member router egress links. Each of the two remote egress links in the example receives 17 percent of the traffic.
Note:The actual amount of traffic that the local member router receives can vary slightly from the percentages in the algorithm calculations.
If L = 0 or R = 0, then locality bias does not change the forwarding state.
For both the L < R and L >= R algorithms, locality bias percentages are recalculated on each line card whenever one of the aggregated Ethernet child links goes up or down, or whenever a link is added to or removed from an ECMP bundle.
If an ECMP bundle has one or more child links that are aggregated Ethernet links, then those aggregated Ethernet child links are always considered remote unless all of the aggregated Ethernet child links are local.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.