Changing the Alternative Facility Name for Remote Messages

Some facilities assigned to messages logged on the local routing platform have JUNOS-specific names (see Table 7). Because a remote machine designated at the [edit system syslog host hostname] hierarchy level is not a Juniper Networks routing platform, its syslogd utility cannot interpret the JUNOS-specific names. To enable the standard syslogd utility to handle messages from these facilities, when messages are directed to a remote machine a standard localX facility name is used instead of the JUNOS-specific facility name.

Table 9 lists the default alternative facility name used for each JUNOS-specific facility name. For facilities that are not listed, the default alternative name is the same as the local facility name.

Table 9: Default Facilities for Messages Directed to a Remote Destination 

JUNOS-Specific Local Facility	Default Facility When Directed to Remote Destination
change-log	local6
conflict-log	local5
dfc	local1
firewall	local3
interactive-commands	local7
pfe	local4

The syslogd utility on a remote machine handles all messages that belong to a facility in the same way, regardless of the source of the message (the Juniper Networks routing platform or the remote machine itself). As an example, the following statements in the configuration of the routing platform local-router direct messages from the authorization facility to the remote machine monitor.mycompany.com:

[edit system syslog]

host monitor.mycompany.com {

    authorization info;

}

The default alternative facility for the local authorization facility is also authorization. The syslogd utility on monitor is configured to write messages belonging to the authorization facility to the file /var/log/auth-attempts, which means that the file contains both the messages generated when users log in to local-router and the messages generated when users log in to monitor. Although the name of the source machine appears in each system log message, the mixing of messages from multiple machines can make it more difficult to analyze the contents of the auth-attempts file.

To change the facility used for all messages directed to a remote machine, include the facility-override statement at the [edit system syslog host hostname] hierarchy level:

[edit system syslog host hostname]

facility severity;

facility-override facility;

In general, it makes sense to specify an alternative facility that is not already in use on the remote machine, such as one of the localX facilities. On the remote machine, you must also configure the syslogd utility to handle the messages in the desired manner.

Table 10 lists the facilities that you can specify in the facility-override statement.

Table 10: Facilities for the facility-override Statement 

Facility	Description
authorization	Authentication and authorization attempts
daemon	Actions performed or errors encountered by various system processes
ftp	Actions performed or errors encountered by the FTP process
kernel	Actions performed or errors encountered by the JUNOS kernel
local0	Local facility number 0
local1	Local facility number 1
local2	Local facility number 2
local3	Local facility number 3
local4	Local facility number 4
local5	Local facility number 5
local6	Local facility number 6
local7	Local facility number 7
user	Actions performed or errors encountered by various user-space processes

We do not recommend including the facility-override statement at the [edit system syslog host other-routing-engine] hierarchy level. It is not necessary to use alternative facility names when directing messages to the other Routing Engine, because its JUNOS system logging utility can interpret the JUNOS-specific names.

Examples: Assigning an Alternative Facility

Log all messages generated on the local routing platform at the error level or higher to the local0 facility on the remote machine called monitor.mycompany.com:

[edit system syslog]

host monitor.mycompany.com {

    any error;

    facility-override local0;

}

Configure routing platforms located in California and routing platforms located in New York to send messages to a single remote machine called central-logger.mycompany.com. The messages from California are aggregated into one facility (local0) and the messages from New York into another facility (local2).

• Configure California routing platforms to aggregate messages in the local0 facility:

[edit system syslog]

host central-logger.mycompany.com {

    change-log info;

    facility-override local0;

}

• Configure New York routing platforms to aggregate messages in the local2 facility:

[edit system syslog]

host central-logger.mycompany.com {

    change-log info;

    facility-override local2;

}

On central-logger, you can then configure the system logging utility to write messages from the local0 facility to /var/log/california-config and the messages from the local2 facility to /var/log/new-york-config.