This chapter provides information about configuring boot option parameters.
Topics in this chapter include:
Depending on the chassis, the primary copy of 7705 SAR software is located either on a removable compact flash card that is shipped with the 7705 SAR router or in the router on-board flash memory. The compact flash (cf3) contains a copy of the 7705 SAR image, the bootstrap file (boot.ldr), and the boot options file (BOF). The compact flash can also be used to store configurations and executable images. These configurations and images can also be stored at an FTP file location.
The following chassis have removable compact flash cards:
All other chassis have integrated memory that cannot be removed.
Note: In most cases you must have a console connection in order to access the node when there is no network connectivity to the node. Some commands can be given to the node through the ACO/LT button before there is network connectivity. See Automatic Discovery Protocol. Also refer to the appropriate chassis installation guide, “Automatic Discovery Protocol”. |
Starting a 7705 SAR begins with hardware initialization (a reset or power cycle). By default, the system searches the compact flash (cf3) for the boot.ldr file (also known as the boot loader or bootstrap file). The boot.ldr file is the image that reads and executes the system initialization commands configured in the BOF. The default value to initially search for the boot.ldr file on cf3 cannot be modified.
If the system cannot load or cannot find the boot.ldr file on the compact flash memory device (cf3), the system will reboot continuously in an attempt to successfully find and load the file. If this happens, the available options depend on the chassis.
For the 7705 SAR-8 Shelf V2 and 7705 SAR-18, there are two options:
For the 7705 SAR-M, there are two options:
For the 7705 SAR-H, there are one or two options:
For the 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-Hc, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X, return the faulty chassis to Nokia for replacement.
When the bootstrap image is loaded, the BOF is read to obtain the location of the image and configuration files. The BOF should be located on the same compact flash drive as the boot.ldr file. If the BOF cannot be found or loaded, the system prompts the user for alternate software and configuration file locations.
The following example displays the output when the boot sequence is interrupted.
. . .
Figure 4 displays the system initialization sequence.
Figure 5 displays the compact flash directory structure and filenames.
Files on the compact flash are:
Note:
|
When the system executes the boot.ldr file, the initialization parameters from the BOF are processed. Three locations can be configured for the system to search for the files that contain the runtime image. The locations can be local or remote. The first location searched is the primary image location. If not found, the secondary image location is searched, and lastly, the tertiary image location is searched.
If the files cannot be found or loaded, the system enters a console message dialog session prompting the user to enter alternate file locations and filenames.
When the runtime image is successfully loaded, control is passed from the bootstrap loader to the image. Depending on the options in the BOF file, the runtime image loads the configuration in one of two ways.
If ADP is enabled, no configuration files are processed at startup. Instead, ADP discovers the node configuration from the network and the primary-config file is generated based on the configuration discovered by ADP. Any existing primary-config file is backed up, then overwritten.
If ADP is not enabled, the runtime image attempts to locate the configuration file as configured in the BOF. Like the runtime image, three locations can be configured for the system to search for the configuration file. The locations can be local or remote. The first location searched is the primary configuration location. If not found, the secondary configuration location is searched, and lastly, the tertiary configuration location is searched.
The configuration file includes chassis, CSM, adapter card and port configurations, as well as system, routing, and service configurations.
Figure 6 displays the boot sequence.
Figure 7 shows the boot sequence if Automatic Discovery Protocol (ADP) is run on the system.
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, and path IDs. If persistence is not required and the configuration file is successfully processed, the system becomes operational. If persistence 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. 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.
Automatic Discovery Protocol (ADP) is triggered by a factory-installed boot option and automates the initial commissioning of 7705 SAR nodes. When the 7705 SAR is started for the first time, an ADP keyword in the BOF causes automatic discovery to run as part of the TiMOS application image. Refer to the appropriate chassis installation guide, “Automatic Discovery Protocol”, for more information on ADP.
ADP supports null, dot1q, and qinq encapsulation on:
Caution: For XOR ports, ADP will not run successfully if the connection to the network is made from the SFP connector because the default connector is RJ-45. |
Note: ADP is not supported on the 4-port SAR-H Fast Ethernet module. |
When run on the system, ADP goes through four basic stages:
During the self-discovery stage, all supported adapter cards and CSMs are detected and automatically provisioned. The 7705 SAR then brings up all Ethernet ports. Depending on the physical connectivity of the port, some ports may fail to come up. If at least one port connected to the transport network becomes operationally up, ADP moves to the next stage.
During the network discovery stage, the 7705 SAR sends a DHCP DISCOVER message from all operational ports. Table 18 describes the DHCP DISCOVER message options.
Option | Name | Description |
chaddr | Client HW Address | The MAC address of the port |
51 | Lease Time | Always set to Infinite |
60 | Class Identifier | The class of 7705 SAR router: ALU-AD | SAR-8 ALU-AD | SAR-18 ALU-AD | SAR-A ALU-AD | SAR-Ax ALU-AD | SAR-H ALU-AD | SAR-Hc ALU-AD | SAR-M ALU-AD | SAR-W ALU-AD | SAR-Wx ALU-AD | SAR-X |
61 | Client Identifier | Not sent by default, but can be configured to be the chassis MAC address or an operator-defined string |
82 | Relay Agent Information | Network uplink information, such as circuit ID and gateway address, added by the relay agent, if applicable |
No client identifier is sent by default, but you can configure this option during boot-up, or with the auto-discover command, to be the chassis MAC address or a unique string. During boot-up, you can also configure the VLAN ID for ADP with dot1q or qinq encapsulation.
The ADP network discovery phase has been enhanced to automatically scan the entire VLAN range on every datapath Ethernet port on supported cards and nodes. During startup a new node will act as an ADP client and send DHCP discovery packets across the entire VLAN range to automatically discover the Ethernet virtual connection (EVC) VLAN. If at least one DHCP discovery packet reaches a server and that server responds with a DHCP offer packet, the ADP client node registers the new interface against that server's VLAN.
During the configuration discovery stage, the DHCP server receives the DHCP DISCOVER message and replies with a DHCP OFFER message that contains an IP address assigned to the network interface. Table 19 describes the options included in the DHCP OFFER. If any of the required options are not included, the packet may be dropped and not processed.
Option | Name | Description | Required |
yiaddr | Client Ip-Address | The network interface IP address For network consistency, it is recommended that this IP address be a fixed IP address, not assigned randomly from a DHCP server IP pool | Yes |
1 | Subnet Mask | The network interface subnet mask | Yes |
3 | Router | The network interface default gateway Only the first router is used – all others are ignored | No |
12 | Host Name | The network interface host name | No |
51 | Lease Time | The least time, validated as infinite | Yes |
54 | Server Address | Identifies the DHCP server | No |
67 | Bootfile Name | Contains the ADP instructions or a URL to an ADP instructions file | No |
DHCP OFFER messages are not dropped if they contain a yiaddr that does not match the local configured subnets on the DHCP relay interface. This applies only to regular IES and VPRN interfaces with no lease-populate configured on the DHCP relay interface.
Option 67 contains further configuration information in the form of keyword text files interpreted by ADP as instructions and executed during the Configuration and Test phases. For basic reachability, option 67 is not mandatory; however, it can be used to send the system IP address of a newly discovered node, making it possible to communicate with the NSP NFM-P and complete ADP.
If a system IP address is made available with the DHCP OFFER and a template configuration file is also executed using the load-cfg keyword, then the system IP address specified in the template configuration file is used instead of the one in the DHCP OFFER.
Table 20 describes the keywords used in ADP instructions. A DHCP offer message can contain a maximum of 15 instructions in either the Bootfile Name option, or in an external file referenced by the include keyword. If more than 15 instructions are included, ADP fails to complete and the system generates an error message in the ADP log.
Keyword | Description | Format |
sys-addr | Specifies the system interface IP address and the system base routing instance subnet | sys-addr 10.10.10.1/32 |
sys-name | Specifies the chassis name | sys-name SITE43_7705 |
sys-loc | Specifies the chassis location | sys-loc 600_MARCH_ROAD |
load-cfg | Specifies the URL of a template configuration file to load into the router's runtime configuration | load-cfg ftp://.....@.../7705.cfg |
test-ip | Specifies an IP address that must be successfully pinged before committing configuration and declaring ADP a success | test-ip 192.20.2.30 |
include | Specifies the URL of a file containing additional ADP instructions | include ftp://.....@.../7705.tmp |
Any BOF keyword | Interpreted as instructions to update the specified field in the BOF | As per BOF |
In order for ADP to be declared successful during the test and commit stage, the discovered configuration must contain an IP address. If the optional test-ip keyword is included in the ADP instructions, the node pings the IP address included in the DHCP OFFER message. If ADP is successful, the system stores the configuration and opens an SSH session to provide remote operators access to the router.
ADP can be controlled, without a connected PC or ASCII terminal, by the ACO/LT button on the Fan module. You can use the ACO/LT button to terminate or restart ADP, or reboot the chassis.
Note: The ACO/LT button is not available on the 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-W, or 7705 SAR-Wx. |
ADP runs in the background to allow continued CLI access for status queries and troubleshooting. Periodic progress updates are sent to the console and can be viewed through a connected PC. Additionally, dump commands are available to display information and detailed logs about ADP during and after running on the system. The logs are not retained over a chassis reboot.
ADP runs only once on a router during initial startup if the automatic discovery is successful. The learned network interface configuration is retained in the local database. On subsequent reboots, the router uses its local database to reload its network configuration. After ADP successfully completes, or if it is manually terminated, the system sends a command to the BOF to remove the ADP keyword. You can terminate ADP at any time while it is running by using the CLI or the ACO/LT button.
Any temporary configuration done by ADP is not stored; however, network configuration and remote access remain enabled to allow the router to be manually provisioned remotely. ADP does not run again on future system reboots unless it is re-enabled via the CLI. If a standby CSM with ADP enabled is inserted into a running system that does not have the ADP keyword in its BOF file, the ADP keyword is automatically removed from the inactive card’s BOF file during reconcile.
The 7705 SAR provides the fips-140-2 boot command to allow a node to run in FIPS-140-2 mode. This mode limits the use of cryptographic algorithms on both the CSM and data plane to only those that are in accordance with security level 1 of the Federal Information Processing Standards 140 series, version 2 (FIPS-140-2).
FIPS-140-2 mode is supported on the CSM on all 7705 SAR platforms that are equipped with a CSM.
FIPS-140-2 mode is supported on both the CSM and data plane on the following platforms:
On the 7705 SAR-A and 7705 SAR-M, FIPS-140-2 mode is supported on the CSM only.
To support the implementation of FIPS-140-2, the TiMOS software image contains an HMAC-SHA-256 secret key that is verified upon boot-up. When FIPS-140-2 is enabled on the node, an HMAC-SHA-256 integrity check is performed during the loading of the both.tim file to ensure that the calculated HMAC-SHA-256 secret key of the loaded image matches that stored in the hmac-sha256.txt file. This is a signature file that has been added to the TiMOS software image and only applies to FIPS-140-2.
Note: The hmac-sha256.txt file must be stored in the same directory as the TiMOS image. |
If the image fails the HMAC-SHA-256 check, the node does not boot up, an error message is displayed, and the node tries to reboot the load after a delay of 60 s. The node keeps trying to reboot until the operator cancels the reboot. If the software image is verified by the HMAC-SHA-256 check, the node boots up normally and a message indicating that the software load has passed verification is displayed.
The node performs its normal boot-up sequence, including reading the config.cfg file and loading the configuration. The config.cfg file that is used to boot the node in FIPS-140-2 mode must not contain any configuration that is not supported by the FIPS-140-2 implementation. If such a configuration is present in the config.cfg file when the node boots up, the node loads the config.cfg file until the unsupported configuration is reached and then stops. A failure message is also displayed.
When the node boots in FIPS-140-2 mode, Cryptographic Module Validation Program (CMVP) startup tests are executed on the CSM and applicable data plane. CMVP conditional tests, such as manual key entry tests, pairwise consistency checks, and RNG tests, are executed when required during normal operation.
Table 21 and Table 22 show the CSM and data path security features and associated algorithms for a 7705 SAR node running in FIPS-140-2 mode.
FIPS-140-2 CSM Algorithms | SSHv2 | IPSec (IKEv1, IKEv2) | NGE | SNMPv3 | SCP, SFTP | IGP, BGP, MPLS | PKI |
Authentication | RSA 2048 DSA 1024 Preference to RSA in SSH negotiation | PSK (DH G14, DH G15) | SSH | N/A | SSH | N/A | N/A |
Asymmetric Key | DH G14 (P ≥ 2K prime numbers, q > 224) | DH G14, DH G15 (P ≥ 2K prime numbers, q > 224) | SSH | N/A | SSH | N/A | RSA/ DSA 2048 |
Symmetric Key | AES-CBC (128,192, 256) 3DES-CBC | AES-CBC (128,192, 256) 3DES-CBC | N/A | AES-128 | SSH | N/A | N/A |
Hash Algorithm | SHA-1 (128) –HMAC-MD5 –HMAC-RIPEMD-160 –HMAC-SHA1-96 –HMAC-MD5-96 | SHA-1 (128) SHA-2 (256, 384, 512) | N/A | SHA-1 (SHA-128) | SSH | SHA-1 (128) SHA-2 (256) AES-18- CMAC-96 | SHA1 SHA-224 SHA-256 SHA-384 SHA-512 |
Digital Signature | RSA 2048 DSA 1024 | N/A | N/A | N/A | N/A | N/A | RSA/ DSA 2048 |
Note: MD5 algorithms are not blocked from configuration in FIPS-140-2 mode. Although MD5 is not a FIPS-140-2-approved algorithm, it is allowed to be used when running in FIPS-140-2 mode. |
FIPS-140-2 Data Path Algorithms | SSHv2 | IPSec | NGE/L3 Encryption | SNMPv3 | SCP, SFTP | IGP, BGP, MPLS |
Authentication | N/A | N/A | N/A | N/A | N/A | N/A |
Asymmetric Key | N/A | N/A | N/A | N/A | N/A | N/A |
Symmetric Key | N/A | AES-CBC (128,192, 256) 3DES-CBC | AES-CBC (128, 256) | N/A | N/A | N/A |
Hash Algorithm | N/A | SHA-1 (128) SHA-2 (256, 384, 512) | N/A | N/A | N/A | N/A |
SSHv1 is not supported in FIPS-140-2 mode and is therefore blocked from configuration; only SSHv2 is supported. The following algorithms, configured using the client-cipher-list or server-cipher-list command, are available for SSHv2 when the node is running in FIPS-140-2 mode:
The following algorithms are not available for SSHv2 when the node is running in FIPS-140-2 mode:
Figure 8 displays the process for starting a system that has a removable compact flash. This example assumes that the boot loader, BOF, and the image and configuration files are successfully located. For a system with a non-removable compact flash, the first step in Figure 8 does not apply.
Nokia recommends that the boot loader file on all 7705 SAR platforms be upgraded using a specific command. This command is mandatory on all 7705 SAR platforms that do not have a removable compact flash drive and is part of a mechanism that protects the boot loader file from accidental overwrites on these platforms.
The command checks that the new boot.ldr file is a valid image and that it is at least a minimum supported variant for the hardware platform on which it is being loaded. Once this has been verified, the command overwrites the boot.ldr file that is stored on the system.
Before starting the upgrade, all 7705 SAR image files must be copied to the cf3: device on the system. Nokia recommends copying all the image files for a given release into an appropriately named subdirectory off the root directory; for example, cf3:\7705-TiMoS-R6.1.R2. Copying the boot.ldr and other files in a given release to a separate subdirectory ensures that all files for that release are available in case it is necessary to downgrade the software version.
Note: On systems that do not have removable flash drives, you cannot overwrite the boot.ldr file in the root directory on cf3:. Instead, copy the file into a subdirectory, or allow the update boot-loader command to obtain the file from a network address. Nokia strongly recommends following this process for all 7705 SAR systems. |
Upgrade the boot loader file using the command admin>update boot-loader source_url, where the source URL specifies the new boot.ldr filename and its location; for example, in the format cf3:\sub_directory\boot.ldr.
Warning: The file upgrade command takes several minutes to complete. Do not reset or power down the system, or insert or remove cards or modules, while the upgrade is in progress, as this could render the system inoperable. |
On systems with redundant CSMs, the upgraded boot.ldr file can be copied to the secondary CSM by using the command admin>redundancy>synchronize boot-env.
Refer to the latest 7705 SAR Software Release Notes, “Standard Software Upgrade Procedure” section, for complete instructions.
There are three ways to access management of the 7705 SAR:
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:
Parameter | Value |
Baud Rate | 115 200 |
Data Bits | 8 |
Parity | None |
Stop Bits | 1 |
Flow Control | None |
Figure 9 displays an example of the Console port on a 7705 SAR front panel.
To establish a console connection:
Telnet access via a connection to the Management port provides the same options for user and administrator access as those available through the Console port or SSH. You can access the chassis with a Telnet connection from a PC or workstation connected to the network once the following conditions are met:
where:
address is an IPv4 (or IPv6) address
After the Management port IP address is configured, the CLI can be accessed with a Telnet connection. To establish a Telnet connection, run a Telnet program and issue the telnet command, followed by the Management port IP address.
The following displays an example of a Telnet login:
The default login is admin.
The default password is admin.
SSH access via a connection to the Management port provides the same options for user and administrator access as those available through the console port or Telnet; however, SSH is more secure than Telnet. You can access the chassis with an SSH connection from a PC or workstation connected to the network once the following conditions are met:
where:
address is an IPv4 or IPv6 address
Note: SSH connection attempts after a reboot may generate key warnings as the node generates new SSH keys on each reboot. To avoid these key warnings, enable key preservation using the config>system>security>ssh>preserve-key command. |
After the IP parameters are configured, the CLI can be accessed with an SSH connection. To establish an SSH connection, run an SSH program and issue the SSH command, followed by -l and the user name (optional), followed by the IP address.
The following displays an example of an SSH connection with the default admin user (the default password is admin).
The 7705 SAR-W supports in-band and out-of-band node management communication. The RJ-45 Management port provides physical access for out-of-band communication. When the Inband/Local switch on the chassis is in the Inband position, the management interface on the CSM processor connects to the internal data port on the datapath for in-band management, and the external RJ-45 Management port is disabled.
The internal data port is identified in the CLI as vrtl-mgmt, and as port 1/1/6 in SNMP. The vrtl-mgmt port only supports access mode and Epipe service, where the port has encap-type null, dot1q, or qinq with VLAN 0.
See the “Installation and Provisioning” section in the 7705 SAR-W Chassis Installation Guide for details on setting up in-band management connections.
The Wavence MPT Craft Terminal Launcher (MCT Launcher) is an application that runs on a Windows PC. By connecting the PC to the 7705 SAR out-of-band Management (Mgmt) port on the active CSM, local MPT radios can be configured and monitored using this application.
To reach both local and remote MPT radios, the PC must be connected to an Ethernet data port on an adapter card and requires a service access point (SAP) to enable in-band management. An IES service together with a local DHCP server configured on the 7705 SAR provides this capability to on-site technicians.
The following output shows a configuration example for a local DHCP server and an IES service.
Refer to the Wavence MPT Craft Terminal User Manual for Single NE Mode with 7705 SAR for information on using the MCT Launcher.
The following describes BOF configuration guidelines and caveats.