Junos and all things syslog

This article is about Junos and all things syslog. I'll go over several examples showing you what you can configure under the [ system syslog ] stanza. Parts of the examples I use here are based on what I think can benefit a device running Junos OS. I'll cover logging to a syslog server, a file, users and wrap up with the configuration of remote logging for traceoptions.

Logging to a server:

Starting with the basics, to make a Juniper device send syslog information to a server, you can configure the following:

set system syslog host 10.0.0.1 any any

This configuration command will make the device send syslog messages for any facility (the source that generates the messages) and any severity. If you want, narrowing things down is possible. Instead of inserting 'any', just hit the '?' in the configuration menu and select whatever you think is interesting. The list of facilities and severities is pretty self-explanatory. I chose 'any any' so I can do the filtering on the syslog server.

Most of the messages you can expect from a Junos device can be found in a document called 'Junos OS System Log Messages Reference'. On certain platforms you can also try issuing 'help syslog message' from the CLI:

play@MX480-00-RE0> help syslog SNMP_TRAP_LINK_DOWN
Name:          SNMP_TRAP_LINK_DOWN
Message:       ifIndex <snmp-interface-index>, ifAdminStatus <admin-status>, ifOperStatus <operational-status>, ifName <interface-name>
Help:          linkDown trap was sent
Description:   The SNMP agent process (snmpd) generated a linkDown trap because the indicated interface changed state to 'down'.
Type:          Event: This message reports an event, not an error
Severity:      warning
Facility:      LOG_DAEMON

Logging to a file.

Let's look at two examples where we log messages to a file. First a rather generic one:

set system syslog file messages any notice
set system syslog file messages authorization notice

These configuration statements will send messages from any facility with the notice severity to the file called messages. Defaults can vary per Juniper device, but an MX will write messages to a file until it reaches 1 Megabyte. After that, the MX will store the file and create a new one to write subsequent messages to. In total, up to 10 files are stored. After the MX has stored 10 files, it will start to overwrite them. This default behavior can be changed. For instance, if we want to store 15 files, with a 2 Megabyte maximum file size each, we can configure the following:

set system syslog archive size 2m
set system syslog archive files 15

Let's configure another example file. The following will generate a log, called 'commands'. This log will contain the commands that have been issued by any user;

set system syslog file commands interactive-commands any
set system syslog file commands archive size 1m
set system syslog file commands archive files 5

Note that because this file has a size and a maximum configured for it, those values will take precedence over the default behavior that is configured for the device.

To have a look at the content of one of the files we just created, we can use a show command. By issuing the following command, we can see exactly what user 'play' has been up to:

Instead of issuing show commands, we can also make the terminal follow a file that the device is writing messages to. To follow the file called 'messages', issue the following command:

monitor start messages

To stop following this file:

monitor stop

The files generated by the device will be stored in /var/log/. This can come in handy when you want to obtain (or delete) any of the files.

Logging to a user.

Another place to send messages to are users. When a device is configured to send messages to users, it will send messages to the specified users when they are logged in via SSH or Telnet. What I like is to have everyone staring at a terminal informed about certain events. This includes critical events, other users logging in to the device and other users altering the configuration of the device. To accomplish this, you can configure something like the following:

set system syslog user * any critical
set system syslog user * authorization info
set system syslog user * interactive-commands notice
set system syslog user * match "!(.*Login attempt.*)"

The '*' means any user, so everyone currently logged in will be updated. And by putting the 'notice' option after the 'interactive-commands', the terminals in use will not get cluttered. Everyone will be informed about the import stuff, like users entering configuration mode, users altering the configuration or users restarting processes.

The match "!(.*Login attempt.*)" part is a way to filter out syslog messages that contain certain strings. In this case, any message containing the 'Login attempt' string is omitted from being displayed. You can use this approach to filter out any other annoyances you might have logging to any of the possible destinations. The easiest way to filter out multiple strings is by using a pipe, like this:

"!(.*Login attempt.*|.*something_annoying.*|.*something_not_interesting.*|.*etc.*)"

Back to where we were, logging to a user. Let's look at the terminal belonging to user 'play'. The following will show you what happens when another user, called 'play1', logs in and changes the configuration of the device:

play@MX480-00-RE0>
Message from syslogd@MX480-00-RE0 at Aug 29 07:43:30  ...
MX480-00-RE0 mgd[85992]: UI_DBASE_LOGIN_EVENT: User 'play1' entering configuration mode

Message from syslogd@MX480-00-RE0 at Aug 29 07:43:49  ...
MX480-00-RE0 mgd[85992]: UI_COMMIT: User 'play1' requested 'commit' operation (comment: change nr 34255)

Message from syslogd@MX480-00-RE0 at Aug 29 07:43:55  ...
MX480-00-RE0 mgd[85992]: UI_COMMIT_COMPLETED: commit complete

Nice to know you're not the only one logged in and doing things.

Remote logging for traceoptions.

One last thing I wanted to go over is the fact that you can send traceoptions towards your syslog server as well. The configuration knob for this cannot be found in the [system syslog ] stanza, it's hidden elsewhere. The following configuration command will transfer output from all activated traces to your syslog server:

set system tracing destination-override syslog host 10.0.0.13

This configuration statement has a system-wide effect. As soon as it is applied, all of the output of your currently activated traces will be send towards the syslog server instead of a local file. You can still choose to store some traces locally. You'll have to configure the 'no-remote-trace' to do so. For example, suppose you are logging all traceoptions to a syslog server but you do not want this to happen for the dhcp-relay traceoptions. If that is the case, you have to add the following to those traceoptions;

set forwarding-options dhcp-relay traceoptions no-remote-trace

This was just to show you that making Junos log stuff isn't hard at all. Hopefully, this post has given you an idea or two. For now, I just have one final final remark left. Logging to users seems to be broken on a lot of EX and QFX releases I am currently running (12.x and above). Logging to users works on MX 12.x and above or SRX 12.x and above.