Some facilities assigned to messages logged on the local routing platform have the JUNOS software-specific names (see Table 19). In the recommended configuration, a remote machine designated at the [edit system syslog host hostname] hierarchy level is not a Juniper Networks routing platform, so its syslogd utility cannot interpret the JUNOS software-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 software-specific facility name.
Table 21 lists the default alternative facility name next to the JUNOS software-specific facility name it is used for. For facilities that are not listed, the default alternative name is the same as the local facility names.
Table 21: Default Facilities for Messages Directed to a Remote Destination
|
JUNOS Software-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). For example, the following statements in the configuration of the routing platform called 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. If the syslogd utility on monitor is configured to write messages
belonging to the authorization facility to the file /var/log/auth-attempts, 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 make it easier to separate the messages from each source, you can assign an alternative facility to all messages generated on local-router when they are directed to monitor. You can then configure the syslogd utility on monitor to write messages with the alternative facility to a different file from messages generated on monitor itself.
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 22 lists the facilities that you can specify in the facility-override statement.
Table 22: Facilities for the facility-override Statement
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 software-specific names.