Event Logging System

The Event Logging System is a competent network assessment tool resident in OpenROUTE Networks, Inc. units.

The ELS offers many subsystems to evaluate. Within each subsystem are events which describe what is happening in the router. These subsystems can describe activity at the protocol, data-link, or device level. When configured to do so, a description of these events, as they occur, will be sent to the same monitor that is used to configure the unit.

The user can, in the midst of configuring and/or monitoring the router, ask the Command Line Interface (CLI ) to get out of that operation and change-- such that the screen will act as a live reporter on the activities of the unit. Each event that occurs in the router can become a descriptive sentence scrolling up the monitor screen. What you will see depends upon the commands you issued while you were still in the configure/monitor operation.

Example:

* MONITOR
+ EVENT
   Event Logging System user console
ELS>NODISPLAY SUBSYSTEM all ALL
ELS>DISPLAY SUBSYSTEM d
The choices/prefixes are (a complete list):

ELS>DISPLAY SUBSYSTEM s

The choices/prefixes are (a complete list):

ELS>DISPLAY SUBSYSTEM i The choices/prefixes are (a complete list):

ELS>DISPLAY SUBSYSTEM IP ALL

ELS>DISPLAY SUBSYSTEM ALL ERROR

ELS> ^P

* TALK 2

This is the first time you have run OpenROUTE (tm) 3.0[P7].
Please see the release notes for information about important changes to the configuration information for going to OpenROUTE (tm) 3.0[P7].
After updating the configuration information, give the
Config> UPDATE VERSION-OF-SRAM command.
GW.001:
Copyright 1984 Massachusetts Institute of Technology,
Copyright 1989 The Regents of the University of California
GW.002: Portable COW myRouter Rel OpenROUTE (tm) 3.0[P7] strtd
GW.005: Bffrs: 400 avail 400 idle fair 103 low 80
SL.044: no cable installed, dev WAN
ETH.047: Eth self-test Operational test fld maintenance failure nt 0 int EW0
It is important to re-iterate that what you ask the CLI to show will be shown. Therefore if you ask it to display subsystem all all, everything that happens inside the router will be sent to the screen. In a busy network, this could cause the router to spend so much time buffering messages and then sending them to the screen that it could impair the router's ability to route. A common-sense approach to choosing which subsystems to display will not only produce only information that is usable, but also a screen that is increasingly readable. Remember, the reason to display in the first place is to learn something specific. It is not to see how much information the router can display. Finally, to stop the display and return to the CLI, type ^P.

If the messages seem to 'hang' the screen, it is probable that there are no more messages 'in queue'. Doing the command, at this point is desirable also. While most of the messages are readable you will have to 'fill-in' vowels and the like--you will want to cross-reference these messages with a manual. The manual explains the messages in plain text, giving the probable cause (s) and configuration changes possible in the event that the event shown is an error message. These events can be used to show the 'bring-up' of a connection, or data-link, or protocol. It then can be used to detail the moment-by-moment activity of these subsystems.