James Hanback It could even cure your acne or stop that annoying cough you can’t seem get rid of. You know better. Computer systems have become so embedded in our lives that many of the most common problems we face are now easily solved by a system reboot or pressing the Caps Lock key. The user reboots, and hopefully, the user can move on.
As you progress in your career, maybe you take on the role of server administrator or network administrator. This makes it less practical to fix problems. Rebooting a router or managed switch is unlikely to solve all problems unless you have accessed the network device’s running configuration and not yet written it to it, or if there’s a memory issue or other hardware issue that only a powercycle can resolve. It is a great way for your company to temporarily disrupt its business and irritate your co-workers, especially if it is done without notifying them. No longer can you rely on the operating system’s simple, dying request that you restart. Susan Kare, an old version of Mac OS, illustrated this famously with a friendly bomb with a lit fuse. You must now interpret error messages and use them to guide you in your troubleshooting quests.
Syslog is a logging standard that was originally created in the 1980s. Syslog is commonly found on Unix and Linux systems as well as network devices such Cisco IOS switches and routers. If you’ve ever used the no shutdown command to shut down a Cisco router’s network interface, you will have seen output similar to this:
Sep 5 09/10:28.087 : %LINK-3 UPDOWN Interface FastEthernet0/0 changed state to Up Sep 5 09/10:29.087 : %LINEPROTO-5 UPDOWN Line protocol on Interface FastEthernet0/0 changed state to Up
The console output shown above displays two interface messages in standard Berkeley Software Distribution Syslog format. This is how Cisco IOS implements it. The first message indicates that FastEthernet0/0 has moved to the up state. The second message is that the FastEthernet interface line protocol has changed to the up state. The Syslog message format for Cisco devices can be identified using a percent sign (%), followed by a facility code and a severity code. These codes are separated by dashes. The dash-separated codes will be followed by a colon or descriptive text that explains the event in plainer terms.
Each message in our example starts with a timestamp. This indicates the exact date and time of the event, at least according the device’s system clock. (And that’s a whole other story). If you don’t see timestamps similar as the ones shown above on your Cisco device you may need to issue the global configuration mode service timestamps log timetime msec command. If your system does not display log messages with timestamps, the output lines above will begin with the percent sign. In this example, however, we can see that physical interface transition took place on Sept. 5, at 9:10 a.m., and lasted 28 seconds. The line protocol transition took place exactly one second later.
The facility code and the percent sign follow the timestamp. Cisco device facility codes are usually free-form keywords that are used to identify the service and software that generated the message. The facility code LINK is displayed on the first line of output. This allows you to deduce that the event occurred.
