Boot options

Optionally, the BOF persist parameter can specify whether the system should preserve system indexes when a save command is executed. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indexes are preserved between reboots, including the 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 x.ndx file must be located and successfully processed before the system can become operational. Matching files (configuration and index files) must have the same filename prefix such as test123.cfg and test123.ndx and are created at the same time when a save command is executed. Note that the persistence option must be enabled to deploy the Network Management System (NMS). The default is off.

Traps, logs, and console messages are generated if problems occur and SNMP shuts down for all SNMP gets and sets, however, traps are issued.

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.

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.

System profiles provide flexibility when using FP4-based line cards 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 FP3- and FP4-based hardware 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 FP4-based line cards. 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 BOF should be on the same drive as the boot loader file. If the system cannot load or cannot find the BOF then the system checks whether the boot sequence was manually interrupted. The system prompts for a different image and configuration location.

The following example shows output when the boot sequence is interrupted.

###########################################
Sample output:
Hit a key within 3 seconds to change boot parameters...   
Type "sros" and hit ENTER within 29 seconds to begin changing parameters: sros 
You must supply some required Boot Options. At any prompt, you can type:
   "restart" - restart the query mode.
   "reboot"  - reboot.
   "exit"    - boot with existing values.
Press ENTER to begin, or 'flash' to enter firmware update...
Software Location
-----------------
   You must enter the URL of the TiMOS software.
   The location can be on a Compact Flash device,
   or on the network.
   Here are some examples
      cf3:/timos1.0R1
      ftp://user:passwd@192.168.1.150/./timos1.0R1
      ftp://user:passwd@[3FFE::1]/./timos1.0R1
The existing Image URL is 'ftp://*:*@192.168.192.20/./images'
Press ENTER to keep it.
Software Image URL: ftp://vxworks:vxw0rks@192.168.10.20/./rel/0.0/xx
Configuration File Location
---------------------------
   You must enter the location of configuration
   file to be used by TiMOS.  The file can be on
   a Compact Flash device, or on the network.
   Here are some examples
      cf1:/config.cfg
      ftp://user:passwd@192.168.1.150/./config.cfg
      ftp://user:passwd@[3FFE::1]/./config.cfg
      tftp://192.168.1.150/./config.cfg
      tftp://[3FFE::1]/./config.cfg
The existing Config URL is 'ftp://*:*@192.168.192.20/./images/dut-b.cfg'
Press ENTER to keep it, or the word 'none' for no Config URL.
Config File URL: cf1:/config.cfg
License File Location
---------------------------
   You must enter the location of the license
   file to be used by TiMOS.  The file can be on
   a Compact Flash device, or on the network.
   Here are some examples
      cf1:/license.txt
      ftp://user:passwd@192.168.1.150/./license.txt
      ftp://user:passwd@[3FFE::1]/./license.txt
      tftp://192.168.1.150/./license.txt
      tftp://[3FFE::1]/./license.txt
License File URL: 
No license file specified.
IP Autoconfiguration
--------------------
   This device supports IP autoconfiguration of the management port.
   When the Software Image URL and the License File URL are not local,
   the network configuration must be static (no autoconfiguration).
   When the Config File URL is not local,
   the network configuration is recommended to be static (no autoconfiguration).
   Per address family the configuration must be either static, either auto.
The Software Image URL is not local and does require that the IPv4 network is statically configured.
   [IPv4 Autoconfiguration cannot be enabled]
Would you like to enable IPv4 Autoconfiguration? (yes/no) no
Would you like to enable IPv6 Autoconfiguration? (yes/no) no
Network Configuration
---------------------
   You specified a network location for either the
   software or the configuration file.  You need to
   configure IP(v6) for this system.
   IP addresses should be entered in standard
   dotted decimal form with a network length.
       example:   192.168.1.169/24
The existing Active IP address is 192.168.192.23/18. Press ENTER to keep it.
Enter Active IP Address (Type 0 if none desired): 192.168.10.1/20
The existing Standby IP address is 192.168.192.24/18. Press ENTER to keep it.
Enter Standby IP Address (Type 0 if none desired): 192.168.10.2/20
   In case of an IPv6, the IPv6 address should be
   entered in standard colon hexadecimal notation
   with a prefix length.
       example:   3FFE::1/112
The existing Active IPv6 address is 3000::c0a8:c015/114. Press ENTER to keep it.
Enter Active IPv6 Address (Type 0 if none desired): 3ABC::AAAA:1/100
The existing Standby IPv6 address is 3000::c0a8:c016/114. Press ENTER to keep it.
Enter Standby IPv6 Address (Type 0 if none desired): 3ABC::AAAA:2/100
Would you like to add a static route? (yes/no) yes
Static Routes
-------------
   You specified network locations which require
   static routes to reach. You will be asked to
   enter static routes until all the locations become
   reachable.
   Static routes should be entered in the following format:
   prefix/mask next-hop ip-address
       example:     192.168.0.0/16 next-hop 192.168.1.254
       example:     3FFE::1:0/112 next-hop 3FFE::2:1
Enter ip route: 1.1.1.0/24 next-hop 192.168.1.250
1.1.1.0/24 next-hop 192.168.1.250
A route to that subnet already exists.
Would you like to add a static route? (yes/no) no
Would you like to add an IPv6 static route? (yes/no) no
The existing fips-140-2 configuration is : 'no fips-140-2'
If you would like to change it please enter 'fips-140-2' followed by ENTER
or press ENTER to keep existing fips configuration
Auto-Boot
---------
   This device supports automated provisioning
   from the network.  When this mode is enabled
   the system will not execute the boot configuration
   file. Instead, it will boot to the default 
   configuration and automatically provision supported
   equipment for further loading from the network.
Would you like to enable Automated-Provisioning? (yes/no) no
New Settings
------------
    primary-image    ftp://*:*@192.168.10.20/./rel/0.0/xx
    primary-config   cf1:/config.cfg
    address          192.168.10.1/20 active
    address          192.168.10.2/20 standby
    address          3abc::aaaa:1/100 active
    address          3abc::aaaa:2/100 standby
    static-route     1.1.1.0/24 next-hop 192.168.1.250
    autonegotiate
    duplex           full
    speed            100
    wait             3
   persist          off
    no fips-140-2
    console-speed    115200
Do you want to overwrite cf3:/bof.cfg with the new settings? (yes/no): yes
Successfully saved the new settings in cf3:/bof.cfg
###########################################

To access the CLI to configure the software for the first time, follow these steps:

1. When the CPM/CCM is installed, and power to the chassis is turned on, the SR OS software automatically begins the boot sequence.

2. When the boot loader and BOF image and configuration files are successfully located, establish a router connection (console session).

The BOF contents can be encrypted using AES256 or SHA256.

Use the following command to configure BOF encryption:

• MD-CLI

  bof configuration encrypt true

• classic CLI

  bof encrypt on

Access to the BOF interactive menu can be controlled using a password.

Use the following command to configure a BOF interactive menu password:

• MD-CLI

  bof configuration password

• classic CLI

  bof password

The password can be in one of the following formats:

• a plaintext string between 8 and 32 characters; the plaintext string cannot contain embedded nulls or end with " hash", " hash2", or " custom"

  Caution: When entering the password in plaintext, ensure that the password is not visible to bystanders.

• a hashed string between 1 and 64 characters; the selected hashing scheme can be hash, hash2, or custom

  Note: The hash2 encryption scheme is node-specific and the password cannot be transferred between nodes.

The configuration file contents can be encrypted using AES256 or SHA256.

Use the following command to configure a BOF file encryption key:

• MD-CLI

  bof configuration encryption-key

• classic CLI

  bof encryption-key

When configuring an encryption key, the key can be in one of the following formats:

• a plaintext string between 8 and 32 characters; the plaintext string cannot contain embedded nulls or end with “ hash”, “ hash2”, or “ custom”
  Caution: When entering the encryption key in plaintext, ensure that the key is not visible to bystanders.

• a hashed string between 1 and 64 characters; the selected hashing scheme can be hash, hash2, or custom

When autoconfigure is enabled, a static IP address or static route cannot be configured in the BOF.

Similarly, a DNS server cannot be configured in the BOF, and only the DNS server provided by the DHCP offer can be used to resolve URLs.

The option 15 DNS domain name is not supported. The user can configure the DNS domain in the BOF so that the domain is not blocked when autoconfigure is used. Otherwise, the user must use the absolute URL with the hostname and domain included.

When autoconfigure is used on redundant CPM chassis, the DHCP discovery uses the chassis MAC address. Only the active CPM performs a DHCP discovery and not the inactive CPM. When the offer arrives, the node uses that IP and the chassis MAC as addresses for management. Consequently, the inactive CPM is not reachable by the network, because it has no separate IP address. On activity switch, the inactive CPM inherits the active IP and chassis MAC.

For non-redundant CPMs, the management port MAC is used.

SR OS supports type 2 DUID (link local), which is set to the chassis serial number. Type 3 (enterprise) is set to the chassis MAC address. Type 1 is not supported.

For type 2 DUID, the SR OS sends the Nokia Enterprise ID as the second byte of the DUID, followed by the chassis serial number. The first byte is the DUID type code. The chassis serial number starts with capital ASCII letters, which ensures that the serial number is unique as an application ID in the SR OS IPv6 DHCP application domain.

DUID type codes are as follows:

• DHCP6C_DUID_ENT_ID__IPSEC_IPV4ADDR - 1

• DHCP6C_DUID_ENT_ID__IPSEC_ASN1DN - 2

• DHCP6C_DUID_ENT_ID__IPSEC_FQDN - 3

• DHCP6C_DUID_ENT_ID__IPSEC_USER_FQDN - 4

• DHCP6C_DUID_ENT_ID__IPSEC_IPV6ADDR - 5

• DHCP6C_DUID_ENT_ID__IPSEC_ASN1GN - 6

• DHCP6C_DUID_ENT_ID__IPSEC_KEYID - 7

• DHCP6C_DUID_ENT_ID__WLAN_GW - 8

• DHCP6C_DUID_ENT_ID__AUTOBOOT - 9

• DHCP6C_DUID_ENT_ID__ZTP_BOF_AUTOP - Capital letters in ASCII

An IPv6 DHCP offer does not have an IP prefix within the offer, unlike an IPv4 DHCP offer. The IPv6 prefix is usually obtained from the IPv6 Route Advertisement (RA) arriving from the upstream router. For ZTP, SR OS is a host and assigns a /128 prefix to the IPv6 address obtained from the DHCP offer.In addition, SR OS supports the installation of IPv6 default and static routes from upstream routers using the IPv6 RA. Multiple upstream routers can respond to a route solicitation with their own RA. SR OS installs all the routes advertised by the RA. If the same route is advertised by multiple upstream routers (next hops), the SR OS installs the route with the highest preference. The SR OS does not support ECMP when the same route is advertised from multiple next hops by multiple RAs.

To ensure that all the RAs are obtained before the auto-provisioning process is started for IPv6, SR OS follows the RFC 4861 recommendation that the host (in this case SR OS) send a minimum of three route solicitations. This is to ensure that if a route solicitation is lost, at least one of the three would reach the upstream routers. Each route solicitation is followed by a 4 s timeout. If the first route solicitation is sent at T0, the second is sent at T0+4 s and the third is sent at T0+8 s. The upstream routers must respond to the route solicitation with in 0.5 s. This means that the SR OS has all of the RAs and the routes within 8.5 s of the first route solicitation. Therefore, SR OS waits for a maximum of 9 s to receive all RAs.

If the DHCPv6 timeout is less than 9 s, the DHCPv6 timeout is honored even for the RA wait time. If the node has received a single RA and DHCP offer, the process is considered a success. However, it is possible that not all the RAs have arrived on the node because the node has waited less than 9 s.