| |
|
|
This manual documents the system logging messages generated and displayed by the TSR and SSR systems.
During operation, each subsystem has the capability to generate a logging message. Severity levels of logging messages provide information regarding unexpected events, aid in system troubleshooting when problems do occur, and generate critical alarms when warranted. Users can configure how, where, and when the logging messages are displayed and stored according to their own network's requirements.
The following chapter offers a brief overview of configuration information, message formats, and display options. For configuration and command line information, please refer to the IPriori Software Configuration Guide (Vol. I) and IPrior CLI Reference (Vol.1) respectively.
Logging Messages
Logging messages originate from a subsystem and are relayed to a r a server, module, or bay platform on the TSR. The subsystem identification within each logging message specifies the occurrence and time when the logging message originated. In addition, each logging messages' severity level identifies the nature of the event and provides the user with a basis for filtering messages. Filtering of logging messages allows users to determine the use of resources, viewing of messages, and display options.
With the exception of Critical level messages which are sent to the server immediately, logging message that pass filtering criteria are immediately stored in RAM on the local platform before being sent to the server. Multiple logging files may be configured for each platform.
Message Format
Information displayed in the format of the logging message includes the platform forwarding the message, the subsystem generating the message, the day, date, and time of the message, the severity level, and the reason the log message generated (see Figure 1-1). Refer to Table 1-1 for descriptions of the logging message fields.
Figure 1-1. Logging Message Format
Severity Levels
Each logging message is assigned a severity level. Severity levels indicate the effect the subsystem occurrence had on the operation of the system. Regardless of any filtering configured, Critical level logging messages are always generated.
The severity level codes are as follows:
- CRITICAL: Errors that result in a platform reset, or errors that will cause the platform to halt very soon. Also used to indicate that a critical subsystem failed to initialize correctly.
- MAJOR: Errors that result in performance degradation. The problem can result in the incorrect operation of more than one subsystem and will likely cause a halt.
- MINOR: A problem that affected one subsystem, but operation of other subsystems should be unaffected.
- WARNING: Notification of an unexpected or unusual event. An abnormal condition, but the unit should continue to operate normally. In some cases, hundreds of warning messages may indicate a service-impacting problem.
- INFO: Notices of an informational nature that do not indicate a problem with the subsystem.
Subsystem Identifiers
Also contained with the message format is a subsystem identifier. The subsystem identifier, which specifies exactly what triggered the the logging message, indicates the source of the logging message. Subsystems operate on specific platforms as shown in Table 1-2 "Logging Subsystems Supported - by Platform."
Table 1-2 provides the following information:
- List and description of all subsystems
- The platform(s) on which each subsystem operates:
Table 1-2. Logging Subsystems Supported - by Platform Subsystem CS1 M2 BC3 Description os
X
X
X
System module; includes: operating system logging, TSR logging, and memory and buffer management
acm
X
X
Arp Cache Manager
alarms
X
X
X
arp-cache-mgr
X
ARP Cache Manager messages
arp-tbl-mgr
X
ARP Table Manager messages
avl-library
X
AVL tree library messages.
bay-controller
X
Bay controller communications/hardware messages
bgp-events
X
BGP events information
bgp-updates
X
BGP updates information
cli
X
CLI messages
co-alarm
X
Central office alarm messages
data link
debug
X
system debug messages
environment
X
X
Environmental-based messages
Includes temperature and fans
fph
X
X
Failure Protection Handler
gated
X
Gated support
gated-ldp
X
Gated support for LDP
gated-te
X
Gated Extensions for Traffic Engineering
gated-te
X
Gated Extensions for Traffic Engineering
ha fttcp
X
High Availability messages
isis
X
IS-IS routing protocol messages
isis-te
X
ISIS Extensions for Traffic Engineering
ldp
X
MPLS Label Distribution Protocol (LDP) messages
management
X
X
X
Management error messages
multicast
X
Multicast messages
message-transport
Message Transport error messages
module
X
Router module communications/hardware messages
mpls-statc
X
TE/MPLS Statistics Collector messages
ospf-events
X
OSPF events
ospf-linkstate
X
OSPF Link state packets, flooding and spf
ospf-te
X
OSPF Extensions for Traffic Engineering
packer fpga
X
Packer Driver Error messages
pkt filt
X
X
Packet filtering messates
pim
X
PIM Protocol messages
policy
X
Routing policy messages
post
X
X
POST messages
qos-manager
X
QOS manager messages
rep bgp
X
High availability messages
rep fttcp
X
High availability messages
resource-mgmt
Resource management events
rtm
X
X
Route Table manager
routing
Non-specific routing functionality.
server
X
Server communications/hardware messages
snmp
X
SNMP error messages
snmp-traps
X
X
X
SNMP generated trap messages.
switch-mapping
X
Switch mapping messages
system-events
X
X
X
Special events signalling a change of platform or interface state
te-api-common
X
Common Traffic Engineering Internal API.
te-api-gated
X
Gated Traffic Engineering Internal API.
te-api-pathmgr
X
Path Manager Internal API.
te-api-rsvpd
X
RSVPd Traffic Engineering Internal API.
te-api-swmap
X
Switch Mapping Internal API.
te-ipc
X
TE IPC messages
te-ipc-library
X
TE IPC library messages.
te-ipc-memory
X
TE IPC memory allocation.
traffic-engineering
X
Traffic engineering messages
transport
X
Transport messages
user-commands
X
X
X
CLI commands entered during sessions.
1CS = Server 2 M = Module, 3 BC = Bay Controller Filtering Messages
Filtering of logging messages allows users to determine which messages display and where. Filtering restricts the quantity and diversity of messages as well as defining time periods when messages generate. In addition, efficient filtering makes the best use of the Ethernet link bandwidth between a platform and a server.
The two types of message filtering available are input filtering and display filtering. Input filtering filters messages by severity level at the time of message generation. Only messages with a severity level at or above the configured setting are sent to the server (see Figure 1-2).
NOTE Critical level messages can not be filtered. They are always sent to the server immediately.
Figure 1-2 shows input filtering configured at the warning level. Messages at the warning level and above are sent to the server, and messages below the warning level are discarded.
Figure 1-2. Input Filtering Example
Any messages that pass input filtering are written to the log files, regardless of the display filter settings. Display filtering further reduces the messages sent to the console or telnet session.
Display Options
Messages display to the console, current telnet session, or to user created file. Messages can either be displayed as they arrive at the server or displayed from saved files. Message-filtering options are the same regardless of display choice.
Display filtering directs messages logged onto the server to the console, monitor, or log file. Display filter criteria is by platform, subsystem, and severity level. In addition, start and end time stamps may be configured. Logging files may be searched and sorted by any allowed filtering configuration, with the output sent either to the console or to another file.
Log Files
Messages that pass input filtering are stored in log files on a hard disk partition. Because the size of each log file is fixed at 500K, multiple files must be configured for each platform. The default setting for each platform is five log files. Depending on a user's needs, the number of logging files for each platform can be configured separately, as long as the total disk space of the log files does not exceed 2Gbytes.In most cases, the default values satisfy log file requirements. However, increasing the number of log files on a platform can help in troubleshooting a sporadic error.
For each platform, when the maximum number of log files has been reached, the save file will roll over to the next file number. For example, if the server is set to 5 log files, when the next file is saved, it will roll over to the number 0. The old log file is written over (see Figure 1-3).
Figure 1-3. Log File Rotation
File names are determined by platform (server, router module or bay controller.) File names indicate the platform number and file number (from 0 up to one less than the configured maximum number of log files allowed). The default is 0-4. File name formats are described in Table 1-3 "Save File Name Formats."
Display of logging files can be configured to a console or a telnet session.
NOTE When a system is first booted and the server ID has not been set using the server-id command, the server ID defaults to 0. If you see that the server files are named SRV0000.yyy, you will need to give the server a unique ID using the server-id command.
Preparation for Customer Support
For any message in which the action directs you to "contact Avici Customer Support," you must first save your system log to a file. Use the following command to generate the syslog:
copy logging filename
where filename is a unique name.
NOTE Do not over-write the output file (filename) if you are going to contact Avici Customer Support.
See the Preface for information about contacting Customer Support.
| |
|
|
Copyright © 2006
Avici Systems Inc.
Avici® and TSR®
is a registered trademark of Avici Systems Inc.
IPriori™, Composite Links™, SSR™, QSR, and NSR® are
trademarks of Avici Systems Inc.
Source
File Name: Overview.fm
HTML File Name: Overview.html
Last Updated: 09/26/06 at 14:20:29