System Initialization and boot options

The router startup process begins after a reset or power cycle with the firmware initializing the hardware before executing the Boot Loader images. The Boot Loader then executes the boot options file (BOF) to load the SR OS software image and configuration. The BOF file contains system initialization commands including the software image and configuration locations.

SR OS Boot Loader, software images, and configuration files are stored in storage media cards referred to as CF in the system. See Storage devices for more information on the type of storage supported for each platform.

The following diagram describes the system boot process from the firmware up to the SR OS image and configuration file.

The Boot Loader executes the initialization command options from the BOF to load the software images and configuration file.

The Boot Loader phase can be manually interrupted even if the BOF is present by pressing any key on the console connected to the console port. This is done by typing sros and pressing the Enter key within 30 seconds to enter the BOF manual mode. This mode allows the configuration of the BOF system initialization commands manually and overwrites the existing BOF file, if present.

Different Boot Loader images are used depending on the CPM control module:

• 7450 ESS, 7750 SR, 7750 SR 7s/14s, 7950 XRS
  • boot.ldr is the Boot Loader image that executes the BOF file before loading SR OS TiMOS software images and configuration
  • boot.ldr must be located at the root directory of the CF3 card (for systems using boot.ldr)
• 7750 SR-1x-48D, SR-1x-92S, SR-1-24D, SR-1-48D, SR-1-46S, SR-1-92S, SR-1se, and SR-2se

  • bootx64.efi is the original Boot Loader image located in /EFI/BOOT

  • bootx64.efi executes the other images in /EFI/BOOT/x86_64 before executing the BOF file and loading SR OS TiMOS software images and configuration

The BOF file (bof.cfg) must be located at the root of the CF3 card directory and contains various system initialization commands including:

• management ethernet port (speed, duplex, IP address, static routes)
• console port speed
• software image locations
• configuration file locations
• BOF and configuration file encryption settings
• BOF password
• system profile
• wait time
• Zero Touch Provisioning
• licenses
• persistency

BOF Manual Mode

The system enters the BOF manual mode if the BOF is not present in the CF3 card or if the user interrupts the Boot Loader phase and requires access to the console port for configuration.

After the manual BOF configuration is completed and saved, a bof.cfg file with the new configured command options is created in the CF3 card and used for subsequent reboots. The Boot Loader image then processes the new BOF command options to boot the system.

This process is described in the following diagram.

The software image and configuration file location are configured in the BOF.

Up to three locations, local or remote, can be configured for the software image and configuration file defined as primary image, secondary image, tertiary image, primary config, secondary config and tertiary config in the BOF.

Before loading the configuration, the software first attempts to read the license file if one has been included in the BOF. If a license file is found, it is activated. If there are any issues with the activation, a log event is raised, and the startup processing continues with the reading of the configuration file.

The following usage guidelines apply:

• The primary, secondary, and tertiary image locations must have the same version of software. If the secondary or tertiary image are configured with an older software image, this may result in a failure to load the configuration file as it may contain commands only applicable to the more recent release.
• Similarly, the secondary and tertiary configuration files, if used, should be saved with the same version of software as the software executed on boot as it can result in a failure to load the configuration file otherwise.
• In model-driven configuration mode with incremental saved configuration files enabled, the primary configuration location supports complete and incremental saved configuration files. The secondary and tertiary configuration locations support complete saved configuration files. The user must ensure that complete saved configuration files are stored at both locations.

The following diagram provides additional details on the boot process differences between classic and MD CLI configuration file processing.

The following recommendations apply to all Extensible Firmware Interface (EFI) boot loader systems:

• When installing a new CF3 SD card for the first time, all files including the installer files listed in the storage card content section of the respective platforms must be present in the SD card, and the SD card must be in FAT32 format. See Storage card content for more information. The first boot of the system on a new CF3 SD card initializes the software and partitions on the SD card. Two hidden partitions are created for internal use, the third partition is for operator use and is visible from TiMOS as CF3:.
  Note: An SD card containing necessary files and partitions can be hot-plugged into an operational router; replacing the CF3 SD card with a brand new SD card, however, requires a reboot for the system to initialize the card.
• When upgrading or changing the software on a system that has previously booted correctly, the OS installer files in the /EFI directory can be omitted from the SD card content and are automatically updated by the system on upgrade to the new SR OS TiMOS software version.
• The bof.cfg BOF file must be in the CF3:\ directory.
• The boot.ldr file is not required in the CF3:\ directory.

The following recommendations apply to all boot.ldr boot systems:

• The boot.ldr and bof.cfg files must be present at the root of the CF3:\ directory.
• When upgrading or changing the software, the corresponding boot.ldr image version must also be updated in the CF3:\ directory.
• The /EFI content is not required in the CF3:\ directory.

SR OS software downloaded from the Nokia support website includes boot and operating system images for all platforms. This section describes the required storage media card directory and filenames on a per-platform basis to clarify which files and directory apply to which platform.

The primary copy of the SR OS software is located on a Compact Flash or SD card which is shipped with each software license agreement. The content of this storage media card can differ depending on the platform.

Configurations and executable images can be stored in any storage media supported by the platform while the boot loader images and boot option file must be installed in the storage media card slot 3 (CF3:).

See the Storage devices section for the list of storage media names, locations, and support for each SR OS platform.

The BOF persist parameter specifies whether the system should preserve system indices when the configuration is saved. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indices are preserved between reboots, including the SNMP interface index, LSP IDs, path IDs, and so on. If persistence is not required and the configuration file is successfully processed, the system becomes operational. If persist is required, a matching config.ndx file must be successfully processed before the system can become operational. Configuration and index files must have the same filename prefix such as config.cfg and config.ndx and are created at the same time when an admin save command is executed. Note that the persistence option must be enabled to deploy a Network Management System (NMS) using SNMP. The default is off.

In cases where the platform is not installed in a physically secure location, the user can encrypt the BOF and the configuration file to halt or hinder interpretation of the file content.

By default, the BOF and configuration files are not encrypted. When encryption is enabled for either file and a change is saved , the original file is moved to filename.1 and the encrypted file becomes the new filename.cfg.

When the BOF is encrypted on the Compact Flash, the BOF interactive menu can be used during node startup to access the file and modify BOF fields. To prevent unauthorized modification of the BOF using the BOF interactive menu, configure a password using the following command:

• MD-CLI

  bof configuration password

• classic CLI

  bof password

The BOF interactive menu is accessible only when the configured password is entered. If the correct password is not entered in 30 seconds, the node reboots.

See Configuring BOF encryption for information about configuring BOF encryption. See Configuring the BOF interactive menu password for information about configuring the BOF interactive menu password. See Configuring configuration file encryption for information about configuring the configuration file encryption.

System profiles provide flexibility when using line cards based on FP4 and later generations by supporting different system capabilities. The system profile is defined in the BOF and is used by the system when it is next rebooted. Contact your Nokia representative for system profile information.

The following system profiles are supported:

• profile none

  This profile represents the existing system capabilities and allows hardware based on FP3 and later generations to coexist within a system. This profile is indicated by the omission of the profile parameter in the BOF.

• profile A

  This profile is primarily targeted at subscriber services and Layer 2 and 3 VPN business services. Use the following command to configure the profile:

  • MD-CLI

    bof system profile profile-a

  • classic CLI

    bof system-profile profile-a

• profile B

  This profile is primarily targeted at infrastructure routing, core, peering, and DC-GW applications.

System profiles profile-a and profile-b support only line cards based on FP4 and later generations. Provisioning FP2- or FP3-based line cards is prohibited when the system profile is set to profile-a or profile-b. If FP2- or FP3-based card types are present in the boot configuration when using these profiles, the boot sequence aborts the loading of the configuration file when it encounters their configuration.

When changing between system profiles, it is mandatory to remove all configuration commands for features that are not supported in the target system profile before rebooting the system, otherwise the reboot fails at the unsupported configuration command on startup.

On 7750 SR-1 and 7750 SR-s systems, the following conditions apply about the profile parameter:

• The parameter should be configured to either profile-a or profile-b.

• If the parameter is omitted, profile profile-a is used by the system.

• If the parameter is configured to an invalid value, it is ignored and profile profile-a is used by the system.

On 7750 SR-7-B/12-B/12e and 7950 XRS-20/20e systems, the following conditions apply about the profile parameter:

• The default system profile is none when the parameter is omitted.

• The parameter can be configured to either profile-a or profile-b, in which case only FP4-based line cards are supported.

• If the parameter is configured to an invalid value, it is ignored and profile none is used by the system.

On all other systems, the following conditions apply about the profile parameter:

• These systems must use profile none (the existing system capabilities). As a result, the parameter must not be configured.

• If the parameter is configured to profile-a or profile-b, the system boots, allowing access using the console and CPM management interface, but FP2-based and FP3-based line cards cannot be provisioned; if these card types are present in the boot configuration, the boot sequence aborts loading the configuration file when it encounters their configuration. This issue can be corrected by removing the parameter and rebooting the system.

• If the parameter is configured to an invalid value, it is ignored and profile none is used by the system.

configure redundancy synchronize boot-env

When performing a minor or major ISSU software upgrade on dual CPM systems, it is important that the system profile in the BOF on both the active and standby CPM is the same and has a value supported on the pre-upgrade software release. If the standby CPM happened to have a system profile which is only supported in the post-upgrade release, the active CPM reboots the standby and keeps it down because of a system profile mis-match.

Use the following command to display the BOF system profile:

• MD-CLI

  admin show configuration bof | match profile

• classic CLI

  show bof | match system-profile

The BOF system profile used by the system when it booted can be seen in the boot messages (using the show boot-messages command), which display the BOF read when rebooting.

show chassis | match "System Profile"

Use the following command to configure the system profile:

• MD-CLI

  bof system profile

• classic CLI

  bof system-profile

The 7750 SR includes a configurable parameter in the bof.cfg file to make the node run in FIPS-140-2 mode. When the node boots in FIPS-140-2 mode, the following behaviors are enabled on the node:

• The node performs an HMAC-SHA-256 integrity test on the software images .tim files.

• The node limits the use of encryption and authentication algorithms to only those allowed for the associated FIPS-140-2 certification of the 7750-SR.

• Cryptographic module startup tests are executed on the CPM when the node boots to ensure the associated approved FIPS-140-2 algorithms are operating correctly.

• Cryptographic module conditional tests are executed when required during normal operation of associated when using FIPS-140-2 approved algorithms.

• When configuring user-defined encryption or authentication keys, the CLI prompts for the key to be re-entered. For keys entered in hash format, for example, the key must be re-entered in hash format, followed by the appropriate hash keyword. If the re-entered key does not match the original, the CLI command is canceled. This affects several protocols and applications.

To support FIPS-140-2, an HMAC-SHA-256 integrity check is performed to verify the integrity of the software images. The hmac-sha256.txt file, containing the hmac-sha-256 signature, is included in the TIMOS-m.n.Yz software bundle.

During the loading of the cpm.tim or both.tim, an HMAC-SHA-256 check is performed to ensure that the calculated HMAC-SHA-256 of the loaded image matches that stored in the hmac-sha256.txt file.

The HMAC-SHA-256 check is performed on the data loaded from the .tim file. Note that when configuring the primary-image, secondary-image and tertiary-image, the hmac-sha256.txt file must exist in the same directory as the .tim files. If the load has been verified correctly from the HMAC-SHA-256 integrity check, the load continues to start up as normal. If the load is not verified by the HMAC-SHA-256 integrity check, the image load fails.

After the HMAC-SHA-256 integrity check passes, the nodes continue their normal startup sequence including reading the config.cfg file and loading the configuration. The config.cfg file used to boot the node in FIPS-140-2 mode must not contain any configuration that is not supported in FIPS-140-2 mode. If such configuration is present in the config.cfg file when the node boots, the node loads the config.cfg file until the location of the offending configuration and then halt the configuration at that point. Upon a failure to load the config.cfg file, a failure message is printed on the console.

Enabling FIPS-140-2 restricts the ability to configure and use cryptographic algorithms and functions that are not FIPS approved. FIPS-140-2 impacts the ability to configure SSH, SNMP and certificates. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for details of FIPS-140-2 related items.

In addition, signature algorithms of the following combinations only are approved for FIPS:

• FIPS-140 Approved - Digital Signature Standard (DSS)

  • DSA

  • RSA

  • ECDSA

• FIPS-140 Approved - Secured Hash Standard (SHS)

  • SHA-1

  • SHA-224

  • SHA-256

  • SHA-384

  • SHA-512

Any other combination is not supported in FIPS mode. Using other FIPS signature algorithms in certificates affecting IPsec can cause tunnels to fail. Restrictions to cryptographic algorithms are listed in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.

Lawful Intercept (LI) describes a process to intercept telecommunications by which law enforcement authorities can unobtrusively monitor voice and data communications to combat crime and terrorism with higher security standards of lawful intercept capabilities in accordance with local law and after following due process and receiving correct authorization from competent authorities. The interception capabilities are sought by various telecommunications providers.

As lawful interception is subject to national regulation, requirements vary from one country to another. -This implementation satisfies most national standard’s requirements. LI is configurable for all service types.

This section provides information about configuring BOF parameters with CLI.