6.11. Configuring System Management with CLI
This section provides information about configuring system management features with CLI.
6.11.1. Saving Configurations
Whenever configuration changes are made, the modified configuration must be saved so the changes are not 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. See Boot Options for more information about boot option files.
Configuration files are saved by executing implicit or explicit command syntax.
- An explicit save writes the configuration to the location specified in the save command syntax using 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) has changed since the last boot, the new configuration source is used.
Use the detail option of the save command to save both default and non-default configuration parameters.
The index option ensures that the system preserves system indexes when a save command is executed, regardless of the persistent status in the BOF. 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.
6.11.2. 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.
6.11.3. Common Configuration Tasks
This section provides an overview of the following tasks that must be performed to configure system parameters, and describes the associated CLI commands.
6.11.3.1. System Information
This section describes the basic system information parameters to configure the physical location of the router, contact information, location information for the router such as an address, floor, and room number, global positioning system (GPS) coordinates, and system name.
Use the CLI syntax displayed in this section to configure the following system components:
6.11.3.1.1. System Information Parameters
This section describes the system information parameters.
General system parameters include:
6.11.3.1.1.1. 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 is a sample configuration for the system name command.
6.11.3.1.1.2. Contact
Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.
Use the following syntax to specify the contact name.
The following example shows the command usage to specify the contact name.
6.11.3.1.1.3. 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.
The following example shows the command usage to configure the location of the device.
6.11.3.1.1.4. 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 router.
Use the following CLI command syntax to define the CLLI code.
The following example shows the command usage to define the CLLI code.
6.11.3.1.2. Coordinates
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 shows the command usage to configure the location.
The following is a sample configuration output of the general system commands.
6.11.3.1.3. 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:
6.11.3.1.3.1. Zone
The zone command sets the time zone and/or time zone offset for the device. The 7210 SAS OS supports system-defined and user-defined time zones.
Use the following CLI syntax to set the time zone.
The following example shows the command usage to set the time zone.
The following is a sample zone output:
Table 41 describes the system-defined time zones.
Table 41: 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 (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 |
6.11.3.1.3.2. 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 is adjusted by adding the configured offset when summer time starts and subtracting the configured offset when summer time ends.
Use the following CLI syntax to configure daylight savings time.
The following example shows the command usage to configure daylight savings time.
If the time zone configured is listed in Table 41, 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 41 or entered as optional parameters in this command.
The following is a sample output for the configured parameters.
6.11.3.1.3.3. NTP
Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. It enables participating network nodes to keep time more accurately and maintain time in a synchronized manner between all participating network nodes.
NTP time elements include:
6.11.3.1.3.3.1. Authentication-check
The authentication-check command provides 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 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 incremented, one counter for key-id, one for type, and one for key value mismatches.
Use the following CLI syntax to authenticate NTP PDUs on receipt.
The following example shows the command usage to authenticate NTP PDUs on receipt.
6.11.3.1.3.3.2. 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.
Use the following CLI syntax to configure an authentication key ID, key type, and key.
The following example shows the command usage to configure an authentication key-id, key type, and key.
The following sample configuration shows NTP disabled with the authentication-key parameter enabled.
6.11.3.1.3.3.3. Broadcast
The broadcast command is used to transmit broadcast packets on a specific subnet.
Use the following CLI syntax to transmit broadcast packets.
The following example shows the command usage to transmit broadcast packets.
The following sample configuration of the system>time context shows NTP enabled with the broadcast command configured.
The following sample configuration shows NTP enabled in the config context with the broadcast command configured. At this level, the NTP broadcast commands are displayed at the end of the output after the router interfaces are shown.
6.11.3.1.3.4. Broadcastclient
The broadcastclient command enables listening to NTP broadcast messages on the specified interface.
Use the following CLI syntax to enable listening to NTP broadcast messages.
The following example shows the command usage to enable listening to NTP broadcast messages.
The following is a sample configuration of NTP enabled with the broadcastclient parameter enabled.
6.11.3.1.3.4.1. NTP-Server
This 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 an authentication key-id is specified in this command, the NTP server requires client packets to be authenticated.
Use the following CLI syntax to configure the node to function as an NTP client only.
The following example shows the command usage to configure the node to function as an NTP client only.
The following is a sample configuration output of NTP enabled with the ntp-server command configured.
6.11.3.1.3.4.2. Peer
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, Nokia recommends to configure authentication and to configure known time servers as their peers. Use the no form of the command to remove the configured peer.
Use the following CLI syntax to configure symmetric active mode.
The following example shows the command usage to configure symmetric active mode.
The following is a sample configuration output of NTP enabled with the peer command configured.
6.11.3.1.3.4.3. 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.
Use the following CLI syntax to configure the node to operate in client mode.
The following example shows the command usage to configure the node to operate in client mode.
The following is a sample configuration of NTP enabled with the server command configured.
6.11.3.1.3.5. 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:
Use the following CLI syntax to configure the SNTP.
6.11.3.1.3.5.1. Broadcast-client
The broadcast-client command enables listening at the global device level to SNTP broadcast messages on interfaces with broadcast client enabled.
Use the following CLI syntax to enable listening to SNTP broadcast messages at the global device level.
The following example shows the command usage to enable listening to SNTP broadcast messages at the global device level.
The following is a sample configuration output of SNTP enabled with the broadcast-client command enabled.
6.11.3.1.3.5.2. Server-address
The server-address command configures an SNTP server for SNTP unicast client mode.
Use the following CLI syntax to configure an SNTP server for unicast client mode.
The following example shows the command usage to configure an SNTP server for unicast client mode.
The following is a sample configuration output of SNTP enabled with the server-address command configured.
6.11.3.1.3.6. CRON
The cron command supports the Service Assurance Agent (SAA) functions and 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:
6.11.3.1.3.6.1. 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.
Use the following CLI syntax to configure the parameters for a script.
The following example shows the command usage to configure the parameters for a script.
The following sample output shows a script named “test” receiving an action to store its results in a file called “test-results”.
6.11.3.1.3.6.2. 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.
Use the following CLI syntax to configure the type of schedule to run.
The following example shows the command usage to configure the type of schedule to run.
The following is sample configuration output that 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.
6.11.3.1.3.6.3. Script
The script command opens a new nodal context that contains information about a script.
Use the following CLI syntax to create a nodal context.
The following example shows the command usage to create a nodal context called “test”.
The following is a sample configuration output that names a script “test”:
6.11.3.1.3.7. Time Range
ACLs and QoS policy configurations may be enhanced to support time-based matching. CRON configuration includes time matching with the schedule subcommand. Schedules are based on events; time-range defines an end-time that is used as a match criteria.
Time range elements include:
6.11.3.1.3.7.1. Create
This command can be used to enable the time-range context.
Use the following syntax to create a time-range.
The following example shows the command usage to create a time-range called "test1".
6.11.3.1.3.7.2. Absolute
The absolute command configures a start and end time that will not repeat.
Use the following syntax to configure a non-repetitive time range.
The following example shows the command usage to configure a non-repetitive time range.
The following is a sample configuration output of an absolute time range beginning on May 5, 2006 at 11:00 and ending May 6, 2006 at 11:01.
6.11.3.1.3.7.3. Daily
The daily command configures the start and end of a periodic schedule for every day of the week (Sunday through Saturday).
Use the following syntax to configure a time range that is repeated daily.
The following example shows the command usage to create a time range that is repeated daily.
The following is a sample configuration output of a daily time range beginning at 11:00 and ending at 12:00.
6.11.3.1.3.7.4. Weekdays
The weekdays command configures the start and end of a periodic schedule for weekdays (Monday through Friday).
Use the following syntax to configure a time range that is repeated on weekdays.
The following example shows the command usage to create a time range that is repeated on weekdays.
The following is a sample configuration output of a time range beginning at 11:00 and ending at 12:00. This schedule runs all weekdays during this time period.
6.11.3.1.3.7.5. Weekend
The weekend command configures the start and end of a periodic schedule for weekends (Saturday and Sunday). The resolution must be at least one minute apart, for example, start at 11:00 and end at 11:01. A start time and end time of 11:00 is invalid.
Use the following syntax to configure a time range that is repeated on weekends.
The following example shows the command usage to create a time range that is repeated on weekends.
The following is a sample configuration output of a weekend time range beginning at 11:00am and ending at 12:00pm, both Saturday and Sunday.
To specify 11:00am to 12:00pm on Saturday or Sunday only, use the absolute parameter for one day, or the weekly parameter for every Saturday or Sunday accordingly. In addition, see the schedule parameter to schedule oneshot or periodic events in the config>system>cron context.
6.11.3.1.3.7.6. Weekly
The weekly command configures the start and end of a periodic schedule for the same day every week, for example, every Friday. The start and end dates must be the same. The resolution must be at least one minute apart, for example, start at 11:00 and end at 11:01. A start time and end time of 11:00 is invalid.
Use the following syntax to configure a time range that is repeated weekly.
The following example shows the command usage to create a time range is repeated weekly.
The following is a sample configuration output of a weekly time range beginning on Friday at 1:01am ending Friday at 1:02am.
6.11.3.1.3.8. Time of Day
Time of Day (TOD) suites are useful when configuring many types of time-based policies or when a large number of subscribers or SAPs require the same type of TOD changes. The TOD suite may be configured while using specific ingress or egress ACLs or QoS policies, and is an enhancement of the ingress and egress CLI trees.
Time of day elements include:
6.11.3.1.3.8.1. SAPs
- If a TOD Suite is assigned to a SAP, statistics collection are not collected for that SAP.
- When an item is configured both on SAP level and in the TOD suite assigned to the SAP, the TOD-suite defined value takes precedence.
- A policy or filter assignment configured directly on a SAP has a lower priority than any assignment in a TOD Suite. Therefore, it is possible that a new direct configuration has no immediate effect. If the configuration is made by CLI, a warning is given.
6.11.3.1.3.8.2. Egress
This command is an enhancement for specific egress policies. Use this command to create time-range based associations of previously created filter lists, QoS and scheduler policies. Multiple policies may be included and each must be assigned a different priority; in case time-ranges overlap, the priority will be used to determine the prevailing policy. Only a single reference to a policy may be included without a time-range.
6.11.3.1.3.8.3. Filters
In a TOD suite, filters that have entries with time-ranges may not be selected. Similarly, filter entries with a time-range may not be created while a TOD suite refers to that filter. QoS policies and filters referred to by a TOD suite must have scope “template” (default).
Use the following syntax to configure TOD-suite egress parameters.
The following example shows the command usage to configure TOD-suite egress parameters.
The following is a sample configuration output of an egress IP filter association with filter ID 100.
6.11.3.1.3.8.4. Ingress
This command is an enhancement for specific ingress policies including filter lists and QoS policies. Use this command to create time-range based associations of previously created filter lists and QoS policies. Multiple policies may be included and each must be assigned a different priority; in case time-ranges overlap, the priority will be used to determine the prevailing policy. Only a single reference to a policy may be included without a time-range. To configure a daily time-range across midnight, use a combination of two entries. An entry that starts at hour zero will take over from an entry that ends at hour 24.
Use the following syntax to configure time range based associations.
The following example shows the command usage to configure an IP filter association.
The following is a sample configuration output of an ingress IP filter association with filter ID 100.
The following example shows the command usage to configure an association with a SAP ingress QoS policy..
The following is a sample configuration output of an association with SAP ingress QoS policy 101.
6.11.3.2. Configuring Backup Copies
The config-backup command allows you to specify the maximum number of backup versions of the 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 named xyz.cfg. When a save command is issued, the xyz.cfg file 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, the save is performed to xyz.cfg and the index file is created as xyz.ndx. Synchronization between the active and standby is performed for all configurations and their associated persistent index files.
Use the following syntax to specify the maximum number of backup versions of the configuration and index files kept in the primary location.
The following example shows the command usage to set the maximum number of backup versions of the configuration and index files kept in the primary location to 7.
The following is a sample configuration output for the config-backup command.
6.11.4. System Administration Parameters
This section describes the CLI syntax to configure the following system administration parameters.
6.11.4.1. Validating the Golden Bootstrap Image
The admin>check-golden-bootstrap command validates the current golden bootstrap image and displays its version. A default golden bootstrap image is installed on each 7210 SAS-M device.
Use the following syntax to validate the golden boot strap image.
The following example shows the command usage to validate the golden boot strap image.
The following is a sample output.
6.11.4.2. Updating the Golden Bootstrap Image
The admin>update-golden-bootstrap command validates the input file, which must be a 7210 SAS-M bootstrap image, and updates the golden bootstrap image with the contents of this file.
Use the following syntax to update the golden bootstrap image.
The following example shows the command usage to update the golden bootstrap image.
The following is a sample output.
6.11.4.3. Disconnect
The disconnect command immediately disconnects a user from a console, Telnet, FTP, or SSH session.
 | Note: Configuration modifications are saved to the primary image file. |
Use the following syntax to disconnect a user from a session.
The following example shows the command usage to disconnect a user from a session.
The following is a sample output of the disconnect command.
6.11.4.4. 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.
Use the following syntax to set the date and time.
The following example shows the command usage to set the date and time.
The following is a sample output of the set-time command.
6.11.4.5. Display-config
The display-config command displays the running configuration of the system.
Use the following syntax to display the running configuration of the system.
The following example shows the command usage to display the running configuration of the system.
The following is a portion of the sample configuration output of the display-config detail command.
6.11.4.6. Tech-support
The tech-support command creates a system core dump.
| Note: This command should only be used with explicit authorization and direction from Nokia’s Technical Assistance Center (TAC). |
6.11.4.7. Save
The save command saves the running configuration to a configuration file. If the debug-save parameter is specified, debug configurations are saved in the configuration file; otherwise, the debug configurations are not saved between reboots.
Use the following syntax to save the running configuration.
The following example shows the command usage to save the running configuration.
The following is a sample configuration output of the save command.
6.11.4.8. Reboot
The reboot command reboots the router including redundant cards 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 device firmware (CPLD and ROM) and reboots.
Use the following syntax to reboot the router.
The following example shows the command usage to reboot the router.
The following is a sample output of the reboot command.
When an admin reboot auto-init command is issued, the system resets the existing BOF and reboots. The system startup process after the admin reboot auto-init command is executed is the same as the first time system boot described in System Initialization.
| Note: After the BOF is reset, the system may not boot up with the last saved system configuration unless the new BOF also uses the same configuration file. If you require the system to boot up with the last saved system configuration, Nokia recommends that you should run the admin>save file-url command to save the current system configuration and modify the BOF to use this configuration. |
Use the following syntax to reset the BOF and reboot.
The following is a sample output of the admin reboot auto-init command.
6.11.4.9. 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 that are 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 reboots and are included in the configuration saves (admin>save).
Use the following syntax to configure a URL for a CLI script that runs when the boot-up configuration is completed.
The following example shows the command usage to configure a URL for a CLI script that runs when the boot-up configuration is completed.
The following is a sample command output.
6.11.4.9.1. Show Command Output and Console Messages
The show>system>information command displays the current value of the bad and 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.
When executing a post-boot configuration extension file, status messages are output to the CONSOLE screen before the “Login” prompt.
The following is a sample output of a failed boot-up configuration that caused a boot-bad-exec file containing another error to be executed.
6.11.5. System Timing
When synchronous Ethernet is enabled, the operator can select an Ethernet port as a candidate for timing reference. The timing information recovered from this port is used to time the system.
6.11.5.1. CLI command Syntax for 7210 SAS Platforms
This section describes the CLI command syntax to enable synchronous Ethernet on specific 7210 SAS platforms.
6.11.5.1.1. CLI Syntax for the 7210 SAS-M
The following is a sample CLI configuration for the 7210 SAS-M.
6.11.5.1.2. CLI Syntax for 7210 SAS-R6 and 7210 SAS-R12
The following is a sample CLI configuration for the 7210 SAS-R6 and 7210 SAS-R12.
6.11.5.1.3. CLI Syntax for 7210 SAS-T
The following is a sample CLI configuration for the 7210 SAS-T.
6.11.5.1.4. CLI Syntax for 7210 SAS-Mxp
The following is a sample CLI configuration for the 7210 SAS-Mxp.
6.11.5.1.5. CLI Syntax for 7210 SAS-Sx/S 1/10GE:
The following is a sample CLI configuration for the 7210 SAS-Sx/S 1/10GE.
6.11.5.2. Entering Edit Mode
To enter edit mode and edit timing references, enter the begin keyword at the config>system>sync-if-timing# prompt.
Use the following CLI syntax to enter the edit mode.
The following is a sample error message that is displayed if you try to modify sync-if-timing parameters without entering the begin keyword.
| Note: Use commit to save or abort to discard the changes made in a session. |
6.11.5.3. Configuring Timing References
The following is a sample configuration of timing reference parameters.
Example:
The following is a sample output of the timing reference parameters.
6.11.5.4. 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.
If revertive switching is enabled, the highest-priority valid timing reference is used. If a reference with a higher priority becomes valid, a switchover 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 active reference always remains selected while it is valid, even if a higher priority reference becomes available. If the active reference becomes invalid, a reference switchover to a valid reference with the highest priority is initiated. The failed reference is eligible for selection when it becomes operational.
Use the following syntax to revert the clock to a higher priority reference.
6.11.5.5. Other Editing Commands
Other editing commands are:
- 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.
Use the following syntax to abort or commit changes made to a timing reference.
6.11.5.6. 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. After the system timing reference input has been forced, it will not revert to another reference unless explicitly reconfigured, or if the forced reference fails, or if the received QL code is QL-DNU/DUS and QL selection is enabled. |
When the debug sync-if-timing force-reference command is run, the current system synchronous timing output is immediately referenced from the specified reference input. The reference must be qualified.
Debug configurations are not saved between reboots.
Use the following syntax to reference the current system synchronous timing output from the specifies reference input.
The following example shows the command usage to reference the current system synchronous timing output from the specifies reference input.
6.11.6. Configuring System Monitoring Thresholds
This section describes how to configure system monitoring thresholds.
6.11.6.1. 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 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.ping-address.
Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the 7210 SAS 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 the configured log destinations, including 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. To trigger the notification or logging of a threshold crossing event, at least one associated rmon event must be 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, alarms, and compact flash usage warnings and alarms.
To create events, use the following sample CLI configuration.
The following is a sample command output.
6.11.6.2. System Alarm Contact Inputs
7210 SAS hardware supports alarm contact inputs that allow the operator to monitor and report changes in external environmental conditions. In a remote or outdoor deployment, alarm contact inputs allow the operator to detect conditions, for example, air conditioner fault, open door.
You can configure generation of events when alarm contact inputs transition between the open and close states. For each generated event, you can specify the following:
- action associated with each state transition
- severity associated with each state transition
- log message associated with each state transition
6.11.7. Configuring 1830 VWM
The following is a sample output for the creation of a vwm-shelf.
| Note: Card 1 corresponds to slot #1 and card 2 corresponds to slot #2 on the 1830 CWDM device. The optical modules or line cards are inserted into these slots. |
The following is a sample output for the deletion of a vwm-shelf.
6.11.8. Configuring LLDP
Use the following syntax to configure LLDP.
The following is a sample LLDP port configuration.
The following is a sample global system LLDP configuration.