This section provides information about configuring system management features with CLI.
Topics in this chapter include:
Whenever configuration changes are made, the modified configuration must be saved so 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, refer to the Boot Options.
Configuration files are saved by executing implicit or explicit command syntax.
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, path IDs, etc. 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.
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:
This section provides a brief overview of the tasks that must be performed to configure system parameters and provides the CLI commands.
This section covers the basic system information parameters to configure the physical location of the router, contact information, location information such as the place the router is located such as an address, floor, room number, etc., global positioning system (GPS) coordinates, and system name.
Use the CLI syntax displayed below to configure the following system components:
General system parameters include:
Use the system 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:
Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.
Use the location command to specify the system location of the device. For example, enter the city, building address, floor, room number, etc., where the router is located.
Use the following CLI syntax to configure the location:
The Common Language Location Code (CLLI code) is an 11-character standardized geographic identifier that is used to uniquely identify the geographic location of an SR-series router.
Use the following CLI command syntax to define the CLLI code:
Use the optional coordinates command to specify the GPS location of the device. If the string contains special characters (#, $, spaces, etc.), 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:
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:
The zone command sets the time zone and/or time zone offset for the router. The router supports system-defined and user-defined time zones. The system-defined time zones are listed in Table 39.
The following example displays the zone output:
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 (e.g., Perth) | UTC +8 hours |
ACST | Central Standard Time (e.g., Darwin) | UTC +9.5 hours |
AEST | Eastern Standard/Summer Time (e.g., Canberra) | UTC +10 hours |
NZT | New Zealand Standard Time | UTC +12 hours |
NZDT | New Zealand Daylight Saving Time | UTC +13 hours |
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 39, 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 39 or entered as optional parameters in this command.
The following example displays the configured parameters.
Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis and RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification. 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:
NTP supports an authentication mechanism to provide some security and access control to servers and clients. The default behavior when any authentication keys are configured is to reject all NTP protocol PDUs that have a mismatch in either the authentication key-id, type, or key. The authentication-check command provides for the options to skip or maintain this rejection of NTP PDUs that do not match the authentication requirements.
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.
The authentication-key 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.
The broadcast command is used to transmit broadcast packets on a given interface. Interfaces in the base routing context or the management interface may be specified. Due the relative ease of spoofing of broadcast messages, it is strongly recommended to use authentication with broadcast mode. The messages are transmitted using a destination address that is the NTP Broadcast address.
The following example in the system>time context shows NTP enabled with the broadcast command configured.
The broadcastclient command enables listening to NTP broadcast messages on the specified interface. Interfaces in the base routing context or the management interface may be specified. Due the relative ease of spoofing of broadcast messages, it is strongly recommended to use authentication with broadcast mode. The messages must have a destination address of the NTP Broadcast address.
The following example shows NTP enabled with the broadcastclient parameter enabled.
When configuring NTP the node can be configured to transmit or receive multicast packets on the CPM MGMT port (CPM applies to the 7450 ESS and 7750 SR). Broadcast & Multicast messages can easily be spoofed, therefore, authentication is strongly recommended. Multicast is used to configure the transmission of NTP multicast messages. The no construct of this command removes the transmission of multicast packets on the management port.
When transmitting multicast NTP messages the default address of 224.0.1.1 is used.
The following example shows NTP enabled with the multicast command configured.
The multicastclient command is used to configure an address to receive multicast NTP messages on the CPM MGMT port (7450 ESS and 7750 SR). Broadcast & Multicast messages can easily be spoofed, therefore, authentication is strongly recommended. The no construct 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.
The ntp-server command configures the node to assume the role of an NTP server. Unless the server command is used this node will function as an NTP client only and will not distribute the time to downstream network elements. If authentication is specified in this command, the NTP server requires client packets to be authenticated based on the key received in the client request.
The following example shows NTP enabled with the ntp-server command configured.
Configuration of an NTP peer configures symmetric active mode for the configured peer. Although any system can be configured to peer with any other NTP node, it is recommended to configure authentication and to configure known time servers as their peers. Use the no form of the command to remove the configured peer.
The following example shows NTP enabled with the peer command configured.
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 ten NTP servers can be configured.
The following example shows NTP enabled with the server command configured.
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:
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 command enabled.
The server-address command configures an SNTP server for SNTP unicast client mode.
The following example shows SNTP enabled with the server-address command configured.
CRON provides various time and date scheduling functions. Configuration notes for the CRON schedule are provided below.
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 July 17, 2007:
Persistency is available for subscriber’s ANCP attributes and is stored on the on-board compact flash card. ANCP data will stay persistence during an ISSU as well as nodal reboots. During recovery, ANCP attributes are first restored fully from the persistence file, and incoming ANCP sessions are temporarily on hold. Afterwards, new ANCP data can overwrite any existing values. This new data is then stored into the compact flash in preparation for the next event.
The following example displays subscriber management system persistence command usage for the 7450 ESS and 7750 SR:
The switchover-exec command specifies the location and name of the CLI script file executed following a redundancy switchover from the previously active CPM card.
Note that automatic synchronization can be configured in the config>system> synchronization context.
The following shows the output which displays during a manual synchronization:
The force-switchover now command forces an immediate switchover to the standby CPM card.
If the active and standby are not synchronized for some reason, users can manually synchronize the standby CPM by rebooting the standby by issuing the admin reboot standby command on the active or the standby CPM.
Network operators can specify the type of synchronization operation to perform between the primary and secondary CPMs 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 to configure the boot-env option:
The following displays the configuration:
Use the following CLI to configure the config option:
The following example displays the configuration.
When configuring associated LAG ID parameters, the LAG must be in access mode and LACP must be enabled.
Use the CLI syntax displayed below to configure multi-chassis redundancy features.
The following displays the configuration:
The 7450 mixed mode feature allows a 7450 ESS-7 or ESS-12 chassis to utilize 7750 IOM3-XPs, MDAs, and IMMs to enable 7750 SR capabilities on the associated slots. This allows features such as multicast routing, VPRN and IPv6 support as well as others to be enabled on existing 7450 systems.
The following are mixed-mode requirements:
Notes:
To configure mixed mode support, 7750 SR IOM3-XPs, 7750 MDAs, or 7750 SR IMMs must be installed in a 7450 ESS-7 or ESS-12 router that is running OS 8.0 or later. All network interfaces must be migrated to ports on the 7750 SR cards.
The mixed mode state is then enabled by using the mixed-mode-upgrade command:
This tool will take a list of slots that should have 7750 SR cards installed. The command then checks to ensure that all network interfaces are located on ports on these slots and that they are all 7750 SR cards. It then enables the mixed-mode state at the system level and changes the capability setting for the specified slots to sr.
At this point the 7450 ESS system is operating in a mixed mode state and supported features and services can now be configured on the slots with SR capabilities enabled.
Once in mixed mode use the capability command to configure slots for SR capabilities:
Slots using 7750 SR-capable cards will have to have 7750 SR capability enabled on all slots with 7750 SR IOM3s and IMMs, as well as mixed-mode at the system level.
See Table 40 for a description of mixed-mode support.
![]() | Note:
This table is not intended to be exhaustive, but to provide examples to illustrate the basic principle of mixed versus non-mixed mode operation. |
Feature | 7450 ESS Standard Mode | 7450 ESS Mixed Mode (Limited to 7750 SR IOM3/IMM) |
Full IES Support | Limited IES support | Yes |
Full VPRN Support | No | Yes |
BGP for routing (all address families) | No | Yes |
IPv6 routing: IPv6 routing (Unicast and Multicast) 6PE 6VPE (IPv6 VPRN) | No | Yes |
IP Multicast routing and forwarding Protocols: PIM, MSDP and IGMP mVPN P2MP LSP support | No | Yes |
Spoke termination on L3 (IES/VPRN) interfaces | No | Yes |
TPSDA IPv4 & v6 Routed subscriber management support PPPoE support SRRP Routed subscriber management for wholesale | No | Yes |
IP Mirroring | No | Yes |
The following is a default example for the 7750 SR and 7950 XRS:
The following is a default example for the 7450 ESS:
The ATM context configures system-wide ATM parameters for the 7750 SR.
The following example shows the ATM configuration.
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, assume the config-backup count is set to 5 and the configuration file is called xyz.cfg. When a save command is executed, the file xyz.cfg is saved with a .1 extension. 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 SF/CPMSF/CPM is performed for all configurations and their associated persistent index files.
The following example shows the config-backup configuration.
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:
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.
The following is an example for the 7750 SR:
When executing a post-boot configuration extension file, status messages are output to the CONSOLE screen prior to the “Login” prompt.
Following is an example of a failed boot-up configuration that caused a boot-bad-exec file containing another error to be executed:
In the event that network timing is required for the synchronous interfaces in the router, a timing subsystem is utilized to provide a clock to all synchronous interfaces within the system.
This section describes the commands used to configure and control the timing subsystem.
Use the CLI syntax displayed below to:
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 the keyword begin.
Use the following CLI syntax to configure timing reference parameters. The source port specified for ref1 and ref2 is dependent on the router model type and chassis slot. Please refer to the details in the specific command descriptions.
The following displays a timing reference configuration example for the router:
The revert command allows the clock to revert to a higher priority reference if the current reference goes offline or becomes unstable. When the failed reference becomes operational, it is eligible for selection.
When mode is non-revertive, a failed clock source is not selected again. If a node would enter holdover due to the references being in previous failed state, then the node will select one of the previously failed references rather than going into holdover.
If the current reference goes offline or becomes unstable the revert command allows the clock to revert to a higher-priority reference.
When revertive switching enabled a valid timing reference of the highest priority is used. If a reference with a higher priority becomes valid, a reference switch over to that reference is initiated. If a failure on the current reference occurs, the next highest reference takes over.
If non-revertive switching is enabled, the valid active reference always remains selected even if a higher priority reference becomes available. If the active reference becomes invalid, a reference switch over to a valid reference with the highest priority is initiated. The failed reference is eligible for selection once it becomes operational.
Other editing commands include:
The debug sync-if-timing force-reference command should only be used to test and debug problems. Network synchronization problems may appear if network elements are left with this manual override setting. Once the system timing reference input has been forced, it may be cleared using the no force-reference command.
You can force the CPM clock to use a specific input reference using the force-reference command.
When the command is executed, the CPM clock on the active CPM immediately switches its input reference to that specified by the command. If the specified input is not available (shutdown), or in a disqualified state, the CPM clock shall use the next qualified input reference based on the selection rules.
This command also affects the BITS output port. If the BITS output port selection is set to line-reference and the reference being forced is not the BITS input port, then the system uses the forced reference to generate the signal out the BITS output port. If the BITS output port selection is set to internal-clock, then the system uses the output of the CPM clock to generate the signal for the BITS output port.
On a CPM activity switch, the force command is cleared and normal reference selection is determined.
Debug configurations are not saved between reboots.
The 7750 SR-c4 has two BITS input ports on the CFM. The force reference command on this system allows the selection of the specific port.
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 be created to record the occurrence of the event. It can also specify whether an SNMP notification (trap) be generated for the event. There are two notifications for threshold crossing events, a rising alarm and a falling alarm.ping-address
Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the 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 event logs and that is distributed to whatever log destinations are configured: console, session, memory, file, syslog, or SNMP trap destination. The 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 function. 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 and alarms and compact flash usage warnings and alarms.
To create events, use the following CLI:
The following example displays the command output:
Alarm contact inputs are physical input pins on the Alarms Interface Port of the CPM that allow the operator to monitor and report changes in external environmental conditions. In a remote or outdoor deployment, alarm inputs typically allow an operator to detect conditions such as whether a door is open or closed, an air conditioner fault has occurred, and so on.
There are four input pins, each of which can be configured with an associated severity level and normally open/normally closed state. When an input pin changes state, the router can generate log events and raise facility alarms.
There is a separate log event for each pin (for example, CHASSIS event 3003 tmnxSasAlarminput3StateChanged for input pin 3). The severity level of input pin 3 is controlled by configuring the severity level of the associated log event (using the configure log event-control command).
There is also a single +24VDC power output pin on the Alarms Interface Port of the CPM that can be used to supply power for the alarm inputs.
The alarm inputs can be powered in one of two ways:
The power output pin provided on the CPM is monitored, and the router can report when the power source fails.
If using an external power source for the alarm inputs, then it is recommended that the normal-state closed configuration be used so that a failure of the external power source will trigger all the alarm pins to detect a change of state. If normal-state open is used, a failure of the external power source will not generate any notifications and the alarm input pins will no longer operate correctly.
The following output displays LLDP defaults:
The following example shows an LLDP port configuration:
The following example shows a global system LLDP configuration: