Log messages to an rsyslog server

Ok, so we have all done this a million times. Thing is I recently had to do this, and I typically use syslog-ng, but this time I was on a RHEL/CentOS box and wanted to just check it out with rsyslogd. Conclusion: syslog-ng is more flexible, rsyslogd is easier to setup. Here is how we do rsyslogd and syslog CISCO and Force10 to it.

This document will assume you are sitting on a CentOS 6.5 server installed with rsyslogd (the default) and that you have not modified the rsyslogd config files in any way. It will also assume you would like to do something like syslog messages from a CISCO ASA, perhaps a CISCO Catalyst style switch and a Force10 say an S50. Get on the CentOS server and as root do the following:

 

vi /etc/rsyslog.conf

 

You will find a section that reads:

# Provides UDP syslog reception

#$ModLoad imudp

#$UDPServerRun 514

 

You need to make that into the following:

# Provides UDP syslog reception

$ModLoad imudp

$UDPServerRun 514

$template HostBasedLog,”/var/log/%HOSTNAME%.log”

if $fromhost-ip startswith ‘192.168.’ then -?HostBasedLog

&~

 

Yes, the last part is an ampersand and a tilde on a line by itself. Some small explaining, the fromhost-ip line says that if it sees a udp syslog packet coming in on port 514 from a source IP address that starts with 192.168, then it will follow that rule to throw it in the log file based on the hostname of the sending server/switch/etc.

Save and exit that file and restart rsyslogd with:

 

/etc/init.d/rsyslogd restart

 

Or for you new systems administrators:

 

service rsyslog restart

 

Now, lets pretend you want to have your ASA5520 log to the syslog server. This document assumes you want to get informational messages (level 6), and that gigin is your “inside” interface on the ASA. Let us also assume your syslog server is at 192.168.100.1. On the ASA5510, in privileged exec mode, you would do the following if it is not already done:

 

logging enable

logging trap informational

logging device-id hostname

logging host gigin 192.168.100.1

 

You can of course add all kinds of features to that setup. If you are using the ASDM you can most likely configure it from there, although I hardly ever configure or use the GUI on the ASA.

Note that on a CISCO you can configure a number of options that I will not cover here. Specifically, there is timestaps, synchronous logging, etc. Note again I am going with a trap level of 6 (informational) and not 7 (debugging). Turning on debugging, even logging, can really punish a CISCO switch or ASA or router. On a CISCO catalyst style switch you would do the following in privileged exec mode:

logging 192.168.100.1

logging trap 6

 

You do not need to change the facility, as the default is local7. On to the Force10 switch. We assume you have an S50 style of switch. Again, in privileged mode:

 

logging history informational

logging 192.168.100.1

 

This works very similarly on the big iron like the CISCO 6500 and the Force10 C-series switches. For example, on a 6500 with multiple VLANs configured, let us assume the 192.168.100 vlan is called vlan 100. Note here we are going to do informational again. I would strongly advise against debugging on a large switch, unless you are actually debugging and your syslog server has the available bandwidth, both network and cpu/disk wise. One would configure the 6500 for logging with:

 

logging trap informational

logging source-interface Vlan 100

logging 192.168.100.1

 

That should do it. Since you restarted your syslog, you should see logs arriving when events happen on the switch, and they should be in /var/log/ and they should be named hostname.log where hostname is the actual host name of the switch. Note that a large number of devices support syslog (WiFi access points, switches, routers, firewalls, other servers, etc) and it is a nice item to have due to the fact that you can combine the log with the power of all of the built in UNIX tools for file searching and pattern matching (e.g. writing scripts with sed, awk, grep or perl). You can of course pay for some commercial tools or use open source tools, but the logs are an invaluable tool in problem solving when events are happening on switches.

This entry was posted in Servers, Software. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *