Configuring System Management with CLI
This section provides information about configuring system management features with CLI.
Topics in this section include:
System Management Configuration
Saving Configurations
Whenever configuration changes are made, the modified configuration must be saved so that the changes will not be lost when the system is rebooted. The system uses the configuration and image files, as well as other operational parameters necessary for system initialization, according to the locations specified in the boot option file (BOF) parameters. For more information about boot option files, see Boot Options.
Configuration files are saved by executing explicit or implicit command syntax.
- An explicit save writes the configuration to the location specified in the save command syntax (the file-url option).
- An implicit save writes the configuration to the file specified in the primary configuration location.If the file-url option is not specified in the save command syntax, the system attempts to save the current configuration to the current BOF primary configuration source. If the primary configuration source (path and/or filename) changed since the last boot, the new configuration source is used.
The save command includes an option to save both default and non-default configuration parameters (the detail option).
The index option specifies that the system preserves system indexes when a save command is executed, regardless of the persistent status in the BOF file. 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. This reduces resynchronizations of the Network Management System (NMS) with the affected network element.
If the save attempt fails at the destination, an error occurs and is logged. The system does not try to save the file to the secondary or tertiary configuration sources unless the path and filename are explicitly named with the save command.
Basic System Configuration
This section provides information to configure system parameters and provides configuration examples of common configuration tasks. The minimal system parameters that should be configured are:
The following example displays a basic system configuration:
Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure system parameters and provides the CLI commands.
System Information
This section covers the basic system information parameters to configure the physical location of the 7705 SAR, contact information, router location information such as an address, floor, room number, global positioning system (GPS) coordinates, and system name.
Use the CLI syntax displayed below to configure the following system components:
System Information Parameters
General system parameters include:
Name
Use the system name command to configure a name for the device. The name is used in the prompt string. Only one system name can be configured. If multiple system names are configured, the last one encountered overwrites the previous entry.
Use the following CLI syntax to configure the system name:
The following example displays the system name:
Contact
Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.
Location
Use the location command to specify the system location of the device. For example, enter the city, building address, floor, and room number where the router is located.
Use the following CLI syntax to configure the location:
CLLI Code
The Common Language Location Code (CLLI code) is an 11-character standardized geographic identifier that is used to uniquely identify the geographic location of a 7705 SAR.
Use the following CLI command syntax to define the CLLI code:
Coordinates
Use the optional coordinates command to specify the GPS location of the device. If the string contains spaces, the entire string must be enclosed within double quotes.
Use the following CLI syntax to configure the location:
The following example displays the configuration output of the general system commands:
System Time Elements
The system clock maintains time according to Coordinated Universal Time (UTC). Configure information time zone and summer time (daylight savings time) parameters to correctly display time according to the local time zone.
Time elements include:
Zone
The zone command sets the time zone and/or time zone offset for the router. The 7705 SAR supports system-defined and user-defined time zones. The system-defined time zones are listed in Table 28.
The following example displays the zone output:
Table 28: System-defined Time Zones
Acronym | Time Zone Name | UTC Offset |
Europe: | ||
GMT | Greenwich Mean Time | UTC |
WET | Western Europe Time | UTC |
WEST | Western Europe Summer Time | UTC +1 hour |
CET | Central Europe Time | UTC +1 hour |
CEST | Central Europe Summer Time | UTC +2 hours |
EET | Eastern Europe Time | UTC +2 hours |
EEST | Eastern Europe Summer Time | UTC +3 hours |
MSK | Moscow Time | UTC +3 hours |
MSD | Moscow Summer Time | UTC +4 hours |
US and Canada: | ||
AST | Atlantic Standard Time | UTC -4 hours |
ADT | Atlantic Daylight Time | UTC -3 hours |
EST | Eastern Standard Time | UTC -5 hours |
EDT | Eastern Daylight Saving Time | UTC -4 hours |
CST | Central Standard Time | UTC -6 hours |
CDT | Central Daylight Saving Time | UTC -5 hours |
MST | Mountain Standard Time | UTC -7 hours |
MDT | Mountain Daylight Saving Time | UTC -6 hours |
PST | Pacific Standard Time | UTC -8 hours |
PDT | Pacific Daylight Saving Time | UTC -7 hours |
HST | Hawaiian Standard Time | UTC -10 hours |
AKST | Alaska Standard Time | UTC -9 hours |
AKDT | Alaska Standard Daylight Saving Time | UTC -8 hours |
Australia and New Zealand: | ||
AWST | Western Standard Time | UTC +8 hours |
ACST | Central Standard Time | UTC +9.5 hours |
AEST | Eastern Standard/Summer Time | UTC +10 hours |
NZT | New Zealand Standard Time | UTC +12 hours |
NZDT | New Zealand Daylight Saving Time | UTC +13 hours |
Summer Time Conditions
The config>system>time>dst-zone context configures the start and end dates and offset for summer time or daylight savings time to override system defaults or for user-defined time zones.
When configured, the time will be adjusted by adding the configured offset when summer time starts and subtracting the configured offset when summer time ends.
If the time zone configured is listed in Table 28, then the starting and ending parameters and offset do not need to be configured with this command unless there is a need to override the system defaults. The command will return an error if the start and ending dates and times are not available either in Table 28 or entered as optional parameters in this command.
The following example displays the configured parameters.
NTP
Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. It allows for participating network nodes to keep time more accurately and maintain time in a synchronized manner between all participating network nodes.
NTP time elements include:
Authentication-check
The authentication-check command provides for the option to skip the rejection of NTP PDUs that do not match the authentication key or authentication type requirements. The default behavior when authentication is configured is to reject all NTP protocol PDUs that have a mismatch in either the authentication key ID, type, or key.
When authentication-check is configured, NTP PDUs are authenticated on receipt. However, mismatches cause a counter to be increased, one counter for key ID, one for type, and one for key value mismatches.
Authentication-key
This command configures an authentication key ID, key type, and key used to authenticate NTP PDUs sent to and received from other network elements participating in the NTP protocol. For authentication to work, the authentication key ID, authentication type, and authentication key value must match.
The following example shows NTP disabled with the authentication-key parameter enabled.
Broadcastclient
The broadcastclient command enables listening to NTP broadcast messages on the specified interface.
The following example shows NTP enabled with the broadcastclient parameter enabled.
MDA-timestamp
The mda-timestamp command enables timestamping on an adapter card by the network processor in order to allow more accurate timestamping for in-band NTP packets. Timestamping on an adapter card is only performed on Ethernet-based adapter cards. This command can only be set if NTP is shut down and all the NTP servers are not associated with an authentication key. This command does not change the behavior of NTP over the management port. Use the no form of this command to revert to the default behavior of having NTP packets timestamped by the CSM.
The following example shows enhanced NTP performance enabled using the mda-timestamp command.
Multicastclient
This command is used to configure an address to receive multicast NTP messages on the CSM Management port. The no form of this command removes the multicast client.
If multicastclient is not configured, all NTP multicast traffic will be ignored.
The following example shows NTP enabled with the multicastclient command configured.
Server
The server command is used when the node should operate in client mode with the NTP server specified in the address field. Use the no form of this command to remove the server with the specified address from the configuration.
Up to five NTP servers can be configured.
The following example shows NTP enabled with the server command configured.
SNTP
SNTP is a compact, client-only version of the NTP. SNTP can only receive the time from SNTP/NTP servers; it cannot be used to provide time services to other systems. SNTP can be configured in either broadcast or unicast client mode.
SNTP time elements include:
Broadcast-client
The broadcast-client command enables listening at the global device level to SNTP broadcast messages on interfaces with broadcast client enabled.
The following example shows SNTP enabled with the broadcast-client parameter enabled.
Server-address
The server-address command configures an SNTP server for SNTP unicast client mode.
The following example shows SNTP enabled with the server-address parameter configured.
CRON
The CRON command supports the Service Assurance Agent (SAA) functions as well as the ability to schedule turning on and off policies to meet “Time of Day” requirements. CRON functionality includes the ability to specify the commands that need to be run, when they will be scheduled, including one-time only functionality (oneshot), interval and calendar functions, as well as where to store the output of the results. In addition, CRON can specify the relationship between input, output, and schedule. Scheduled reboots, peer turn ups, service assurance agent tests and more can all be scheduled with CRON, as well as OAM events, such as connectivity checks or troubleshooting runs.
CRON elements include:
Action
Use this command to configure the parameters for a script, including the maximum amount of time to keep the results from a script run, the maximum amount of time a script may run, the maximum number of script runs to store, and the location to store the results.
The following example shows a script named “test” receiving an action to store its results in a file called “test-results”:
Schedule
The schedule function configures the type of schedule to run, including one-time-only (oneshot), periodic, or calendar-based runs. All runs are determined by month, day of month or weekday, hour, minute and interval (seconds). If end-time and interval are both configured, whichever condition is reached first is applied.
The following example schedules a script named “test2” to run every 15 minutes on the 17th of each month and every Friday until noon on September 17, 2010:
Script
The script command opens a new nodal context which contains information on a script.
The following example names a script “test”:
Configuring Synchronization and Redundancy
Use the CLI syntax displayed below to configure various synchronization and redundancy parameters:
Configuring Synchronization
The switchover-exec command specifies the location and name of the CLI script file executed following a redundancy switchover from the previously active CSM card.
Configuring Manual Synchronization
Automatic synchronization can be configured in the config>system> synchronization context.
Manual synchronization can be configured with the following command:
The following shows the output that displays during a manual synchronization:
Forcing a Switchover
The force-switchover now command forces an immediate switchover to the standby CSM card.
If the active and standby CSMs are not synchronized for some reason, users can manually synchronize the standby CSM by rebooting the standby by issuing the admin reboot standby command on the active or the standby CSM.
Configuring Synchronization Options
Network operators can specify the type of synchronization operation to perform between the primary and secondary CSMs after a change has been made to the configuration files or the boot environment information contained in the boot options file (BOF).
Use the following CLI command to configure the boot-env option:
The following displays the configuration:
Use the following CLI command to configure the config option:
The following example displays the configuration.
Configuring Multi-Chassis Redundancy
When configuring multi-chassis redundancy, configuration must be performed on the two nodes that will form redundant-pair peer nodes. Each node will point to its peer using the peer command.
When creating a multi-chassis LAG, the LAG must first be created under the config>lag lag-id context. Additionally, the LAG must be in access mode and LACP must be enabled (active or passive). Under the multi-chassis>peer>mc-lag context, the lag-id is the ID of the previously created LAG.
Use the CLI syntax displayed below to configure multi-chassis redundancy features:
The following displays the configuration:
Configuring ATM Parameters
The ATM context configures system-wide ATM parameters.
The following example shows the ATM configuration.
Configuring Backup Copies
The config-backup command allows you to specify the maximum number of backup versions of configuration and index files kept in the primary location.
For example, if the config-backup count is set to 5 and the configuration file is called xyz.cfg, the file xyz.cfg is saved with a .1 extension when the save command is executed. Each subsequent config-backup command increments the numeric extension until the maximum count is reached. The oldest file (5) is deleted as more recent files are saved.
- xyz.cfg
- xyz.cfg.1
- xyz.cfg.2
- xyz.cfg.3
- xyz.cfg.4
- xyz.cfg.5
- xyz.ndx
Each persistent index file is updated at the same time as the associated configuration file. When the index file is updated, then the save is performed to xyz.cfg and the index file is created as xyz.ndx. Synchronization between the active and standby CSMs is performed for all configurations and their associated persistent index files.
The following example shows the config-backup configuration.
Configuring System Administration Parameters
Use the CLI syntax displayed below to configure various system administration parameters.
Administrative parameters include:
Disconnect
The disconnect command immediately disconnects a user from a console, Telnet, FTP, SSH, or MPT craft terminal (MCT) session.
 | Note:
Configuration modifications are saved to the primary image file. |
The following example displays the disconnect command results.
Set-time
Use the set-time command to set the system date and time. The time entered should be accurate for the time zone configured for the system. The system will convert the local time to UTC before saving to the system clock which is always set to UTC. If SNTP or NTP is enabled (no shutdown), this command cannot be used. The set-time command does not take into account any daylight saving offset if defined.
The following example displays the set-time command results.
Display-config
The display-config command displays the system’s running configuration.
The following example displays a portion of the display-config detail command results.
Tech-support
The tech-support command creates a system core dump.
| Note:
This command should only be used with explicit authorization and direction from the Alcatel-Lucent Technical Assistance Center (TAC). |
Save
The save command saves the running configuration to a configuration file. When the debug-save parameter is specified, debug configurations are saved in the config file. If this parameter is not specified, debug configurations are not saved between reboots.
The following example displays the save command results.
Reboot
The reboot command reboots the router, including redundant CSMs in redundant systems. If the now option is not specified, you are prompted to confirm the reboot operation. The reboot upgrade command forces an upgrade of the boot ROM and a reboot.
If synchronization fails, the standby does not reboot automatically. The show redundancy synchronization command displays synchronization output information.
Post-Boot Configuration Extension Files
Two post-boot configuration extension files are supported and are triggered when either a successful or failed boot configuration file is processed. The commands specify URLs for the CLI scripts to be run following the completion of the boot-up configuration. A URL must be specified or no action is taken. The commands are persistent between router (re)boots and are included in the configuration saves (admin>save).
The following example displays the command output:
Show Command Output and Console Messages
The show>system>information command displays the current value of the bad/good exec URLs and indicates whether a post-boot configuration extension file was executed when the system was booted. If an extension file was executed, the show>system> information command also indicates if it completed successfully or not.
When executing a post-boot configuration extension file, status messages are output to the console screen prior to the “Login” prompt.
The following is an example of a failed boot-up configuration that caused a boot-bad-exec file containing another error to be executed:
System Timing
If network timing is required for the synchronous interfaces in a 7705 SAR, a timing subsystem is used to provide a Stratum 3 quality clock to all synchronous interfaces within the system. The clock source is specified in the config>port>tdm>ds1 | e1> clock-source context.
This section describes the commands used to configure and control the timing subsystem.
Entering Edit Mode
To enter the mode to edit timing references, you must enter the begin keyword at the config>system>sync-if-timing# prompt.
Use the following CLI syntax to enter the edit mode:
The following error message displays when the you try to modify sync-if-timing parameters without entering begin first.
Configuring Timing References
The following example shows the command usage:
The following displays the timing reference parameters:
Configuring IEEE 1588v2 PTP
Use the following CLI syntax to configure basic IEEE 1588v2 PTP parameters.
The following example shows the command usage:
The following display shows a basic IEEE 1588v2 PTP configuration:
Configuring QL Values for SSM
Use the following syntax to configure the quality level (QL) values for Synchronization Status Messaging (SSM).
The following example shows the command usage:
The following display shows a basic SSM QL configuration for the 7705 SAR-8:
The following display shows a basic SSM QL configuration for the 7705 SAR-18:
Using the Revert Command
The revert command allows the clock to revert to a higher-priority reference if the current reference goes offline or becomes unstable. With revertive switching enabled, the highest-priority valid timing reference will be used. If a reference with a higher priority becomes valid, a reference switchover to that reference will be initiated. If a failure on the current reference occurs, the next highest reference takes over.
With non-revertive switching, the active reference will always remain selected while it is valid, even if a higher-priority reference becomes available. If this reference becomes invalid, a reference switchover to a valid reference with the highest priority will be initiated. When the failed reference becomes operational, it is eligible for selection.
Other Editing Commands
Other editing commands include:
- commit — saves changes made to the timing references during a session Modifications are not persistent across system boots unless this command is entered.
- abort — discards changes that have been made to the timing references during a session
Forcing a Specific Reference
You can force the system synchronous timing output to use a specific reference.
| Note:
The debug sync-if-timing force-reference command should only be used to test and debug problems. Once the system timing reference input has been forced, it will not revert back to another reference unless explicitly reconfigured. |
When the command is executed, the current system synchronous timing output is immediately referenced from the specified reference input. If the specified input is not available (shut down), or in a disqualified state, the timing output will enter a holdover state based on the previous input reference.
Debug configurations are not saved between reboots.
Configuring System Monitoring Thresholds
Creating Events
The event command controls the generation and notification of threshold crossing events configured with the alarm command. When a threshold crossing event is triggered, the rmon event configuration optionally specifies whether an entry in the RMON-MIB log table will be created to record the occurrence of the event. It can also specify whether an SNMP notification (trap) will be generated for the event. There are two notifications for threshold crossing events, a rising alarm and a falling alarm.
Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the 7705 SAR event logs. However, when the event is set to trap, the generation of a rising alarm or falling alarm notification creates an entry in the 7705 SAR event logs and that is distributed to whatever 7705 SAR log destinations are configured: console, session, memory, file, syslog, or SNMP trap destination. The 7705 SAR logger message includes a rising or falling threshold crossing event indicator, the sample type (absolute or delta), the sampled value, the threshold value, the rmon-alarm-id, the associated rmon-event-id and the sampled SNMP object identifier.
The alarm command configures an entry in the RMON-MIB alarm table. The alarm command controls the monitoring and triggering of threshold crossing events. In order for notification or logging of a threshold crossing event to occur there must be at least one associated rmon event configured.
The agent periodically takes statistical sample values from the MIB variable specified for monitoring and compares them to thresholds that have been configured with the alarm command. The alarm command configures the MIB variable to be monitored, the polling period (interval), sampling type (absolute or delta value), and rising and falling threshold parameters. If a sample has crossed a threshold value, the associated ‘event’ is generated.
Preconfigured CLI threshold commands are available. Preconfigured commands hide some of the complexities of configuring RMON alarm and event commands and perform the same functions. In particular, the preconfigured commands do not require the user to know the SNMP object identifier to be sampled. The preconfigured threshold configurations include memory warnings, alarms, and compact flash usage warnings and alarms.
To create events, use the following CLI syntax:
The following example displays the command output:
Configuring LLDP
Use the following syntax to configure LLDP:
The following example shows the system LLDP configuration: