|
|
This chapter explains operation, administration, and maintenance of the Cisco Optical Networking System (ONS) 15303. The different modes in the Cisco IOS software are described as well as how to interpret various performance and fault management statistics.
Cisco IOS software provides the EXEC command interpreter to interpret the commands you type and execute the corresponding operations.
The two EXEC levels of access to commands are user mode and privileged mode.
When you first log in to the Cisco ONS 15303, you will be in user EXEC mode automatically. To exit user EXEC mode, type logout at the prompt.
The EXEC command interpreter waits for a specified time for you to start input. If no input is detected, EXEC resumes the current connection and you log in to the Cisco ONS 15303 again. The default interval the Cisco ONS 15303 waits for input is 10 minutes; an interval of zero means the Cisco ONS 15303 will not time out. The no exec-timeout command removes the timeout definition and is the same as entering the exec-timeout 0 command. Enter this command in line configuration mode.
You enter privileged EXEC mode by entering enable at the user EXEC mode prompt. Because many of the privileged commands set operating parameters, privileged access should be password protected to prevent unauthorized use. Exit privileged EXEC mode by entering the disable or exit commands. Type exit or logout to log out of the Cisco ONS 15303.
Screen output depends on the version of Cisco IOS software you are using and how you have configured the Cisco ONS 15303.
When you are in the user EXEC mode, you can display the available commands by typing a question mark (?) at the EXEC prompt.
The screen displays 22 lines at one time. The "--More--" prompt at the bottom of the display indicates that multiple screens are available as output. You can resume output of the next available screen by pressing the spacebar. To display the next line, press the Return key (or on some systems, the Enter key). Press any key to return to the user EXEC prompt.
The screen output depends on the version of Cisco IOS software you are using and how you have configured the Cisco ONS 15303.
As in the user EXEC mode, you can display the available commands for the privileged EXEC mode by typing a question mark (?) at the privileged prompt to display a larger list of EXEC commands.
ROM monitor mode allows you to configure the Cisco ONS 15303. ROM monitor mode occurs if your Cisco ONS 15303 does not find a valid system image (the system will only attempt to boot ROM monitor mode if the configuration registration has been configured to boot from the ROM monitor mode) or if you interrupt the boot sequence during startup. The ROM monitor prompt is the angle bracket (>). On the Cisco ONS 15303, rommon> is the default ROM monitor prompt. The continue command takes you from ROM monitor to user EXEC mode. For more information on ROM monitor, see "ROM Monitor."
Setup mode is an interactive prompted dialog at the console that helps the new user create a first-time basic configuration. You can also enter setup mode by entering setup at the privileged EXEC prompt. Setup mode consists of questions and does not exhibit a defining prompt of its own. Cisco ONS 15303-related commands are not supported in this mode.
Global configuration commands apply to features that affect the entire system. You initiate global configuration mode by entering the configure command at the privileged EXEC mode prompt. Global configuration mode is indicated by the device host name (config) followed by the pound sign (#). To exit to privileged EXEC mode, enter exit, end, or press Ctrl-Z at the prompt.
Other configuration modes can be accessed from the global configuration mode. These modes provide more specific multiple-line configurations that target individual interfaces or functionality such as modifying the operation of an interface, configuring multiple virtual interfaces on a single physical interface, or setting an IP routing protocol. There are more than 17 different specific configuration modes. See the Cisco IOS Configuration Guide or the Configuration Guide Master Index available online and on the Documentation CD-ROM for more information on the other configuration modes.
Context-sensitive help allows you to get a list of any keywords and arguments associated with a specific command. Both the user and privileged EXEC modes support context-sensitive help.
You can abbreviate the commands and keywords to the number of characters that allow a unique abbreviation. For example, you can abbreviate the clock command to clo. However, if you enter a nonunique abbreviation, context-sensitive help will provide you with all applicable commands for that abbreviation. For example, entering cl will return both the clear and clock commands.
When using context-sensitive help, the space (or lack of a space) before a question mark (?) is significant. To obtain a list of commands that begin with a particular character sequence, type in those characters followed immediately by a question mark (?). Do not include a space. This form of help is called word help, because it completes a word for you.
To list keywords or arguments, enter a question mark (?) in place of a keyword or argument. Include a space before the question mark. This form of help is called command syntax help because it reminds you which keywords or arguments are applicable based on the command, keywords, and arguments you have already entered.
The user interface provides a history or record of commands you have entered. This feature is particularly useful for recalling long or complex commands or entries. With the command history feature, you can complete the following tasks:
By default, command history is enabled and the system records 10 command lines in its history buffer. To change the number of command lines the system will record during the current terminal session, use the terminal history size or history size command. The maximum number of commands is 256.
To recall commands in the history buffer beginning with the most recent command, press Ctrl-P or the Up arrow key. Repeat the key sequence to recall successively older commands.
To return to more recent commands in the history buffer after recalling commands, press Ctrl-N or the Down arrow key. Repeat the sequence to recall successively more recent commands.
After you enter the unique characters for a command, press the Tab key and the interface will finish the entry.
On most laptop computers, you might also have additional select and copy facilities. Copy a previous command string, then paste or insert it as your current command entry and press Return.
This section covers basic commands that you can enter to determine the current operational status of the Cisco ONS 15303. These commands will help you obtain vital information when monitoring and troubleshooting Cisco ONS 15303 operations.
It is important to be able to always monitor the status of your Cisco ONS 15303. The Cisco ONS 15303 provides a series of commands you can use to determine if it is functioning correctly and if problems have occurred. Enter the following status commands at the EXEC command prompt:
You can enter the following commands at the EXEC command prompt to see statistics and limited configuration information for the various interfaces on the Cisco ONS 15303. See the Cisco Optical Networking System 15303 Command Reference Guide available online and on the Documentation CD-ROM for more information on these commands.
This section describes default alarm threshold values and other pertinent performance management (PM) information. The system collects PM statistics in conformance with Telcordia Technologies (formerly Bellcore) GR-253, ANSI T1.231, and RFC 1213. Thirty-three 15-minute PM registers are maintained for each parameter. These include the current register that is being filled in real time and 32 historical registers (eight hours of historical data). The most recent 15-minute register is the same as the first of the historical registers. The system also maintains seven daily registers for each parameter. These include the current register that is being updated in real time and seven historical registers (one week of historical data). The most recent daily register is the same as the first of the historical registers.
Statistics for the following near-end parameters are collected for the SONET Section layer (no far-end parameters are defined). SONET Section PM is provided only for the OC-3 signal because it is based on section parity, which is valid only for the first STS-1.
Statistics for the following near-end parameters are collected for the SONET Line layer. SONET Line PM is provided only for the OC-3 signal because line parity errors are combined for all three STS-1s into a single set of parameters.
STS Pointer Justifications (STSPJ), Protection Switch Count (PSC), and Protection Switch Duration (PSD) are not collected.
Statistics for the following far-end parameters are collected for the SONET Line layer. SONET Line PM is provided only for the OC-3 signal because line parity errors are combined for all three STS-1s into a single set of parameters.
Statistics for the following parameters are collected for both the near end and far end (except where noted) of the SONET STS Path layer:
VT Pointer Justifications (VTPJ) are near end only and are not collected.
Statistics for the following parameters are collected for both the near end and far end of the SONET VT Path layer:
The system uses the values displayed in Table 1-1 for default values for SONET PM alarm thresholds.
| Parameter | Location | Default Threshold (15 Minute) | Default Threshold (24 Hour) |
|---|---|---|---|
| Section | |||
CV-S | NEND | 140 | 13440 |
ES-S | NEND | 25 | 250 |
SES-S | NEND | 4 | 8 |
SEFS-S | NEND | 2 | 40 |
| Line | |||
CV-L | NEND/FEND | 138 | 13290 |
ES-L | NEND/FEND | 25 | 250 |
SES-L | NEND/FEND | 4 | 40 |
UAS-L | NEND/FEND | 10 | 10 |
FC-L | NEND/FEND | Not required | Not required |
| STS Path | |||
CV-P | NEND/FEND | 15 | 125 |
ES-P | NEND/FEND | 12 | 100 |
SES-P | NEND/FEND | 3 | 7 |
UAS-P | NEND/FEND | 10 | 10 |
| VT Path | |||
CV-V | NEND/FEND | 45 | 1440 |
ES-V | NEND/FEND | 25 | 250 |
SES-V | NEND/FEND | 4 | 40 |
UAS-V | NEND/FEND | 10 | 10 |
| Other | |||
Excessive BER | NEND | GR-1400 | GR-1400 |
Signal degrade | NEND | GR-1400 | GR-1400 |
The system provides counters for Ethernet PM. These counters always increment and eventually roll over. An external management application is required to calculate PM statistics from these counters. Statistics for the following parameters are collected for near-end Ethernet:
The system does not have thresholds for Ethernet PM. No threshold crossing alerts (TCAs) are generated for these parameters.
Statistics for the following parameters are collected for the near-end DS1 Line layer:
The following parameters are collected for both the near-end and far-end DS1 Path layer:
Controlled slip seconds (CSS-P) are not collected.
See Table 1-2 for default values for DS1 PM alarm thresholds.
| Parameter | Location | Default Threshold (15 Minute) | Default Threshold (24 Hour) |
|---|---|---|---|
| Line | |||
CV-L (BPV) | NEND | 13,340 | 133,400 |
ES-L | NEND | 65 | 648 |
SES-L | NEND | 10 | 100 |
| Path | |||
CV-P (CRC-6) | NEND/FEND | 13,296 | 132,960 |
CV-P (FE) | NEND/FEND | 72 | 691 |
ES-P | NEND/FEND | 65 | 648 |
SAS-P | NEND/FEND | 2 | 17 |
SES-P | NEND/FEND | 10 | 100 |
UAS-P | NEND/FEND | 10 | 100 |
The system follows the guidelines listed in Telcordia Technologies GR-253 for collecting PM data and declaring threshold crossings. When a failure preventing PM data from being collected occurs, the current register is marked "invalid data."
The main functions associated with administration include:
The Cisco ONS 15303 provides a variety of security features for controlling access to your system. The most basic form is to control who can log in to the Cisco ONS 15303. Access can be controlled by:
You can also control access to privileged EXEC mode by assigning a password to this mode during the initial setup of the Cisco ONS 15303.
There is also a feature that allows you to encrypt passwords. If you use this feature, the password is stored in the Cisco ONS 15303 in an encoded form and is masked when you display the configuration parameters.
To learn more about setting passwords, refer to the Cisco Security Configuration Guide available online and on the Documentation CD-ROM.
Like other Cisco products, the Cisco ONS 15303 supports a wide range of customizable privilege levels for command access. Assigning a privilege level to a user defines which commands the user is able to access. For convenience, the Cisco ONS 15303 is shipped with three pre-defined user levels:
After the software finishes loading, the Cisco ONS 15303 is up and running. The system automatically checks for the presence of users at the Administrator level. If an Administrator does not exist, one is created with a default username and password. After entering each of the following commands, press the Enter key.
Step 1 At the ONS> prompt, enter:
login
Step 2 At the username prompt, enter:
admin
Step 3 At the password prompt, enter:
admin
Step 4 A warning message will appear and you will then be in user EXEC mode. For an explanation of the user EXEC mode and what can be done in this mode, see the Cisco Configuration Fundamentals Configuration Guide available online and on the Documentation CD-ROM. The login screen looks like this:
Password: ONS>login Username: admin Password: admin ******************************************************** * WARNING - PRIVATE COMPUTER SYSTEM * * UNAUTHORIZED ACCESS MAY LEAD TO CRIMINAL PROSECUTION * ********************************************************
Step 5 At the ONS# prompt, enter:
conf t
Step 6 At the (config)# prompt, enter:
username username privilege 4 password
Substitute a username for username and substitute a password for password. Enter privilege level 4 if you are the administrator who will be configuring the system and adding users.
Step 7 At the (config)# prompt, enter:
end
Step 8 To verify that the username and password are added to the configuration file, at the ONS# prompt, enter:
show running-config
Configuration data and the software image on the system should be backed up to a server. Because the system has no server, a network management application such as the Cisco Transport Manager (CTM) can be used. The CTM accomplishes backup and restore by accessing the file transfer capability of the system. When you enter a memory backup or restore command, the system transfers data between itself and the management application using TFTP. The download occurs over the DCC or through the LAN console port. Only users with system administration security privileges can perform this action using the LAN console port or the DCC.
The backup file and/or its description contains the following information:
The system displays a text response message at the user interface that a file transfer has completed successfully (or failed).
To back up the software or configuration files, the Cisco ONS 15303 must have access to a server. Table 1-3 contains instructions to perform a memory backup for both the image present on the system and the system's configuration file.
| Step and Prompt | Enter Command |
|---|---|
Step 1 | ine copy memory {pri | remt | sec} {both | data | prog} to {remt | sec} |
Step 2 | xxx.xxx.xxx.xxx |
Step 3 | image1 (the directory and filename are required) |
This section describes upgrading the software for both single and redundant SAM configurations. Upgrading software is the process of retrieving and saving into Flash memory the compressed binary software code that runs on the processor. Only users with system administration privileges can perform software upgrades. You must understand the following operating characteristics before attempting an upgrade:
Generally, the code update process involves copying the new compressed code image to the secondary partition of both the active and standby SAMs. After the image is copied, the user can set the boot file variable in the boot control area of the NVRAM used by the ROM monitor. After this variable is set, the processor is reset, and the new code is decompressed and copied into SDRAM by the ROM monitor.
To upgrade the software, files must exist at a remote location that the Cisco ONS 15303 can access. Table 1-4 contains instructions to perform a software upgrade or file download for software images and configuration files.
| Step and Prompt | Enter Command |
|---|---|
Step 1 | ine copy memory {pri | remt | sec} {both | data | prog} to {remt | sec} |
Step 2 | xxx.xxx.xxx.xxx (tftp server host address) |
Step 3 | image1 |
Step 4 | ine swap memory |
The tmg-src command indicates the priority of the timing source(s) from which the Cisco ONS 15303 can derive clocking. The possible choices are line-a (OC-3 A primary, no secondary), line-b (OC-3 B primary, no secondary), line-a-b (OC-3 A primary, OC-3 B secondary), line-b-a (OC-3 B primary, OC-3 A secondary), ext (external clocking derived from DS-1 eight primary, no secondary), or none (no primary, no secondary). The system will first try to synchronize to the primary timing source if defined and usable. If not, it will try to synchronize to the secondary timing source if defined and usable. If neither the primary nor the secondary timing source is defined or usable, the system will synchronize to its internal clock. The default is none.
Configuration data is automatically synchronized between the online SAM and the standby/offline SAM. To disable automatic synchronization, the no redundancy auto-sync command should be used.
| Task | Command |
|---|---|
Enable automatic synchronization | config# redundancy auto-sync |
Caution 
This should only be done under the guidance of Cisco TAC personnel.
Four exec-level commands are available to conduct the operations listed in the table below.
| Task | Command |
|---|---|
Retrieve the crash-stack from the remote SAM if one is available. | exec# redundancy crash-stack |
Reload the remote SAM. | exec# redundancy reload-slave |
Check synchronization status. | exec# redundancy sync-check |
Force a synchronization operation upon user command. Only configuration data requiring synchronization are updated. | exec# redundancy sync-force |
Three commands are available to show the current status information about the redundancy subsystem.
| Task | Command |
|---|---|
Display redundancy event log | exec# show redundancy log |
Display synchronization status | exec# show redundancy status |
Display version tag table | exec# show redundancy vtag |
The following set of debug commands are used to diagnose a problem should a problem arise in the redundancy subsystems.
| Task | Command |
|---|---|
Turn on all debugging flags | exec# [no] debug redundancy all |
Enable debugging of client services provided by the CSM component of redundancy subsystem to other subsystems | exec# [no] debug redundancy client |
Monitor configuration synchronization including running-config and startup-config sync operations | exec# [no] debug redundancy config |
Turn on printing of error events | exec# [no] debug redundancy error |
Show special events | exec# [no] debug redundancy events |
Follow the operation of the Flash file system synchronization operations | exec# [no] debug redundancy flash |
Monitor the operation of the IPC interface used by CSM | exec# [no] debug redundancy ipc |
Show CSM peer message processing | exec# [no] debug redundancy messages |
Turn on miscellaneous debug flags | exec# [no] debug redundancy misc |
Enable debugging of synchronization events relating to the NVRAM | exec# [no] debug redundancy nvram |
Monitor the interface between CSM and RSM components of redundancy | exec# [no] debug redundancy rsm |
Debug operations related to version tag processing to determine when one or more version elements are mismatched | exec# [no] debug redundancy sync |
This section contains an explanation of alarm processing within the system. The concepts of alarm level, service-affecting level, whether an alarm is posted or not, and whether an alarm is reported or not are covered in this section. Also covered are the similarities and differences among events, conditions, and alarms.
A condition is an occurrence ("something happened or something is happening") on either the system equipment or the facilities terminating or traversing the equipment.
Conditions are divided into two classifications. Conditions can be standing (posted and subsequently cleared) or transient. Standing conditions are assigned a level of CR, MJ, MN, NA and NR. Additionally, conditions indicate whether they are service affecting (SA) or non-service affecting (NSA).
Alarms are simply standing conditions with condition levels of Critical (CR), Major (MJ), or Minor (MN). Because alarms are standing conditions, alarms are always stored as part of the real time state of the system.
When an alarmed condition is standing, the system generates an autonomous alarm message (REPT-ALM) to the user/OSS/system log. This message indicates the system ID, date, time, the AID location of the condition, the condition level, the standing condition, and whether it is service affecting or non-service affecting. In addition, the appropriate alarm contact closures and LEDs on the front of the system trigger to the appropriate setting.
When the system detects that the alarm has been cleared, a subsequent "Condition-Clear" message is output to the user/OSS/system log identifying that the offending alarmed condition has been cleared. Additionally, the contact closures and system LED associated with the alarm level also return to normal (if there are no remaining alarms of that level).
Remember, there are three configurations that affect the monitoring and reporting of transient and standing conditions:
1. Both monitoring (interrupts) and reporting are ON
2. Monitoring ON and reporting OFF (standing conditions still stored in database/log)
3. Both monitoring and reporting are OFF (no conditions possible because interrupts
are now disabled)
Another standing condition level which is not alarmed, yet reported, is called a Not Alarmed (NA) condition. Because Not Alarmed conditions are standing conditions, these conditions are always stored as part of the real time state of the system.
When a Not Alarmed condition is posted, the system generates an autonomous event message (REPT-ETU) to the user/OSS/system log. This message indicates the system ID, date, time, the AID location of the condition, the condition level, the standing condition, and whether it is service affecting or non-service affecting.
When the system detects that the standing Not Alarmed condition has been cleared, a subsequent "Condition Clear" message is output to the user/OSS/system log identifying that the offending condition has been cleared. There are no alarm contacts associated with Not Alarmed standing conditions.
Not Reported level conditions are standing conditions stored as part of the real-time state of the system, but do not generate an autonomous report (or subsequent clear) to the user or the OSS. They are posted and cleared within the system log only.
Transient conditions include TCAs (BER is not a TCA, it is a standing condition) as well as system occurrences that reflect transient conditions (for example, a protection switch occurred or a database backup occurred). Transient conditions are not stored as part of the real-time state of the system and might be reported to the user/OSS/ system log (via REPT-ETU) if the system is configured to report that particular transient condition.
An event is an autonomous message output by the system, created either by a standing condition that is not an alarm or a transient condition. See Table 1-5 for a list of conditions.
| Condition Type | Standing/Transient | Reported/Not Reported | Service Affecting/Non-Service Affecting |
|---|---|---|---|
CR | Standing | Reported to user, OSS, and log; LED illuminates (REPT-ALM) | SA/NSA |
MJ | Standing | Reported to user, OSS, and log; LED illuminates (REPT-ALM) | SA/NSA |
MN | Standing | Reported to user, OSS, and log; LED illuminates (REPT-ALM) | SA/NSA |
NA | Standing | Reported to user, OSS, and log; no LED (REPT-ETU) | SA/NSA |
NR | Standing | Not reported to user or OSS, only to log; no LED | SA/NSA |
TCA | Transient | If configured to not report, message to log only. If configured to report, message to user/OSS/log. (REPT-ETU) | Not applicable |
The assignment of a standing condition to levels of CR, MJ, MN, NA, NR for a particular entity (the entity must support standing conditions) is determined by cross-referencing the condition (while posted) to its indicated standing condition level. The standing condition level is defined in a user modifiable look-up table called the alarm profile table.
An alarm profile table can be edited to define the importance (or "severity" level) of any particular standing condition. However, in the first release of the Cisco ONS 15303, the cross-references to condition levels cannot be changed by the network operator. Later releases of the Cisco ONS 15303 will allow the system user to modify the level of a particular standing condition from that of the system default. The SA/NSA parameter cannot be edited as this is determined by the system architecture itself.
In determining what constitutes the level of a standing condition, the following has generally been accepted practice (although not specifically defined in any standard).
The default assignment of Critical Alarm conditions generally pertains to any posted state that indicates that a signal of E3 rate or higher is experiencing trouble due to facility or equipment failure.
The default assignment of Major Alarm conditions generally pertains to any posted state that indicates an incoming signal between DS1 and DS3 is experiencing trouble due to facility or equipment failure.
The default assignment of Minor Alarm conditions generally pertains to any posted state that indicates there exists an off-normal state in which transmitted service is not impacted, yet there might be some impact to the network or equipment due to the off-normal condition. One example of an off normal is if there is a non-service affecting loss of equipment redundancy.
The default assignment of Not Alarmed conditions generally pertains to any posted state that indicates an off normal (but not necessarily abnormal) condition that might warrant operator attention. One example is an existing loopback.
The default assignment of Not Reported conditions generally pertains to any posted state that indicates an off-normal (but not necessarily abnormal) condition that might not warrant operator attention. RDI or facility Yellow is a Not Reported condition because the fault is a far-end, and not a local fault. SGEOs are also Not Reported conditions because the higher level entity is posting its respective condition.
Because standing conditions are real-time states, the user requires the ability to request the current (standing) condition of the system or facility. Using system command language, the user can enter show conditions all to retrieve the current state of all currently posted conditions, regardless of condition level. Using the show conditions all command includes all conditions, even Not Reported conditions that are currently posted.
By being more specific, the user can request the condition by condition level using show conditions [level]. Or, if the operator is just interested in the conditions that are identified as alarms (MJ, MN, CR) show alarms all can be used.
The user can also specify equipment or facility as part of the show command:
show conditions SAM A [level]
show conditions [Facility Type {STS-1|AU|TU|DS1|Ethernet}] [level]
By allowing this selectivity of retrieval, the user is able to quickly obtain information should a network situation arise.
Table 1-6 shows a list of standing conditions, their default levels and autonomous outputs. This list is by no means all-inclusive and additional conditions might be identified during development and added to this list. The first column in the list identifies the type of entity. The second column is a coded description of the condition. The third column lists condition severity. The fourth column is a long description of the condition. The fifth column signifies whether the condition is service-affecting (SA) or non-service-affecting (NSA), and the last column describes whether the condition is at the near end (on the system where the condition declaration is being made) or at the far end (somewhere else).
Where two severities are listed, the first entry refers to the first failure of a redundant pair, and the second entry refers to the failure of the second item in that redundant pair.
Where two service impacts are listed, the first entry refers to the first failure of a redundant pair, and the second entry refers to the failure of the second item in that redundant pair.
| Entity | Standing Condition | Standing Condition Level | Impact/System Message Free Format Text (FFT) | Service Impact | Location |
|---|---|---|---|---|---|
SAM | SYSPROTNA | MN | Protection of stand-by SAM not available. | NSA | NEND |
SAM | SAMRMV | NA | IS SAM has been removed. | NSA | NEND |
SAM | SAMFLT | MN/CR | A single SAM has failed (redundant system). | NSA/SA | NEND |
SAM | SAMIDFLT | NA | SAM A/B does not match the current system ID. | NSA | NEND |
FAN | SYSFAN | MN | The system has detected a single fan failure. | NSA | NEND |
FAN | SYSCRFAN | CR | The system has detected multiple fan failures. | NSA | NEND |
SYS | OVRTEMP | CR | An over-temperature condition has been detected. | NSA | NEND |
FAN | FANFLT | MN | Fan tray has been removed. | NSA | NEND |
SYS | FANPWRF:LT | CR | Power has failed on the fan tray. | NSA | NEND |
SYS | IOFLT | MJ | I/O card has failed. | SA | NEND |
SYS | SYSPWR | MN | The system has detected a blown fuse or the loss of power on one power input (A/B). | NSA | NEND |
SYS | DBMISMAT | NA | Running config does not match startup config. | NSA | NEND |
SYS | SYSDB | CR | The system has detected errors in the active DB program | SA | NEND |
SYS | SYSINHAR | NA | The system has condition reporting inhibited. | NSA | NEND |
SYS | SYSINHAD | NA | The system has condition detection inhibited. | NSA | NEND |
SYS | SYSENVALM | MJ | The system has identified a site alarm on contact closure n. | NSA | NEND |
OC-3 | MSLOS | MJ/CR | The system has detected loss of signal on STM N A/B (simultaneous peer OC-3 is CR). | NSA/SA | NEND |
OC-3 | MSLOF | MJ/CR | The system has detected loss of signal on STM N A/B (simultaneous peer OC-3 is CR). | NSA/SA
| NEND |
OC-3 | MSAIS | NR | The system has detected a far-end failure on STM N A/B (line AIS). | NSA | FEND |
OC-3 | MSRFI | NR | There is a far-end facility failure on STM N A/B (line RFI). | SA | FEND |
OC-3 | MSSD | MN/CR | The BER-L threshold has been crossed on STM N A/B. | NSA/SA | NEND |
OC-3 | MSSF | MJ/CR | The BER-H threshold has been crossed on STM N A/B (simultaneous peer OC-3 is CR). | NSA/SA | NEND |
OC-3 | MSLOOP | NA | A facility/network loopback has been placed on STM N A/B. | SA | NEND |
OC-3 | MSINT | MJ/CR | An internal failure for OC-3 has been detected (simultaneous peer OC-3 is CR). | SA | NEND |
OC-3 | MSKBYTE | NA | Protection switching byte unstable. | NSA | NEND |
OC-3 | MSAPSCHAN | NA | APS channel mismatch failure. | NSA | NEND |
OC-3 | MSAPSMODE | NA | APS mode mismatch failure. | NSA | NEND |
OC-3 | MSAPSPR | MN | Far-end protection line failure. | NSA | FEND |
STS-1 | AULOP | MJ/CR | The system has detected a loss of pointer on STS-1 n (simultaneous peer STS-1 is CR). Drop terminated | NSA/SA | NEND |
STS-1 | HPTIM | NA | The system has detected a path trace identified mismatch on STS-1 n. Drop terminated. | NSA | NEND |
STS-1
| HPPLM | MJ | The system has detected a path signal label mismatch on STS-1 n (second STS-1 is CR). Drop terminated. | NSA/SA | NEND |
STS-1
| HPUNEQ | MJ/CR | STS-1 n, provisioned for service, is unequipped (simultaneous peer STS-1 is CR). Drop terminated. | NSA/SA | NEND |
STS-1
| AUAIS | NR | The system has detected a far-end failure on STS-1 n (path AIS). Drop terminated. | NSA/SA | NEND |
STS-1
| AURFI | NR | There is a far-end facility failure on STS-1 n (path RFI). Drop terminated. | NSA | FEND |
VT1.5 | TULOP | MJ/CR | The system has detected a loss of pointer on VT1.5 n (simultaneous peer VT1.5 is CR). Drop terminated. | NSA/SA | NEND |
VT1.5 | LPTIM | NA | The system has detected a path trace identifier mismatch on VT1.5 n. Drop terminated. | NSA | NEND |
VT1.5 | LPPLM | MJ | The system has detected a path signal label mismatch on VT1.5 n (9 second VT1.5 is CR). Drop terminated. | NSA/SA | NEND |
VT1.5 | LPUNEQ | MJ/CR | VT1.5 n, provisioned for service, is unequipped (simultaneous peer VT1.5 is CR). Drop terminated. | NSA/SA | NEND |
VT1.5 | TUAIS | NR | The system has detected a far-end failure on VT1.5 n (path AIS). Drop terminated. | NSA | FEND |
VT1.5 | TURFI | NR | There is a far-end facility failure on VT1.5 n (path RFI). Drop terminated. | NSA | FEND |
VT1.5 | TUAIS | NR | The system has detected a far-end failure on VT1.5 n (path AIS). Pass through. | NSA/SA | FEND |
VT1.5 | TULOP | MJ/CR | The system has detected a loss of pointer on VT1.5 n (simultaneous peer VT1.5 is CR). Pass through. | NSA/SA | NEND |
DS1 | DS1RED | MJ | The system has detected a loss of signal on DS1 n. | SA | NEND |
DS1 | DS1LOF | MJ | DS1 loss of frame (serial DS1s) | Sa | NEND |
DS1 | DS1AIS | NR | The system has detected a far-end failure on DS1 n (AIS). | NSA | FEND |
DS1 | TS1RAI | NR | There is a far-end failure on DS1 n (yellow alarm). | NSA | FEND |
DS1 | TS1SD | MN | The BER-L threshold has been crossed on DS1 n. | NSA | NEND |
DS1 | TS1SF | MJ | The BER-H threshold has been crossed on DS1 n. | SA | NEND |
DS1 | DS1LOOP | NA | A facility/network loopback has been placed on DS1 n. | SA | NEND |
DS1 | DS1FDL | MN | The system has detected an ESF datalink failure on DS1 n. | NSA | FEND |
DS1 | DS1INT | MJ | An internal failure for DS1 n has been detected. | SA | NEND |
CRS | VT1.5PPS | NA | n is not on the preferred path. | NSA | NEND |
CRS | VT1.5LOCK | MN | A user-initiated lock-out has been executed on VT1.5 n A/B. | NSA | NEND |
CRS | VT1.5FS | MN | A user-initiated force switch has been executed on VT1.5 n A/B. | NSA | NEND |
CRS | VT1.5MS | MN | A user-initiated manual switch has been executed on VT1.5 n A/B. | NSA | NEND |
SYNC | SYNHLDVR | MJ | System synchronization is in hold-over mode. | SA | NEND |
SYNC | SYNFRUN | MJ | System synchronization is in free-run mode. | SA | NEND |
SYNC | SYNANR | MN/MJ | Reference failure (message indicates PRI/SEC). | NSA/SA | NEND |
SYNC | SYNCINT | MJ/CR | The system has determined that the internal synchronization hardware has failed. | NSA/SA | NEND |
PPP | PPPSF | MJ | A PPP link has failed. | SA | NEND |
PPP MULTI- | PPP MULTI-LINKSF | CR | All PPP links within a PPP Multilink bundle have failed. | SA | NEND |
Ethernet | ETHERNETSF | CR | Ethernet facility [1-8] has failed. | SA | NEND |
Table 1-7 lists transient conditions (Threshold Crossing Alerts, TCAs, and autonomous messages) that can be declared by the system. The first column identifies the entity against which the declaration is being made. The second column provides an abbreviation for the condition while the third column provides a more verbose description. The fourth column provides an indication of SA or NSA for the transient condition. While the concept of SA and NSA is not normally applied to transient conditions, doing so can be useful for filtering purposes. A network operator or monitoring OS could ignore all NSA-type declarations and only focus on SA (the alarms). The last column indicates the location of the TCA as being either near end (NEND) or far end (FEND).
| Entity | Transient Condition | Impact/System Message Free Format Text (FFT) | Service Impact | Location |
|---|---|---|---|---|
SYS | SYSSW | The system has successfully performed a redundancy switch. SAM-X is now active. | NSA | NEND |
SYS | SAMIN | SAM A/B has been inserted. | NSA | NEND |
SYS | SAMOUT | SAM A/B has been removed. | NSA | NEND |
SYS | CONFIGCHG | A configuration change has occurred. | NSA | NEND |
SYS | SYSACO | The alarm cut-off has been activated on the system. | NSA | NEND |
SYS | SYSRST | The system has successfully completed a reset. SAM-X is now active (system restart). | NSA | NEND |
SYNC | SYNSWPRI | The system has detected a synchronization switch to the primary reference. | NSA | NEND |
SYNC | SYNSWSEC | The system has detected a synchronization switch to the secondary reference. | NSA | NEND |
SYNC | SNYSWINT | The system has detected a synchronization switch to the internal reference. | NSA | NEND |
SYNC | PRISSM | SSM has changed on the primary reference. | NSA | NEND |
SYND | SECSSM | SSM has changed on the secondary reference. | NSA | NEND |
OC-3 | OCCVS | The system has detected a threshold crossing of Coding Violations Section on OC-3 A/B. | NSA | NEND |
OC-3 | OCESS | The system has detected a threshold crossing of Errored Seconds Section on OC-3 A/B. | NSA | NEND |
OC-3 | OCSESS | The system has detected a threshold crossing of Severely Errored Seconds Section on OC-3 A/B. | NSA | NEND |
OC-3 | OCSEFSS | The system has detected a threshold crossing of Severely Errored Framing Seconds Section on OC-3 A/B. | NSA | NEND |
OC-3 | OCCVL | The system has detected a threshold crossing of Coding Violations Line on OC-3 A/B. | NSA | NEND/FEND |
OC-3 | OCESL | The system has detected a threshold crossing of Severely Errored Seconds Line on OC-3 A/B. | NSA | NEND/FEND |
OC-3 | OCSESL | The system has detected a threshold crossing of Severely Errored Seconds Line on OC-3 A/B. | NSA | NEND/FEND |
OC-3 | OCUASL | The system has detected a threshold crossing of Unavailable Seconds Line on OC-3 A/B. | NSA | NEND/FEND |
OC-3 | OCPJC | The system has detected a threshold crossing of Pointer Justifications on OC-3 A/B. | NSA | NEND |
STS-1 | AU4CVP | The system has detected a threshold crossing of Coding Violations Path on STS-1 n. | NSA | NEND/FEND |
STS-1 | AU4ESP | The system has detected a threshold crossing of Errored Seconds Path on STS-1 n. | NSA | NEND/FEND |
STS-1 | AU4SESP | The system has detected a threshold crossing of Severely Errored Seconds Path on STS-1 n. | NSA | NEND/FEND |
STS-1 | AU4UASP | The system has detected a threshold crossing of Unavailable Seconds Path on STS-1 n. | NSA | NEND/FEND |
STS-1 | AU4VTPJ | The system has detected a threshold crossing of Pointer Justification Counts on STS-1 n. | NSA | NEND/FEND |
VT1.5 | VT1.5PPSPRF | n has switched to the preferred path. | NSA | NEND |
VT1.5 | VT1.5PPSALT | n has switched to the alternate path. | NSA | NEND |
VT1.5 | VT1.5PPSFAIL | PPS failure on n. | NSA | NEND |
VT1.5 | VT1.5CVV | The system has detected a threshold crossing of Coding Violations on VT1.5 n. | NSA | NEND/FEND |
VT1.5 | VT1.5ESV | The system has detected a threshold crossing of Severely Errored Seconds on VT1.5 n. | NSA | NEND/FEND |
VT1.5 | VT1.5SESV | The system has detected a threshold crossing of Severely Errored Seconds on VT1.5 n. | NSA | NEND/FEND |
VT1.5 | VT1.5T1UASV | The system has detected a threshold crossing of Unavailable Seconds on VT1.5 n. | NSA | NEND/FEND |
DS1 | DS1CVL | The system has detected a threshold crossing of Line Coding Violations on DS1 n. | NSA | NEND |
DS1 | DS1ESL | The system has detected a threshold crossing of Errored Seconds Line on DS1 n. | NSA | NEND |
DS1 | DS1SESL | The system has detected a threshold crossing of Severely Errored Seconds Line on DS1 n. | NSA | NEND/FEND |
DS1 | DS1CVP | The system has detected a threshold crossing of Coding Violations Path (CRC-6 for ESF or FE for SF) on DS1 n. | NSA | NEND/FEND |
DS1 | DS1ESP | The system has detected a threshold crossing of Errored Seconds Path on DS1 n. | NSA | NEND/FEND |
DS1 | DS1SASP | The system has detected a threshold crossing of Severely Errored Framing/AIS Seconds Path on DS1 n. | NSA | NEND/FEND |
DS1 | DS1SESP | The system has detected a threshold crossing of Severely Errored Seconds Path on DS1 n. | NSA | NEND/FEND |
DS1 | DS1UASP | The system has detected a threshold crossing of Unavailable Seconds Path on DS1 n. | NSA | NEND/FEND |
The system classifies alarm processing according to the following list. This list defines the information necessary to create an alarm profile along with identification as to whether the condition is service-affecting (SA) or non-service-affecting (NSA).
New failure declaration does not cause any independent conditions to clear.
The system is able to report with a single command all conditions/alarms currently being monitored by the system.
The system is able to report with a single command all alarms currently being monitored by the system. This excludes anything that is not alarmed or not reported.
The system does not allow the operator to provision the level of conditions (CR, MJ, MN, not alarmed, or not reported). This will be performed in future releases through the use of different alarm profiles.
There is a one-to-one relationship between a condition/alarm declaration and its corresponding clear.
The system uses the following hierarchy for SONET defect management in an effort to achieve a single declaration for a single failure (failures encountered due to other higher order failures are not to be declared):
1. LOS
2. LOF
3. AIS-L
4. AIS-P
5. LOP-P
6. UNEQ-P/PLM-P
7. AIS-V
8. LOP-V
9. UNEQ-V/PLM-V
The reporting of declaration and clearing of standing conditions as well as transient conditions generated is controlled in a number of ways through the following four parameters:
Auto-delay timer has been defined for entities for which failure reporting and TCA reporting needs to be controlled. It is specified as some absolute time in the future. When it is specified, the reporting of failures and TCAs is disabled until the timer expires or the operator changes this configuration parameter to zero.
This is a one-shot timer. After it expires, it does not start again because the timer value in the configuration record is reset to zero.
Auto-trigger timer is another method used to control the failure and TCA reporting for different entities. It is specified in terms of hours and minutes. It is different from the auto-trigger in the sense that it is not an absolute time. After it has been specified, the reporting of failures and TCAs is disabled until the signal on the specified entity is free of service affecting failures for the time specified for this timer. For example, if the timer is specified for 30 minutes the reporting is stopped immediately. When the signal is good, the timer is started for 30 minutes. If a service affecting failure is declared for the TP (or one of its supporting TPs) before the timer expires, the timer is terminated but the reporting is not enabled. When a good signal is received again (failure is cleared) the timer is restarted. If the signal remains failure free during the timer duration, reporting is reenabled when the timer expires.
This is a one-shot timer. On the expiration of this timer, its configuration data is reset to zero so that it does not start up again.
This parameter controls the reporting of failures for an entity. It can be used to enable or disable the reporting of failure declarations. This parameter is also supported at the equipment level to provide a single parameter to control the reporting of failures for all entities.
This parameter controls the reporting of TCAs for an entity for which PM parameters are gathered. It can be used to enable or disable reporting TCAs. It is supported at the equipment level to provide a single parameter to control the reporting of TCAs for all entities.
The following commands are used to configure the reporting controls parameters:
For more information on these commands, see the Cisco Optical Networking System 15303 Command Reference Guide.
The system processes the following network element equipment failure events:
The system processes the following SONET events:
The system processes the following DS1 events:
The system processes the following Ethernet events:
The system supports AIS per Telcordia GR-253 and TR-TSY-191. AIS has a default alarm profile of not alarmed, SA.
The system supports RDI, REI, and RFI per GR-253. The system does not support enhanced RDI. Support in future releases is for further study. RFI has a default alarm profile of not reported, SA.
The system is able to function normally under a single fan failure condition. A minor alarm (default: MN, NSA) is reported for a single fan failure condition. The system reports a critical alarm (default: CR, SA) for a condition where two or three fans have failed.
The following Cisco ONS 15303 commands, entered from the EXEC command prompt, allow you to see alarm information for the various interfaces on the Cisco ONS 15303. For more information on the commands, see the Cisco Optical Networking System 15303 Command Reference Guide available online and on the Documentation CD-ROM.
The Cisco ONS 15303 provides diagnostic tools for troubleshooting both IP and TDM networks.
Although both performance and fault monitoring statistics are useful in diagnosing IP-related network problems, the Cisco ONS 15303 also provides two tools for diagnosing problems: ping and traceroute.
The ping tool can be used to determine valid connections within an IP network. When a ping command is entered, a packet is sent to the destination, which is referred to as an echo request. The sending station then waits to receive an echo reply. If the reply fails, the problem is related to one of the following conditions:
When entering the ping command from the Cisco ONS 15303, all directly attached networks are reachable, assuming that the physical connection exists and nothing has been done to administratively prevent the Cisco ONS 15303 from pinging the destination.
The traceroute tool can be used in identifying exactly where communication is being lost. Traceroute creates a short UDP message with an IP header and sets the time-to-live value to 1. The packet is sent three times. The first Cisco ONS 15303 in the path to the destination decrements the time-to-live value to 0 and sends an ICMP expired message back to the source. The source sends the same message again but sets the time-to-live value to 2. At this point, the first hop Cisco ONS 15303 decrements the time-to-live to 1 while the second hop Cisco ONS 15303 decrements the time-to-live to 0 and sends the expired ICMP message back to the source. This process is repeated until the destination network is reached or the problem is located in the network.
Traceroute can be run using the traceroute command. For more information about the traceroute command, see the Cisco Optical Networking System 15303 Command Reference Guide available online and on the Documentation CD-ROM.
Although you can use both performance and fault monitoring statistics to aid in diagnosing TDM-related network problems, the Cisco ONS 15303 also provides two tools for diagnosing problems: loopbacks and BERT.
Within the Cisco ONS 15303, loopbacks are referenced to the facility termination point (DS1, VC, STS-1, or OC-3). For all interfaces, loops toward the line facility loopbacks and loops toward the system are equipment loopbacks. To create a loopback, use the ine operate command. To release the loopback, use the ine release command. For facility and equipment loopbacks, the system continues the valid signal generated or passed by the system.
You can use the Cisco ONS 15303 to generate and measure bit errors. The system is capable of generating bit patterns from serial DS1 interfaces with none, all ones, or QRSS. To generate a bit error rate test, use the ine generate command. To measure a bit error rate test, use the ine measure command. For more information regarding these commands, refer to the Cisco Optical Networking System 15303 Command Reference Guide available online and on the Documentation CD-ROM.
This section describes the process for configuring the Cisco Transport Manager/CNM agent software within the Cisco ONS 15303. A brief description of Cisco Transport Manager/CNM is given along with an overview of the relationship between the Cisco Transport Manager/CNM server, client, and agent components. Only the Cisco Transport Manager/CNM agent component reside with the Cisco ONS 15303 and only the agent component is described in this section. Refer to the Cisco Transport Manager Products Installation Guide and the Cisco Transport Manager Products Operations Guide for information about the Cisco Transport Manager/CNM client and server components.
When used as a service delivery platform, the Cisco ONS 15303 supports an in-band service monitoring facility referred to as Cisco Transport Manager/CNM. Cisco Transport Manager/CNM allows customers to retrieve information about the status and quality of their subscribed TDM and packet transmission services. It provides customers with visibility into TDM and packet fault and performance management information maintained within the Cisco ONS 15303 element and network management system databases. The provided information can be used by customers as a value-added service monitoring capability or as a mechanism for service reconciliation. Cisco Transport Manager/CNM gives service providers a tool to differentiate their service offering from their competition.
Cisco Transport Manager/CNM, unlike other customer network management services, can take place in an in-band or out-of-band communication path. The term in-band refers to the use of the Ethernet port interfaces to access Cisco Transport Manager/CNM information. The Ethernet ports are normally used only to provide both packet transmission services, but the Ethernet interface can also serve as an access path for Cisco Transport Manager/CNM information. The Cisco Transport Manager/CNM agent is required only if an in-band communication path via an Ethernet port is used. The term out-of-band refers to the use of a separate communication path (such modems) to access Cisco Transport Manager/CNM information. This chapter assumes an in-band communication path is used, hence requiring the Cisco Transport Manager/CNM agent to be present. For out-of-band communication paths, the Cisco Transport Manager/CNM agent is not necessary. Please refer to the Cisco Transport Manager Products Installation Guide and the Cisco Transport Manager Products Operations Guide for information about how to set up the Cisco Transport Manager/CNM clients and servers to use out-of-band communication paths.
For inband communication paths, Cisco Transport Manager/CNM is comprised of three discrete software components:
Cisco Transport Manager/CNM uses TCP connections to reliably transfer performance monitoring and link status information. Each Cisco Transport Manager/CNM client initiates a downstream TCP connection to the agent, and this connection is accepted if the client is configured to participate in Cisco Transport Manager/CNM. Similarly, the Cisco Transport Manager/CNM agent establishes and maintains a single upstream TCP connection to each of the servers it is configured to use. Cisco Transport Manager/CNM messages from multiple clients for the same server will have their messages interleaved within the single upstream TCP connection. The Cisco Transport Manager/CNM agent processes messages from each client and routes the message to the server assigned by configuration. For a configuration with 8 Cisco Transport Manager/CNM clients using 2 servers, a total of 10 TCP connections will be managed by the Cisco Transport Manager/CNM agent. None of the TCP connections go directly between the server and client; the agent mediates all information transfer between the servers and clients.
Because Cisco Transport Manager/CNM bridges between the user and management planes of the network, it is necessary to carefully control the amount of bandwidth consumed by Cisco Transport Manager/CNM clients.
To protect the amount of management plane bandwidth consumed by Cisco Transport Manager/CNM, each connection from the Cisco Transport Manager/CNM client to the agent is buffered and regulated by a rate-control mechanism that will allow only a carefully metered amount of traffic to be issued from a client to a server. A simple leaky-bucket metering mechanism is implemented in the Cisco ONS 15303, which will nominally allow only 4 kbps of throughput to each client with a burst-size of 2048 bytes. Both of these parameters governing the rate control algorithm can be customized if desired. The rate-control mechanism does not apply to traffic from the server destined toward the clients.
Before beginning the process of configuring a Cisco Transport Manager/CNM agent, you should have available the following pieces of information:
To configure, follow these steps:
Step 1 At the privileged EXEC prompt, enter:
configure
You are now in the global configuration mode.
Step 2 In the global configuration mode, activate the Cisco Transport Manager/CNM agent. Enter:
(config)# cnm enable
This command will enable Cisco Transport Manager/CNM, but you will need to enter the association between Cisco Transport Manager/CNM clients and servers.
Step 3 Enter one or more cnm client client-ip-address server-ip-address lines. Each line specifies an association between a Cisco Transport Manager/CNM client and server. Cisco Transport Manager/CNM traffic from the indicated client will be forwarded to the specified server, and similarly for traffic going in the opposite direction.
If you are adding a new Cisco Transport Manager/CNM client to a Cisco ONS 15303 that is already configured for Cisco Transport Manager/CNM, only Step 1 and Step 3 are required.
To enable the Cisco Transport Manager/CNM agent, use the cnm enable configuration statement. The Cisco Transport Manager/CNM agent is not normally enabled. An optional port number "tcp-port-number" can be specified to override the default TCP port number 27613 used by the Cisco Transport Manager/CNM application. The no form of the command is used to disable the Cisco Transport Manager/CNM agent.
| Task | Command |
|---|---|
Activate the Cisco Transport Manager/CNM agent. | config# cnm enable [tcp-port-number] |
Deactivate the Cisco Transport Manager/CNM agent | config# no cnm enable |
The cnm client configuration command specifies the IP address of a Cisco Transport Manager/CNM client that is permitted access to Cisco Transport Manager/CNM. This statement also specifies the address of the Cisco Transport Manager/CNM server that should process messages from the client. Cisco Transport Manager/CNM connection requests from a client are rejected if they do not originate from an IP address other than the one specified in the cnm client statement. Cisco Transport Manager/CNM messages arriving from the client are forwarded only to the specified server. A Cisco Transport Manager/CNM client can only be associated to a single server. Different Cisco Transport Manager/CNM servers can be specified for different clients.
| Task | Command |
|---|---|
Associate a Cisco Transport Manager/CNM client to a server. | cnm client client-ip-address |
Remove an association between a Cisco Transport Manager/CNM client and a server. | no cnm client client-ip-address |
You will need to repeat the cnm client configuration statement for each Cisco Transport Manager/CNM client that is served by the Cisco ONS 15303. Names can be used instead of addresses if a hostname mapping was specified earlier. If not, the IP address will need to be provided.
You can use the no form of the command to remove an association. The client IP address and the server IP address must both be specified. De-activating Cisco Transport Manager/CNM does not automatically remove the associations. When the association is removed, the client will no longer be able to access Cisco Transport Manager/CNM.
The leaky bucket mechanism operating parameters can be configured if desired. Two parameters are available: the average message rate and the burst size.
The leaky bucket mechanism will attempt to meter outgoing traffic according to a configurable average rate. The cnm rate-limit configuration statement specifies the average transmission bandwidth to be consumed by Cisco Transport Manager/CNM traffic going in the upstream direction toward the server. Cisco Transport Manager/CNM traffic rate control is applied on a per-client basis; that is, each client is permitted to send only a specified amount of traffic. The parameter is specified in units of kilobits per second, with a default of 4 kbps. The range of permissible values are between 1 and 1024 kbps, but the rate scheduling is accurate only up to about 128 kbps.
The default and no forms of this command are equivalent to returning the default operating mode to the default statement.
| Task | Command |
|---|---|
Specify the average amount of traffic to service from a Cisco Transport Manager/CNM client. | config# cnm rate-limit kbps |
Return the average traffic rate parameter to the default value. | config# default cnm rate-limit |
The leaky bucket mechanism can transmit a burst of traffic if there are sufficient credits available in the leaky bucket. The size of the burst is specified by the cnm burst-size command. The configuration line is optional and is used to tune the operation of the leaky-bucket algorithm. The default setting is 2048 bytes, with a minimum value of 1024 bytes and a maximum value of 262144 bytes.
| Task | Command |
|---|---|
Specify the maximum amount of data to burst out. | cnm burst-size bytes |
Return the burst size parameter to the default value of 2048 bytes | default cnm burst-size |
The following configuration lines are optional and are used to customize the operation of the Cisco Transport Manager/CNM client should the default parameters not be suitable. Normally, the default parameters are adequate for most deployments.
If no traffic is received from a client for an extended period of time, the TCP connection from the client is released to conserve memory and to avoid lingering TCP sessions. The cnm idle-timeout configuration statement specifies the length of time (in seconds), before a client TCP session is released. The idle time is set to 1800 seconds (30 minutes) as a default value. Setting the value to zero disables the idle timeout function and will allow a TCP connection to persist indefinitely. This option is useful mostly to prevent lingering sockets from remaining in the system.
| Task | Command |
|---|---|
Set the amount of time a client TCP connection can remain idle before closing the connection. | cnm idle-timeout seconds |
Return the TCP idle time parameter to the default value of 1800 seconds (30 minutes). | default cnm idle-timeout |
The Cisco Transport Manager/CNM agent limits to two the number of concurrent Cisco Transport Manager/CNM client sessions that it will accept from each configured IP client address. Normally a single IP host (such as a Windows NT station) will have only a single Cisco Transport Manager/CNM client session. Should an occasion require more than two concurrent sessions, the cnm max-sess-addr command can be used to increase the number. Having multiple active sessions will increase memory consumption.
| Task | Command |
|---|---|
Specify the number of concurrent Cisco Transport Manager/CNM client sessions that will be processed from each Cisco Transport Manager/CNM client. | |
Return the maximum session parameter to the default value. | config# default cnm max-sess-per-addr |
The Cisco Transport Manager/CNM agent will periodically attempt a TCP connection request to Cisco Transport Manager/CNM servers if a TCP connection is not already open. The cnm retry-conn-time command controls the retry time interface. The default value is 15 seconds. The minimum value is one second with a maximum of 900 seconds.
| Task | Command |
|---|---|
Set the connection retry interval for connecting to a Cisco Transport Manager/CNM server. | config# cnm retry-conn-time seconds |
Return the connection retry interval to the default value. | config# default cnm retry-conn-time |
The Cisco Transport Manager/CNM agent enforces a limit on the maximum message size that it will accept from Cisco Transport Manager/CNM clients and servers. Messages exceeding this size will be discarded, considered a protocol error, and result in closure of the TCP connection. To change the maximum message size, use the cnm max-msg-size command. The default value is 16384 bytes, with a minimum value of 2048 and a maximum value 65536 bytes.
| Task | Command |
|---|---|
Set the maximum message size that will be accepted by the Cisco Transport Manager/CNM agent. | config# cnm max-msg-size bytes |
Return the maximum message size to the default value. | config# default cnm max-msg-size |
The command show cnm information allows the user to retrieve and view the operating state of the Cisco Transport Manager/CNM agent.
| Task | Command |
|---|---|
Display information about operating parameters, message statistics, and current TCP connection information. | exec# show cnm information |
A sample output from the show cnm information command is as follows:
ONS#sh cnm information
Cisco Transport Manager/CNM agent enabled using TCP port number 27613
Rate Limit 4 kbps, Burst Size 2048 bytes, Increment 50 bytes
Max Sessions/Client 2, Conn Retry Time 15 sec, Idle Timeout 1800 secs
Connection Accepts 1 Rejects 0 Timeouts 0
Total Input Msgs 1 Bytes 9 Errors 0
Total Output Msgs 1 Bytes 9 Errs 0
TCP Session Control Blocks
Client session, Peer address 192.168.110.51:32878 (tscb=0x61429FE4)
Process id 71 Reasembly State 0 (tcb 0x611EC820)
TCP state ESTAB, Flow Credits 2048, TCP Recv/Send Window 4119/8896 bytes
Input Msgs/Bytes/Errs 1/9/0 Output Msgs/Bytes/Errs 0/0/0
Server session, Peer address 192.168.10.6:27613 (tscb=0x61436CBC)
Process id 70 Reasembly State 0 (tcb 0x611EC3DC)
TCP state ESTAB, TCP Recv/Send Window 4128/8896 bytes
Input Msgs/Bytes/Errs 0/0/0 Output Msgs/Bytes/Errs 1/9/0
Cisco Transport Manager/CNM Client Service List
Client 192.168.110.51:0, Server 192.168.10.6:0 (entry=0x611DE680)
Several debug commands are available and provide additional information about the operation of the Cisco Transport Manager/CNM agent should a situation arise where more detailed information is needed to identify the source of a problem. The debug commands should be used judiciously to isolate a run-time problem in the field. System and Cisco Transport Manager/CNM performance will be negatively impacted when debugging options are enabled.
| Task | Command |
|---|---|
Turn on all debugging including the debugging options listed below. Turning on this option might cause a large number of debug messages to appear. | exec# debug cnm all |
Show events related to TCP connections including the establishment and termination of TCP sessions. | exec# debug cnm connections |
Display abnormal protocol or system errors such as lack of improperly formed messages, lack of memory, or other unexpected conditions. | exec# debug cnm error |
Show the operation of the leaky bucket flow control algorithm. | exec# debug cnm flow |
Show events related to the processing of Cisco Transport Manager/CNM messages, including detailed information like reception and transmission of messages, queuing of rate-limited messages, and message fragment processing. | exec# debug cnm messages |
Display other events not covered in the above list. | exec# debug cnm miscellaneous |
Posted: Fri Apr 7 10:24:17 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.