This section provides information to configure BOF parameters with CLI.
Nokia routers do not contain a boot EEPROM. The boot loader code is loaded from the boot.ldr file. The BOF file performs the following tasks:
The parameters which specify location of the image filename that the router will try to boot from and the configuration file are in the BOF.
The most basic BOF configuration should have the following:
The following is a sample of a basic BOF configuration.
The following sections are basic system tasks that must be performed.
For details about hardware installation and initial router connections, refer to the specific router hardware installation guide.
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 an example of the output when the boot sequence is interrupted.
. . .
To access the CLI to configure the software for the first time, follow these steps:
To establish a console connection, you will need the following:
Table 29 lists the console configuration parameter values.
Parameter | Value |
Baud Rate | 115,200 |
Data Bits | 8 |
Parity | None |
Stop Bits | 1 |
Flow Control | None |
To establish a console connection:
The following example shows a BOF configuration on a 7750 SR:
When autoconfigure is enabled, the router performs a DHCP discovery or solicit (IPv6) to get the IP address of the out-of-band (OOB) management port.
The OOB management port can support a DHCP client for IPv4, IPv6, or dual stack. For dual stack, both IPv4 and IPv6 DHCP are configured. When the offer for either of the address families arrives, the management port is configured with the IP address in the offer. Eventually, both offers arrive and the management port is configured with both address families.
When a DHCP client is configured using autoconfigure, all image and license files should be placed and loaded from the CF. The configuration file could be loaded from the network, but Nokia recommends that the config file be on the CF as well. The configuration file is not loaded until the DHCP client offer is received and programmed successfully for the management port IP address, or the DHCP client timeout is expired.
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 host-name 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.
![]() | Note: The router must be rebooted when enabling autoconfigure for the first time to ensure that the CPM card uses the chassis MAC address. |
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:
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 will have 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.
This section discusses service management tasks related to the BOF.
Use the following administrative commands to perform management tasks.
Use one of the following CLI commands to display the current configuration. The detail option displays all default values. The index option displays only the persistent indices. The info command displays context-level information.
The following example shows a configuration file for the 7750 SR:
If you modify a configuration file, the changes remain in effect only during the current power cycle unless a save command is executed. Changes are lost if the system is powered down or the router is rebooted without saving.
The following command saves a configuration:
The following command saves the system configuration:
![]() | Note: If the persist option is enabled and the admin save file-url command is executed with an FTP path used as the file-url parameter, two FTP sessions simultaneously open to the FTP server. The FTP server must be configured to allow multiple sessions from the same login, otherwise, the configuration and index files will not be saved correctly. |
You can delete specific BOF parameters. The no form of these commands removes the parameter from configuration. The changes remain in effect only during the current power cycle unless a save command is executed. Changes are lost if the system is powered down or the router is rebooted without saving.
Deleting a BOF address entry is not allowed from a Telnet session.
Use the following CLI syntax to save and remove BOF configuration parameters:
Save the current configuration with a unique filename to have additional backup copies and to edit parameters with a text editor. You can save your current configuration to an ASCII file.
Use the following CLI syntax to save a configuration to a different location:
When an admin>reboot command is issued, routers with redundant CPM are rebooted as well as the XMAs, XCMs, and IOMs. Changes are lost unless the configuration is saved. Use the admin>save file-url command to save the current configuration. If no command line options are specified, the user is prompted to confirm the reboot operation.
Use the following CLI syntax to reboot: