Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Writing: Rekha J
Editing: Chris Dresden
Cover Design: Edmonds Design
Revision History
July 2010 —R1 Junos 10.3
The information in this document is current as of the date listed in the revision history.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. The Junos OS has no known time-related limitations through
the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE.
BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS
CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO
BIND THE CUSTOMER)CONSENT TO BE BOUNDBY THIS AGREEMENT.IF YOUDO NOTOR CANNOT AGREE TO THE TERMS CONTAINED
HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS
REGARDING LICENSE TERMS.
1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or
Juniper Networks (Cayman) Limited (ifthe Customer’sprincipal officeis located outsidethe Americas) (such applicable entitybeing referred
to herein as“Juniper”),and (ii) the person or organization thatoriginally purchasedfrom Juniperor an authorized Juniperreseller the applicable
license(s) for use of the Software (“Customer”) (collectively, the “Parties”).
2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for
which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by
Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades
and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper
equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment.
3. License Grant. Subject to paymentof the applicable fees and thelimitations and restrictionsset forthherein, Juniper grants toCustomer
a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the
following use restrictions:
a. Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by
Customer from Juniper or an authorized Juniper reseller.
b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units
for which Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access
Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space
and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines
(e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single
chassis.
c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may
specify limitsto Customer’s useof the Software. Suchlimits may restrictuse to amaximum numberof seats, registered endpoints, concurrent
users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of
separate licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput,
performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use
of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software.
Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.
d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the
Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not
extend or create an additional trial period by re-installing the Software after the 30-day trial period.
e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s
enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the
Steel-Belted Radius software to support any commercial network access services.
The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase
the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.
4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees
not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized
copies of the Software (except as necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the
Software,in any form, toany thirdparty; (d)remove any proprietarynotices, labels,or marks on orin any copy of the Softwareor any product
in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper
equipment sold inthe secondhand market; (f)use any ‘locked’ orkey-restricted feature,function, service, application, operation, orcapability
without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application,
operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the
Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i)
use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that
the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking
of the Software to any third party without the priorwritten consent of Juniper; or (l) use the Software in any manner other than as expressly
provided herein.
5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper,
Customer shall furnish such records to Juniper and certify its compliance with this Agreement.
6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper.
As such, Customer shall exercise allreasonable commercial efforts to maintain the Software and associated documentation in confidence,
which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software
for Customer’s internal business purposes.
7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to
the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance
of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies
of the Software.
8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty
statementthat accompaniesthe Software (the“Warranty Statement”).Nothing inthis Agreement shallgive riseto any obligation to support
the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services
agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA,
OR COSTSOR PROCUREMENTOF SUBSTITUTEGOODS ORSERVICES,OR FOR ANY SPECIAL,INDIRECT,OR CONSEQUENTIALDAMAGES
ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANY JUNIPEROR JUNIPER-SUPPLIEDSOFTWARE. INNO EVENT SHALLJUNIPER
BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE.
EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY
AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES
JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT
ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’
or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid
by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by
Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in
reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between
the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same
form an essential basis of the bargain between the Parties.
9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination
of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related
documentation in Customer’s possession or control.
10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from
the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction
shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All
payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in
connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing
Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to
be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with
all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any
liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under
this Section shall survive termination or expiration of this Agreement.
11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any
applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such
restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the
Software supplied to Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without
an export license.
12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use,
duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS
227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.
13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer
with the interface information needed to achieve interoperability between the Software and another independently created program, on
payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use
such information in compliance with any applicable terms and conditions upon which Juniper makes such information available.
14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier ofJuniper whose products
or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement,
and such licensor or vendor shall have the right to enforce this Agreement in itsown name asif it wereJuniper. In addition, certain thirdparty
software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent
portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such
portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper
will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three
years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA
94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL
at http://www.gnu.org/licenses/lgpl.html .
15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws
principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes
arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal
courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer
with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written
(including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an
authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained
herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing
by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity
of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the
Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de
même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that
this Agreement and all related documentation is and will be in the English language)).
This preface provides the following guidelines for using the Junos®OS System Log
Messages Reference:
•
Junos Documentation and Release Notes on page lvii
•
Objectives on page lviii
•
Audience on page lviii
•
Supported Platforms on page lviii
•
Using the Examples in This Manual on page lix
•
Documentation Conventions on page lx
•
Documentation Feedback on page lxii
•
Requesting Technical Support on page lxii
Junos Documentation and Release Notes
For a list of related Junos documentation, see
http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the
documentation, follow the Junos Release Notes.
To obtain the most current version of all Juniper Networks®technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
Juniper Networks supports a technical bookprogram to publish booksby JuniperNetworks
engineers and subject matter experts with book publishers around the world. These
books go beyond the technical documentation to explore the nuances of network
architecture, deployment, and administration using the Junos operating system (Junos
OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library,
published in conjunction with O'Reilly Media, explores improving network security,
reliability, and availability using Junos OS configuration techniques. All the books are for
sale at technical bookstores and book outlets around the world. The current list can be
viewed at http://www.juniper.net/books .
This reference describes system log messages generated by the Junos OS. Use the
information to interpret system log messages and determine the appropriate corrective
action for error conditions
NOTE: For additional informationabout Junos OS—either corrections to or information
that might have been omitted from this guide—see the software release notes at
http://www.juniper.net/.
Audience
This guide is designed for network administrators who are configuring and monitoring a
Juniper Networks M Series, MX Series, T Series, EX Series, or J Series router or switch.
To use this reference, you need a broad understanding of networksin general, the Internet
in particular, networking principles, and network configuration. You must also be familiar
with one or more of the following Internet routing protocols:
•
•
•
•
•
•
•
•
•
•
•
Personnel operating the equipment must be trained and competent; must not conduct
themselves in a careless, willfully negligent, or hostile manner; and must abide by the
instructions provided by the documentation.
Supported Platforms
For the features described in this manual, Junos OS currently supports the following
platforms:
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. If the example configuration
contains the top level of the hierarchy (or multiple hierarchies), the example is a fullexample. In this case, use the load merge command
If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example
About This Guide
To merge a full example, follow these steps:
1.From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy thefollowing configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2.Merge the contents of the file into your routing platform configuration by issuing the
Table 2 on page lxi defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions
About This Guide
ExamplesDescriptionConvention
Fixed-width text like this
Italic text like this
Italic text like this
Plain text like this
Represents text that you type.Bold text like this
Represents output that appears on the
terminal screen.
•
Introduces important new terms.
•
Identifies book names.
•
Identifies RFC and Internet draft titles.
Represents variables (options for which
you substitute a value) in commands or
configuration statements.
Represents names of configuration
statements, commands, files, and
directories; IP addresses; configuration
hierarchy levels; or labels on routing
platform components.
To enter configuration mode, type the
configure command:
user@host> configure
user@host> show chassis alarms
No alarms currently active
•
A policy term is a named structure
that defines match conditions and
actions.
•
Junos System Basics Configuration
Guide
•
RFC 1997, BGP Communities Attribute
Configure the machine’s domain name:
[edit]
root@# set system domain-name
domain-name
•
To configure a stub area, include the
stub statement at the [edit protocols
ospf area area-id] hierarchy level.
•
The console port islabeledCONSOLE.
stub <default-metric metric>;Enclose optional keywords or variables.< > (angle brackets)
| (pipe symbol)
# (pound sign)
[ ] (square brackets)
Indention and braces ( { } )
; (semicolon)
Indicates a choice betweenthe mutually
exclusivekeywords or variables on either
side of the symbol. The set of choices is
often enclosed in parentheses for clarity.
same lineas theconfiguration statement
to which it applies.
Enclose a variable for which you can
substitute one or more values.
Identify a level in the configuration
hierarchy.
Identifies a leaf statement at a
configuration hierarchy level.
broadcast | multicast
(string1 | string2 | string3)
rsvp { # Required for dynamic MPLS onlyIndicates a comment specified on the
Represents J-Web graphical user
interface (GUI) items you click or select.
ExamplesDescriptionConvention
•
In the Logical Interfaces box, select
All Interfaces.
•
To cancel the configuration, click
Cancel.
> (bold right angle bracket)
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
techpubs-comments@juniper.net, or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
•
Document or topic name
•
URL or page number
•
Software release version (if applicable)
Requesting Technical Support
Technical productsupport isavailablethrough theJuniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need postsales technical support, you can access
our tools and resources online or open a case with JTAC.
Separates levels in a hierarchy of J-Web
selections.
In the configuration editor hierarchy,
select Protocols>Ospf.
•
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
JTAC Hours of Operation —The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
•
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications:
https://www.juniper.net/alerts/
•
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
•
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verifyservice entitlement byproduct serial number,use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
•
Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
•
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit us at
The Junos OS generates system log messages (also called syslog messages) to record
events that occur on the routing platform, including the following:
•
Routine operations, such as creation of an OSPF protocol adjacency or a user login
into the configuration database
•
Failureand error conditions, such as failure to access a configuration file or unexpected
closure of a connection to a peer process
•
Emergencyor critical conditions, such as routingplatformpower-downdue toexcessive
temperature
Each system log message identifies the Junos OS process that generated the message
and briefly describes the operation or error that occurred. This reference provides more
detailed information about each system log message and, when applicable, describes
possible causes of the message and action you can take to correct error conditions.
NOTE: The configuration hierarchy in this chapter applies to Junos OS processes and
libraries, not to the services on a PIC such as the Adaptive Services PIC. For information
about configuring system logging for PIC services, see the Junos Services InterfacesConfiguration Guide.
For information about interpreting messages generated by services on a PIC, see
“Interpreting Messages Generatedin Standard Format by Services on a PIC” on page 41.
This chapter discusses the following topics:
•
System Logging Configuration Statements on page 4
•
Minimum and Default System Logging Configuration on page 4
•
Configuring System Logging for a Single-Chassis System on page 7
•
Configuring System Logging for a Routing Matrix on page 26
•
Displaying and Interpreting System Log Messages on page 35
To record or view system log messages, you must include the syslog statement at the
[edit system] hierarchy level. Specify at least one destination for the messages, as
described in Table 3 on page 5.
Table 3: Minimum Configuration Statements for System Logging
File
Chapter 1: Configuring System Log Messages
Minimum Configuration StatementsDestination
[edit system syslog]
file filename {
facility severity ;
}
Terminal session of one, several, or all users
Routing platform console
Remote machine or the other Routing Engine
on the routing platform
Default System Log Settings
Table 4 on page 5 summarizes the default system log settings that apply to all platforms
that run the Junos OS, and specifies which statement to include in the configuration to
override the default value.
Table 4: Default System Logging Settings
Alternative facility for
message forwarded
to a remote machine
For change-log: local6
For conflict-log: local5
For dfc: local1
For firewall: local3
[edit system syslog]
user (username | *) {
facility severity ;
}
[edit system syslog]
console {
facility severity ;
}
[edit system syslog]
host (hostname | other-routing-engine) {
facility severity ;
}
InstructionsOverriding StatementDefaultSetting
[edit system syslog]
host hostname {
facility-override
facility;
}
“Changing the
Alternative
Facility Name
for Remote
Messages” on
page 13
Format of messages
logged to a file
For
interactive-commands:
local7
For pfe: local4
Standard Junos
format, based on
UNIX format
[edit system syslog]
file filename {
structured-data;
}
“Logging
Messages in
Structured-Data
Format” on
page 11
Table 4: Default System Logging Settings (continued)
files in the archived
set
InstructionsOverriding StatementDefaultSetting
10Maximum number of
[edit system syslog]
archive {
files number;
}
file filename {
archive {
files number ;
}
}
“Configuring
the Size and
Number of Log
Files” on
page 17
Maximum size of log
file
Timestamp format
Users who can read
log files
J Series: 128 kilobytes
(KB)
M Series, MX Series,
and T Series: 1
megabyte (MB)
TX Matrix: 10 MB
Month, date, hour,
minute, second For
example: Aug 21
12:36:30
root user and users
with the Junos
maintenance
permission
[edit system syslog]
archive {
size size;
}
file filename {
archive {
size size;
}
}
[edit system syslog]
time-format format;
[edit system syslog]
archive {
world-readable;
}
file filename {
archive {
world-readable;
}
}
“Configuring
the Size and
Number of Log
Files” on
page 17
“Including the
Year or
Millisecond in
Timestamps”
on page 21
“Configuring
the Size and
Number of Log
Files” on
page 17
In addition, the following messages are generated by default on specific platforms. To
view either type of message, you must configure at least one destination for messages
as described in “Minimum System Logging Configuration” on page 5.
•
On J Series platforms, a message is logged when a process running in the kernel
consumes 500 or more consecutive milliseconds of CPU time.
To log the message on an M Series, MX Series, or T Series platform, include the kernel
info statement at the appropriate hierarchy level:
[edit system syslog]
(console | file filename | host destination | user username) {
kernel info;
}
•
The master Routing Engine on each T640 routing node in a routing matrix forwards to
the master Routing Engine on the TX Matrix platform all messages with a severity of
info and higher. This is equivalent to the following configuration statement included
Configuring System Logging for a Single-Chassis System
The Junos system logging utility issimilar tothe UNIX syslogd utility. This section describes
how to configure system logging for a single-chassis system that runs the Junos OS.
System logging configuration for the Junos-FIPS software and for Juniper Networks
routing platforms in a Common Criteria environment is the same as for the Junos OS. For
more information, see the Secure Configuration Guide for Common Criteria and Junos-FIPS.
Each system log message belongs to a facility, which groups together related messages.
Each message is also preassigned a severity level, which indicates how seriously the
triggering event affects routing platform functions. You always specify the facility and
severity of the messages to include in the log. For more information, see “Specifying the
Facility and Severity of Messages to Include in the Log” on page 8.
Chapter 1: Configuring System Log Messages
You direct messages to one or more destinations by including the appropriate statement
at the [edit system syslog] hierarchy level:
•
To a named file in a local file system, by including the file statement. See “Logging
Messages in Structured-Data Format” on page 11.
•
To the terminal sessionof oneor more specificusers (or all users) whenthey arelogged
in to the routing platform, by including the user statement. See “Directing Messages
to a User Terminal” on page 12.
•
To the routing platform console, by including the console statement. See “Directing
Messages to the Console” on page 12.
•
To a remote machine that is running the syslogd utility or to the other Routing Engine
on the routing platform, by including the host statement. See “Directing Messages to
a Remote Destination from the Routing Matrix” on page 32.
By default, messages are logged in a standard format, which is based on a UNIX system
log format; for detailed information, see “Interpreting Messages Generated in Standard
Format by a JUNOS Process or Library” on page 41, “Interpreting Messages Generated
in Standard Format by Services on a PIC” on page 41, and “Interpreting Messages
Generated in Structured-Data Format” on page 36. You can alter the content and format
of logged messages in the following ways:
•
In Junos 8.3 and later, you can log messages to a file in structured-data format instead
of the standard Junos format. Structured-data format provides more information
without adding significant length, and makes it easier for automated applications to
extract information from the message. For more information, see “Logging Messages
in Structured-Data Format” on page 11.
•
A message’s facility and severity level are together referred to as its priority. By default,
the standard Junos format for messages does not include priority information.
(Structured-data format includes a priority code by default.) To include priority
information in standard-format messages directed to a file or a remote destination,
include the explicit-priority statement. For more information, see “Including Priority
Information in System Log Messages” on page 18.
•
By default, the standard Junos format for messages specifies the month, date, hour,
minute, and second when the message was logged. You can modify the timestamp
on standard-format messages to include the year, the millisecond, or both.
(Structured-data format specifies the year and millisecond by default.) For more
information, see “Including the Year or Millisecond in Timestamps” on page 21.
•
When directing messages to a remote machine, you can specify the IP address that is
reported in messages as their source. You can also configure features that make it
easier to separate Junos-specific messages or messages generated on particular
routing platforms. For more information, see “Directing Messages to a Remote
Destination from the Routing Matrix” on page 32.
•
The predefined facilities group togetherrelatedmessages, but you can alsouse regular
expressions to specify more exactly which messages from a facility are logged to a
file, a user terminal, or a remote destination. For more information, see “Using Regular
Expressions to Refine the Set of Logged Messages” on page 22.
For a statement summary for the statements discussed in this chapter, see the JunosSystem Basics Configuration Guide.
For detailed information about configuring system logging, see the following sections:
•
Specifying the Facility and Severity of Messages to Include in the Log on page 8
•
Directing Messages to a Log File on page 10
•
Directing Messages to a User Terminal on page 12
•
Directing Messages to the Console on page 12
•
Directing Messages to a Remote Machine or the Other Routing Engine on page 12
•
Configuring the Size and Number of Log Files on page 17
•
Including Priority Information in System Log Messages on page 18
•
Including the Year or Millisecond in Timestamps on page 21
•
Using Regular Expressions to Refine the Set of Logged Messages on page 22
•
Disabling Logging of a Facility on page 24
•
Examples: Configuring System Logging on page 24
Specifying the Facility and Severity of Messages to Include in the Log
Each system log message belongs to a facility, which groups together messages that
either are generated by the same source (suchas a softwareprocess) or concerna similar
condition or activity (such as authentication attempts). Each messageis alsopreassigned
a severity level, which indicateshow seriously the triggering eventaffectsrouting platform
functions.
When you configure logging for a facility and destination, you specify a severity level for
each facility. Messages from the facility that are rated at that level or higher are logged
to the following destination:
[edit system syslog]
(console | file filename | host destination | user username) {
facility severity ;
}
For more informationabout thedestinations, see “DirectingMessagesto a User Terminal”
on page 12,“Directing Messages to a User Terminal” on page 12, “Directing Messages to
the Console” on page 12.
To log messages belonging to more than one facility to a particular destination, specify
each facility and associated severity as aseparate statement withinthe setof statements
for the destination.
Table 5 on page 9 lists the facilities that you can specify in configuration statements at
the [edit system syslog] hierarchy level.
Table 5: Junos System Logging Facilities
Type of Event or ErrorFacility
All (messages from all facilities)any
conflict-log
daemon
firewall
ftp
interactive-commands
kernel
Authentication and authorization attemptsauthorization
Changes to the Junos configurationchange-log
Specified configuration is invalid on the routing
platform type
Actions performed or errors encountered by
system processes
Events related to dynamic flow capturedfc
Packet filtering actions performed by a firewall
filter
Actionsperformed orerrors encountered by the
FTP process
Commands issued at the Junos OS
command-line interface (CLI) prompt or
invoked by a client application such as a Junos
XML protocol or NETCONF client
Actionsperformed orerrors encountered by the
Junos kernel
pfe
user
Actionsperformed orerrors encountered by the
Packet Forwarding Engine
Actions performed or errors encountered by
user-space processes
Table 6 on page10 lists the severity levels that you can specify in configuration statements
at the [edit system syslog] hierarchy level. The levels from emergency through info are in
order from highest severity (greatest effect on functioning) to lowest.
Unlike the other severity levels, the none level disables logging of a facility instead of
indicating how seriouslya triggeringevent affects routing functions. For more information,
see “Disabling Logging of a Facility” on page 24.
Table 6: System Log Message Severity Levels
DescriptionSeverity Level
Includes all severity levelsany
Disables logging of the associated facility to a destinationnone
emergency
alert
error
Directing Messages to a Log File
To direct system log messages to a file in the /var/log directory of the local Routing
Engine, include the file statement at the [edit system syslog] hierarchy level:
[edit system syslog]
file filename {
facility severity ;
explicit-priority;
match "regular-expression";
structured-data {
brief;
}
archive {
files number ;
size size;
(world-readable | no-world-readable);
}
}
System panic or other condition that causes the routing platform to
stop functioning
Conditions that require immediate correction, such as a corrupted
system database
Critical conditions, such as hard drive errorscritical
Error conditions that generally have less serious consequences than
errors in the emergency, alert, and critical levels
Conditions that warrant monitoringwarning
Conditions that are not errors but might warrant special handlingnotice
For the list of facilities and severity levels, see “Specifying the Facility and Severity of
Messages to Include in the Log” on page 8.
To prevent log files from growing too large, the Junos system logging utility by default
writes messages to a sequence of files of a defined size. By including the archive
statement, you can configure the number of files, their maximum size, and who can read
them, for either all log files or a certain log file. For more information, see “Configuring
the Size and Number of Log Files” on page 17.
For information about the following statements, see the indicated sections:
•
explicit-priority—See “Including Priority Information in System Log Messages” on
page 18.
•
match—See “Using Regular Expressions to Refine the Set of Logged Messages” on
page 22.
•
structured-data—See “Logging Messages in Structured-Data Format” on page 11.
•
Logging Messages in Structured-Data Format on page 11
Logging Messages in Structured-Data Format
In Junos 8.3 and later, you can log messages to a file in structured-data format instead
of thestandard Junosformat. Structured-data format provides more information without
adding significant length, and makes it easier for automated applications to extract
information from a message.
The structured-data format complies with Internet draft draft-ietf-syslog-protocol-21.txt,
The draft establishes a standard message format regardless of the source or transport
protocol for logged messages.
To output messages to a file in structured-data format, include the structured-data
statement at the [edit system syslog file filename] hierarchy level:
[edit system syslog file filename]
facility severity;
structured-data {
brief;
}
The optional brief statement suppresses the English-language text that appears by
default at the end of a message to describe the error or event. For information about the
fields in a structured-data–format message, see “Displaying a Log File from a
Single-Chassis System” on page 35.
The structured format is used for all messages logged to the file that are generated by
a Junos process or software library.
NOTE: If you include either or both of the explicit-priority and time-format statements
along with the structured-data statement, they are ignored. These statements apply to
the standard Junos system log format, not to structured-data format.
To direct system log messages to the terminal session of one or more specific users (or
all users) when they are logged in to the local Routing Engine, include the user statement
at the [edit system syslog] hierarchy level:
[edit system syslog]
user (username | *) {
facility severity;
match "regular-expression";
}
Specify one or more Junos usernames, separating multiple values with spaces, or use
the asterisk (*) to indicate all users who are logged in to the local Routing Engine.
For the list of facilities and severity levels, see “Specifying the Facility and Severity of
Messages to Include in the Log” on page 8. For information about the match statement,
see “Using Regular Expressions to Refine the Set of Logged Messages” on page 22.
Directing Messages to the Console
To direct system log messages to the console of the local Routing Engine, include the
console statement at the [edit system syslog] hierarchy level:
[edit system syslog]
console {
facility severity;
}
For the list of facilities and severity levels, see “Specifying the Facility and Severity of
Messages to Include in the Log” on page 8.
Directing Messages to a Remote Machine or the Other Routing Engine
To direct system log messages to a remote machine or to the other Routing Engine on
the routing platform, include the host statement at the [edit system syslog] hierarchy
level:
[edit system syslog]
host (hostname | other-routing-engine) {
facility severity;
explicit-priority;
facility-override facility;
log-prefix string;
match "regular-expression";
}
source-address source-address;
To directsystem log messages to aremote machine, includethe host hostname statement
to specify the remote machine’s IP version 4 (IPv4) address, IP version 6 (IPv6) address,
or fully qualified hostname. The remote machine must be running the standard syslogd
utility. We do not recommend directing messages to another Juniper Networks routing
platform. In each system log message directed to the remote machine, the hostname of
the local Routing Engine appears after the timestamp to indicate that it is the source for
the message.
To direct system log messages to the other Routing Engine on a routing platform with
two Routing Engines installed and operational, include the host other-routing-engine
statement. The statement is not automatically reciprocal, so you must include it in each
Routing Engine’s configuration if you want them to direct messages to each other. In
each message directed to the other Routing Engine, the string re0 or re1 appears after
the timestamp to indicate the source for the message.
For the list of facilities and severity levels to configure under the host statement, see
“Specifying the Facility and Severity of Messages to Include in the Log” on page 8.
To record facility and severity level information in each message, include the
explicit-priority statement. For more information, see “Including Priority Information in
System Log Messages” on page 18.
For information about the match statement, see “Using Regular Expressions to Refine
the Set of Logged Messages” on page 22.
When directing messages to remote machines, you can include the source-address
statement to specify the IP address of the routing platform that is reported in the
messagesas theirsource. Ineach hoststatement,you canalso includethe facility-override
statement to assign an alternative facility and the log-prefix statement to add a string
to each message. For more information, see the following sections:
•
Specifying an Alternative Source Address for System Log Messages on page 13
•
Changing the Alternative Facility Name for Remote Messages on page 13
•
Examples: Assigning an Alternative Facility on page 15
•
Adding a Text String to System Log Messages on page 16
•
Adding a String on page 16
Specifying an Alternative Source Address for System Log Messages
To specify the routing platform that is reported in system log messages as their source
when they are directed to a remote machine, include the source-address statement at
the [edit system syslog] hierarchy level:
[edit system syslog]
source-address source-address;
source-address is a valid IPv4 or IPv6 address configured on one of the routing platform
interfaces. The address is reported in the messages directed to all remote machines
specified in host hostname statements at the [edit system syslog] hierarchy level, but not
in messages directed to the other Routing Engine.
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 Junos SystemLogging Facilities in “Specifyingthe Facility
and Severity of Messages to Include in the Log” on page 8. 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-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 7 on page 14 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 7: Default Facilities for Messages Directed to a Remote Destination
Default Facility When Directed to Remote
DestinationJunos-Specific Local Facility
local6change-log
local5conflict-log
local1dfc
local3firewall
local7interactive-commands
local4pfe
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 called 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 onmonitor is configured to write messagesbelonging to the authorization
facility to the file /var/log/auth-attempts, the file contains both the messages generated
when userslog 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 8 on page 15 lists thefacilities that you can specify in the facility-overridestatement.
Table 8: Facilities for the facility-override Statement
DescriptionFacility
Authentication and authorization attemptsauthorization
Actions performed or errors encountered by system processesdaemon
Actions performed or errors encountered by the FTP processftp
Actions performed or errors encountered by the Junos kernelkernel
Local facility number 0local0
Local facility number 1local1
Local facility number 2local2
Local facility number 3local3
Local facility number 4local4
Local facility number 5local5
Local facility number 6local6
Local facility number 7local7
Actions performed or errors encountered by user-space processesuser
Wedo notrecommend including thefacility-override statement at the [edit systemsyslog
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:
Configure routing platforms located in 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 assigned alternative facility local0 and the messages from
New York are assigned to alternative 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;
}
Related TopicsJunos System Log Alternate Facilities for Remote Logging•
On central-logger, you can then configure the system logging utility to write messages
from the local0 facility to the file california-config and the messages from the local2
facility to the file new-york-config.
Adding a Text String to System Log Messages
To add a text string to every system log message directed to a remote machine or to the
other Routing Engine, include the log-prefix statement at the [edit system syslog host]
hierarchy level:
The string can contain any alphanumeric or special character except the equal sign (=)
and the colon (:). It also cannot include the space character; do not enclose the string in
quotation marks (“ “) in an attempt to include spaces in it.
The Junos system logging utility automatically appends a colon and a space to the
specified string. The string is inserted after the identifier for the Routing Engine that
generated the message.
Adding a String
Add the string M120 to all messages to indicate that the router is an M120 router, and
direct the messages to the remote machine hardware-logger.mycompany.com:
[edit system syslog]
host hardware-logger.mycompany.com {
When these configuration statements are included on an M120 router called origin1, a
message in the system log on hardware-logger.mycompany.com looks like the following:
Mar 9 17:33:23 origin1 M120: mgd[477]: UI_CMDLINE_READ_LINE: user ‘root’, command ‘run
show version’
Configuring the Size and Number of Log Files
To prevent log files from growing too large, the Junos system logging utility by default
writes messages to a sequence of files of a defined size. The files in the sequence are
referred to as archive files to distinguish them from the active file to which messages are
currently being written. The default maximum size depends on the platform type:
•
128 kilobytes (KB) for J Series Services Routers
•
1 megabyte (MB) for M Series, MX Series, and T Series routing platforms
When an active log file called logfile reaches the maximum size, the logging utility closes
the file, compresses it, and names the compressed archive file logfile.0.gz. The logging
utility then opens and writes to a new active file called logfile. When the new logfile
reaches the configured maximum size,logfile.0.gz is renamed logfile.1.gz, and the newlogfile is closed, compressed, and renamed logfile.0.gz. By default, the logging utility
creates up to 10 archive files in this manner. When the maximum number of archive files
is reached, each time the active file reaches the maximum size the contents of the oldest
archive file are lost (overwritten by the next oldest file). The logging utility by default also
limits the users who can read log files to the root user and users who have the Junos
maintenance permission.
Chapter 1: Configuring System Log Messages
You can include the archive statement to change the maximum size of each file, how
many archive files are created, and who can read log files. To configure values that apply
to all log files, include the archive statement at the [edit system syslog] hierarchy level:
size size specifies the maximum size of each file. The value can be from 64 KB (64k)
through 1 gigabyte (1g); to represent megabytes, use the letter m after the integer. There
is no space between the digits and the k, m, or g units letter.
world-readable enables all users to read log files. To restore the default permissions,
include the no-world-readable statement.
Including Priority Information in System Log Messages
A message’s facility and severity level are together referred to as its priority. By default,
messages logged in the standard Junos format do not include information about priority.
To include priority information in standard-format messages directed to a file, include
the explicit-priority statement at the [edit system syslog file filename] hierarchy level:
[edit system syslog file filename]
facility severity;
explicit-priority;
NOTE: Messages logged in structured-data format include priority information by
default (structured-data format is available in Junos OS Release 8.3 and later and for
file destinations only). If you include the structured-data statement at the [edit system
syslog file filename] hierarchy level along with the explicit-priority statement, the
explicit-priority statement is ignored and messagesare loggedin structured-dataformat.
For information about the structured-data statement, see “Logging Messages in
Structured-Data Format” on page 11. For information about the contents of a
structured-data message, see “Displaying a Log File from a Single-Chassis System” on
page 35.
To include priority information in messages directed to a remote machine or the other
Routing Engine, include the explicit-priority statement at the [edit system syslog host
[edit system syslog host (hostname | other-routing-engine)]
facility severity;
explicit-priority;
The priority recorded in a message always indicates the original, local facility name. If
the facility-override statement isincluded formessages directed to a remote destination,
the Junos system logging utility still uses the alternative facility for the messages
themselves when directing them to the remote destination. For more information about
alternative facilities, see “Changing the Alternative Facility Name for Remote Messages”
on page 13.
When the explicit-priority statement is included, the Junos logging utility prepends codes
for the facility name and severity level to the message tag name, if the message has one:
FACILITY-severity[-TAG]
(The tag is a unique identifier assigned to some Junos system log messages; for more
information,see “Interpreting MessagesGeneratedin Structured-Data Format” onpage 36,
“Interpreting Messages Generated in Standard Format by Services on a PIC” on page 41,
“Interpreting Messages Generated in Standard Format by a JUNOS Process or Library”
on page 41, and “Displaying and Interpreting System Log Message Descriptions” on
page 47.)
Table 9 on page 19 lists the facility codes that can appear in system log messages and
maps them to facility names.
NOTE: If the second column in Table 9 on page 19 does not include the Junos facility
name for a code, the facility cannot be included in a statement at the [edit system
syslog] hierarchy level. The Junos OS might use the facilities in Table 9 on page 19—
and others that are not listed—when reporting on internal operations
Table 9: Facility Codes Reported in Priority Information
Type of Event or ErrorJunos Facility NameCode
authorizationAUTH
Authentication and
authorization attempts
AUTHPRIV
CONSOLE
CRON
Authentication and
authorization attempts that
can be viewed by superusers
only
change-logCHANGE
conflict-logCONFLICT
daemonDAEMON
dfcDFC
Changes to the Junos
configuration
Specified configuration is
invalid on the routing platform
type
Messages written to
/dev/console by the kernel
console output driver
Actions performed or errors
encountered by the cron
process
Actions performed or errors
encountered by system
processes
Actions performed or errors
encountered by the dynamic
flow capture process
firewallFIREWALL
ftpFTP
Packet filtering actions
performed by a firewall filter
Actions performed or errors
encountered by the FTP
process
Table 10: Numerical Codes for Severity Levels Reported in Priority
Information (continued)
DescriptionSeverity LevelNumerical Code
warning4
Conditions that warrant
monitoring
notice5
info6
debug7
Conditions that are not errors
but might warrant special
handling
Events or nonerror conditions
of interest
Softwaredebugging messages
(these appear only if a
technical support
representative has instructed
you to configure this severity
level)
In the following example, the CHASSISD_PARSE_COMPLETE message belongs to the
daemon facility and is assigned severity info (6):
Aug 21 12:36:30 router1 chassisd[522]:
%DAEMON-6-CHASSISD_PARSE_COMPLETE: Using new configuration
When the explicit-priority statement is not included, the priority does not appear in the
message:
Aug 21 12:36:30 router1 chassisd[522]: CHASSISD_PARSE_COMPLETE: Using new
configuration
For moreinformation about messageformatting, see “Displayingand Interpreting System
Log Message Descriptions” on page 47.
Including the Year or Millisecond in Timestamps
By default, the timestamp recorded in a standard-format system log message specifies
the month, date, hour, minute, and second when the message was logged, as in the
following example:
Aug 21 12:36:30
To include the year, the millisecond, or both in the timestamp, include the time-format
statement at the [edit system syslog] hierarchy level:
edit system syslog]
time-format (year | millisecond | year millisecond);
The modified timestamp is used in messages directed to each destination configured by
a file, console, or user statement at the [edit system syslog] hierarchy level, but not to
destinations configured by a host statement.
The following example illustrates the format for a timestamp that includes both the
millisecond (401) and the year (2006):
Aug 21 12:36:30.401 2006
NOTE: Messages logged in structured-data format (available in Junos OS Release 8.3
and laterfor file destinations) include the year and millisecond by default. If you include
the structured-data statement at the [edit system syslog file filename] hierarchy level
along with the time-format statement, the time-format statement is ignored and
messages are logged in structured-data format.
For information about the structured-data statement, see “Logging Messages in
Structured-Data Format” on page 11. For information about the information in a
structured-data message, see “Displaying a Log File from a Single-Chassis System” on
page 35.
Using Regular Expressions to Refine the Set of Logged Messages
The predefined facilities group together related messages, but you can also use regular
expression matching to specify more exactly which messages from a facility are logged
to a file, a user terminal, or a remote destination.
To specify the text string that must (or must not) appear in a message for the message
to be logged to a destination, include the match statement and specify the regular
expression which the text string must match:
match "regular-expression";
You can include this statement at the following hierarchy levels:
•
[edit system syslog file filename] (for a file)
•
[edit system syslog user (username | *)] (for the terminal session of one or all users)
•
[edit system syslog host (hostname | other-routing-engine)] (for a remote destination)
In specifying the regular expression, use the notation defined in POSIX Standard 1003.2
for extended (modern) UNIX regular expressions. Explaining regular expression syntax
is beyond the scopeof thisdocument, but POSIX standardsare availablefrom theInstitute
of Electrical and Electronics Engineers (IEEE, http://www.ieee.org).
Table 11 on page 23 specifies which character or characters are matched by some of the
regularexpression operators that youcan use in the matchstatement.In thedescriptions,
the term term refers to either a single alphanumeric character or a set of characters
enclosed in square brackets, parentheses, or braces.
Table 11: Regular Expression Operators for the match Statement
MatchesOperator
One instance of any character except the space.. (period)
Zero or more instances of the immediately preceding term.* (asterisk)
One or more instances of the immediately preceding term.+ (plus sign)
Zero or one instance of the immediately preceding term.? (question mark)
One of the terms that appear on either side of the pipe operator.| (pipe)
Using Regular
Expressions
! (exclamation point)
^ (caret)
[ ] (paired square
brackets)
( ) (paired parentheses)
Any string except the one specified by the expression, when the
exclamation point appears at the start of the expression. Use of the
exclamation point is Junos OS–specific.
Start of a line, when the caret appears outside square brackets.
One instance of any character that does not follow it within square
brackets, when the caret is the first character inside square brackets.
End of a line.$ (dollar sign)
One instance of one of the enclosed alphanumeric characters. To
indicate a range of characters, use a hyphen ( - ) to separate the
beginning and endingcharacters of the range. For example, [a-z0-9]
matches any letter or number.
One instance of the evaluated value of the enclosed term.
Parenthesesare used toindicate theorder ofevaluationin theregular
expression.
Filter messages that belong to the interactive-commands facility, directing those that
include the string configure to the terminal of the root user:
[edit system syslog]
user root {
interactive-commands any;
match “.*configure.*”;
}
Messages like the following appear on the root user’s terminal when a user issues a
configure command to enter configuration mode:
timestamp router-name mgd[PID]: UI_CMDLINE_READ_LINE: User 'user', command
'configure private'
Filter messages that belong to the daemon facility and have severity error or higher,
directing them tothe file/var/log/process-errors. Omit messages generated by the SNMP
process (snmpd), instead directing them to the file /var/log/snmpd-errors:
Related TopicsSingle-Chassis System Logging Configuration Overview•
• Examples: Configuring System Logging
Disabling Logging of a Facility
To disable the logging of messages that belong to a particular facility, include the facility
none statement in the configuration. This statement is useful when, for example, you
want to log messages that have the same severity level and belong to all but a few
facilities. Instead ofincluding a statement for each facility you want to log, you can include
the any severity statement and then a facility none statement for each facility that you
do not want to log. For example, the following logs all messages at the error level or
higher to the console, except for messages from the daemon and kernel facilities.
Messages from those facilities are logged to the file /var/log/internals instead:
[edit system syslog]
console {
any error;
daemon none;
kernel none;
}
file internals {
daemon info;
kernel info;
}
Examples: Configuring System Logging
Log messages about all commands entered by users at the CLI prompt or invoked by
client applications such as JunosXML protocol or NETCONF clients, and all authentication
or authorization attempts, both to the file cli-commands and to the terminal of any user
who is logged in:
[edit system]
syslog {
file cli-commands {
interactive-commands info;
authorization info;
}
user * {
interactive-commands info;
authorization info;
}
}
Log all changes in the state of alarms to the file /var/log/alarms:
Configure the handling of messages of various types, as described in the comments.
Information is logged to two files, to the terminal of user alex, to a remote machine, and
to the console:
[edit system]
syslog {
/* write all security-related messages to file /var/log/security */
file security {
authorization info;
interactive-commands info;
}
/* write messages about potential problems to file /var/log/messages: */
/* messages from “authorization” facility at level “notice” and above, */
/* messages from all other facilities at level “warning” and above */
file messages {
authorization notice;
any warning;
}
/* write all messages at level “critical” and above to terminal of user “alex” if */
/* that user is logged in */
user alex {
any critical;
}
/* write all messages from the “daemon” facility at level “info” and above, and */
/* messages from all other facilities at level “warning” and above, to the */
/* machine monitor.mycompany.com */
host monitor.mycompany.com {
daemon info;
any warning;
}
/* write all messages at level “error” and above to the system console */
console {
any error;
}
}
Configurethe handling of messagesgenerated whenusers issueJunos OSCLI commands,
by specifying the interactive-commands facility at the following severity levels:
•
info—Logs a message when users issue any command at the CLI operational or
configuration mode prompt. The example writes the messages to the file
/var/log/user-actions.
•
notice—Logs a message when users issue the configuration mode commands rollback
and commit. The example writes the messages to the terminal of user philip.
•
warning—Logs a message when users issue a command that restarts a software
process. The example writes the messages to the console.
This section explainshow toconfigure system logging for theT640 Internetrouting nodes
and TXMatrix platform ina routing matrix. It assumes youare familiar withsystem logging
for single-chassis systems. For more information about routing matrixes, see the JunosSystem Basics Configuration Guide and the TX Matrix Platform Hardware Guide.
To configure system logging for all platforms in a routing matrix, include the syslog
statement at the [edit system] hierarchy level on the TX Matrix platform. The syslog
statement applies to every platform in the routing matrix.
time-format (year | millisecond | year millisecond);
user (username | *) {
facility severity ;
match "regular-expression";
}
}
When included in theconfigurationon theTX Matrix platform, thefollowingconfiguration
statements have the same effect as on a single-chassis system, except that they apply
to every platform in the routing matrix:
•
archive—Sets the size and number of log files archived on each platform in the routing
matrix. See “Configuring the Size and Number of Log Files” on page 17.
•
console—Directs the specified messages to the console of each platform in the routing
matrix. See “Directing Messages to the Console” on page 12.
•
file—Directs the specified messages to a file of the same name on each platform in
the routing matrix. See “Logging Messages in Structured-Data Format” on page 11.
•
match—Limits the set of messages logged to a destination to those that contain (or
do not contain) a text string matching a regular expression. See “Using Regular
Expressions to Refine the Set of Logged Messages” on page 22.
The separate match statement at the [edit system syslog host scc-master] hierarchy
level applies to messages forwarded from the T640 routing nodes to the TX Matrix
platform.
•
source-address—Sets the IP address of the routing platform to report in system log
messages as the message source, when the messages are directed to the remote
machines specified inall host hostname statementsat the[edit system syslog] hierarchy
level, for each platform in the routing matrix. The address is not reported in messages
directed to the other Routing Engine on each platform or forwarded to the TX Matrix
platform by the T640 routing nodes. See “Specifying an Alternative Source Address
for System Log Messages” on page 13.
•
structured-data—Writes messages to a file in structured-data format. See “Logging
Messages in Structured-Data Format” on page 11.
•
time-format—Adds the millisecond, year, or both to the timestamp in each
standard-format message. See “Including the Year or Millisecond in Timestamps” on
page 21.
•
user—Directs the specified messages to the terminal session of one or more specified
users on each platform in the routing matrix that they are logged in to. See “Directing
Messages to a User Terminal” on page 12.
The effect of the other statements differs somewhat for a routing matrix than for a
single-chassis system. For more information, see the following sections:
•
Configuring Message Forwarding in the Routing Matrix on page 28
•
Configuring Optional Features for Forwarded Messages on page 31
•
Directing Messages to a Remote Destination from the Routing Matrix on page 32
•
Configuring System Logging Differently on Each Platform on page 33
Configuring Message Forwarding in the Routing Matrix
By default, the master RoutingEngine on each T640 routingnode forwards to themaster
Routing Engine on the TX Matrix platform all messages from all facilities with severity
info and higher. To change the facility, the severity level, or both, include the host
scc-masterstatement at the [edit systemsyslog] hierarchy level on the TX Matrix platform:
[edit system syslog]
host scc-master {
facility severity;
}
To disable message forwarding, set the facility to any and the severity level to none:
[edit system syslog]
host scc-master {
any none;
}
In either case, the setting applies to all T640 routing nodes in the routing matrix.
To capture the messages forwarded by the T640 routing nodes (as well as messages
generated on the TX Matrix platform itself), you must also configure system logging on
the TX Matrix platform. Direct the messages to one or more destinations by including
the appropriate statements at the [edit system syslog] hierarchy level on the TX Matrix
platform:
•
To a file, as described in Directing Messages to a Log File.
•
To the terminal session of one or more specific users (or all users), as described in
“Directing Messages to a User Terminal” on page 12.
•
To the console, as described in “Directing Messages to the Console” on page 12.
•
To a remote machine that is running the syslogd utility or to the other Routing Engine.
For more information, see “Directing Messages to a Remote Destination from the
Routing Matrix” on page 32.
As previously noted, the configuration statements included on the TX Matrix platform
also configure the same destinations on each T640 routing node.
When specifying the severity level for local messages (at the [edit system syslog (file |
host | console | user)] hierarchy level) and forwarded messages (at the [edit system
syslog host scc-master] hierarchy level), you can set the same severity level for both, set
a lower severity level for local messages, or set a higher severity level for local messages.
The following examples describe the consequence of each configuration. (For simplicity,
the examples use the any facility in every case. You can also specify different severities
for different facilities, with more complex consequences.)
•
Messages Logged When Local and Forwarded Severity Level Are the Same on page 29
•
Messages Logged When Local Severity Level Is Lower on page 29
•
Messages Logged When Local Severity Level Is Higher on page 30
Messages Logged When Local and Forwarded Severity Level Are the Same
When the severity level is the same for local and forwarded messages, the log on the TX
Matrix platform contains all messages from the logs on the T640 routing nodes. For
example, you can specify severity info for the /var/log/messages file, which is the default
severity level for messages forwarded by T640 routing nodes:
[edit system syslog]
file messages {
any info;
}
Table 12 on page29 specifieswhich messagesare included in thelogs onthe T640 routing
nodes and the TX Matrix platform
Table 12: Example: Local and Forwarded Severity Level Are Both info
Lowest Severity IncludedSource of MessagesLog Location
infoLocalT640 routing node
infoLocalTX Matrix platform
infoForwarded from T640 routing
nodes
Messages Logged When Local Severity Level Is Lower
When the severity level is lower for local messages than for forwarded messages, the
log on the TX Matrix platformincludes fewer forwarded messagesthan when the severities
are the same. Locally generated messages are still logged at the lower severity level, so
their number in each log is the same as when the severities are the same.
For example, you can specify severity notice for the /var/log/messages file and severity
Table 13 on page30 specifieswhich messages areincluded inthe logs onthe T640 routing
nodes andthe TX Matrix platform. The T640 routing nodes forwardonly thosemessages
with severity critical and higher, so the log on the TX Matrix platform does not include
the messages with severity error, warning, or notice that the T640 routing nodes log
locally:
Table 13: Example: Local Severity Is notice, Forwarded Severity Is critical
Messages Logged When Local Severity Level Is Higher
When the severity level is higher for local messages than for forwarded messages, the
log on the TX Matrix platformincludes fewer forwarded messagesthan when the severities
are the same, and all local logs contain fewer messages overall.
Lowest Severity IncludedSource of MessagesLog Location
noticeLocalT640 routing node
noticeLocalTX Matrix platform
criticalForwarded from T640 routing
nodes
For example, you can specify severity critical for the /var/log/messages file and severity
notice for forwarded messages:
[edit system syslog]
file messages {
any critical;
}
host scc-master {
any notice;
}
Table 14 on page 30 specifies which messages are included in the logs on the T640
routing nodes and the TX Matrix platform. Although the T640 routing nodes forward
messages with severity notice and higher, the TX Matrix platform discards any of those
messageswith severitylowerthan critical(does notlog forwarded messages with severity
error, warning, or notice). None of the logs include messages with severity error or lower.
Table 14: Example: Local Severity Is critical, Forwarded Severity Is notice
Lowest Severity IncludedSource of MessagesLog Location
criticalLocalT640 routing node
criticalLocalTX Matrix platform
criticalForwarded from T640 routing
nodes
We do not recommend this type of configuration, because it wastes bandwidth for the
routing nodes to forward messages that are not recorded in the log on the TX Matrix
platform.
Configuring Optional Features for Forwarded Messages
To configure additional optional features when specifying how the T640 routing nodes
forward messages to the TX Matrix platform, include statements at the [edit system
sysloghost scc-master] hierarchy level. To include priority information (facility and severity
level) in each forwarded message, include the explicit-priority statement. To insert a text
string in each forwarded message, include the log-prefix statement. To use regular
expressionmatching to specify moreexactlywhich messages from afacilityare forwarded,
include the match statement.
[edit system syslog host scc-master]
facility severity;
explicit-priority;
log-prefix string;
match "regular-expression";
}
NOTE: You can also include the facility-override statement at the [edit system syslog
host scc-master] hierarchy level, but we do not recommend doing so. It is not necessary
to use alternative facilities for messages forwarded to the TX Matrix platform, because
it runs the Junos system logging utility and can interpret the Junos-specific facilities.
For more information about alternative facilities, see “Changing the Alternative Facility
Name for Remote Messages” on page 13.
Chapter 1: Configuring System Log Messages
1. Including Priority Information in Forwarded Messages on page 31
2. Adding a Text String to Forwarded Messages on page 32
3. Using Regular Expressions to Refine the Set of Forwarded Messages on page 32
Including Priority Information in Forwarded Messages
When you include the explicit-priority statement at the [edit system syslog host
scc-master]hierarchy level, messages forwarded to the TXMatrix platforminclude priority
information. For the information to appear in a log file on the TX Matrix platform, you
must also include the explicit-priority statement at the [edit system syslog file filename]
hierarchy level for the file on the TX Matrix platform. As a consequence, the log file with
the same name on each platform in the routing matrix also includes priority information
for locally generated messages.
To include priority information in messages directed to a remote machine from all
platforms in the routing matrix, also include the explicit-priority statement at the [edit
system syslog host hostname] hierarchy level for the remote machine. For more
information, see “Directing Messages to a Remote Destination from the Routing Matrix”
on page 32.
In the following example, the /var/log/messages file on all platforms includes priority
information for messages with severity notice and higher from all facilities. The log on
the TX Matrix platform also includes messages with those characteristics forwarded
from the T640 routing nodes.
When you include the log-prefix statement at the [edit system syslog host scc-master]
hierarchy level, the string that you define appears in every message forwarded to the TX
Matrix platform. For more information, see“Addinga Text String toSystem Log Messages”
on page 16.
Using Regular Expressions to Refine the Set of Forwarded Messages
When you include the match statement at the [edit system syslog host scc-master]
hierarchy level, the regular expression that you specify controls which messages from
the T640 routing nodes are forwarded to the TX Matrix platform. The regular expression
is not appliedto messages from the T640 routing notes that are directedto destinations
other than the TX Matrix platform. For more information about regular expression
matching, see “Using Regular Expressions to Refine the Set of Logged Messages” on
page 22.
Directing Messages to a Remote Destination from the Routing Matrix
You can configure arouting matrixto direct system loggingmessages to a remote machine
or the other Routing Engine on each routing platform, just as on a single-chassis system.
Include the host statement at the [edit system syslog] hierarchy level on the TX Matrix
platform:
[edit system syslog]
host (hostname | other-routing-engine) {
facility severity ;
explicit-priority;
facility-override facility;
log-prefix string;
match "regular-expression";
}
source-address source-address;
The TX Matrix platform directs messages to a remote machine or the other Routing
Engine in the same way as a single-chassis system, and the optional statements
(explicit-priority, facility-override, log-prefix, match, and source-address) also have the
same effect as on a single-chassis system.
For the TX Matrix platform to include priority information when it directs messages that
originated on a T640 routing node to the remote destination, you must also include the
explicit-priority statement at the [edit system syslog host scc-master] hierarchy level.
The other-routing-engine statement does not interact with message forwarding from the
T640 routing nodes to the TX Matrix platform. For example, if you include the statement
in the configuration for the Routing Engine inslot 0 (re0),the re0 Routing Engine on each
T640 routing node sends messages to the re1 Routing Engine on its platform only. It does
not also send messages directly to the re1 Routing Engine on the TX Matrix platform.
Because the configuration on the TX Matrix platform applies to the T640 routing nodes,
any T640 routing node that has interfaces for direct access to the Internet also directs
messages to the remote machine which has the following consequences:
•
If theT640 routingnodes areconfigured to forward messages to the TX Matrix platform
(as in the default configuration), the remote machine receives two copies of some
messages: one directly from the T640 routing node and the other from the TX Matrix
platform. Which messages are duplicated depends on whether the severities are the
same for local logging and for forwarded messages. For more information, see
“Messages Logged When Local Severity Level Is Lower” on page 29,“Messages Logged
When Local Severity Level Is Higher” on page 30, and “Messages Logged When Local
and Forwarded Severity Level Are the Same” on page 29.
•
If the source-address statement is configured at the [edit system syslog] hierarchy
level, all platforms in the routing matrix report the same source routing platform in
messages directed to the remote machine. This is appropriate, because the routing
matrix functions as a single routing platform.
•
If the log-prefix statement is included, the messages from all platforms in the routing
matrix include the same text string. You cannot use the string to distinguish between
the platforms in the routing matrix.
Configuring System Logging Differently on Each Platform
We recommend that all platforms in a routing matrix use the same configuration, which
implies that you include system logging configuration statements on the TX Matrix
platform only.In rare circumstances,however, you mightchoose to log different messages
on different platforms. For example, if one platform in the routing matrix is experiencing
problems with authentication, a Juniper Networks support representative might instruct
you to log messages from the authorization facility on that platform.
To configure platforms separately, include configuration statements in the appropriate
groups at the [edit groups] hierarchy level on the TX Matrix platform:
•
To configure settings that apply to the TX Matrix platform but not the T640 routing
nodes, include them in the re0 and re1 configuration groups.
•
To configure settings that apply to particular T640 routing nodes, include them in the
lccn-re0 and lccn-re1 configuration groups, where n is the line-card chassis (LCC) index
number of the routing node.
When you use configuration groups, do not issue CLI configuration-mode commands to
change the statements at the [edit system syslog] hierarchy level on the TX Matrix
platform. If you do, the resulting statements overwrite the statements defined in
configuration groups and apply to the T640 routing nodes also. (We further recommend
that you do not issue CLI configuration mode commands on the T640 routing nodes at
any time.)
For moreinformation about the configurationgroups fora routing matrix, seethe chapter
about configuration groups in the Junos OS CLI User Guide.
The following example shows how to configure the /var/log/messages files on three
platforms to include different sets of messages:
•
On the TX Matrix platform, local messages with severity info and higher from all
facilities. The file does not include messages from the T640 routing nodes, because
the host scc-master statement disables message forwarding.
•
On the T640 routing node designated LCC0, messages from the authorization facility
with severity info and higher.
•
On the T640 routing node designated LCC1, messages with severity notice from all
facilities.
[edit groups]
re0 {
system {
syslog {
file messages {
any info;
}
host scc-master {
any none;
}
}
}
}
re1 {
... same statements as for re0 ...
}
lcc0-re0 {
system {
syslog {
file messages {
authorization info;
}
}
}
}
lcc0-re1 {
... same statements as for lcc0-re0 ...
}
lcc1-re0 {
This section explains how to display a log file and interpret the contents of system log
messages:
For moreinformationabout the commands discussedin this section, see the Junos System
Basics and Services Command Reference.
•
Displaying a Log File from a Single-Chassis System on page 35
•
Displaying a Log File from a Routing Matrix on page 35
•
Interpreting System Log Messages on page 36
•
Format of the message-source Field on page 42
•
Examples: Displaying a Log File on page 45
Displaying a Log File from a Single-Chassis System
Chapter 1: Configuring System Log Messages
To display a log file stored on a single-chassis system, enter Junos OS CLI operational
mode and issue either of the following commands:
user@host> show loglog-filename
user@host> file show log-file-pathname
By default, the commands display the file stored on the local Routing Engine. To display
the file stored on a particular Routing Engine, prefix the file- or pathname with the string
re0 or re1 and a colon. The following examples both display the /var/log/messages file
stored on the Routing Engine in slot 1:
user@host> show log re1:messages
user@host> file show re1:/var/log/messages
For information about the fields in a log message, see “Interpreting Messages Generated
in Standard Format by a JUNOS Process or Library” on page 41, “Interpreting Messages
Generated in Standard Format by Services on a PIC” on page 41, and “Interpreting
Messages Generated in Structured-Data Format” on page 36. For examples, see
“Examples: Displaying a Log File” on page 45.
Displaying a Log File from a Routing Matrix
One way to display a log file stored on the local Routing Engine of any of the individual
platforms in a routing matrix (T640 routing nodes or TX Matrix platform) is to log in to
a Routing Engine on the platform, enter Junos OS CLI operational mode, and issue the
show log or file show command described in “Displaying a Log File from a Single-Chassis
System” on page 35.
To display a log file stored on a T640 routing node during a terminal session on the TX
Matrix platform, issue the show log or file show command and add a prefix that specifies
the T640 routing node’s LCC index number as lccn, followed by a colon. The index can
be from 0 (zero) through 3:
By default, the show log and file show commands display the specified log file stored on
the master Routing Engine on the T640 routing node. To display the log from a particular
Routing Engine, prefix the file- or pathname with the string lccn-master, lccn-re0, or
lccn-re1, followed by a colon. The following examples all display the /var/log/messages
file stored on the master Routing Engine (in slot 0) on routing node LCC2:
user@host> show log lcc2:messages
user@host> show log lcc2-master:messages
user@host> show log lcc2-re0:messages
user@host> file show lcc2:/var/log/messages
If the T640 routing nodes are forwarding messages to the TX Matrix platform (as in the
defaultconfiguration), another way to view messages generated on a T640 routing node
during a terminal session on the TX Matrix platform is simply to display a local log file.
However, the messages are intermixed with messages from other T640 routing nodes
and the TX Matrix platform itself. For more information about message forwarding, see
“Messages Logged When Local Severity Level Is Lower” on page 29, “Messages Logged
When Local Severity Level Is Higher” on page 30, and “Messages Logged When Local
and Forwarded Severity Level Are the Same” on page 29.
For information about the fields in a log message, see “Interpreting Messages Generated
in Structured-Data Format” on page 36, “Interpreting Messages Generated in Standard
Format by Services on a PIC” on page 41, and “Interpreting Messages Generated in
StandardFormat bya JUNOSProcessor Library”on page41. Forexamples, see “Examples:
Displaying a Log File” on page 45.
Interpreting System Log Messages
The fields in a message written to the system log depend on whether the message was
generated by a Junos process or subroutine library, or by services on a PIC, and whether
it isin standard format orstructured-dataformat. For more information, see thefollowing
sections:
•
Interpreting Messages Generated in Structured-Data Format on page 36
•
Interpreting Messages Generated in Standard Format by a Junos Process or
Library on page 41
•
Interpreting Messages Generated in Standard Format by Services on a PIC on page 41
Interpreting Messages Generated in Structured-Data Format
Beginning in Junos OS Release 8.3, when the structured-data statement is included in
the configuration for a log file, Junos processes and software libraries write messages to
the file in structured-data format instead of the standard Junos format. For information
about thestructured-data statement, see “Logging Messages in Structured-Data Format”
on page 11.
Structured-format makes it easier for automated applications to extract information
from the message. In particular, the standardized format for reporting the value of
variables (elements in the English-language message that vary depending on the
circumstances that triggered the message) makes it easy for an application to extract