To configure a Virtual Chassis for MX Series routers,
you must create a preprovisioned configuration on the primary router
by including the virtual-chassis stanza at the [edit
virtual-chassis] hierarchy level. The preprovisioned configuration
specifies the chassis serial number, member ID, and role for both
member routers in the Virtual Chassis.
When a new member router joins the Virtual Chassis, the software
compares its serial number against the values specified in the preprovisioned
configuration. If the serial number of a joining router does not match
any of the configured serial numbers, the software prevents that router
from becoming a member of the Virtual Chassis.
To configure the preprovisioned member information for
an MX Series Virtual Chassis:
- Specify that you want to create a preprovisioned Virtual
Chassis configuration.
[edit virtual-chassis]
user@host# set preprovisioned
- Configure the member ID (
0 or 1),
role (routing-engine), and chassis serial number for each
member router in the Virtual Chassis.[edit virtual-chassis]
user@host# set member member-number role routing-engine serial-number serial-number
user@host# set member member-number role routing-engine serial-number serial-number
Note: In a two-member MX Series Virtual Chassis configuration,
you must assign the routing-engine role to each router.
The routing-engine role enables the router to function
either as the primary router or backup router of the Virtual Chassis.
- Disable detection of a split in the Virtual Chassis configuration.
(By default, split detection in an MX Series Virtual Chassis is enabled.)
[edit virtual-chassis]
user@host# set no-split-detection
Best Practice: We recommend that you disable split detection
for a two-member MX Series Virtual Chassis configuration if you think
the backup router is more likely to fail than the Virtual Chassis
port links to the backup router. Configuring redundant Virtual Chassis
ports on different line cards in each member router reduces the likelihood
that all Virtual Chassis port links to the backup router will fail.
- (Optional) Enable locality bias in the Virtual Chassis
configuration.
[edit virtual-chassis]
user@host# set locality-bias
Best Practice: Starting
in Junos OS Release 14.1, you can enable locality bias in the Virtual
Chassis configuration. Locality bias can cause
traffic loss and oversubscription on egress interfaces if you configure
it in a network that is not designed to handle locality biasing. 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.
- (Optional) Enable tracing of Virtual Chassis operations.
For example:
[edit virtual-chassis]
user@gladius# set traceoptions file filename
user@gladius# set traceoptions file size maximum-file-size
user@gladius# set traceoptions flag flag
- Commit the configuration.
Best Practice: We recommend that you use the commit synchronize command to save any configuration changes to the Virtual Chassis.
For an MX Series Virtual Chassis, the force option
is the default and only behavior when you issue the commit synchronize command. Issuing the commit synchronize command for an
MX Series Virtual Chassis configuration has the same effect as issuing
the commit synchronize force command.
