Understanding Resilient Dual-Root Partitions on Switches

Resilient dual-root partitioning, introduced on Juniper Networks EX Series Ethernet Switches in Juniper Networks Junos operating system (Junos OS) Release 10.4R3, provides additional resiliency to switches in the following ways:

• Allows the switch to boot transparently from the second (alternate) root partition if the system fails to boot from the primary root partition.
• Provides separation of the root Junos OS file system from the /var file system. If corruption occurs in the /var file system (a higher probability than in the root file system because of the greater frequency in /var of reads and writes), the root file system is insulated from the corruption.

Note: For instructions on upgrading Junos OS (from a release prior to Release 10.4R3) to a release that supports resilient dual-root partitions, see the release notes (New Features in Junos OS Release 11.2 for EX Series Switches).

Resilient Dual-Root Partition Scheme (Junos OS Release 10.4R3 and Later)

EX Series switches that ship with Junos OS Release 10.4R3 or later are configured with a root partition scheme that is optimized for resiliency, as shown in Table 1.

In the resilient dual-root partition scheme, the /var file system is contained in a separate slice (Slice 3) from the root file systems; the /config directory is contained in its own slice (Slice 4), and switches ship from the factory with identical Junos OS images in Slice 1 and Slice 2. The /var file system, which has a greater frequency of reads and writes than the root file systems and is therefore more likely to have corruption issues, is isolated from the root directories and the /config directory. If the switch fails to boot from the active partition, the switch automatically boots from the alternate root partition and triggers an alarm.

Automatic Fixing of Corrupted Primary Root Partition with the Automatic Snapshot Feature

Resilient dual-root partitioning also provides the automatic snapshot feature. You can enable the automatic snapshot feature for the system to automatically fix the corrupt Junos OS file in the primary root partition. If you enable the automatic snapshot feature, the switch automatically takes a snapshot of the Junos OS root file system in the alternate root partition and copies it onto the primary root partition, thereby repairing the corrupt file in the primary root partition. The automatic snapshot procedure takes place whenever the system reboots from the alternate root partition, regardless of whether the reboot is due to a command or due to a corruption of the primary root partition.

On EX4550 switches, the automatic snapshot feature is enabled by default. On other EX Series switches, you can enable the automatic snapshot feature by configuring the auto-snapshot statement at the [edit system] hierarchy level. If the automatic snapshot feature is enabled in a Virtual Chassis configuration, the automatic snapshot procedure takes place whenever any member of the Virtual Chassis has rebooted from its alternate root partition.

The automatic snapshot feature provides an additional layer of fault protection if you maintain the same version of Junos OS in both partitions of resilient dual-root partitions. The repair happens automatically. Therefore, when auto-snapshot is enabled, the switch does not issue an alarm to indicate that the system has been rebooted from the alternate partition. However, it does log the event. You cannot execute a manual snapshot when an automatic snapshot procedure is in process. The login banner indicates that an automatic snapshot operation is in progress and that banner is removed when the snapshot operation is complete. The next reboot happens from the primary partition.

Note: EX Series switches that ship with Junos OS Release 10.4R3 or later are configured with identical Junos OS images in the primary root partition (Slice 1) and the alternate root partition (Slice 2). However, if you do not maintain the same version of Junos OS in both partitions, you might want to disable the automatic snapshot feature. If you have an older version of Junos OS in the alternate partition and the system reboots from the alternate root partition, the automatic snapshot feature replaces the newer Junos OS version with the older version. When automatic snapshot is disabled and the system reboots from the alternate root partition, it also triggers an alarm indicating that the system has rebooted from its alternate partition.

Earlier Partition Scheme (Junos OS Release 10.4R2 and Earlier)

The partition scheme used in Junos OS 10.4R2 and earlier is shown in Table 2.

This is the partitioning scheme for a switch shipped with Release 10.4R2 or earlier (or after you reformat the disk during a downgrade from Release 10.4R3 or later to Release 10.4R2 or earlier). In this partitioning scheme, the switch comes from the factory with only one Junos OS image installed in the root Junos OS partition of Slice 1. The first time that you perform a software upgrade, the new Junos OS image is installed in Slice 2. If the switch fails to boot, you must manually trigger it to boot from the alternate partition (rebooting from the alternate partition does not occur automatically).

Understanding Upgrading or Downgrading Between Resilient Dual-Root Partition Releases and Earlier Releases

Upgrading from Release 10.4R2 or earlier to Release 10.4R3 or later differs from other upgrades in two important ways:

• You must install a new loader software package in addition to installing the new Junos OS image.
• Rebooting after the upgrade reformats the disk from three partitions to four partitions. See Table 1.

You can perform all operations for this special software upgrade from the CLI.

Caution: Back up any important log files because the /var/log files are not saved or restored during an upgrade from Release 10.4R2 or earlier to a release that supports resilient dual-root partitions (Release 10.4R3 or later). We recommend that you also save your /config files and any important log files to an external medium because if there is a power interruption during the upgrade process, they might be lost.