Configuring Your System for Booting

Juniper Networks delivers your E-series router already set up with a factory default configuration and a software release (.rel) file. You can, however, create a new configuration file (.cnf) and select a different software release file to use in future reboots of your router. When you reboot your router, you can use:

• An existing configuration file to be used each time the system reboots
• An existing configuration file limited to a single reboot
• An existing script file to be used on only the next reboot
• An existing script file to be used on the next and every subsequent reboot using backup mode
• The configuration that is already running on the system
• The factory default configuration

In addition, you can configure the system to load a different software release file on its next reboot. Use the boot system command to do this. If you do not configure your system with a backup release, it reverts to the release and configuration it had before the crash.

You can use the boot backup command to specify a software release and configuration for the system to use in case the system resets too many times in a given period.

The boot subsystem command enables you to override the system release setting for a given subsystem—for example, OC3.

Booting the GE-2 Line Module

The GE-2 line module can now detect whether it supports the software release installed on the primary SRP module in an E-series router. When the GE-2 line module is booting and it detects that it supports the software release on the SRP module, the line module boots successfully with that software release. However, if the GE-2 line module detects that it does not support the software release on the SRP module, the module does not boot successfully and the following messages appear in the system log:

boot backup

• Use to set the release version and the configuration to be used when the boot logic chooses backup mode.
• This command does not reboot the system; it configures the system for rebooting.
• You can require the system to reboot from an existing configuration file, from an existing local script file, or with the factory default configuration.
• Example

  host1(config)#boot backup rel_1_1_0.rel newfile.cnf

• Use the no version of this command to remove the backup setting.
• See boot backup.

boot config

• Use to specify the configuration with which the system is rebooted.

  Caution: All versions of this command except those using the running-configuration or startup-configuration keywords erase the current system running configuration. Before issuing one of those versions, you might want to save the running configuration to a .cnf file by issuing the copy running-configuration command.

• You can require the system to reboot from a configuration file.

  To specify an existing system configuration (.cnf) file that the system uses for the next reboot and all subsequent reboots:

  host1(config)#boot config newconffile.cnf

  To specify an existing system configuration (.cnf) file that the system uses only on the next reboot. On subsequent reboots, the system will use the running configuration current at the time of that reboot:

  host1(config)#boot config newconffile.cnf once

• You can require the system to reboot from an existing local script (.scr) file that the system uses only on the next reboot. On subsequent reboots, the system will use the running configuration current at the time of that reboot:

  host1(config)#boot config scriptfile.scr

  Configuring this option causes the system to ignore—only at the next reboot—an autocfg.scr file that you may also have configured.

• If you specify a .cnf file, upon the next reboot the system resets to the factory defaults; it then opens the .cnf file and begins applying it immediately. If you specify a .scr file, upon the next reboot the system resets to the factory defaults; it then waits for a 600-second countdown timer to expire before applying the script. This period gives the line modules an opportunity to fully initialize before configuration begins. Upon timer expiration or system initialization (whichever occurs first), the script executes regardless of the state of the line modules. You can escape from the countdown by pressing Ctrl+c; the system prompts you to execute the script immediately or return to the system console.
• You can require the system to reboot from the configuration running on the system at the time of the reboot.

  If the system is in Automatic Commit mode:

  host1(config)#boot config running-configuration

  If the system is in Manual Commit mode:

  host1(config)#boot config startup-configuration

  See Saving the Current Configuration in Managing the System , for information about Automatic and Manual Commit modes.

• You can require the system to reboot from the factory default configuration. On subsequent reboots, the system will use the running configuration current at the time of that reboot:

  host1(config)#boot config factory-defaults

• This command does not reboot the system.
• Use the no version to clear a previous request to reboot in a specified manner.
• See boot config.

boot force-backup

• Use to force the system to use the backup release/configuration on the next boot.
• This command does not reboot the system.
• Example

  host1(config)#boot force-backup mysafe.rel mysafe.cnf

  Note: Even if you request the normal release/configuration, the boot logic still checks the reboot history file. It may force the backup mode regardless of your request. To guarantee that the boot logic does not override your request to use the normal release/configuration, do either of the following: Delete the reboot history file after issuing the no boot force-backup command. Do not configure a backup release or configuration file.

• Use the no version to set the system to return to its normal release/configuration on the next boot.
• See boot force-backup.

boot revert-tolerance

• Use to set the reversion tolerances that the boot logic uses to determine whether to use normal or backup settings.
• The default settings tolerate up to three resets in 30 minutes.
• This command does not reboot the system when high availability is not enabled.
• Issuing this command when high availability is enabled results in the system cold-restarting the router and using the backup settings if the tolerance settings are met.
• Example

  host1(config)#boot revert-tolerance 2 60

• Use the no version to restore the default values, 3 and 1800.
• See boot revert-tolerance.

boot revert-tolerance never

• Use to set the boot logic to never revert to the backup image/configuration.
• This command does not reboot the system.
• Example

  host1(config)#boot revert-tolerance never

  Note: This command is functionally equivalent to specifying no backup image/configuration, but it allows you to leave the backup settings alone and to toggle autoreversion on and off. This command is undone by using the no boot revert-tolerance command, which restores the default settings, or the boot revert-tolerance command. The default settings are count = 3 (crashes) and time = 1800 (seconds); that is, 3 crashes in 30 minutes.

• There is no no version.
• See boot revert-tolerance never.

boot subsystem

• Use to configure the software release the selected subsystem will use the next time it reboots.
• This command does not reboot the subsystem.
• Example 1

  host1(config)#boot subsystem ct3 rel_1_0_1.rel

• The boot backup subsystem version of this command enables you to configure a backup subsystem for booting.
• Example 2

  host1(config)#boot backup subsystem ct3 rel_1_0_1.rel

• Use the no version to remove the configuration setting.
• See boot subsystem.

boot system

Caution: This command attempts to reprogram the SRP boot PROMs, if necessary. The SRP has a primary and, typically, a backup boot PROM. If the boot system command is executed on an SRP with no backup boot PROM, the following message is displayed: “ Write to Backup Boot ROM failed.” In this instance, this message is correct, and you can ignore it.

• Use to specify the software release (.rel) file that your system will use when rebooting.
• This command does not reboot the system.
• In a dual SRP configuration, when this information is synchronized to the standby SRP, the standby SRP is reloaded to boot the specified release. The high availability feature requires the release to be the same on the active and the standby SRP. This means that arming the system to boot with a different release causes the standby to reload and prevent high availability from becoming active or disable high availability it if it is active or pending.
• Example

  host1(config)#boot system release1.rel

• There is no no version.
• See boot system.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.