Logging
| When logging is enabled on a router, messages for certain events that occur on the router are created and stored. The log may reside on the router, or it may be an external log, residing on a server somewhere in the network. Routers send output from debug commands and system error messages to the logging process. The logging process distributes the messages to the various logging devices and files, depending on the router configuration. Messages are sent to the logging buffer, to terminal lines, and/or to a UNIX syslog server. The logging buffer is maintained on the router. It is a circular buffer, with the oldest messages replaced by the newest messages. The oldest entry appears first when you are viewing the log. NOTE The syslog format is compatible with 4.3 BSD UNIX. The following commands enable the log to be buffered, show the contents of the log, and clear the log:
Messages sent to a syslog service are stored in files on a server. The messages are sent directly to the syslog process running on the server, which stores the messages in the appropriate files. The logging host command enables logging to the syslog server and specifies the IP address of that server. When you Telnet to a router, normally you do not see any log messages. To enable the router to send log messages to the Telnet session, enter the EXEC command terminal monitor. You do not need to enter the command if you connect to a router via the console port. The default configuration is to send logging messages to the console port. The router will send all messages, from the debugging level to emergencies, to the Telnet session, which is extremely useful when troubleshooting problems. Log all information sent and received over the Telnet session, and you will have a good record of debugging activity and events that occurred on the router while you were connected to it. NOTE Log the information via the Telnet application's logging or capture facility. Time stamps must be enabled and the clock set to make the information in the logs meaningful. Example 9-13 displays the output of the show logging command with no time stamps enabled. Example 9-13 Output of the show logging Command Seattle# show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 9 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 9 messages logged Trap logging: level informational, 13 message lines logged Log Buffer (4096 bytes): %LINK-5-CHANGED: Interface TokenRing0, changed state to administrative ly down %LINK-5-CHANGED: Interface Serial0, changed state to administratively down %LINK-3-UPDOWN: Interface Serial1, changed state to down %SYS-5-CONFIG_I: Configured from console by console There is no reference to the time that any of the events occurred. Using the service timestamps log uptime command displays the time stamp with the time since the system was last rebooted. Example 9-14 displays the same log output with service timestamps log uptime enabled. Example 9-14 Output of the show logging Command with service timestamps log uptime Enabled Seattle# show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 9 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 9 messages logged Trap logging: level informational, 13 message lines logged Log Buffer (4096 bytes): 00:00:39: %LINK-5-CHANGED: Interface TokenRing0, changed state to administratively down 00:00:39: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down 00:00:39: %LINK-3-UPDOWN: Interface Serial1, changed state to down 1d07h: %SYS-5-CONFIG_I: Configured from console by console The events are time stamped. You can see that the first three events occurred at the same time. In fact, they all occurred 39 seconds after router startup. The fourth event occurred 1 day and 7 hours after the router startup. To display the actual date and time, as known by the router, enter the following command: service timestamps log datetime [ msec ] [ localtime ] [ show-timezone ] This time can include milliseconds and can be displayed as the router's local time. The time zone can be displayed. Some routers do not maintain calendars, so when they reboot, their clock resets. If no network time protocol is being used, you need to set the clocks manually by using the following EXEC command: clock set hh:mm:ss day month year When you are recording log information from multiple routers, consistent time stamp information makes event correlation much easier. When troubleshooting problems, and looking for messages that were reported from multiple routers due to a particular event, it is useful to have all routers time stamp their messages using a single time zone ”that is, do not specify localtime. If each router is time stamping the message with its localtime, you should specify show-timezone for clarification . Syslog daemons log the date and time in the file based on their own clocks at the time a message arrives. You can limit the messages logged by specifying the severity level of messages. Table 9-2 lists the message logging levels. Table 9-2. Message Logging Levels
If you specify a level of messages to see in a particular log, you get that level and all levels above. If you specify debugging, for instance, you get all levels of messages. If you specify warnings, you also get errors, critical, alerts, and emergencies. Specify the level using the following configuration commands:
Software and hardware malfunctions display at the levels warning through emergencies. Interface up/down transitions and system restart messages display at the notifications level. Reload requests and low-process stack messages display at the informational level, and debug output displays at the debugging level. Example 9-15 shows the configuration of a router located in Seattle, in the Pacific time zone. Example 9-15 Configuring Logging of a Router in Seattle (Pacific Time Zone)service timestamp debug datetime localtime show-timezone service timestamp log datetime localtime show-timezone clock timezone PST 8 clock summer-time PDT recurring logging buffered The router's system clock is based on Coordinated Universal Time (UTC), which is the same as Greenwich mean time. Pacific standard time is 8 hours earlier than UTC. Example 9-16 displays the router's log after the configuration referenced in Example 9-15 has been implemented. Example 9-16 Display of the Logging Buffer After the Configuration Listed in Example 9-15 Is Implemented Seattle> show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 8 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 8 messages logged Trap logging: level informational, 12 message lines logged Log Buffer (4096 bytes): *Nov 28 16:00:39 PST: %LINK-5-CHANGED: Interface TokenRing0, changed state to administratively down *Nov 28 16:00:39 PST: %LINK-3-UPDOWN: Interface Serial1, changed state to down *Nov 28 16:00:39 PST: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down *Nov 30 12:00:39 PST: %SYS-5-CONFIG_I: Configured from console by console Although the logging buffer is very useful if no syslog server is available, it has some drawbacks. Searching for an event requires either paging through the entire file or saving the file to another system and using the system's search facilities. If you are looking for a very recent event, you have to page through the entire file (or again, save the file to another system), because the oldest events display first. Logging to syslog automatically creates a file on the UNIX server, which offers better search and file maintenance techniques. |
![Routing TCP[s]IP (Vol. 22001)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 22001)"){kind=icon}