Junos syslog configuration allows us to be informed in real-time about important changes in the network, for example when an interface goes down, a BGP neighborship goes down, or a new command is configured on the network device.

Syslog configuration is critical to be activated not only on network devices, but also on all servers and services running in the enterprise.

Junos Syslog Fundamental

There are three concepts you should understand before you start configuring the syslog service.

junos syslog configuration
junos syslog configuration

The first is the syslog destination. That is, where you want to send your syslog messages.

There are many destinations to which you can send your log messages. The most important  is to send log messages to a remote syslog server.

A remote syslog server with large storage allows you to keep your messages for a long time and they usually have a powerful search function to find your desired logs.

It is also very important to store logs locally on Juniper devices since sometimes the connectivity of the network device is disrupted and no logs are received on the syslog server and this is important to be sure that copy of lates logs are always stored in the device itself.

Since the storage size of the device is usually not too big, it is possible to store only the latest logs in the device itself. The “archive” options allow us to configure the size and the number of log files to be stored locally on the device, depending on the device’s local storage size.

It is also possible to send the log in the console of the device or to a specific administrator terminal which are less important.

The second concept is the syslog facility, which is actually the category of log messages. Log are categorized by vendor based on the type of the log. as examples, kernel facility, are the logs related to OS itself. Or interactive-commands logs any command generated by administrators.

There are many category or facility to configure and usually we choose to log all facilities.

The last concept is log severity, which shows the importance of a log. Log severity is categorized from 0 (emergency logs) to 7 (debug), which logs everything.

In the syslog configuration, you select which log severity should be sent to a syslog destination. Normally syslog messages from 0 to 5 are very important to keep for a long time.

It is important to notice that when you configure log severity of 4 (as an example) to be sent to the destination, that means all log with severity from 0 to 4 will be sent to that destination.

It is obvious that you can configure logs with different categories and severities to be sent to different syslog destinations.

Now it is the time to start configuring syslog in Junos device.

Junos Syslog configuration and monitoring

Before configuring syslog in the juniper device, let’s check what is syslog default configuration with “show configuration system syslog” command.

rayka@vSRX# run show configuration system syslog 
file interactive-commands {
    interactive-commands any;
}
file messages {
    any any;
    authorization info;
}

[edit]
rayka@vSRX#

By default only file is configured as destination. In other words, log messages are stored locally in the device.

The first command shows that all commands configured by administrators, in other words, “interactive-commands” facility and with any severity are stored locally in a file with the name of “interactive-commands”.

The second command shows that logs with “authorization” category and “info” severity and also all other logs with any facility and any severity are stored locally in a file called “messages”.

To check the output of log files, we use “show log” command.

With “show log interactive-commands”, we can check the commands configured in the device.

rayka@vSRX# run show log interactive-commands    
May 16 11:15:00 vSRX newsyslog[37057]: logfile turned over due to size>1024K
May 16 13:19:47  vSRX mgd[41650]: UI_AUTH_EVENT: Authenticated user 'rayka10' assigned to class 'j-super-user'
May 16 13:19:47  vSRX mgd[41650]: UI_LOGIN_EVENT: User 'rayka10' login, class 'j-super-user' [41650], ssh-connection '192.168.200.111 35808 192.168.200.100 22', client-mode 'cli'
May 16 13:23:22  vSRX mgd[41650]: UI_CMDLINE_READ_LINE: User 'rayka10', command 'exit '
May 16 13:23:22  vSRX mgd[41650]: UI_LOGOUT_EVENT: User 'rayka10' logout
May 16 13:27:36  vSRX mgd[35650]: UI_CMDLINE_READ_LINE: User 'rayka', command 'set system login user rayka20 uid 2020 '
May 16 13:27:41  vSRX mgd[35650]: UI_CMDLINE_READ_LINE: User 'rayka', command 'set system login user rayka class super-user '
May 16 13:28:04  vSRX mgd[35650]: UI_CMDLINE_READ_LINE: User 'rayka', command 'set system login user rayka20 class super-user '
May 16 13:29:24  vSRX mgd[35650]: UI_CMDLINE_READ_LINE: User 'rayka', command 'set system login user rayka20 authentication load-key-file /var/home/rayka/id_rsa.pub '
May 16 13:35:37  vSRX mgd[35650]: UI_CMDLINE_READ_LINE: User 'rayka', command 'commit '
May 16 13:35:37  vSRX mgd[35650]: UI_COMMIT: User 'rayka' requested 'commit' operation (comment: none)
....

With command “show log messages | last”, you can check latest log messages stored locally in “messages” file.

rayka@vSRX# run show log messages | last 
May 26 20:26:14  vSRX kernel: ifl_pfestat_add_async_sync_dependency: No dependency for this ifl
May 26 20:26:14  vSRX kernel: ifl_pfestat_add_async_sync_dependency: No dependency for this ifl
May 26 20:30:00  vSRX /usr/sbin/cron[33251]: (root) CMD (newsyslog -X)
May 26 20:30:00  vSRX /usr/sbin/cron[33252]: (root) CMD (   /usr/libexec/atrun)
May 26 20:30:00  vSRX /usr/sbin/cron[33250]: (root) MAIL (mailed 39 bytes of output but got status 0x0001 )
May 26 20:35:00  vSRX /usr/sbin/cron[33435]: (root) CMD (   /usr/libexec/atrun)
May 26 20:35:00  vSRX /usr/sbin/cron[33434]: (root) MAIL (mailed 39 bytes of output but got status 0x0001 )
May 26 20:40:00  vSRX /usr/sbin/cron[33618]: (root) CMD (   /usr/libexec/atrun)
May 26 20:40:00  vSRX /usr/sbin/cron[33617]: (root) MAIL (mailed 39 bytes of output but got status 0x0001 )
May 26 20:45:00  vSRX /usr/sbin/cron[33802]: (root) CMD (   /usr/libexec/atrun)
May 26 20:45:00  vSRX /usr/sbin/cron[33803]: (root) CMD (newsyslog -X)
May 26 20:45:01  vSRX /usr/sbin/cron[33801]: (root) MAIL (mailed 39 bytes of output but got status 0x0001 )
May 26 20:50:00  vSRX /usr/sbin/cron[33986]: (root) CMD (   /usr/libexec/atrun)
May 26 20:50:00  vSRX /usr/sbin/cron[33985]: (root) MAIL (mailed 39 bytes of output but got status 0x0001 )
May 26 20:55:00  vSRX /usr/sbin/cron[34169]: (root) CMD (   /usr/libexec/atrun)
.....

Log files are stored in “/var/log/” folder in juniper devices, which we can check with “file list /var/log/messages*”.

rayka@vSRX# run file list /var/log/messages*  
/var/log/messages
/var/log/messages.0.gz
/var/log/messages.1.gz
/var/log/messages.2.gz
/var/log/messages.3.gz

[edit system syslog]
rayka@vSRX# 

by default, for each log file , up to 10 versions and a size of 1 MB for each version are stored in the SRX device. But it is possible to change the default value which we will see in a few minutes.

Junos Syslog configuration

For syslog configuration, first we enter into “system syslog” context mode.

After “set” command, as you can see, there are options to send syslog messages to different destination like console, file, host (syslog server) or a admin user terminal.

[edit]
rayka@vSRX# edit system syslog    

[edit system syslog]
rayka@vSRX# set ?
Possible completions:
  allow-duplicates     Do not suppress the repeated message for all targets
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> archive              Archive file information
> console              Console logging
> file                 File in which to log data
> grpc-replay          GRPC streaming
> host                 Host to be notified
  log-rotate-frequency  Rotate log frequency (1..59 minutes)
  routing-instance     Routing instance
> server               Enable syslog server
  source-address       Use specified address as source address
> time-format          Additional information to include in system log timestamp
> user                 Notify a user of the event
[edit system syslog]
rayka@vSRX#

For file as destination, we need to configure the name of the file, the logging facility, and logging severity. As an example, I configure that all logs with severity from emergency to warning be saved in a file named “uptowarninglogs”.

[edit system syslog]
rayka@vSRX# set file uptowarninglogs any warning

To change the number of each log file to be stored locally and the maximum size of each file we use “archive” option in syslog command. As an example , I change the configuration so that up to 20 files from each file is stored locally in the device. By default it is 10. I also increase the size of each log file from 1MB to 2MB.

[edit system syslog]
rayka@vSRX# set archive files 20 

[edit system syslog]
rayka@vSRX# set archive size 2000000 

[edit system syslog]
rayka@vSRX# 

For syslog server as a destination, we have to configure the IP address of syslog server, log facility and log severity. As an example, I configure all logs with severity up to information be sent to the server with IP address 192.168.1.88.

[edit system syslog]
set host 192.168.1.88 any info 

Then I commit the changes.

Just to review the final syslog configuration, I use “show configuration system syslog | display set” command.

rayka@vSRX# run show configuration system syslog | display set 
set system syslog archive size 2000000
set system syslog archive files 20
set system syslog host 192.168.1.88 any info
set system syslog file interactive-commands interactive-commands any
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file uptowarninglogs any warning

[edit system syslog]
rayka@vSRX# 
Back to: Juniper Junos Associate version 22.1R1.10 (JNCIA-Junos) > Junos Configuration Basics

2 Comments

  1. Hello.
    Is there any way to suppress the amount of log messages generated for the same event? we had a situation in which a device was under heavy load because it generated lots of the same log messages over and over again for the same event (in our case, for incompatible SFP model). that device was nearly unresponsive for SNMP pull request due to the load.

Leave a Reply

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


Post comment