保存路由器日志信息到日志服务器中

保存路由器日志信息到日志服务器中

conf t
interface FastEthernet0/0
ip address 192.168.1.21 255.255.255.0
no shutdown
ip access-group 101 in
exit
!
logging trap debugging
logging 192.168.1.118
ip access-list logging interval 1000
ip access-list log-update threshold 10

access-list 101 permit ip any any log
no logging console
!

href="file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/msohtml1/01/clip_filelist.xml" rel="File-List" />

相关说明文档

Logging Facility

The single syslog daemon (syslogd) can be thought of as having multiple pipes. It uses the pipes to decide where to send incoming information based on the pipe on which the information arrives. In this analogy, the logging facilities are the pipes by which the syslogd decides where to send information it receives.

The eight logging facilities commonly used for syslog are local0 through local7, as shown below.

local0

local1

local2

local3

local4

local5

local6

local7

Levels

There are also different degrees of importance attached to incoming messages. Think of the levels as what. The LocalDirector can be set to send messages at the following different levels (these are listed from highest to lowest importance):

Level	Numeric Code
emergency	0
alert	1
critical	2
error	3
warning	4
notification	5
informational	6
debug	7

When a LocalDirector is set up to send syslog messages, levels of lower importance include levels of higher importance. For example, if the LocalDirector is set for warning, error, critical, alert, and emergency messages would also be sent in addition to the warning. A debug setting would obviously include messages at all 8 levels.

Configuring the LocalDirector to Send Syslog

The syslog syntax is as follows:

syslog host #.#.#.#

 

!--- #.#.#.# is the syslog servers address.

 

syslog output X.Y

 

!--- X is the logging facility and Y is the level.

 

How does the X number translate to logging facility?

The X number translates to a logging facility when converted to binary. The last bits bits comprise the local facility, as shown below.

16 = 00010000 = local0

17 = 00010001 = local1

18 = 00010010 = local2

19 = 00010011 = local3

20 = 00010100 = local4

21 = 00010101 = local5

22 = 00010110 = local6

23 = 00010111 = local7

For example, since 22 = 00010110, and the last 4 bits=0110=decimal 6, this is local6. A short-cut is to take the X value and subtract 16. For example, 22-16=6, or local6. On LocalDirector, the default facility is local4.

The Y number is the level. For example, if Y=2, messages sent would include those at level 2 (critical), level 1 (alert), and level 0 (emergency). The LocalDirector levels are 0-7; these should not be confused with the logging facilities, which are local0-local7. On LocalDirector, the default level is 3 (error). Two examples are shown below.

syslog 20.7

 

!--- 20 equals local4 logging facility.

!--- .7 is the level. 7 means debug to the LocalDirector, that is,

!--- all messages will be logged.

 

syslog 23.2

 

!--- 23 equals local7 logging facility

!--- .2 is the level. 2 means critical to the LocalDirector, that is,

!--- critical, alert, and emergency messages will be logged.

 

You can view the current facility.level and syslog server settings on LocaLDirector by issuing the show syslog command.

How to Set Up a Syslogd Server

Because syslogd was originally a UNIX concept, the features available in the syslogd products on non-UNIX systems depend on the vendor implementation. Features may include dividing incoming messages by facility or debug level, or both, resolving the names of the sending devices, reporting facilities, and so on. For information on configuring the non-UNIX syslog server, refer to the vendor's documentation.

To configure syslog on UNIX, perform the following steps:

1. As root, on SunOS, AIX, HPUX, or Solaris, backup the /etc/syslog.conf file prior to modification.
2. Modify /etc/syslog.conf to tell the UNIX system how to sort out the syslog messages coming in from the sending devices, that is, which logging_facility.level goes in which file. Make sure that there is a tab between the logging_facility.level and file_name.
3. Make sure the destination file exists and is writable.
4. The #Comment section at the beginning of syslog.conf usually explains syntax for the UNIX system. Alternatively, you can read the man page of syslogd with man syslogd .
5. Do not put file information in the ifdef section.
6. As root, restart syslogd to pick up the changes.

Examples

• If /etc/syslog.conf is set for local7.warn /var/log/local7.warn:

The warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged in the local7.warn file. The notification, informational, and debug messages coming in on the local7 facility will not be logged anywhere.

• If /etc/syslog.conf is set for local7.debug /var/log/local7.debug:

The debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file.

• If /etc/syslog.conf is set for local7.warn /var/log/local7.warn or local7.debug /var/log/local7.debug:

The warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.warn file. The debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file (some messages will go to both files).

• If /etc/syslog.conf is set for *.debug /var/log/all.debug:

All message levels from all logging facilities will go to this file.

Debugging Syslog

Before issuing any debug commands, please see Important Information on Debug Commands.

To start syslog in debug (SunOS, AIX, HPUX, or Solaris), you must be root:

 

ps -ef | grep syslogd

kill -9 <pid>

syslogd -d

You should see the following messages at the beginning, as syslogd is reading syslog.conf:

cfline(local7.info /var/log/local7.info)

cfline(local7.debug /var/log/local7.debug)

X X X X X X X X X X X X X X X X X X X X X X X 6 X FILE:

/var/log/local7.info

X X X X X X X X X X X X X X X X X X X X X X X 7 X FILE:

/var/log/local7.debug

If these scroll by too quickly, issue the following command:

syslogd -d | more

If you see the following messages:

cfline(local7.info /var/log/local7.junk)

syslogd: /var/log/local7.junk: No such file or directory

logmsg: pri 53, flags 8, from pinecone, msg syslogd: /var/log/local7.junk:

No such file or directory

There is a problem in the setup. In the above example, the file did not exist. Running a debug will also show incoming syslog messages and to which file they are going.

logmsg: pri 275, flags 0, from 10.8.1 .76, MSG 14: %SYS-5-CONFIG_I:

Configured

from console by vty0 (171.68.118.108)

Logging to UNUSED

Logging to FILE /var/log/local7.debug

In this case, a message that should have gone to local7.junk and local7.debug was received. Because local7.junk did not exist, the following message is also received:

Logging to UNUSED.

If syslogd -d shows that no messages are coming in, check to make sure that the show syslog command has been issued on LocalDirector. If syslogd information is arriving on the UNIX system, but not going into the proper file, work with the UNIX system administrator or operating system vendor support to correct the problem. If the cause of the problem still cannot be determined, syslog may be run in debug and the output redirected to a file as follows:

sh or ksh:

syslogd -d > <target_file> 2>&1

or

csh

syslogd -d >& <target_file>

Note: Red Hat Linux syslogd must be started with the -r option to capture network output.

UNIX Extension	Meaning
.emerg	System unusable, emergencies.
.alert	Take immediate action, alerts.
.crit	Critical condition, critical.
.err	Error message, errors.
.warn	Warning message, warnings.
.notice	Normal but significant condition, notifications.
.info	Informational messages, informational.
.debug	Debug message, debugging.

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

 

href="file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/msohtml1/01/clip_filelist.xml" rel="File-List" /> href="file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/msohtml1/01/clip_editdata.mso" rel="Edit-Time-Data" />

Syslog

Cisco IOS Software has the capability to do UNIX system logging (syslog) to a UNIX syslog server. The Cisco UNIX syslog format is compatible with 4.3 Berkeley Standard Distribution (BSD) UNIX. System logging is useful for monitoring interface status, security alerts, environmental conditions, CPU processes, and many other events on the router can be captured and analyzed by means of UNIX syslog. Management platforms such as Cisco Resource Manager Essentials (RME) and Network Analysis Toolkit (NATKit) make powerful use of syslog information to collect inventory and configuration changes.

The following is a summary and description of the recommended IOS configuration for syslog.

Global Syslog Configuration

Configure the following in global configuration mode:

no logging console

no logging monitor

logging buffered 16384

logging trap notifications

logging facility local7

logging host-ip 

logging source-interface loopback 0

service timestamps debug datetime localtime show-timezone msec

service timestamps log datetime localtime show-timezone msec

Interface Syslog Configuration

Configure the following in interface configuration mode on interfaces of interest:

logging event link-status

logging event bundle-status

Useful Syslog Commands

The following syslog commands are particularly useful:

• no logging console

• no logging monitor

• logging buffered 16384

• logging trap notifications

• logging facility local7

• logging host

• logging source-interface loopback 0

• service timestamps debug datetime localtime show-timezone msec

• logging event

no logging console

By default, all system messages are sent to the system console. Console logging is a high-priority task in Cisco IOS Software. This function was primarily designed to generate error messages to the system operator prior to a system failure. It is recommended that console logging be disabled in all device configurations to avoid a situation where the router/switch might hang while waiting for a response from a terminal. Console messages can, however, be useful during trouble isolation. In these instances, console logging should be enabled by means of the logging console level command, to obtain the desired level of message logging. Logging levels range from 0 to 7.

no logging monitor

This command disables logging for terminal lines other than the system console. If monitor logging is required (by means of logging monitor debugging or another command option), it should be enabled at the specific logging level required for the activity (see above).

logging buffered 16384

The logging buffered command should be added to log system messages in the internal log buffer. The logging buffer is circular. Once the logging buffer is filled, older entries are overwritten by newer entries. The size of the logging buffer is user-configurable and is specified in bytes. The size of the system buffer varies by platform. 16384 is a good default and should provide adequate logging in most cases.

logging trap notifications

This command provides notification (level 5) messaging to the specified syslog server. The default logging level for all devices (console, monitor, buffer, and traps) is debugging (level 7). Leaving the trap logging level at 7 produces many extraneous messages that are of little or no concern to the health of the network. It is recommended that the default logging level for traps be set to 5.

logging facility local7

This command sets the default logging facility/level for UNIX system logging. The syslog server receiving these messages should be configured for the same facility/level.

logging host

This command sets the IP address of the UNIX syslog server.

logging source-interface loopback 0

This command sets the default IP source address for the syslog messages. Hard coding the logging source address makes it easier to identify the host that sent the message.

service timestamps debug datetime localtime show-timezone msec

By default, log messages are not time stamped. Use this command to enable the time stamping of log messages and configure the time stamping of system debug messages. Time stamping enhances real-time debugging by providing the relative timing of logged events. This information is especially useful when customers send debugging output to technical support personnel for assistance. To enable the time stamping of system debug messages, use the above command in global configuration mode. This only has an affect when debugging is enabled.

logging event

The logging event link-status command enables logging related to link status. The logging event bundle-status command enables logging related to bundle status.