cc/td/doc/product/access/sc/r1
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Managing Status Alarms

Managing Status Alarms

4.1 Alarm Acknowledgment

The MML command, ALM-ACK, is used to acknowledge that an alarm is recognized. This does not clear the alarm; it is visible when a RTRV-ALM command is invoked. When this command is received by the Alarm Manager, the associated alarm is removed from a maintained list. If this is the last current alarm of a certain severity, then the associated alarm relay is turned off. 

ACK-ALM:<id>:<alarm category>

For example:

mml> alms-ACK:T-1-16:"SUPPORT FAILED"



 Sample Response:


CONFIG01/REL1 97-08-28 18:00:32
M COMPLD
;
mml> 



4.2    Platform Alarms

 
4.2.1    Retrieving Alarms


 This MML command displays all active alarms:


RTRV-ALMS



 Example:


mml> RTRV-ALMS 



 Sample Response:


CONFIG01/BUILD 13.6 97-05-15 16:24:20
M RTRV 
"T-1-1:SC M-OOS,MN"
;
mml>



4.2.2    Retrieving Alarms Continuously


 An MML session can be used to display alarms as they occur. This is achieved by entering the the following MML Retrieve Alarms Continuous command: 


mml> RTRV-ALMS::CONT



 Alarms and autonomous messages are reported continuously through this interface for the duration of the command. The format of the command and the autonomous messages are described in "MML Commands."


4.2.3    Platform Level Alarm and Recovery


 This section provides a list of possible platform level alarms that can be generated by the TransPath system software. Each alarm cause and recovery action is described.


 Configuration Load Failure "CONFIG FAIL"


 



 Alarm Cause


 Configuration file is corrupted when reading.




 Recovery Action


 Depending on the severity, the process will either continue or exit. If the process exits, the Process Manager will sense this and may post an error alarm. The Process Manager will keep a list of those processes that are required for full operation of the TransPath system.













 XE Resource Failure "XE RSRC FAIL"


 



 Alarm Cause


 Failures caused by resource exhaustion:


  • Memory exhaustion
    

  • Queue overflow
    

  • Message congestion
    





 Recovery Action


 Depending on severity, the process will either continue or exit.













 General Process Failure "GEN FAIL"


 



 Alarm Cause


 Failures caused by these configuration problems:


  • IPC File cannot be opened
    

  • Some timer expirations (e.g. IPC message is received after timer expiration.)
    





 Recovery Action


 Depending on severity, the process will either continue or exit. See "Alarm Support Diagrams" for method of resolving this alarm.













 Software Failure "SW FAIL"


 



 Alarm Cause


 Failures caused by the following software logic problems: 


  • Unknown message received.
    

  • Process in undesirable state.
    

  • Unexpected logic being executed (e.g. conditional code that should never be executed is being executed).
    

  • Some timer expirations.
    

  • Alarm Report: Informational.
    





 Recovery Action


 Depending on severity, the process will either continue or exit. See "Alarm Support Diagrams" for method of resolving this alarm.













 Operating System Failure "OS FAIL"


 



 Alarm Cause


 Something in the system OS has stopped functioning.




 Recovery Action


 Will require system administrator intervention. May require a system reboot. See "Alarm Support Diagrams" for method of resolving this alarm.













 Required Process Failure "SOFTW REQ"


 



 Alarm Cause


 A required process has exceeded the process restart limit for a process. The process cannot be started by the Process Manager for some reason.




 Recovery Action


 Investigate platform logs and establish the error condition. If this does not clear the problem, contact Cisco Systems Technical Assistance Center (TAC) for support. See "Alarm Support Diagrams" for method of resolving this alarm.













 Non-required Process Failure "SOFTW NON"


 



 Alarm Cause


 A non-required process has exceeded the process restart limit for a process. For some reason, the process cannot be started by the Process Manager. This condition does not adversely effect run time operations on the platform. However, the problem should be investigated and cleared as soon as possible.




 Recovery Action


 Investigate platform logs and establish the error condition. If the problem cannot be cleared, contact Cisco System Technical Assistance Center (TAC) for support. See "Alarm Support Diagrams" for method of resolving this alarm.













4.3    Entering the Log Level for Processes

 
 The MML command, CHG-LOG, sets the logging level for active processes only. This command can be invoked for individual active processes or for all processes. When the "ALL" parameter is used, a message is returned that some processes' log level did not change. The processes that did not change their log level are the monitored and passive processes.


CHG-LOG:<procName>:<logLevel>
CHG-LOG:ALL:<logLevel>



 For a more detailed explanation of the elements of this process, see "MML Commands."


4.3.1    Setting the Log Level of a Process


 The following is an example of this command for a single process:


mml> CHG-LOG:ENG-01:INF 



 Sample Response:


CONFIG01/BUILD 13.6 97-05-15 16:35:29
M COMPLD
 ;
mml>



 See "MML Commands" for log levels and their meanings as applied to single processes.


4.3.2    Setting the Log Level of All Processes


 The following is an example of a command for setting all processes to a log level of "warn":


mml> CHG-LOG:ALL:WRN 



 Sample Response:


CONFIG01/BUILD 13.6 97-05-15 16:37:43
M COMPLD
 SNSP
 "DSKM-01:Operation not supported"
 /* Status, Operation Not Supported By Component */
 SNSP
 "IOCC-01:Operation not supported"
 /* Status, Operation Not Supported By Component */
 SNSP
 "IOCC-02:Operation not supported"
 /* Status, Operation Not Supported By Component */
 ;
mml>



 This response indicates that the DSKM-01, IOCC_01, and IOCC-02 processes will not allow their log levels to be changed. 


 See "MML Commands" for log levels and their meanings as applied to all processes. 


4.3.3    Clearing an Alarm


 The following is an example of the mml command used to clear an alarm category for a component:


CLR-ALM:<compName>:<alarmCatName>



 For example: 


mml>CLR-ALM:T-1-16:"SUPPORT FAIL" 



 Sample Response:


CONFIG01/BUILD 13.6 97-05-19 12:22:57
M COMPLD
;
mml>



 For a more detailed explanation of the elements of this process, see "MML Commands."


4.4    Network Measurements and Statistics - Log Record Dumper

 
4.4.1    			Purpose


 The purpose of this subsystem is to periodically collect measurements from the TransPath system, and save them to log files for further extraction and examination by external programs with access to the TransPath log files.


4.4.2    		Log Record Dumper Description


 The Dumper collects and assembles Call Detail, Measurement, and Alarm records into log files for a configurable period. The Dumper closes the log files for the current period and opens new log files. The files being written to are called the "current" file period, and the log files that have been closed are called the "historical" files. Closed log files are moved to the spool area for retrieval or off-line inspection.


4.4.3    			Log File Naming Conventions


 Each log file contains a set of records particular to the type of log. The Log Record Dumper Configuration can be tailored to meet your specific requirements. The logs are saved as UNIX files in the TransPath system spool area with a short, descriptive name. The naming and format of the records are described in this section. These names are built from the following identifiers:


<Record Type>_<yymmddHHMMSS>.<Record Format>



 <Record Type> represents the type of record being placed in the file. This can be altered via the Dumper configuration file (see Record Formats
 below) by using the following:





 CDR


 Call detail records




 ALM


 Alarms




 MEAS


 Measurement counters
















 <yymmddHHMMSS> represents the date and time when the capture file was created using "Time of Epoch," January 1, 1970:





 yy


 Two digit year.




 mm


 Two digit month (Julian calendar).




 dd


 Two digit day.




 HH


 Two digit hour (24 hour clock GMT).




 MM


 Two digit minutes.




 SS


 Two digit seconds.
















 <Record Format> represents the format of the record being placed in the file:





 CSV


 Comma separate variable.




 BIN


 Binary.
















 		Record Formats


 The format of records in the capture files are specific to each record type and format. This section will display only those in CSV format.


 Time stamps are always in the number of seconds starting on January 1, 1970 at 00:00:00 GMT.


 Alarm Record Format


 



 releaseLevel


 Record release level (version).




 timeStamp


 Time when record was written to log.




 state


 Set to 1 if the alarm is active, 0 if the alarm is clear. For informational alarms, state is always set to 1.




 severity


 Severity of the alarm.




 alarmCat


 Name of the alarm category. See alarmCat.dat in "Data Dictionary and Glossary." 




 componentId


 Component on which the alarm occurred. See components.dat in "Data Dictionary and Glossary."




 originator


 Process that originated the alarm. See components.dat and processes.dat in "Data Dictionary and Glossary."













 Measurement Record Format


 



 releaseLevel


 Record Release Level (version).




 intervalStarted


 Time when measurement interval started using timeStamp format.




 intervalSeconds


 Elapsed time of collection interval in seconds.




 measValue


 Value of the measurement at the end of the interval.




 severity


 Severity of the alarm.




 measUnit


 Type of measurement (e.g. number of occurrences).




 measCat


 Measurement category. See measCats.dat in "Data Dictionary and Glossary."




 componentId


 Component for which the measurement was being made. See components.dat in "Data Dictionary and Glossary."













 Call Detail Record (CDR) Format


 Records are fixed length and written in binary (i.e. hex, etc.). One record is written per call. Field lengths in the table below refer to the number of decimal digits or characters that must be stored.



Table 4-1: Call Detail Record Definition Table 




Field Name
Data Type
Field Length
Comments



 Revision Level


 Integer


 3


 Describes format of records.




 Pre-translation. CLI Type Indicator


 Integer


 1


 Indicates whether calling line identification (CLI) was present.


 1 = present; 0 = not present




 CLI - pre-translated


 String


 32


 CLI prior to any translation performed by TransPath.




 Dialed Number Pre-translation Indicator


 Integer


 1


 Indicates whether the Dialed Number was present.


 1 = present; 0 = not present




 Dialed Number - pre-translation


 String


 32 


 Dialed number prior to any translation performed by the TransPath .




 Post-translation. CLI Indicator


 Integer


 1


 Indicates whether a translated CLI is present.


 1 = present; 0 = not present




 CLI - post-translation


 Integer


 32


 CLI after any translations performed by the TransPath.




 Post-translation. Dialed Number Indicator


 Integer


 1


 Indicates whether a translated Dialed Number was present.


 1 = present; 0 = not present




 Dialed Number - post-translation


 String


 32


 Dialed Number after any translations performed by the TransPath.




 Setup message timestamp


 Integer


 10


 Time when the initial setup message was received.




 Line seizure occurred timestamp


 Integer


 10


 Time when the line was seized.




 Answer supervision received timestamp


 Integer


 10


 Time when the call was answered (if applicable).




 Disconnect message timestamp


 Integer


 10


 This is the time when call ended (if applicable).




 Direction of disconnect


 Integer


 1


 This is the side of the call that disconnected first:


 0 = originating side


 1 = terminating side




 Release code


 Hex


 4


 Cisco Systems specific format.




 Signal Path ID In


 Hex


 8


 ID for the originating Signal Path.




 Traffic Channel ID In


 Hex


 5


 ID for the originating Traffic Channel.




 Protocol In Family1


 Integer


 2


 Numeric representation of the protocol family for the originating side, which can be the following:


  • ISDN PRI 0
    

  • C7 1(Currently Not Supported)
    

  • DPNSS 2
    

  • CAS 3 (Currently Not Supported)
    

  • ASN 4
    

  • Unknown 5
    





 Signal Path ID Out


 Hex


 5


 ID for the terminating Signal Path.




 Traffic Channel ID Out


 Hex


 6


 ID for the Traffic Channel.




 Protocol Out Family*


 Integer


 2


 Numeric representation of the protocol family for the terminating side, which can be the following:


  • ISDN PRI 0
    

  • C7 1 (Currently Not Supported)
    

  • DPNSS 2
    

  • CAS 3 (Currently Not Supported)
    

  • ASN 4
    

  • Unknown 5
    





 Bearer Capabilities


 Hex


 4


 Voice and 64K Data in Cisco Systems specific format (TBD) are examples.




 Orig. Line Information


 Hex


 4


 Supplied by some protocols Cisco Sytems specific format (TBD).




 Customer ID


 Integer


 5


 Internal to Cisco Systems.








1The items contained in "Protocol Family" in and out indicate general groupings or families of protocols. This means, for example, that ETSI00-102 and QSIG would both have this field set for zero since they are both Q.931based. Future releases of TransPath system will allow the ability to distinguish individual protocols within a family.





 		Viewing Capture Files


 The capture files produced by the Dumper are stored as UNIX files in the spool area. They can be retrieved and viewed through a variety of means including a text editor or a custom report generator. The record format of each type is described above. It is feasible for the capture files to be automatically retrieved and processed by a customer Operations Support System.


 		Installation and Configuration Instructions


 The Dumper is installed to run automatically by the Process Manager with a default configuration via the Package Install operation.


 To change the configuration, follow these steps:



Step 1	 Stop the Dumper program.



Step 2	 Edit the configuration file called "dmprSink.dat."



Step 3	 Restart the Dumper program.


 		Site Configurations


 The Dumper will function correctly using the default settings. The customer can customize the Dumper settings by editing the dmprSink.dat text file.


 The following three records in the file for the logs are collected:



 While all fields are customizable, modifications to the following fields are recommended:



Note One or more of these fields must be set for each record in the dmprSink.dat file.





 maxRecs


 Maximum number of records that a file is allowed to contain before it is flushed or moved to the spool area. If this is 0, the number of records is unlimited.




 maxSize


 Maximum size of the file before it is moved to the spool area. If this is 0, the size of the file is unlimited. The default is 0.




 maxTime


 Maximum time the file is allowed to remain open, in minutes, before it is flushed or moved to the spool area. If this is 0, there is no time limit. If there is no data in the file, it will not be flushed if the time limit is exceeded.
















 It is recommended that the following fields not be modified or changed:





 recordFormat


 Translation of the records being placed in the capture file. Defaults to "CSV" or "BIN".




 logDirectory


 Directory where the current Dumper logs reside.




 logSpoolDir


 Directory where the historic logs are copied to after being closed.
















 		Other Affected Files or Commands


 The Dumper can potentially generate a large number of files to the logSpoolDir area. For example, if a maxTime value (field 3 listed above) of fifteen minutes is set, over two hundred files would be created in the logSpoolDir every day.


4.5    Retrieving Measurement Category Counter Values

 
 The following MML command retrieves a measurement counter on a component:


RTRV-CTR:<comp>:"<measCatName>"



 For example:


mml> RTRV-CTR:T-1-1:"SC: RCV FRM TOT"



 Sample response:


LPC Release 1.0 97-08-28 21:15:54
M RTRV
"T-1-1:b_chR_tot15=0"
"T-1-1:b_chR_tot60=1"
"T-1-1:b_chR_tot24=27"
;
mml>



 For a more detailed explanation of the elements of this command, see "MML Commands."


 







hometocprevnextglossaryfeedbacksearchhelp




Copyright 1989-1998 
 © 
Cisco Systems Inc.