SNMP On Junos Os Faq

Technology Overview
SNMP on Junos OS Frequently Asked Questions
Release
10.3
Published: 2010-10-12
Revision 1
Copyright 2010, Juniper Networks, Inc.
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright 1986-1997,
Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part
of them is in the public domain.
This product includes memory allocation software developed by Mark Moraes, copyright 1988, 1989, 1993, University of Toronto.
This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation
and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright
1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.
GateD software copyright 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through
release 3.0 by Cornell University and its collaborators. Gated is based on Kirtons EGP, UC Berkeleys routing daemon (routed), and DCNs
HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD
software copyright 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright 1991, D.
L. S. Associates.
This product includes software developed by Maker Communications, Inc., copyright 1996, 1997, Maker Communications, Inc.
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.
Technology Overview SNMP on Junos OS Frequently Asked Questions

Release 10.3
All rights reserved. Printed in USA.
Writing: Yeshaswini R.
Editing: Katie Smith, Roy Spencer, Marilyn Kerr
Cover Design: Edmonds Design
Revision History
July 2010R1 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.
ii
END USER LICENSE AGREEMENT

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 BOUND BY THIS AGREEMENT. IF YOU DO NOT OR 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 Customers principal office is located in the Americas) or
Juniper Networks (Cayman) Limited (if the Customers principal office is located outside the Americas) (such applicable entity being referred
to herein as Juniper), and (ii) the person or organization that originally purchased from Juniper or an authorized Juniper reseller 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 payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer
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 limits to Customers use of the Software. Such limits may restrict use to a maximum number of 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.
Customers 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, Customers 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 Customers
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, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software or 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 in the secondhand market; (f) use any locked or key-restricted feature, function, service, application, operation, or capability
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
iii
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 prior written 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 all reasonable 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 Customers internal business purposes.
7. Ownership. Juniper and Junipers 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
statement that accompanies the Software (the Warranty Statement). Nothing in this Agreement shall give rise to 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 COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER
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 Junipers 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 Customers 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
Customers 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 Customers non-compliance or delay with its responsibilities herein. Customers 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 Customers ability to export the Software without
an export license.
iv
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 of Juniper 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 its own name as if it were Juniper. In addition, certain third party
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 prsents confirment leur volont que cette convention de
mme que tous les documents y compris tout avis qui s'y rattach, soient redigs en langue anglaise. (Translation: The parties confirm that
this Agreement and all related documentation is and will be in the English language)).
vi
Table of Contents
Junos OS SNMP Frequently Asked Questions Overview . . . . . . . . . . . . . . . . . . . . . . 1
Junos OS SNMP Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Junos OS SNMP Support Frequently Asked Questions . . . . . . . . . . . . . . . . . . . 3
Junos OS MIBs Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Junos OS SNMP Configuration Frequently Asked Questions . . . . . . . . . . . . . . 12
SNMPv3 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SNMP Interaction with Juniper Networks Devices Frequently Asked
Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
SNMP Traps and Informs Frequently Asked Questions . . . . . . . . . . . . . . . . . 20
SNMP Support for Routing Instances Frequently Asked Questions . . . . . . . . 26
SNMP Counters Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii
viii
Junos OS SNMP Frequently Asked Questions Overview

This document presents the most frequently asked questions about the features and
technologies used to implement SNMP services on Juniper Networks devices using the
Junos operating system.
SNMP allows users to monitor network devices from a central location. Many network
management systems (NMS) are based on SNMP, and support for this protocol is a key
feature of most network devices.
Juniper Networks provides many different platforms that support SNMP on Junos OS.
Junos OS includes an onboard SNMP agent that provides remote management
applications with access to detailed information about the devices on the network.
A typical SNMP implementation contains three components:
Managed devices such as routers and switches.
SNMP agent process that resides on a managed device and communicates with the
NMS.
NMS a combination of hardware and software used to monitor and administer the
network; network device that runs SNMP manager software. Also referred to as an
SNMP manager.
The SNMP agent exchanges network management information with the SNMP manager
(NMS). The agent responds to requests for information and actions from the manager.
The SNMP manager collects information about network connectivity, activity, and events
by polling managed devices.
SNMP implementation in Junos OS uses a master SNMP agent (known as SNMP process
or snmpd) that resides on the managed device. Various subagents reside on different
modules of Junos OS as well (such as the Routing Engine), and these are managed by
the snmpd.
Related
Documentation
Junos OS SNMP Frequently Asked Questions on page 3
Junos OS SNMP Frequently Asked Questions

This Frequently Asked Questions technology overview covers these SNMP-related areas:
Junos OS SNMP Support Frequently Asked Questions on page 3
Junos OS MIBs Frequently Asked Questions on page 4
Junos OS SNMP Configuration Frequently Asked Questions on page 12
SNMPv3 Frequently Asked Questions on page 16
SNMP Interaction with Juniper Networks Devices Frequently Asked Questions on page 18
SNMP Traps and Informs Frequently Asked Questions on page 20
SNMP Support for Routing Instances Frequently Asked Questions on page 26
SNMP Counters Frequently Asked Questions on page 27
Junos OS SNMP Support Frequently Asked Questions

This section presents frequently asked questions and answers related to SNMP support
on Junos OS.
Which SNMP versions are supported by Junos OS?
Junos OS supports SNMP version 1 (SNMPv1), version 2 (SNMPv2c), and version 3
(SNMPv3). By default, SNMP is disabled on a Juniper Networks device. To enable SNMP,
see instructions in Configuring SNMP on Devices Running Junos OS in the Best Practices
SNMP-Based Network Management on Devices Running Junos OS document.
Which ports (sockets) are used by SNMP?
The default port for SNMP queries is port 161; the default port for SNMP traps and informs
is port 162. The ports used by SNMP are configurable, and you can configure your system
to use ports other than the defaults.
Is SNMP support different among Junos OS platforms?
No, SNMP support is not different among Junos OS platforms; SNMP configuration,
interaction, and behavior are the same on any Junos OS device. The only difference that
may occur across platforms is MIB support. See the next section Junos OS MIBs
Frequently Asked Questions on page 4 for more information about MIB support on
Junos OS platforms.
See also the Junos OS Network Management Configuration Guide for a list of MIBs that
are supported across Junos OS platforms.
Does Junos OS support the user-based security model (USM)?
Yes, Junos OS supports USM as part of its support for SNMPv3. SNMPv3 contains more
security measures than previous versions of SNMP, including providing a defined USM.
SNMPv3 USM provides message security through data integrity, data origin authentication,
message replay protection, and protection against disclosure of the message payload.
Does Junos OS support the view-based access control model (VACM)?

Yes, Junos OS supports VACM as part of its support for SNMPv3. SNMPv3 contains more
security measures than previous versions of SNMP, including providing a defined VACM.
SNMPv3 VACM determines whether a specific type of access (read or write) to the
management information is allowed.
Does Junos OS support SNMP informs?
Yes, Junos OS supports SNMP informs as part of its support for SNMPv3. SNMP informs
are confirmed notifications sent from SNMP agents to SNMP managers when significant
events occur on a network device. When an SNMP manager receives an inform, it sends
a response to the sender to verify receipt of the inform.
Can I provision or configure a device using SNMP on Junos OS?
No, provisioning or configuring a device using SNMP is not allowed on Junos OS.
Related
Documentation
SNMP Interaction with Juniper Networks Devices Frequently Asked Questions on

page 18
Junos OS MIBs Frequently Asked Questions

This section presents frequently asked questions and answers related to Junos OS MIBs.
What is a MIB?
A management information base (MIB) is a table of definitions for managed objects in
a network device. MIBs are used by SNMP to maintain standard definitions of all of the
components and their operating conditions within a network device. Each object in the
MIB has an identifying code called an object identifier (OID).
MIBs are either standard or enterprise-specific. Standard MIBs are created by the Internet
Engineering Task Force (IETF) and documented in various RFCs; enterprise-specific MIBs
are developed and supported by a specific equipment manufacturer.
For a list of supported standard MIBs, see Standard SNMP MIBs Supported by Junos OS
in the Junos OS SNMP MIBs and Traps Reference.
For a list of Juniper Networks enterprise-specific MIBs, see Juniper Networks
Enterprise-Specific MIBs in the Junos OS SNMP MIBs and Traps Reference.
Do MIB files reside on Junos OS devices?

No, MIB files do not reside on Junos OS devices. You must download the MIB files from
the Juniper Networks Technical Publications page for the required Junos OS release:
http://www.juniper.net/techpubs/software/junos/mibs.html.
How do I compile and load Junos OS MIBs onto an SNMP manager or NMS?
For your NMS to identify and understand the MIB objects used by Junos OS, you must
first load the MIB files to your NMS using a MIB compiler. A MIB compiler is a utility that
parses the MIB information such as the MIB object names, IDs, and data types for the
NMS.
You can download the Junos MIB package from the Enterprise-Specific MIBs and Traps
section at http://www.juniper.net/techpubs/software/junos/mibs.html or
http://www.juniper.net/techpubs/software/junos/index.html.
The Junos MIB package has two folders: StandardMibs, containing standard MIBs
supported on Juniper Networks devices, and JuniperMibs, containing Juniper Networks
enterprise-specific MIBs. You must have the required standard MIBs downloaded and
decompressed before downloading any enterprise-specific MIBs. There may be
dependencies that require a particular standard MIB to be present on the compiler before
loading a particular enterprise-specific MIB.
The Junos MIB package is available in .zip and .tar formats; download the format
appropriate for your requirements.
Use the following steps to load MIB files for devices running Junos OS:
1.
Navigate to the appropriate Juniper Networks software download page and locate
the Enterprise MIBs link under the Enterprise-Specific MIBs and Traps section.
NOTE: Although the link is titled Enterprise MIBs, both standard MIBs and
enterprise-specific MIBs are available for download from this location.
2. Click the TAR or ZIP link to download the Junos MIB package.
3. Decompress the file (.tar or .zip) using an appropriate utility.
4. First load the standard MIB files from the StandardMibs folder.
NOTE: Some commonly used MIB compilers are preloaded with standard
MIBs. You can skip Step 4 and Step 5 and proceed to Step 6 if you already
have the standard MIBs loaded on your system.
Load the files in the following order:

a. mib-SNMPv2-SMI.txt
b. mib-SNMPv2-TC.txt
c. mib-IANAifType-MIB.txt
d. mib-IANA-RTPROTO-MIB.txt
e. mib-rfc1907.txt
f. mib-rfc2011a.txt
g. mib-rfc2012a.txt
h. mib-rfc2013a.txt
i.
mib-rfc2863a.txt
5. Load any remaining standard MIB files.
NOTE: You must follow the order specified in this procedure, and ensure
that all standard MIBs are loaded before you load the enterprise-specific
MIBs. There may be dependencies that require a particular standard MIB
to be present on the compiler before loading a particular enterprise-specific
MIB. Dependencies are listed in the IMPORT section of the MIB file.
6. After loading the standard MIBs, load the Juniper Networks enterprise-specific SMI
MIB, mib-jnx-smi.txt, and the following optional SMI MIBs based on your requirements:
mib-jnx-exp.txt(Recommended) for Juniper Networks experimental MIB objects
mib-jnx-js-smi.txt(Optional) for Juniper Security MIB tree objects
mib-jnx-ex-smi.txt(Optional) for EX Series Ethernet Switches
7. Load any remaining desired enterprise-specific MIBs from the JuniperMibs folder.
TIP: While loading a MIB file, if the compiler returns an error message
indicating that any of the objects are undefined, open the MIB file using a
text editor and ensure that all the MIB files listed in the IMPORT section
are loaded on the compiler. If any of the MIB files listed in the IMPORT
section are not loaded on the compiler, first load the missing file or files,
then try to load the MIB file that failed.
The system may return an error if files are not loaded in a particular order.
What is SMI?
Structure of Management Information Version (SMI) is a subset of Abstract Syntax
Notation One (ASN.1), which describes the structure of objects. SMI is the notation syntax,
or grammar, that is the standard for writing MIBs.
Which versions of SMI are supported by Junos OS?

Junos OS supports SMIv1 for SNMPv1 MIBs and SMIv2 for SNMPv2c and enterprise MIBs.
Is MIB II supported by Junos OS?
Yes, MIB II is supported by Junos OS. MIB II is the second version of the MIB standard.
The features of MIB II include:
Additions that reflect new operational requirements.
Backwards compatibility with the original MIBs and SNMP.
Improved support for multiprotocol entities.
Improved readability.
Refer to the relevant release documentation for a list of MIBs that are supported at
http://www.juniper.net/techpubs/software/junos/index.html.
Are the same MIBs supported across all Juniper Networks devices?
There are some common MIBs supported by all Junos OS devices, such as the Interface
MIB (ifTable), System MIB, and Chassis MIB. Some MIBs are supported only by
functionalities on specific platforms. For example, the Bridge MIB is supported on the EX
Series Ethernet Switches and the SRX Series Services Gateways for the branch.
What is the system object identifier (SYSOID) of a device? How do I determine the
SYSOID of my device?
The jnx-chas-defines (Chassis Definitions for Router Model) MIB has a jnxProductName
branch for every Junos OS device. The system object ID of a device is identical to the
object ID of the jnxProductName for the platform. For example, for an M7i Multiservice
Edge Router, the jnxProductNameM7i is .1.3.6.1.4.1.2636.1.1.1.2.10 in the jnxProductName
branch, which is identical to the SYSOID of the M7i (.1.3.6.1.4.1.2636.1.1.1.2.10).
How can I determine if a MIB is supported on a platform? How can I determine which
MIBs are supported by a device?
MIBs device and platform support is listed on the Junos Software Technical Publications
index page. Go to http://www.juniper.net/techpubs/software/junos/ and select the tab
at the top of the page that corresponds to your version or release of Junos OS. Click the
plus (+) sign that expands the Configuration Guides section. Select the Network
Management Guide, which specifies which MIBs are supported on the different platforms.
What can I do if the MIB OID query is not responding?

There can be various reasons why the MIB OID query stops responding. One reason could
be that the MIB is unresponsive. To verify that the MIB responds, use the show snmp mib
walk | get MIB name | MIB OID command:
If the MIB responds, the communication issue exists between the SNMP master and
SNMP agent. Possible reasons for this issue include network issues, an incorrect
community configuration, an incorrect SNMP configuration, and so on.
If the MIB does not respond, enable SNMP traceoptions to log PDUs and errors. All
incoming and outgoing SNMP PDUs are logged. Check the traceoptions output to see
if there are any errors.
If you continue to have problems with the MIB OID query, technical product support is
available through the Juniper Networks Technical Assistance Center (JTAC).
What is the enterprise branch number for Junos OS?
The enterprise branch number for Junos OS is 2636. Enterprise branch numbers are used
in SNMP MIB configurations, and they are also known as SMI network management
private enterprise codes.
Which MIB displays the hardware and chassis details on a Juniper Networks device?
The Chassis MIB (jnxchassis.mib) displays the hardware and chassis details for each
Juniper Networks device. It provides information about the router and its components;
the Chassis MIB objects represent each component and its status.
For more information about the enterprise-specific Chassis MIBs, see Chassis MIBs in the
Junos OS SNMP MIBs and Traps Reference.
Does Junos OS support the Entity MIB?
No, Junos OS does not support the Entity MIB, which is designed to identify physical and
logical elements of a managed device. Instead, Junos OS supports the enterprise-specific
Chassis MIB to identify the chassis components on the device.
Which MIB objects can I query to determine the CPU and memory utilization of the
Routing Engine, Flexible PIC Concentrator (FPC), and PIC components on a device?
Query the Chassis MIB objects jnxOperatingMemory, jnxOperatingtBuffer, and
jnxOperatingCPU to find out the CPU and memory utilization of the hardware components
of a device.
Is the interface index (ifIndex) persistent?
For Junos OS Release 10.0 and earlier, the ifIndex is persistent when reboots occur if the
Junos OS version remains the same, meaning the values assigned to the interfaces in the
ifIndex do not change. When there is a software upgrade, it is a best effort to keep the
ifIndex persistent.
For Junos OS Release 10.1 and later, the ifIndex is persistent on all platforms, except for
the EX4200 virtual chassis because it can have over 500 interfaces.
Is it possible to set the ifAdminStatus?
SNMP is not allowed to set the ifAdminStatus.
Which MIB objects support SNMP set operations?
Junos OS SNMP set operations are supported in the following MIB tables and variables:
snmpCommunityTable
eventTable
alarmTable
snmpTargetAddrExtTable
jnxPingCtlTable
pingCtlTable
traceRouteCtlTable
jnxTraceRouteCtlTable
sysContact.0
sysName.0
sysLocation.0
pingMaxConcurrentRequests.0
traceRouteMaxConcurrentRequests.0
usmUserSpinLock
usmUserOwnAuthKeyChange
usmUserPublic
vacmSecurityToGroupTable (vacmGroupName, vacmSecurityToGroupStorageType,

and vacmSecurityToGroupStatus)
vacmAccessTable (vacmAccessContextMatch, vacmAccessReadViewName,

vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType,
and vacmAccessStatus)
vacmViewSpinLock
vacmViewTreeFamilyTable (vacmViewTreeFamilyMask, vacmViewTreeFamilyType,

vacmViewTreeFamilyStorageType, and vacmViewTreeFamilyStatus)
Does Junos OS support remote monitoring (RMON)?

Yes, Junos OS supports RMON as defined in RFC 2819, Remote Network Monitoring
Management Information Base. However, remote monitoring version 2 (RMON 2) is not
supported.
Can I use SNMP to determine the health of the processes running on the Routing
Engine?
Yes, you can use SNMP to determine the health of the Routing Engine processes by
configuring the health monitoring feature. On Juniper Networks devices, RMON alarms
and events provide much of the infrastructure needed to reduce the polling overhead
from the NMS. However, you must set up the NMS to configure specific MIB objects into
RMON alarms. This often requires device-specific expertise and customizing of the
monitoring application. Additionally, some MIB object instances that need monitoring
are set only at initialization, or they change at runtime and cannot be configured in
advance.
To address these issues, the health monitor extends the RMON alarm infrastructure to
provide predefined monitoring for a selected set of object instances, such as the file
system usage, CPU usage, and memory usage, and includes support for unknown or
dynamic object instances, such as Junos OS software processes.
To display the health monitoring configuration, use the show snmp health-monitor
command:
user@host> show snmp health-monitor
interval 300;
rising-threshold 90;
falling-threshold 80;
When you configure the health monitor, monitoring information for certain object instances
is available, as shown in Table 1 on page 10.
Table 1: Monitored Object Instances

Object
Description
jnxHrStoragePercentUsed.1
Monitors the following file system on the router or switch: /dev/ad0s1a:

This is the root file system mounted on /.
jnxHrStoragePercentUsed.2
Monitors the following file system on the router or switch: /dev/ad0s1e:

This is the configuration file system mounted on /config.
jnxOperatingCPU (RE0)
jnxOperatingCPU (RE1)
jnxOperatingBuffer (RE0)
jnxOperatingBuffer (RE1)
sysApplElmtRunCPU
10
Monitor CPU usage for Routing Engines RE0 and RE1. The index values assigned to the
Routing Engines depend on whether the Chassis MIB uses a zero-based or a ones-based
indexing scheme. Because the indexing scheme is configurable, the correct index is
determined whenever the router is initialized and when there is a configuration change.
If the router or switch has only one Routing Engine, the alarm entry monitoring RE1 is
removed after five failed attempts to obtain the CPU value.
Monitor the amount of memory available on Routing Engines RE0 and RE1. Because
the indexing of this object is identical to that used for jnxOperatingCPU, index values
are adjusted depending on the indexing scheme used in the Chassis MIB. As with
jnxOperatingCPU, the alarm entry monitoring RE1 is removed if the router or switch
has only one Routing Engine.
Monitors the CPU usage for each Junos OS software process. Multiple instances of
the same process are monitored and indexed separately.
Table 1: Monitored Object Instances (continued)

Object
Description
sysApplElmtRunMemory
Monitors the memory usage for each Junos OS software process. Multiple instances
of the same process are monitored and indexed separately.
The system log entries generated for any health monitor events, such as thresholds
crossed and errors, have a corresponding HEALTHMONITOR tag rather than a generic
SNMPD_RMON_EVENTLOG tag. However, the health monitor sends generic RMON
risingThreshold and fallingThreshold traps.
Are the Ping MIBs returned in decimal notation and ASCII?
Yes, both decimal notation and ASCII are supported, which is the standard implementation
in SNMP. All strings are ASCII encoded.
The following example displays the Ping MIB in hexadecimal notation:
pingCtlTargetAddress.2.69.72.9.116.99.112.115.97.109.112.108.101 = 0a fa 01 02
This translates to ASCII:

pingCtlTargetAddress."EH"."tcpsample" = 0a fa 01 02
2= length of the string
69=E
72=H
9=length of second string
116=t
99 =c
112=p
115=s
97=a
109=m
112 =p
108 =l
101 =e
As of Junos OS Release 9.6 and later, the Junos OS CLI returns ASCII values using the
command show snmp mib get | get-next | walk ascii.
The following example shows the output with the ASCII option:
user@host> show snmp mib walk pingCtlTargetAddress ascii
pingCtlTargetAddress."EH"."httpgetsample" = http://www.yahoo.com
pingCtlTargetAddress."p1"."t2" = 74 c5 b3 06
pingCtlTargetAddress."p1"."t3" = 74 c5 b2 0c
The following example shows the output without the ASCII option:
user@host> show snmp mib walk pingCtlTargetAddress
pingCtlTargetAddress.2.69.72.13.104.116.116.112.103.101.116.115.97.109.112.108.101
= http://www.yahoo.com
pingCtlTargetAddress.2.112.49.2.116.50 = 74 c5 b3 06
pingCtlTargetAddress.2.112.49.2.116.51 = 74 c5 b2 0c
11
You can convert decimal and ASCII values using a decimal ASCII chart like the one at:
http://www.asciichart.com/.
Is IPv6 supported by the Ping MIB for remote operations?
No, IPv6 is not supported.
Is there an SNMP MIB to show Address Resolution Protocol (ARP) table information?
Are both IP and MAC addresses displayed in the same table?
Yes, Junos OS supports the standard MIB ipNetToMediaTable, which is described in RFC
2011, SNMPv2 Management Information Base for the Internet Protocol using SMIv2. This
table is used for mapping IP addresses to their corresponding MAC addresses.
Related
Documentation

page 18
Junos OS SNMP Configuration Frequently Asked Questions

This section presents frequently asked questions and answers related to Junos OS SNMP
configuration.
Can Junos OS be configured for SNMPv1 and SNMPv3 simultaneously?
Yes, SNMP has backward compatibility, meaning that all three versions can be enabled
simultaneously.
Can I filter specific SNMP queries on a device?
Yes, you can filter specific SNMP queries on a device using exclude and include statements.
The following example shows a configuration that blocks read-write operation on all
OIDs under .1.3.6.1.2.1.1 for the community test:
user@host# show snmp
view system-exclude {
oid .1.3.6.1.2.1.1 exclude;
oid .1 include;
}
community test {
view system-exclude;
authorization read-write;
}
12
Can I change the SNMP agent engine ID?

Yes, the SNMP agent engine ID can be changed to the MAC address of the device, the IP
address of the device, or any other desired value. Several examples are included here.
The following example shows how to use the MAC address of a device as the SNMP
agent engine ID:
engine-id {
use-mac-address;
}
The following example shows how to use the IP address of a device as the SNMP agent
engine ID:
engine-id {
use-default-ip-address;
}
The following example shows the use of a selected value, AA in this case, as the SNMP
agent engine ID of a device:
engine-id {
local AA;
}
How can I configure a device with dual Routing Engines or a chassis cluster (for SRX
Series Services Gateways or J Series Service Routers) for continued communication
during a switchover?
When configuring for continued communication, the SNMP configuration should be
identical between the Routing Engines. However, it is best to have separate Routing
Engine IDs configured for each Routing Engine, especially when using SNMPv3.
The following example shows the configuration of the Routing Engines in a dual Routing
Engine device. Notice that the Routing Engine IDs are set to the MAC addresses for each
Routing Engine:
user@host# show groups
re0 {
system {
host-name PE3-re0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 116.197.178.14/27;
address 116.197.178.29/27 {
master-only;
}
}
}
}
13
}
snmp {
engine-id {
use-mac-address;
}
}
}
re1 {
system {
host-name PE3-re1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 116.197.178.11/27;
address 116.197.178.29/27 {
master-only;
}
}
}
}
}
snmp {
engine-id {
use-mac-address;
}
}
}
The following is an example of an SNMPv3 configuration on a dual Routing Engine device:

user@host> show snmp name host1
v3 {
vacm {
security-to-group {
security-model usm {
security-name test123 {
group test1;
}
security-name juniper {
group test1;
}
}
}
access {
group test1 {
default-context-prefix {
security-model any {
security-level authentication {
read-view all;
}
}
}
context-prefix MGMT_10 {
security-model any {
14
read-view all;
}
}
}
}
}
}
target-address server1 {
address 116.197.178.20;
tag-list router1;
routing-instance MGMT_10;
target-parameters test;
}
target-parameters test {
parameters {
message-processing-model v3;
security-model usm;
security-level authentication;
security-name juniper;
}
notify-filter filter1;
}
notify server {
type trap;
tag router1;
}
notify-filter filter1 {
oid .1 include;
}
view all {
oid .1 include;
}
community public {
view all;
}
community comm1;
community comm2;
community comm3 {
view all;
authorization read-only;
logical-system LDP-VPLS {
routing-instance vpls-server1;
}
}
trap-group server1 {
targets {
116.197.179.22;
}
}
routing-instance-access;
traceoptions {
flag all;
}
}
15
How can I track SNMP activities?

SNMP trace operations track activity of SNMP agents and record the information in log
files.
A sample traceoptions configuration may look like this:
[edit snmp]
user@host# set traceoptions flag all
When the traceoptions flag all statement is included at the [edit snmp] hierarchy level,
the following log files are created:
Related
Documentation
snmpd
mib2d
rmopd

page 18
SNMPv3 Frequently Asked Questions

This section presents frequently asked questions and answers related to SNMPv3.
Why is SNMPv3 important?
SNMP v3 provides enhanced security compared to the other versions of SNMP. It provides
authentication and encryption of data. Enhanced security is important for managing
devices at remote sites from the management stations.
In my system, the MIB object snmpEngineBoots is not in sync between two Routing
Engines in a dual Routing Engine device. Is this normal behavior?
Yes, this is the expected behavior. Each Routing Engine runs its own SNMP process
(snmpd), allowing each Routing Engine to maintain its own engine boots.
Do I need the SNMP manager engine object identifier (OID) for informs?
Yes, the engine OID of the SNMP manager is required for authentication, and informs do
not work without it.
16
I see the configuration of informs under the [edit snmp v3] hierarchy. Does this mean
I cannot use informs with SNMPv2c?
Informs can be used with SNMPv2c. The following example shows the basic configuration
for SNMPv3 informs on a device (note that the authentication and privacy is set to none):
[edit snmp]
v3 {
usm {
remote-engine 00000063000100a2c0a845b3 {
user RU2_v3_sha_none {
authentication-none;
privacy-none;
}
}
}
vacm {
security-to-group {
security-name RU2_v3_sha_none {
group g1_usm_auth;
}
}
}
access {
group g1_usm_auth {
read-view all;
write-view all;
notify-view all;
}
}
}
}
}
}
target-address TA2_v3_sha_none {
address 192.168.69.179;
tag-list tl1;
address-mask 255.255.252.0;
target-parameters TP2_v3_sha_none;
}
target-parameters TP2_v3_sha_none {
parameters {
message-processing-model v3;
security-model usm;
security-level none;
security-name RU2_v3_sha_none;
}
notify-filter nf1;
}
notify N1_all_tl1_informs {
type inform; # Replace inform with trap to convert informs to traps.
17
tag tl1;
}
notify-filter nf1 {
oid .1 include;
}
view all {
oid .1 include;
}
}
You can convert the SNMPv3 informs to traps by setting the value of the type statement
at the [edit snmp v3 notify N1_all_tl1_informs] hierarchy level to trap as shown in the
following example:
user@host# set snmp v3 notify N1_all_tl1_informs type trap
Related
Documentation

page 18
SNMP Interaction with Juniper Networks Devices Frequently Asked Questions

This section presents frequently asked questions and answers related to how SNMP
interacts with Juniper Networks devices.
How frequently should a device be polled? What is a good polling rate?
It is difficult to give an absolute number for the rate of SNMP polls per second since the
rate depends on the following two factors:
1.
The number of variable bindings in a protocol data unit (PDU).
2. The response time for an interface from the Packet Forwarding Engine.
In a normal scenario where no delay is being introduced by the Packet Forwarding Engine
and there is one variable per PDU (a Get request), the response time is 130+ responses
per second. However, with multiple variables in an SNMP request PDU (30 to 40 for
GetBulk requests), the number of responses per second is much less. Because the Packet
Forwarding Engine load can vary for each system, there is greater variation in how
frequently a device should be polled.
18
Frequent polling of a large number of counters, especially statistics, can impact the
device. Juniper Networks recommends the following optimization on the SNMP managers:
The polling method should be row-by-row and not column-by-column.
Reduce the number of variable bindings per PDU.
Increase timeout values in polling and discovery intervals.
Reduce incoming packet rate at the SNMP process (snmpd).
For better SNMP response on the device, Junos OS enables the following:
Filters out duplicate SNMP requests.
Excludes interfaces that are slow in response from SNMP queries.
One way to determine a rate limit is to note an increase in the Currently Active count from
the show snmp statistics extensive command.
The following is a sample output of the show snmp statistics extensive command:
user@host> show snmp statistics extensive
SNMP statistics:
Input:
Packets: 226656, Bad versions: 0, Bad community names: 0,
Bad community uses: 0, ASN parse errors: 0,
Too bigs: 0, No such names: 0, Bad values: 0,
Read onlys: 0, General errors: 0,
Total request varbinds: 1967606, Total set varbinds: 0,
Get requests: 18478, Get nexts: 75794, Set requests: 0,
Get responses: 0, Traps: 0,
Silent drops: 0, Proxy drops: 0, Commit pending drops: 0,
Throttle drops: 27084, Duplicate request drops: 0
V3 Input:
Unknown security models: 0, Invalid messages: 0
Unknown pdu handlers: 0, Unavailable contexts: 0
Unknown contexts: 0, Unsupported security levels: 0
Not in time windows: 0, Unknown user names: 0
Unknown engine ids: 0, Wrong digests: 0, Decryption errors: 0
Output:
Packets: 226537, Too bigs: 0, No such names: 0,
Bad values: 0, General errors: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 226155, Traps: 382
SA Control Blocks:
Total: 222984, Currently Active: 501, Max Active: 501,
Not found: 0, Timed Out: 0, Max Latency: 25
SA Registration:
Registers: 0, Deregisters: 0, Removes: 0
Trap Queue Stats:
Current queued: 0, Total queued: 0, Discards: 0, Overflows: 0
Trap Throttle Stats:
Current throttled: 0, Throttles needed: 0
Snmp Set Stats:
Commit pending failures: 0, Config lock failures: 0
Rpc failures: 0, Journal write failures: 0
Mgd connect failures: 0, General commit failures: 0
19
Does SNMP open dynamic UDP ports? Why?

The SNMP process opens two additional ports (sockets): one for IPv4 and one for IPv6.
This enables the SNMP process to send traps.
I am unable to perform a MIB walk on the ifIndex. Why is this?
Any variable bindings or values with an access level of not-accessible cannot be queried
directly because they are part of other variable bindings in the SNMP MIB table. The
ifIndex has an access level of not-accessible; therefore, it cannot be accessed directly
because it is part of the variable bindings. However, the ifIndex can be accessed indirectly
through the variable bindings.
I see SNMP_IPC_READ_ERROR messages when a restart occurs of the SNMP process
or my system , and also during Routing Engine switchover. Is this acceptable?
Yes, it is acceptable to see SNMP_IPC_READ_ERROR messages when the SNMP process
is restarted, the system reboots, or during a Routing Engine switchover. If all the processes
come up successfully and the SNMP operations are working properly, then these messages
can be ignored.
What is the source IP address used in the response PDUs for SNMP requests? Can this
be configured?
The source IP address used in the response PDUs for SNMP requests is the IP address
of the outgoing interface to reach the destination. The source IP address cannot be
configured for responses; it can only be configured for traps.
Related
Documentation
SNMP Traps and Informs Frequently Asked Questions

This section presents frequently asked questions and answers related to SNMP traps
and informs.
Does Junos OS impose any rate limiting on SNMP trap generation?
Junos OS implements a trap-queuing mechanism to limit the number of traps that are
generated and sent.
If a trap delivery fails, the trap is added back to the queue, and the delivery attempt
counter and the next delivery attempt timer for the queue are reset. Subsequent attempts
occur at progressive intervals of one, two, four, and eight minutes. The maximum delay
20
between the attempts is eight minutes, and the maximum number of attempts is ten.
After ten unsuccessful attempts, the destination queue and all traps in the queue are
deleted.
Junos OS also has a throttle threshold mechanism to control the number of traps sent
(default 500 traps) during a particular throttle interval (default five seconds). This helps
ensure consistency in trap traffic, especially when large amounts of traps are generated
due to interface status changes.
The throttle interval begins when the first trap arrives at the throttle. All traps within the
throttle threshold value are processed, and traps exceeding the threshold value are
queued. The maximum size of all trap queues (the throttle queue and the destination
queue) is 40k. The maximum size of any one queue is 20k. When a trap is added to the
throttle queue, or if the throttle queue has exceeded the maximum size, the trap is put
on top of the destination queue. Further attempts to send the trap from the destination
queue are stopped for a 30 second period, after which the destination queue restarts
sending the traps.
NOTE: For the EX Series Ethernet Switch, the maximum size of all trap queues
(the throttle queue and the destination queue) is 1k. The maximum size for
any one queue on the EX Series is 0.5k.
I did not see a trap when I had a syslog entry with a critical severity. Is this normal?
Can it be changed?
Not every syslog entry with critical severity is a trap; however, you can convert any syslog
entry to a trap using the event-options statement.
The following example shows how to configure a jnxSyslogTrap whenever an
rpd_ldp_nbrdown syslog entry message error occurs.
user@host> show event-options
policy snmptrap {
events rpd_ldp_nbrdown;
then {
raise-trap;
}
}
Are SNMP traps compliant with the Alarm Reporting Function (X.733) on Junos OS?
No, SNMP traps on Junos OS are not X.733 compliant.
Can I set up filters for traps or informs?
Traps and informs can be filtered based on the trap category and the object identifier.
You can specify categories of traps to receive per host by using the categories statement
at the [edit snmp trap-group trap-group] hierarchy level. Use this option when you want
to monitor only specific modules of Junos OS.
21
The following example shows a sample configuration for receiving only these traps: link,
vrrp-events, services, and otn-alarms:
[edit snmp]
trap-group jnpr {
categories {
link;
vrrp-events;
services;
otn-alarms;
}
targets {
192.168.69.179;
}
}
Junos OS also has a more advanced filter option (notify-filter) for filtering specific traps
or a group of traps based on their object identifiers.
The SNMPv3 configuration also supports filtering of SNMP version 1 and 2 traps and
excluding Juniper Networks enterprise-specific configuration management traps, as
shown in the following configuration example:
[edit snmp]
v3 {
vacm {
security-to-group {
security-model v2c {
security-name sn_v2c_trap {
group gr_v2c_trap;
}
}
}
access {
group gr_v2c_trap {
security-model v2c {
security-level none {
read-view all;
notify-view all;
}
}
}
}
}
}
target-address TA_v2c_trap {
address 10.209.196.166;
port 9001;
tag-list tg1;
target-parameters TP_v2c_trap;
}
target-parameters TP_v2c_trap {
parameters {
message-processing-model v2c;
security-model v2c;
22
security-level none;
security-name sn_v2c_trap;
}
notify-filter nf1;
}
notify v2c_notify {
type trap;
tag tg1;
}
notify-filter nf1 {
oid .1.3.6.1.4.1.2636.4.5 exclude;
oid .1 include;
}
snmp-community index1 {
community-name "$9$tDLl01h7Nbw2axN"; ## SECRET-DATA
security-name sn_v2c_trap;
tag tg1;
}
view all {
oid .1 include;
}
}
Can I simulate traps on a device?

Yes, you can use the request snmp spoof-trap trap name command for simulating a trap
to the NMS that normally receives your devices traps. You can also add required values
using the variable-bindings parameter.
The following example shows how to simulate a trap to the local NMS using variable
bindings:
user@host> request snmp spoof-trap linkDown variable-bindings "ifIndex[116]=116,
ifAdminStatus[116]=1 ,ifOperStatus[116]=2 , ifName[116]=ge-1/0/1"
How do I generate a warm start SNMPv1 trap?

When the SNMP process is restarted under normal conditions, a warm start trap is
generated if the system up time is more than five minutes. If the system up time is less
than five minutes, a cold start trap is generated.
The NMS sees only the MIB OIDs and numbers, but not the names of the SNMP traps.
Why?
Before the NMS can recognize the SNMP trap details, like the names of the traps, it must
first compile and understand the MIBs and then parse the MIB OIDs.
In Junos OS, how can I determine to which category a trap belongs?
For a list of common traps and their categories, see Juniper Networks Enterprise-Specific
SNMP Version 1 Traps and Juniper Networks Enterprise-Specific SNMP Version 2 Traps
in the Junos OS SNMP MIBs and Traps Reference.
23
Can I configure a trap to include the source IP address?

Yes, you can configure the source-address, routing-instance, or logical-instance name for
the source IP address using the trap-options command:
user@host> show snmp trap-options
source-address 10.1.1.1;
Can I create a custom trap?

Yes, you can use the jnxEventTrap event script to create customized traps as needed.
In the following example, a Junos OS operations (op) script is triggered when a
UI_COMMIT_NOT_CONFIRMED event is received. The Junos OS op script matches the
complete message of the event and generates an SNMP trap.
Example: Junos OS Op
Script
version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
param $event;
param $message;
match / {
/*
* trapm utilty wants the following characters in the value to be escaped
* '[', ']', ' ', '=', and ','
*/
var $event-escaped = {
call escape-string($text = $event, $vec = '[] =,');
}
var $message-escaped = {
call escape-string($text = $message, $vec = '[] =,');
}
<op-script-results> {
var $rpc = <request-snmp-generate-trap> {
<trap> "jnxEventTrap";
<variable-bindings> "jnxEventTrapDescr[0]='Event-Trap' , "
_ "jnxEventAvAttribute[1]='event' , "
_ "jnxEventAvValue[1]='" _ $event-escaped _ "' , "
_ "jnxEventAvAttribute[2]='message' , "
_ "jnxEventAvValue[1]='" _ $message-escaped _ "'";
}
var $res = jcs:invoke($rpc);
}
}
template escape-string ($text, $vec) {
if (jcs:empty($vec)) {
expr $text;
} else {
var $index = 1;
24
var $from = substring($vec, $index, 1);

var $changed-value = {
call replace-string($text, $from) {
with $to = {
expr "\\";
expr $from;
}
}
}
call escape-string($text = $changed-value, $vec = substring($vec, $index
+ 1));
}
}
template replace-string ($text, $from, $to) {
if (contains($text, $from)) {
var $before = substring-before($text, $from);
var $after = substring-after($text, $from);
var $prefix = $before _ $to;
expr $before;
expr $to;
call replace-string($text = $after, $from, $to);
} else {
expr $text;
}
}
After creating your customized trap, you must configure a policy on your router to tell the
router what actions to take after it receives the trap.
Here is an example of a configured policy under the [edit event-options] hierarchy:
[edit event-options]
user@host> show
policy trap-on-event {
events UI_COMMIT_NOT_CONFIRMED;
attributes-match {
UI_COMMIT_NOT_CONFIRMED.message matches complete;
}
then {
event-script ev-syslog-trap.junos-op {
arguments {
event UI_COMMIT_NOT_CONFIRMED;
message "{$$.message}";
}
}
}
}
Can I disable link up and link down traps on interfaces?

Yes, link up and link down traps can be disabled in the interface configuration. To disable
the traps, use the no-traps statement at the [edit interfaces interface-name unit
25
logical-unit-number] and [edit logical-systems logical-system-name interfaces

interface-name unit logical-unit-number] hierarchies for physical and logical interfaces.
(traps | no-traps);
I see the link up traps on logical interfaces, but I do not see the link down traps. Is this
normal behavior?
Junos OS does not send link down traps for a logical interface if the physical interface is
down to prevent flooding alarms for the same root cause. However, when the physical
interface and logical interfaces come back up, traps are sent indicating link up. This is
because the physical interface coming up does not necessarily mean the logical interfaces
are also coming up.
Related
Documentation

page 18
SNMP Support for Routing Instances Frequently Asked Questions

This section presents frequently asked questions and answers related to how SNMP
supports routing instances.
Can the SNMP manager access data for routing instances?
Yes, Junos OS enables SNMP managers for all routing instances to request and manage
SNMP data related to the corresponding routing instances and logical system networks.
Two different routing instance behaviors can occur, depending on where the clients
originate:
Clients from routing instances other than the default can access MIB objects and
perform SNMP operations only on the logical system networks to which they belong.
Clients from the default routing instance can access information related to all routing
instances and logical system networks.
Routing instances are identified by either the context field in SNMPv3 requests or encoded
in the community string in SNMPv1 or SNMPv2c requests.
When encoded in a community string, the routing instance name appears first and is
separated from the actual community string by the @ character.
To avoid conflicts with valid community strings that contain the @ character, the
community is parsed only if typical community string processing fails. For example, if a
26
routing instance named RI is configured, an SNMP request with RI@public is processed

within the context of the RI routing instance. Access control (including views, source
address restrictions, and access privileges) is applied according to the actual community
string (the set of data after the @ characterin this case public). However, if the
community string RI@public is configured, the PDU is processed according to that
community, and the embedded routing instance name is ignored.
Logical systems perform a subset of the actions of a physical router and have their own
unique routing tables, interfaces, policies, and routing instances. When a routing instance
is defined within a logical system, the logical system name must be encoded along with
the routing instance using a slash ( / ) to separate the two. For example, if the routing
instance RI is configured within the logical system LS, that routing instance must be
encoded within a community string as LS/RI@public. When a routing instance is configured
outside a logical system (within the default logical system), no logical system name, or
/ character, is needed.
Additionally, when a logical system is created, a default routing instance named default
is always created within the logical system. This name should be used when querying
data for that routing instance, for example LS/default@public. For SNMPv3 requests,
the name logical system/routing instance should be identified directly in the context field.
Can I access a list of all routing instances on a device?
Yes, you can access a list of all the routing instances on a device using the
vacmContextName object in the SNMP-VIEW-BASED-ACM MIB. In SNMP, each routing
instance becomes a VACM context; this is why the routing instances appear in the
vacmContextName object.
Can I access a default routing instance from a client in another logical router or routing
instance?
No, the SNMP agent can only access data of the logical router to which it is connected.
Related
Documentation

page 18
SNMP Counters Frequently Asked Questions

This section presents frequently asked questions and answers related to SNMP counters.
27
Which MIB should I use for interface counters?

Interface management over SNMP is based on two tables: the ifTable and its extension
the ifXTable. Both are described in RFC 1213, Management Information Base for Network
Management of TCP/IP-based internets: MIB-II and RFC 2233, The Interfaces Group MIB
using SMIv2.
Interfaces can have several layers, depending on the media, and each sub layer is
represented by a separate row in the table. The relationship between the higher layer
and lower layers is described in the ifStackTable.
The ifTable defines 32 bit counters for inbound and outbound octets
(ifInOctets/ifOutOctets), packets (ifInUcastPkts/ifOutUcastPkts, ifInNUcastPkts
/ifOutNUcastPkts), errors, and discards.
The ifXTable provides similar 64 bit counters, also called high capacity (HC) counters,
for inbound and outbound octets (ifHCInOctets/ifHCOutOctets) and inbound packets
(ifHCInUcastPkts).
When should 64 bit counters be used?
It is always good to use 64 bit counters because they contain statistics for both low and
high capacity components.
Are the SNMP counters ifInOctets and ifOutOctets the same as the command reference
show interfaces statistics in and out counters?
Yes, these are the same, but only if SNMP is enabled when the router boots up. If you
power on a Juniper Networks device and then enable SNMP, the SNMP counters start
from 0. SNMP counters do not automatically receive their statistics from the show
command output. Similarly, using the clear statistics show command does not clear the
statistics the SNMP counters collected, which can cause a discrepancy in the data that
is seen by both processes.
Do the SNMP counters ifInOctets and ifOutOctets include the framing overhead for
Point-to-Point Protocol (PPP) and High-Level Data Link Control (HDLC)?
Yes.
Related
Documentation
28
Junos OS SNMP Frequently Asked Questions Overview on page 1

page 18

SNMP On Junos Os Faq

Uploaded by

Copyright:

Available Formats

SNMP On Junos Os Faq

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SNMP On Junos Os Faq

Uploaded by

Copyright:

Available Formats

Technology Overview

SNMP on Junos OS Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

Juniper Networks, Inc.

Technology Overview SNMP on Junos OS Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

END USER LICENSE AGREEMENT

Copyright 2010, Juniper Networks, Inc.

Copyright 2010, Juniper Networks, Inc.

Copyright 2010, Juniper Networks, Inc.

Copyright 2010, Juniper Networks, Inc.

Copyright 2010, Juniper Networks, Inc.

SNMP on Junos OS Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

Junos OS SNMP Frequently Asked Questions Overview

Managed devices such as routers and switches.

Junos OS SNMP Frequently Asked Questions on page 3

Copyright 2010, Juniper Networks, Inc.

SNMP on Junos OS Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

Junos OS SNMP Frequently Asked Questions

Junos OS SNMP Support Frequently Asked Questions on page 3

Junos OS MIBs Frequently Asked Questions on page 4

Junos OS SNMP Configuration Frequently Asked Questions on page 12

SNMPv3 Frequently Asked Questions on page 16

SNMP Traps and Informs Frequently Asked Questions on page 20

SNMP Support for Routing Instances Frequently Asked Questions on page 26

SNMP Counters Frequently Asked Questions on page 27

Junos OS SNMP Support Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

SNMP on Junos OS Frequently Asked Questions

Does Junos OS support the view-based access control model (VACM)?

Junos OS MIBs Frequently Asked Questions on page 4

Junos OS SNMP Configuration Frequently Asked Questions on page 12

SNMP Counters Frequently Asked Questions on page 27

SNMP Interaction with Juniper Networks Devices Frequently Asked Questions on

SNMP Support for Routing Instances Frequently Asked Questions on page 26

SNMP Traps and Informs Frequently Asked Questions on page 20

SNMPv3 Frequently Asked Questions on page 16

Junos OS MIBs Frequently Asked Questions

Copyright 2010, Juniper Networks, Inc.

Junos OS SNMP Frequently Asked Questions

Do MIB files reside on Junos OS devices?

Load the files in the following order:

Copyright 2010, Juniper Networks, Inc.

SNMP on Junos OS Frequently Asked Questions

5. Load any remaining standard MIB files.

mib-jnx-exp.txt(Recommended) for Juniper Networks experimental MIB objects

mib-jnx-js-smi.txt(Optional) for Juniper Security MIB tree objects

mib-jnx-ex-smi.txt(Optional) for EX Series Ethernet Switches

Copyright 2010, Juniper Networks, Inc.

Junos OS SNMP Frequently Asked Questions

Which versions of SMI are supported by Junos OS?

Additions that reflect new operational requirements.

Backwards compatibility with the original MIBs and SNMP.

Improved support for multiprotocol entities.

Copyright 2010, Juniper Networks, Inc.

SNMP on Junos OS Frequently Asked Questions

What can I do if the MIB OID query is not responding?