Junos OS Network Management Admin Guide

Junos® OS
Network Management Administration Guide
Modified: 2017-03-14
Copyright © 2017, Juniper Networks, Inc.

Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
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.
®
Junos OS Network Management Administration Guide
Copyright © 2017, Juniper Networks, Inc.
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. 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.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
ii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Part 1 Overview
Chapter 1 Network Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Understanding Device Management Functions in Junos OS . . . . . . . . . . . . . . . . . . 3
Understanding the Integrated Local Management Interface . . . . . . . . . . . . . . . . . . 6
Chapter 2 Introduction to Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Diagnostic Tools Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
J-Web Diagnostic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
CLI Diagnostic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Part 2 Network Monitoring Using SNMP

Chapter 3 SNMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Understanding SNMP Implementation in Junos OS . . . . . . . . . . . . . . . . . . . . . . . . 13
SNMPv3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 4 SNMP MIBs and Traps Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . 19
Enterprise-Specific SNMP MIBs Supported by Junos OS . . . . . . . . . . . . . . . . . . . . 19
Standard SNMP MIBs Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Enterprise-Specific MIBs and Supported Devices . . . . . . . . . . . . . . . . . . . . . . . . . 47
Standard SNMP Traps Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Standard SNMP Version 1 Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Standard SNMP Version 2 Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Enterprise-Specific SNMP Traps Supported by Junos OS . . . . . . . . . . . . . . . . . . . 64
Juniper Networks Enterprise-Specific SNMP Version 1 Traps . . . . . . . . . . . . . 64
Juniper Networks Enterprise-Specific SNMP Version 2 Traps . . . . . . . . . . . . . 70
Copyright © 2017, Juniper Networks, Inc. iii

Chapter 5 Loading MIB Files to a Network Management System . . . . . . . . . . . . . . . . . . 79

Loading MIB Files to a Network Management System . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 6 Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Configuration Statements at the [edit snmp] Hierarchy Level . . . . . . . . . . . . . . . 84
Optimizing the Network Management System Configuration for the Best
Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Changing the Polling Method from Column-by-Column to Row-by-Row . . . 87
Reducing the Number of Variable Bindings per PDU . . . . . . . . . . . . . . . . . . . 88
Increasing Timeout Values in Polling and Discovery Intervals . . . . . . . . . . . . 88
Reducing Incoming Packet Rate at the snmpd . . . . . . . . . . . . . . . . . . . . . . . . 88
Configuring Options on Managed Devices for Better SNMP Response Time . . . . 88
Enabling the stats-cache-lifetime Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Filtering Out Duplicate SNMP Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Excluding Interfaces That Are Slow in Responding to SNMP Queries . . . . . . 89
Configuring SNMP on Devices Running Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . 90
Configuring Basic Settings for SNMPv1 and SNMPv2 . . . . . . . . . . . . . . . . . . . 91
Configuring Basic Settings for SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuring System Name, Location, Description, and Contact
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Configuring the System Contact on a Device Running Junos OS . . . . . . . . . . . . . . 94
Configuring the System Location for a Device Running Junos OS . . . . . . . . . . . . . 95
Configuring the System Description on a Device Running Junos OS . . . . . . . . . . . 95
Configuring SNMP Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Configuring a Different System Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Configuring the Commit Delay Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Filtering Duplicate SNMP Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuring SNMP Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Examples: Configuring the SNMP Community String . . . . . . . . . . . . . . . . . . . . . . 102
Adding a Group of Clients to an SNMP Community . . . . . . . . . . . . . . . . . . . . . . . 103
Configuring a Proxy SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configuring SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring SNMP Trap Options and Groups on a Device Running Junos OS . . . 107
Configuring SNMP Trap Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring the Source Address for SNMP Traps . . . . . . . . . . . . . . . . . . . . . 109
Configuring the Agent Address for SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . 111
Adding snmpTrapEnterprise Object Identifier to Standard SNMP Traps . . . . 111
Configuring SNMP Trap Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Example: Configuring SNMP Trap Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring the Interfaces on Which SNMP Requests Can Be Accepted . . . . . . . 114
Example: Configuring Secured Access List Checking . . . . . . . . . . . . . . . . . . . . . . . 115
Filtering Interface Information Out of SNMP Get and GetNext Output . . . . . . . . . 115
Configuring MIB Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Ping Proxy MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Chapter 7 Configuring SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Minimum SNMPv3 Configuration on a Device Running Junos OS . . . . . . . . . . . . . 122
Example: SNMPv3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configuring the Local Engine ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
iv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Creating SNMPv3 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Example: Creating SNMPv3 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring the SNMPv3 Authentication Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring SHA Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring No Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring the SNMPv3 Encryption Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring the Advanced Encryption Standard Algorithm . . . . . . . . . . . . . . 130
Configuring the Data Encryption Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Configuring Triple DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Configuring No Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Defining Access Privileges for an SNMP Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Configuring the Access Privileges Granted to a Group . . . . . . . . . . . . . . . . . . . . . 133
Configuring the Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Configuring the Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Configuring the Security Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Associating MIB Views with an SNMP User Group . . . . . . . . . . . . . . . . . . . . . 134
Configuring the Notify View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring the Read View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring the Write View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Example: Configuring the Access Privileges Granted to a Group . . . . . . . . . . . . . 136
Assigning Security Model and Security Name to a Group . . . . . . . . . . . . . . . . . . . 137
Configuring the Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Assigning Security Names to Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Configuring the Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Example: Security Group Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Configuring SNMPv3 Traps on a Device Running Junos OS . . . . . . . . . . . . . . . . . 139
Configuring the SNMPv3 Trap Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Example: Configuring SNMPv3 Trap Notification . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Configuring the Trap Notification Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Configuring the Trap Target Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Configuring the Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Configuring the Address Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Configuring the Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Configuring the Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Configuring the Trap Target Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Applying Target Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Example: Configuring the Tag List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Defining and Configuring the Trap Target Parameters . . . . . . . . . . . . . . . . . . . . . 146
Applying the Trap Notification Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the Target Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the Message Processing Model . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the Security Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configuring the Security Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configuring SNMP Informs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Configuring the Remote Engine and Remote User . . . . . . . . . . . . . . . . . . . . . . . . 150
Example: Configuring the Remote Engine ID and Remote User . . . . . . . . . . . . . . 151
Configuring the Inform Notification Type and Target Address . . . . . . . . . . . . . . . 154
Copyright © 2017, Juniper Networks, Inc. v

Example: Configuring the Inform Notification Type and Target Address . . . . . . . 155
Configuring the SNMPv3 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring the Community Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Configuring the Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Configuring the Security Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Configuring the Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Example: Configuring an SNMPv3 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 8 Configuring SNMP for Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Understanding SNMP Support for Routing Instances . . . . . . . . . . . . . . . . . . . . . . 159
SNMP MIBs Supported for Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Support Classes for MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
SNMP Traps Supported for Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Identifying a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Enabling SNMP Access over Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Specifying a Routing Instance in an SNMPv1 or SNMPv2c Community . . . . . . . . 173
Example: Configuring Interface Settings for a Routing Instance . . . . . . . . . . . . . . 174
Configuring Access Lists for SNMP Access over Routing Instances . . . . . . . . . . . 176
Chapter 9 Configuring SNMP Remote Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SNMP Remote Operations Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SNMP Remote Operation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Setting SNMP Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Example: Setting SNMP Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Setting Trap Notification for Remote Operations . . . . . . . . . . . . . . . . . . . . . . 179
Example: Setting Trap Notification for Remote Operations . . . . . . . . . . 179
Using Variable-Length String Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Example: Set Variable-Length String Indexes . . . . . . . . . . . . . . . . . . . . . 179
Enabling Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Using the Ping MIB for Remote Monitoring Devices Running Junos OS . . . . . . . . 180
Starting a Ping Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Using Multiple Set Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . . . . . . 181
Using a Single Set PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Monitoring a Running Ping Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
pingResultsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
pingProbeHistoryTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Generating Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Gathering Ping Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Stopping a Ping Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Interpreting Ping Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Using the Traceroute MIB for Remote Monitoring Devices Running Junos OS . . . 187
Starting a Traceroute Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Using Multiple Set PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Using a Single Set PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Monitoring a Running Traceroute Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
traceRouteResultsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
traceRouteProbeResultsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
traceRouteHopsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
vi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Generating Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Monitoring Traceroute Test Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Gathering Traceroute Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Stopping a Traceroute Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Interpreting Traceroute Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Chapter 10 Tracing SNMP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance
on a Device Running Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Checking for MIB Objects Registered with the snmpd . . . . . . . . . . . . . . . . . . 197
Tracking SNMP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Monitoring SNMP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Checking CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Checking Kernel and Packet Forwarding Engine Response . . . . . . . . . . . . . 202
Tracing SNMP Activity on a Device Running Junos OS . . . . . . . . . . . . . . . . . . . . . 203
Configuring the Number and Size of SNMP Log Files . . . . . . . . . . . . . . . . . . 204
Configuring Access to the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring a Regular Expression for Lines to Be Logged . . . . . . . . . . . . . . . 205
Configuring the Trace Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Example: Tracing SNMP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Chapter 11 SNMP FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Junos OS SNMP FAQ Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Junos OS SNMP FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Junos OS SNMP Support FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Junos OS MIBs FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Junos OS SNMP Configuration FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
SNMPv3 FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
SNMP Interaction with Juniper Networks Devices FAQs . . . . . . . . . . . . . . . . 224
SNMP Traps and Informs FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Junos OS Dual Routing Engine Configuration FAQs . . . . . . . . . . . . . . . . . . . . 232
SNMP Support for Routing Instances FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . 233
SNMP Counters FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Part 3 Remote Monitoring (RMON) with SNMP

Chapter 12 RMON Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Understanding RMON Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
alarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
jnxRmonAlarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Understanding RMON Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
eventTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Chapter 13 Configuring RMON Alarms and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Understanding RMON Alarms and Events Configuration . . . . . . . . . . . . . . . . . . . 243
Minimum RMON Alarm and Event Entry Configuration . . . . . . . . . . . . . . . . . . . . 244
Configuring an RMON Alarm Entry and Its Attributes . . . . . . . . . . . . . . . . . . . . . 244
Configuring the Alarm Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Configuring the Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Configuring the Falling Event Index or Rising Event Index . . . . . . . . . . . . . . . 245
Copyright © 2017, Juniper Networks, Inc. vii

Configuring the Falling Threshold or Rising Threshold . . . . . . . . . . . . . . . . . 246

Configuring the Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Configuring the Falling Threshold Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Configuring the Request Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Configuring the Sample Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Configuring the Startup Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Configuring the System Log Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Configuring the Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Configuring an RMON Event Entry and Its Attributes . . . . . . . . . . . . . . . . . . . . . . 248
Example: Configuring an RMON Alarm and Event Entry . . . . . . . . . . . . . . . . . . . 249
Chapter 14 Monitoring RMON Alarms and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Using alarmTable to Monitor MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Creating an Alarm Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Configuring the Alarm MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
alarmInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alarmVariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alarmSampleType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alarmValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alarmStartupAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alarmRisingThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
alarmFallingThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
alarmOwner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
alarmRisingEventIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
alarmFallingEventIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Activating a New Row in alarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Modifying an Active Row in alarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Deactivating a Row in alarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Using eventTable to Log Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Creating an Event Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Configuring the MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
eventType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
eventCommunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
eventOwner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
eventDescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Activating a New Row in eventTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Deactivating a Row in eventTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Chapter 15 Using RMON to Monitor Network Service Quality . . . . . . . . . . . . . . . . . . . . . 257
Understanding RMON for Monitoring Service Quality . . . . . . . . . . . . . . . . . . . . . 257
Setting Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
RMON Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
RMON Event Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
RMON Alarm Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Troubleshooting RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Understanding Measurement Points, Key Performance Indicators, and Baseline
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Measurement Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Basic Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Setting Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
viii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Defining and Measuring Network Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Defining Network Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Monitoring the SLA and the Required Bandwidth . . . . . . . . . . . . . . . . . 264
Measuring Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Real-Time Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Measuring Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Measuring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Measuring Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Inbound Firewall Filter Counters per Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Monitoring Output Bytes per Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Dropped Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Part 4 Health Monitoring with SNMP

Chapter 16 Configuring Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Configuring Health Monitoring on Devices Running Junos OS . . . . . . . . . . . . . . . 285
Monitored Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Minimum Health Monitoring Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Configuring the Falling Threshold or Rising Threshold . . . . . . . . . . . . . . . . . 287
Log Entries and Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Example: Configuring Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Part 5 Gathering Statistics for Accounting Purposes Using Accounting

Options, Source Class Usage and Destination Class Usage
Options
Chapter 17 Accounting Options, Source Class Usage and Destination Class Usage
Options Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Accounting Options Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Understanding Source Class Usage and Destination Class Usage Options . . . . 292
Chapter 18 Configuring Accounting Options, Source Class Usage and Destination
Class Usage Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Configuration Statements at the [edit accounting-options] Hierarchy Level . . . 295
Accounting Options Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Accounting Options—Full Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Minimum Accounting Options Configuration . . . . . . . . . . . . . . . . . . . . . . . . 300
Configuring Accounting-Data Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Configuring How Long Backup Files Are Retained . . . . . . . . . . . . . . . . . . . . 305
Configuring the Maximum Size of the File . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Configuring Archive Sites for the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Configuring Local Backup for Accounting Files . . . . . . . . . . . . . . . . . . . . . . . 306
Configuring Files to Be Compressed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Configuring the Maximum Number of Files . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Configuring the Storage Location of the File . . . . . . . . . . . . . . . . . . . . . . . . . 307
Configuring Files to Be Saved After a Change in Mastership . . . . . . . . . . . . 308
Configuring the Start Time for File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 308
Copyright © 2017, Juniper Networks, Inc. ix

Configuring the Transfer Interval of the File . . . . . . . . . . . . . . . . . . . . . . . . . 308

Configuring the Interface Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Configuring Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Configuring the File Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Configuring the Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Example: Configuring the Interface Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Configuring the Filter Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Configuring the Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Example: Configuring a Filter Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Example: Configuring Interface-Specific Firewall Counters and Filter Profiles . . 314
Configuring SCU or DCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Creating Prefix Route Filters in a Policy Statement . . . . . . . . . . . . . . . . . . . . 316
Applying the Policy to the Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . 316
Enabling Accounting on Inbound and Outbound Interfaces . . . . . . . . . . . . . 316
Configuring SCU on a Virtual Loopback Tunnel Interface . . . . . . . . . . . . . . . . . . . 318
Example: Configuring a Virtual Loopback Tunnel Interface on a Provider
Edge Router Equipped with a Tunnel PIC . . . . . . . . . . . . . . . . . . . . . . . . 318
Example: Mapping the VRF Instance Type to the Virtual Loopback Tunnel
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Example: Sending Traffic Received from the Virtual Loopback Interface Out
the Source Class Output Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Configuring Class Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Configuring a Class Usage Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Creating a Class Usage Profile to Collect Source Class Usage Statistics . . . 320
Creating a Class Usage Profile to Collect Destination Class Usage
Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Configuring the MIB Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Configuring the MIB Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Configuring MIB Object Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Example: Configuring a MIB Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Configuring the Routing Engine Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Configuring Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Example: Configuring a Routing Engine Profile . . . . . . . . . . . . . . . . . . . . . . . 325
Part 6 Configuring Monitoring Options

Chapter 19 Configuring Interface Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Alarm Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Alarm Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Alarm Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
x Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Alarm Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Interface Alarm Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
System Alarm Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Example: Configuring Interface Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Monitoring Active Alarms on a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Monitoring Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Chapter 20 Using RPM to Measure Network Performance . . . . . . . . . . . . . . . . . . . . . . . . 341
RPM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
RPM Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Probe and Test Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Jitter Measurement with Hardware Timestamping . . . . . . . . . . . . . . . . . . . . 343
RPM Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
RPM Thresholds and Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
RPM for BGP Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
IPv6 RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Guidelines for Configuring RPM Probes for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 345
RPM Support for VPN Routing and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Example: Configuring Basic RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Example: Configuring RPM Using TCP and UDP Probes . . . . . . . . . . . . . . . . . . . . 351
Example: Configuring RPM Probes for BGP Monitoring . . . . . . . . . . . . . . . . . . . . 354
Directing RPM Probes to Select BGP Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Configuring IPv6 RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Tuning RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
RPM Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Monitoring RPM Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Chapter 21 Configuring IP Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
IP Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Understanding IP Monitoring Test Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Example: Configuring IP Monitoring on SRX Series Devices . . . . . . . . . . . . . . . . 369
Understanding IP Monitoring Through Redundant Ethernet Interface Link
Aggregation Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Example: Configuring IP Monitoring on SRX Series Devices . . . . . . . . . . . . . . . . . 372
Example: Configuring Chassis Cluster Redundancy Group IP Address
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Part 7 Monitoring Common Security Features

Chapter 22 Displaying Real-Time Information from Device to Host . . . . . . . . . . . . . . . 383
Displaying Real-Time Monitoring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Displaying Multicast Path Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Chapter 23 Monitoring Application Layer Gateways Features . . . . . . . . . . . . . . . . . . . . 389
Monitoring H.323 ALG Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Monitoring MGCP ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Monitoring MGCP ALG Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Monitoring MGCP ALG Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Copyright © 2017, Juniper Networks, Inc. xi

Monitoring MGCP ALG Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Monitoring SCCP ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Monitoring SCCP ALG Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Monitoring SCCP ALG Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Monitoring SIP ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Monitoring SIP ALG Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Monitoring SIP ALG Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Monitoring SIP ALG Rate Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Monitoring SIP ALG Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Monitoring Voice ALG H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Monitoring Voice ALG MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Monitoring Voice ALG SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Monitoring Voice ALG SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Monitoring Voice ALG Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Chapter 24 Monitoring Interfaces and Switching Functions . . . . . . . . . . . . . . . . . . . . . . 415
Displaying Real-Time Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Monitoring Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Monitoring Ethernet Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Monitoring GVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Monitoring MPLS Traffic Engineering Information . . . . . . . . . . . . . . . . . . . . . . . . . 421
Monitoring MPLS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Monitoring MPLS LSP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Monitoring MPLS LSP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Monitoring RSVP Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Monitoring MPLS RSVP Interfaces Information . . . . . . . . . . . . . . . . . . . . . . . 426
Monitoring PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Monitoring PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Monitoring Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Monitoring the WAN Acceleration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Chapter 25 Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Monitoring Source NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Monitoring Destination NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Monitoring Static NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Monitoring Incoming Table Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Monitoring Interface NAT Port Information . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Chapter 26 Monitoring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Monitoring Policy Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Monitoring Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Monitoring Route Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Monitoring RIP Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Monitoring OSPF Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
xii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Monitoring BGP Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Monitoring Security Events by Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Monitoring Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Monitoring Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Checking Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Monitoring Screen Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Monitoring IDP Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Monitoring Flow Gate Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Monitoring Firewall Authentication Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Monitoring Firewall Authentication History . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Monitoring 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Chapter 27 Monitoring Events, Services and System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Monitoring DHCP Client Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Monitoring Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Monitoring the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Monitoring System Properties for SRX Series Devices . . . . . . . . . . . . . . . . . 474
Monitoring Chassis Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
System Health Management for SRX Series Devices . . . . . . . . . . . . . . . . . . 478
Chapter 28 Monitoring Unified Threat Management Features . . . . . . . . . . . . . . . . . . . . 481
Monitoring Antivirus Scan Engine Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Monitoring Antivirus Scan Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Monitoring Antivirus Session Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Monitoring Content Filtering Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Monitoring Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Threats Monitoring Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Traffic Monitoring Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Monitoring Web Filtering Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Chapter 29 Monitoring VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Monitoring VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Monitoring IKE Gateway Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Monitoring IPsec VPN—Phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Monitoring IPsec VPN—Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Monitoring IPsec VPN Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Copyright © 2017, Juniper Networks, Inc. xiii

Part 8 Resource Monitoring of Memory Regions and Types Using CLI

and SNMP Queries
Chapter 30 Effective Troubleshooting of System Performance With Resource
Monitoring Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Resource Monitoring Usage Computation Overview . . . . . . . . . . . . . . . . . . . . . . 509
Resource Monitoring and Usage Computation For Trio-Based Line
Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Resource Monitoring and Usage Computation For I-Chip-Based Line
Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Resource Monitoring Mechanism on MX Series Routers Overview . . . . . . . . . . . . 512
Examining the Utilization of Memory Resource Regions Using show
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Diagnosing and Debugging System Performance By Configuring Memory
Resource Usage Monitoring on MX Series Routers . . . . . . . . . . . . . . . . . . . . . 515
Troubleshooting the Mismatch of jnxNatObjects Values for MS-DPC and
MS-MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Managed Objects for Ukernel Memory for a Packet Forwarding Engine in an FPC
Slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Managed Objects for Packet Forwarding Engine Memory Statistics Data . . . . . . 519
Managed Objects for Next-Hop, Jtree, and Firewall Filter Memory for a Packet
Forwarding Engine in an FPC Slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
jnxPfeMemoryErrorsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
pfeMemoryErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Part 9 Troubleshooting
Chapter 31 Configuring Data Path Debugging and Trace Options . . . . . . . . . . . . . . . . . 523
Understanding Data Path Debugging for SRX Series Devices . . . . . . . . . . . . . . . 523
Debugging the Data Path (CLI Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Example: Configuring End-to-End Debugging on SRX Series Device . . . . . . . . . 525
Understanding Security Debugging Using Trace Options . . . . . . . . . . . . . . . . . . 530
Setting Security Trace Options (CLI Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . 530
Displaying Log and Trace Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Displaying Output for Security Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Displaying Multicast Trace Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Using the J-Web Traceroute Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
J-Web Traceroute Results and Output Summary . . . . . . . . . . . . . . . . . . . . . . . . . 535
Understanding Flow Debugging Using Trace Options . . . . . . . . . . . . . . . . . . . . . 536
Setting Flow Debugging Trace Options (CLI Procedure) . . . . . . . . . . . . . . . . . . . 537
Displaying a List of Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Chapter 32 Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits . . . . . . . . . . . . . 541
MPLS Connection Checking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Understanding Ping MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
MPLS Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Loopback Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
xiv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Source Address for Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Using the ping Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Using the J-Web Ping Host Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
J-Web Ping Host Results and Output Summary . . . . . . . . . . . . . . . . . . . . . . . . . 548
Using the J-Web Ping MPLS Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
J-Web Ping MPLS Results and Output Summary . . . . . . . . . . . . . . . . . . . . . . . . . 552
Pinging Layer 2 Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Pinging Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Pinging Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Pinging RSVP-Signaled LSPs and LDP-Signaled LSPs . . . . . . . . . . . . . . . . . . . . 557
Chapter 33 Using Packet Capture to Analyze Network Traffic . . . . . . . . . . . . . . . . . . . . 559
Packet Capture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Packet Capture on Device Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Firewall Filters for Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Packet Capture Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Analysis of Packet Capture Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Example: Enabling Packet Capture on a Device . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Example: Configuring Packet Capture on an Interface . . . . . . . . . . . . . . . . . . . . . 565
Example: Configuring a Firewall Filter for Packet Capture . . . . . . . . . . . . . . . . . . 567
Example: Configuring Packet Capture for Datapath Debugging . . . . . . . . . . . . . 569
Disabling Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Deleting Packet Capture Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Changing Encapsulation on Interfaces with Packet Capture Configured . . . . . . 574
Displaying Packet Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Using the J-Web Packet Capture Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
J-Web Packet Capture Results and Output Summary . . . . . . . . . . . . . . . . . . . . . 582
Chapter 34 Troubleshooting Security Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Recovering the Root Password for SRX Series Devices . . . . . . . . . . . . . . . . . . . . 585
Troubleshooting DNS Name Resolution in Logical System Security Policies
(Master Administrators Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Troubleshooting the Link Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Determine Which CoS Components Are Applied to the Constituent
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Determine What Causes Jitter and Latency on the Multilink Bundle . . . . . . 589
Determine If LFI and Load Balancing Are Working Correctly . . . . . . . . . . . . 590
Determine Why Packets Are Dropped on a PVC Between a Juniper Networks
Device and a Third-Party Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Troubleshooting Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Synchronizing Policies Between Routing Engine and Packet Forwarding
Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Checking a Security Policy Commit Failure . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Verifying a Security Policy Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Debugging Policy Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Understanding Log Error Messages for Troubleshooting ISSU-Related
Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Chassisd Process Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Kernel State Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Installation-Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Copyright © 2017, Juniper Networks, Inc. xv

ISSU Support-Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600

Redundancy Group Failover Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Initial Validation Checks Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Understanding Common Error Handling for ISSU . . . . . . . . . . . . . . . . . . . . . 601
Part 10 Configuration Statements and Operational Commands

Chapter 35 Configuration Statements: Accounting Options, Source Class Usage and
Destination Class Usage Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
accounting-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
archive-sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
backup-on-failure (Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
class-usage-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
cleanup-interval (Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
compress (Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
destination-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
egress-stats (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
fields (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
fields (for Interface Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
fields (for Routing Engine Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
file (Associating with a Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
file (Configuring a Log File) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
file (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
filter-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
flat-file-profile (Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
format (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
general-param (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . 627
ingress-stats (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
interface-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
interval (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
l2-stats (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
mib-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
mpls (Security Forwarding Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
nonpersistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
object-names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
overall-packet (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . 638
push-backup-to-master (Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . 639
routing-engine-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
schema-version (Flat-File Accounting Options) . . . . . . . . . . . . . . . . . . . . . . . . . . 641
size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
source-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
start-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
traceoptions (System Accounting) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
transfer-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
xvi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Chapter 36 Configuration Statements: Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 647

cluster (Chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
global-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
global-weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
ip-monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
ip-monitoring (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Chapter 37 Configuration Statements: Datapath Debug . . . . . . . . . . . . . . . . . . . . . . . . 655
action-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
capture-file (Security) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
datapath-debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
flow (Security Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
icmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
maximum-capture-size (Datapath Debug) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
traceoptions (Security Datapath Debug) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Chapter 38 Configuration Statements: Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . 665
falling-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
health-monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
idp (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
rising-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Chapter 39 Configuration Statements: Remote Monitoring (RMON) . . . . . . . . . . . . . . 671
alarm (SNMP RMON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
falling-event-index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
falling-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
falling-threshold-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
request-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
rising-event-index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
rising-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
rmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
sample-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
startup-alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
syslog-subtag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Chapter 40 Configuration Statements: Resource Monitoring for Memory Regions . . 687
free-fw-memory-watermark (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . 687
free-heap-memory-watermark (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . 688
free-nh-memory-watermark (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . 689
high-threshold (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
no-logging (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
resource-category jtree (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Copyright © 2017, Juniper Networks, Inc. xvii

resource-monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
traceoptions (Resource Monitor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Chapter 41 Configuration Statements: Security Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 695
decryption-failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
idp (Security Alarms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Chapter 42 Configuration Statements: SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
access-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
agent-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
alarm-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
alarm-list-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
alarm-management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
alarm-state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
client-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
client-list-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
commit-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
community (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
contact (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
destination-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
enterprise-oid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
filter-duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
filter-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
interface (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
location (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
logical-system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
logical-system-trap-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
nonvolatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
oid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
proxy (snmp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
routing-instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
routing-instance-access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
snmp-value-match-msmic (Services NAT Options) . . . . . . . . . . . . . . . . . . . . . . 720
source-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
traceoptions (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
trap-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
trap-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
version (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
view (Associating a MIB View with a Community) . . . . . . . . . . . . . . . . . . . . . . . . 726
view (Configuring a MIB View) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
xviii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Chapter 43 Configuration Statements: SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
address-mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
authentication-md5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
authentication-none . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
authentication-password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
authentication-sha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
community-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
context (SNMPv3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
engine-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
group (Configuring Group Name) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
group (Defining Access Privileges for an SNMPv3 Group) . . . . . . . . . . . . . . . . . . 740
retry-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
local-engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
message-processing-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
notify-filter (Applying to the Management Target) . . . . . . . . . . . . . . . . . . . . . . . 745
notify-filter (Configuring the Profile Name) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
notify-view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
oid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
privacy-3des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
privacy-aes128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
privacy-des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
privacy-none . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
privacy-password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
read-view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
remote-engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
routing-instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
security-level (Defining Access Privileges) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
security-level (Generating SNMP Notifications) . . . . . . . . . . . . . . . . . . . . . . . . . 758
security-model (Access Privileges) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
security-model (Group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
security-model (SNMP Notifications) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
security-name (Community String) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
security-name (Security Group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
security-name (SNMP Notifications) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
security-to-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
snmp-community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
tag-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
target-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
target-parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
usm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Copyright © 2017, Juniper Networks, Inc. xix

vacm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
write-view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Chapter 44 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
clear chassis cluster ip-monitoring failure-count . . . . . . . . . . . . . . . . . . . . . . . . . 779
clear chassis cluster ip-monitoring failure-count ip-address . . . . . . . . . . . . . . . . 780
clear ilmi statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
clear snmp history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
clear snmp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
request pppoe connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
request pppoe disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
request services ip-monitoring preempt-restore policy . . . . . . . . . . . . . . . . . . . . 787
request snmp spoof-trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
show chassis alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
show chassis cluster ip-monitoring status redundancy-group . . . . . . . . . . . . . . 796
show interfaces (SRX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
show interfaces snmp-index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
show interfaces summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
show ilmi statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
show security alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
show security datapath-debug capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
show security datapath-debug counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
show security monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
show security monitoring fpc fpc-number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
show security monitoring performance session . . . . . . . . . . . . . . . . . . . . . . . . . . 847
show security monitoring performance spu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
show services ip-monitoring status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
show snmp health-monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
show snmp inform-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
show snmp mib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
show snmp rmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
show snmp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
show snmp stats-response-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
show snmp v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
show system alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
show system resource-monitor fpc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
xx Copyright © 2017, Juniper Networks, Inc.

List of Figures
Figure 1: Inform Request and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 2: SNMP Data for Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Figure 3: Setting Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Figure 4: Network Entry Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Figure 5: Regional Points of Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Figure 6: Measurements to Each Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Figure 7: Network Behavior During Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Figure 8: Sample RPM Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Figure 9: IP Monitoring on an SRX Series Device Topology Example . . . . . . . . . . 373
Figure 10: PPP and MLPPP Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Copyright © 2017, Juniper Networks, Inc. xxi

xxii Copyright © 2017, Juniper Networks, Inc.

List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Part 1 Overview
Chapter 1 Network Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 3: Device Management Features in Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 2 Introduction to Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 4: J-Web Interface Troubleshoot Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 5: CLI Diagnostic Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 4 SNMP MIBs and Traps Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 6: Enterprise-specific MIBs supported by Junos OS . . . . . . . . . . . . . . . . . . . 19
Table 7: Standard MIBs supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 8: Enterprise-Specific MIBs and Supported Devices . . . . . . . . . . . . . . . . . . 47
Table 9: Standard Supported SNMP Version 1 Traps . . . . . . . . . . . . . . . . . . . . . . . 57
Table 10: Standard Supported SNMP Version 2 Traps . . . . . . . . . . . . . . . . . . . . . . 60
Table 11: Juniper Networks Enterprise-Specific Supported SNMP Version 1
Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 12: Juniper Networks Enterprise-Specific Supported SNMP Version 2
Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 13: Values to Use in Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Table 14: MIB Support for Routing Instances (Juniper Networks MIBs) . . . . . . . . 160
Table 15: Class 1 MIB Objects (Standard and Juniper MIBs) . . . . . . . . . . . . . . . . . 164
Table 16: Class 2 MIB Objects (Standard and Juniper MIBs) . . . . . . . . . . . . . . . . 168
Table 17: Class 3 MIB Objects (Standard and Juniper MIBs) . . . . . . . . . . . . . . . . . 169
Table 18: Class 4 MIB Objects (Standard and Juniper MIBs) . . . . . . . . . . . . . . . . 170
Chapter 9 Configuring SNMP Remote Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Table 19: Results in pingProbeHistoryTable: After the First Ping Test . . . . . . . . . . 185
Table 20: Results in pingProbeHistoryTable: After the First Probe of the Second
Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 21: Results in pingProbeHistoryTable: After the Second Ping Test . . . . . . . 186
Table 22: traceRouteProbeHistoryTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Copyright © 2017, Juniper Networks, Inc. xxiii

Chapter 10 Tracing SNMP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Table 23: SNMP Tracing Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Chapter 11 SNMP FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 24: Monitored Object Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Table 25: RMON Event Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Table 26: RMON Alarm Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Table 27: jnxRmon Alarm Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Table 28: Real-Time Performance Monitoring Configuration Options . . . . . . . . 266
Table 29: Health Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Table 30: Counter Values for vlan-ccc Encapsulation . . . . . . . . . . . . . . . . . . . . . 274
Table 31: Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Table 32: Inbound Traffic Per Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Table 33: Inbound Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Table 34: Outbound Counters for ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 279
Table 35: Outbound Counters for Non-ATM Interfaces . . . . . . . . . . . . . . . . . . . . 280
Table 36: Dropped Traffic Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Part 4 Health Monitoring with SNMP

Chapter 16 Configuring Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Table 37: Monitored Object Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Part 5 Gathering Statistics for Accounting Purposes Using Accounting

Options, Source Class Usage and Destination Class Usage
Options
Chapter 17 Accounting Options, Source Class Usage and Destination Class Usage
Options Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Table 38: Types of Accounting Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Chapter 19 Configuring Interface Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Table 39: Interface Alarm Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Table 40: System Alarm Conditions and Corrective Actions . . . . . . . . . . . . . . . . 334
Table 41: Alarms Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Table 42: RPM Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Table 43: RPM Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Table 44: Summary of Key RPM Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Table 45: Test Parameters and Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Table 46: Threshold Supported and Description . . . . . . . . . . . . . . . . . . . . . . . . . 369
xxiv Copyright © 2017, Juniper Networks, Inc.

List of Tables
Part 7 Monitoring Common Security Features

Chapter 22 Displaying Real-Time Information from Device to Host . . . . . . . . . . . . . . . 383
Table 47: CLI traceroute monitor Command Options . . . . . . . . . . . . . . . . . . . . . . 383
Table 48: CLI traceroute monitor Command Output Summary . . . . . . . . . . . . . 384
Table 49: CLI mtrace from-source Command Options . . . . . . . . . . . . . . . . . . . . 385
Table 50: CLI mtrace from-source Command Output Summary . . . . . . . . . . . . 387
Chapter 23 Monitoring Application Layer Gateways Features . . . . . . . . . . . . . . . . . . . . 389
Table 51: Summary of Key H.323 Counters Output Fields . . . . . . . . . . . . . . . . . . 389
Table 52: Summary of Key MGCP Calls Output Fields . . . . . . . . . . . . . . . . . . . . . 391
Table 53: Summary of Key MGCP Counters Output Fields . . . . . . . . . . . . . . . . . 392
Table 54: Summary of Key MGCP Endpoints Output Fields . . . . . . . . . . . . . . . . 393
Table 55: Summary of Key SCCP Calls Output Fields . . . . . . . . . . . . . . . . . . . . . 394
Table 56: Summary of Key SCCP Counters Output Fields . . . . . . . . . . . . . . . . . . 394
Table 57: Summary of Key SIP Calls Output Fields . . . . . . . . . . . . . . . . . . . . . . . 396
Table 58: Summary of Key SIP Counters Output Fields . . . . . . . . . . . . . . . . . . . . 397
Table 59: Summary of Key SIP Rate Output Fields . . . . . . . . . . . . . . . . . . . . . . . 399
Table 60: Summary of Key SIP Transactions Output Fields . . . . . . . . . . . . . . . . 400
Table 61: ALG H.323 Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Table 62: Voice ALG MGCP Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Table 63: Voice ALG SCCP Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Table 64: Voice ALG SIP Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Table 65: Voice ALG Summary Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Chapter 24 Monitoring Interfaces and Switching Functions . . . . . . . . . . . . . . . . . . . . . . 415
Table 66: CLI monitor interface Output Control Keys . . . . . . . . . . . . . . . . . . . . . . 416
Table 67: CLI monitor interface traffic Output Control Keys . . . . . . . . . . . . . . . . . 416
Table 68: Address Pools Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Table 69: Summary of Ethernet Switching Output Fields . . . . . . . . . . . . . . . . . . 419
Table 70: GVRP Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Table 71: Summary of Key MPLS Interface Information Output Fields . . . . . . . . 422
Table 72: Summary of Key MPLS LSP Information Output Fields . . . . . . . . . . . . 422
Table 73: Summary of Key MPLS LSP Statistics Output Fields . . . . . . . . . . . . . . 424
Table 74: Summary of Key RSVP Session Information Output Fields . . . . . . . . . 425
Table 75: Summary of Key RSVP Interfaces Information Output Fields . . . . . . . 426
Table 76: Summary of Key PPPoE Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 428
Table 77: Spanning Tree Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Chapter 25 Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Table 78: Source NAT Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Table 79: Summary of Key Destination NAT Output Fields . . . . . . . . . . . . . . . . . 439
Table 80: Summary of Key Static NAT Output Fields . . . . . . . . . . . . . . . . . . . . . . 441
Table 81: Summary of Key Incoming Table Output Fields . . . . . . . . . . . . . . . . . . 443
Table 82: Summary of Key Interface NAT Output Fields . . . . . . . . . . . . . . . . . . . 443
Chapter 26 Monitoring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Table 83: Filtering Route Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Table 84: Summary of Key Routing Information Output Fields . . . . . . . . . . . . . . 447
Table 85: Summary of Key RIP Routing Output Fields . . . . . . . . . . . . . . . . . . . . . 448
Table 86: Summary of Key OSPF Routing Output Fields . . . . . . . . . . . . . . . . . . 450
Copyright © 2017, Juniper Networks, Inc. xxv

Table 87: Summary of Key BGP Routing Output Fields . . . . . . . . . . . . . . . . . . . . 452

Table 88: View Policy Log Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Table 89: Policy Events Detail Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Table 90: Security Policies Monitoring Output Fields . . . . . . . . . . . . . . . . . . . . . 456
Table 91: Check Policies Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Table 92: Summary of Key Screen Counters Output Fields . . . . . . . . . . . . . . . . . 461
Table 93: Summary of IDP Status Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 464
Table 94: Summary of Key Flow Gate Output Fields . . . . . . . . . . . . . . . . . . . . . . 465
Table 95: Summary of Key Firewall Authentication Table Output Fields . . . . . . 466
Table 96: Summary of Key Firewall Authentication History Output Fields . . . . . 467
Table 97: Summary of Dot1X Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Chapter 27 Monitoring Events, Services and System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Table 98: Summary of Key DHCP Client Binding Output Fields . . . . . . . . . . . . . . 471
Table 99: Events Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 28 Monitoring Unified Threat Management Features . . . . . . . . . . . . . . . . . . . . 481
Table 100: Statistics Tab Output in the Threats Report . . . . . . . . . . . . . . . . . . . . 487
Table 101: Activities Tab Output in the Threats Report . . . . . . . . . . . . . . . . . . . . 489
Table 102: Traffic Report Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Chapter 29 Monitoring VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Table 103: Summary of Key IKE SA Information Output Fields . . . . . . . . . . . . . . 495
Table 104: IPsec VPN—Phase I Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . 499
Table 105: IPsec VPN—Phase II Monitoring Page . . . . . . . . . . . . . . . . . . . . . . . . . 500
Table 106: Summary of Key IPsec VPN Information Output Fields . . . . . . . . . . . 502
Part 8 Resource Monitoring of Memory Regions and Types Using CLI

and SNMP Queries
Chapter 30 Effective Troubleshooting of System Performance With Resource
Monitoring Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Table 107: jnxPfeMemoryUKernTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Table 108: jnxPfeMemory Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Table 109: jnxPfeMemoryForwardingTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Table 110: jnxPfeMemoryErrorsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Table 111: pfeMemoryErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Chapter 31 Configuring Data Path Debugging and Trace Options . . . . . . . . . . . . . . . . . 523
Table 112: CLI mtrace monitor Command Output Summary . . . . . . . . . . . . . . . . 533
Table 113: Traceroute Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Table 114: J-Web Traceroute Results and Output Summary . . . . . . . . . . . . . . . . 535
Table 115: CLI traceroute Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Chapter 32 Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits . . . . . . . . . . . . . 541
Table 116: Options for Checking MPLS Connections . . . . . . . . . . . . . . . . . . . . . . . 542
Table 117: CLI ping Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Table 118: J-Web Ping Host Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Table 119: Ping Host Results and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
xxvi Copyright © 2017, Juniper Networks, Inc.

List of Tables
Table 120: J-Web Ping MPLS Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Table 121: J-Web Ping MPLS Results and Output Summary . . . . . . . . . . . . . . . . . 552
Table 122: CLI ping mpls l2circuit Command Options . . . . . . . . . . . . . . . . . . . . . 553
Table 123: CLI ping mpls l2vpn Command Options . . . . . . . . . . . . . . . . . . . . . . . 554
Table 124: CLI ping mpls l3vpn Command Options . . . . . . . . . . . . . . . . . . . . . . . 556
Table 125: CLI ping mpls ldp and ping mpls lsp-end-point Command Options . . 557
Chapter 33 Using Packet Capture to Analyze Network Traffic . . . . . . . . . . . . . . . . . . . . 559
Table 126: CLI monitor traffic Command Options . . . . . . . . . . . . . . . . . . . . . . . . . 575
Table 127: CLI monitor traffic Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Table 128: CLI monitor traffic Logical Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Table 129: CLI monitor traffic Arithmetic, Binary, and Relational Operators . . . . 578
Table 130: Packet Capture Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Table 131: J-Web Packet Capture Results and Output Summary . . . . . . . . . . . . . 582
Table 132: CoS Components Applied on Multilink Bundles and Constituent
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Table 133: PPP and MLPPP Encapsulation Overhead . . . . . . . . . . . . . . . . . . . . . 592
Table 134: Number of Packets Transmitted on a Queue . . . . . . . . . . . . . . . . . . . 595
Table 135: ISSU-Related Errors and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Part 10 Configuration Statements and Operational Commands

Chapter 44 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Table 136: show chassis alarms Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Table 137: show chassis cluster ip-monitoring status Output Fields . . . . . . . . . . 796
Table 138: show chassis cluster ip-monitoring status redundancy group Reason
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Table 139: show interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Table 140: show interfaces summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . 831
Table 141: show ilmi statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Table 142: show security alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Table 143: show security monitoring fpc fpc-number Output Fields . . . . . . . . . . 844
Table 144: show services ip-monitoring status Output Fields . . . . . . . . . . . . . . . 850
Table 145: show snmp health-monitor Output Fields . . . . . . . . . . . . . . . . . . . . . 854
Table 146: show snmp inform-statistics Output Fields . . . . . . . . . . . . . . . . . . . . 861
Table 147: show snmp mib Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Table 148: show snmp rmon Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Table 149: show snmp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Table 150: show snmp statistics subagents Output Fields . . . . . . . . . . . . . . . . . 874
Table 151: show snmp stats-response-statistics Output Fields . . . . . . . . . . . . . . 878
Table 152: show snmp v3 Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Table 153: show system resource-monitor fpc Output Fields . . . . . . . . . . . . . . . 885
Copyright © 2017, Juniper Networks, Inc. xxvii

xxviii Copyright © 2017, Juniper Networks, Inc.

About the Documentation
• Documentation and Release Notes on page xxix

• Supported Platforms on page xxix
• Using the Examples in This Manual on page xxx
• Documentation Conventions on page xxxi
• Documentation Feedback on page xxxiii
• Requesting Technical Support on page xxxiv
Documentation and 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/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
• ACX Series
• M Series
• MX Series
• T Series
• PTX Series
• SRX Series
• vSRX
• QFX Series
• EX Series
Copyright © 2017, Juniper Networks, Inc. xxix

Using the Examples in This Manual
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. The example does not become
active until you commit the candidate configuration.
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. 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

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 the following 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
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
xxx Copyright © 2017, Juniper Networks, Inc.

Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see CLI Explorer.
Documentation Conventions
Table 1 on page xxxii defines notice icons used in this guide.
Copyright © 2017, Juniper Networks, Inc. xxxi

Table 1: Notice Icons

Icon Meaning Description
Informational note Indicates important features or instructions.
Caution Indicates a situation that might result in loss of data or hardware damage.
Warning Alerts you to the risk of personal injury or death.
Laser warning Alerts you to the risk of personal injury from a laser.
Tip Indicates helpful information.
Best practice Alerts you to a recommended use or implementation.
Table 2 on page xxxii defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions

Convention Description Examples
Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:
user@host> configure
Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen.
No alarms currently active
Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.
• Junos OS CLI User Guide
• Identifies RFC and Internet draft titles.
• RFC 1997, BGP Communities Attribute
Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name
xxxii Copyright © 2017, Juniper Networks, Inc.

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples
Text like this Represents names of configuration • To configure a stub area, include the
statements, commands, files, and stub statement at the [edit protocols
directories; configuration hierarchy levels; ospf area area-id] hierarchy level.
or labels on routing platform • The console port is labeled CONSOLE.
components.
< > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>;
| (pipe symbol) Indicates a choice between the mutually broadcast | multicast

exclusive keywords or variables on either
side of the symbol. The set of choices is (string1 | string2 | string3)
often enclosed in parentheses for clarity.
# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.
[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]
Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
route default {
; (semicolon) Identifies a leaf statement at a
nexthop address;
configuration hierarchy level.
retain;
}
}
}
GUI Conventions
Bold text like this Represents graphical user interface (GUI) • In the Logical Interfaces box, select
items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.
> (bold right angle bracket) Separates levels in a hierarchy of menu In the configuration editor hierarchy,
selections. select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can provide feedback by using either of the following
methods:
• Online feedback rating system—On any page of the Juniper Networks TechLibrary site
at http://www.juniper.net/techpubs/index.html, simply click the stars to rate the content,
and use the pop-up form to provide us with information about your experience.
Alternately, you can use the online feedback form at
http://www.juniper.net/techpubs/feedback/.
Copyright © 2017, Juniper Networks, Inc. xxxiii

• E-mail—Send your comments to techpubs-comments@juniper.net. Include the document

or topic name, URL or page number, and software version (if applicable).
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or Partner Support Service
support contract, or are covered under warranty, and need post-sales technical support,
you can access our tools and resources online or open a case with JTAC.
• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.
• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.
• 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 CSC offerings: http://www.juniper.net/customers/support/
• Search for known bugs: http://www2.juniper.net/kb/
• Find product documentation: http://www.juniper.net/techpubs/
• 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:

http://kb.juniper.net/InfoCenter/
• 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 verify service entitlement by product 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).
xxxiv Copyright © 2017, Juniper Networks, Inc.

For international or direct-dial options in countries without toll-free numbers, see

http://www.juniper.net/support/requesting-support.html.
Copyright © 2017, Juniper Networks, Inc. xxxv

xxxvi Copyright © 2017, Juniper Networks, Inc.

PART 1
Overview
• Network Management Overview on page 3
• Introduction to Network Monitoring on page 7
Copyright © 2017, Juniper Networks, Inc. 1

2 Copyright © 2017, Juniper Networks, Inc.

CHAPTER 1
Network Management Overview
• Understanding Device Management Functions in Junos OS on page 3

• Understanding the Integrated Local Management Interface on page 6
Understanding Device Management Functions in Junos OS
Supported Platforms ACX Series, M Series, MX Series, T Series
After you have installed a device into your network, you need to manage the device within
your network. Device management can be divided into five tasks:
• Fault management—Monitor the device; detect and fix faults.
• Configuration management—Configure device attributes.
• Accounting management—Collect statistics for accounting purposes.
• Performance management—Monitor and adjust device performance.
• Security management—Control device access and authenticate users.
®
The Junos operating system (Junos OS) network management features work in
conjunction with an operations support system (OSS) to manage the devices within the
network. Junos OS can assist you in performing these management tasks, as described
in Table 3 on page 4.

Table 3: Device Management Features in Junos OS

Task Junos OS Feature
Fault management Monitor and see faults using:
• Operational mode commands—For more information about

operational mode commands, see the CLI Explorer.
• SNMP MIBs—For more information about SNMP MIBs supported by
Junos OS, see ““Standard SNMP MIBs Supported by Junos OS” on
page 30” and ““Enterprise-Specific SNMP MIBs Supported by Junos
OS” on page 19.
• Standard SNMP traps—For more information about standard SNMP
traps, see the “Standard SNMP Traps Supported by Junos OS” on
page 57.
• Enterprise-specific SNMP traps—For more information about
enterprise-specific traps, see ““Enterprise-Specific SNMP Traps
Supported by Junos OS” on page 64”.
• System log messages—For more information about how to configure
system log messages, see the Junos OS Administration Library. For
more information about how to view system log messages, see the
System Log Explorer.
Configuration • Configure router attributes using the command-line interface (CLI),

management the Junos XML management protocol, and the NETCONF XML
management protocol. For more information about configuring the
router using the CLI, see the Junos OS Administration Library. For more
information about configuring the router using the APIs, see the Junos
XML Management Protocol Guide and NETCONF XML Management
Protocol Guide.
• Configuration Management MIB—For more information about the
Configuration Management MIB, see Configuration Management
MIB.

Chapter 1: Network Management Overview
Table 3: Device Management Features in Junos OS (continued)

Task Junos OS Feature
Accounting Perform the following accounting-related tasks:

management
• Collect statistics for interfaces, firewall filters, destination classes,
source classes, and the Routing Engine. For more information about
collecting statistics, see “Accounting Options Configuration” on
page 296.
• Use interface-specific traffic statistics and other counters, available
in the Standard Interfaces MIB, Juniper Networks enterprise-specific
extensions to the Interfaces MIB, and media-specific MIBs, such as
the enterprise-specific ATM MIB.
• Use per-ATM virtual circuit (VC) counters, available in the
enterprise-specific ATM MIB. For more information about the ATM
MIB, see ATM MIB.
• Group source and destination prefixes into source classes and
destination classes and count packets for those classes. Collect
destination class and source class usage statistics. For more
information about classes, see “Destination Class Usage MIB” and
“Source Class Usage MIB”, “Configuring Class Usage Profiles” on
page 319, the Junos OS Network Interfaces Library for Routing Devices,
and the Junos OS Routing Protocols Library.
• Count packets as part of a firewall filter. For more information about
firewall filter policies, see “Enterprise-Specific SNMP MIBs Supported
by Junos OS” on page 19 and the Junos OS Routing Protocols Library.
• Sample traffic, collect the samples, and send the collection to a host
running the CAIDA cflowd utility. For more information about CAIDA
and cflowd, see the Junos OS Routing Protocols Library for Security
Devices.
Performance Monitor performance in the following ways:

management
• Use operational mode commands. For more information about
monitoring performance using operational mode commands, see
the CLI Explorer.
• Use firewall filter. For more information about performance
monitoring using firewall filters, see the Junos OS Routing Protocols
Library.
• Sample traffic, collect the samples, and send the samples to a host
running the CAIDA cflowd utility. For more information about CAIDA
and cflowd, see the Junos OS Routing Protocols Library.
• Use the enterprise-specific Class-of-Service MIB. For more
information about this MIB, see Class-of-Service MIB.
Security management Assure security in your network in the following ways:
• Control access to the router and authenticate users. For more

information about access control and user authentication, see the
Junos OS Administration Library.
• Control access to the router using SNMPv3 and SNMP over IPv6. For
more information, see “Configuring the Local Engine ID” on page 126
and “Tracing SNMP Activity on a Device Running Junos OS” on
page 203.

Related • Understanding the Integrated Local Management Interface on page 6

Documentation
• Understanding the SNMP Implementation in Junos OS
• Understanding Measurement Points, Key Performance Indicators, and Baseline Values

on page 261
• Accounting Options Overview on page 291
Understanding the Integrated Local Management Interface
Supported Platforms M Series, MX Series, PTX Series, SRX Series, T Series, vSRX
The Integrated Local Management Interface (ILMI) provides a mechanism for

Asynchronous Transfer Mode (ATM)-attached devices, such as hosts, routers, and ATM
switches, to transfer management information. ILMI provides bidirectional exchange of
management information between two ATM interfaces across a physical connection.
ILMI information is exchanged over a direct encapsulation of SNMP version 1 (RFC 1157,
A Simple Network Management Protocol) over ATM Adaptation Layer 5 (AAL5) using a
virtual path identifier/virtual channel identifier (VPI/VCI) value (VPI=0, VCI=16).
Junos OS supports only two ILMI MIB variables: atmfMYIPNmAddress and

atmfPortMyIfname. For ATM1 and ATM2 intelligent queuing (IQ) interfaces, you can
configure ILMI to communicate directly with an attached ATM switch to enable querying
of the switch’s IP address and port number.
For more information about the ILMI MIB, see the ATM Forum at
http://www.atmforum.com/.
Related • Understanding Device Management Functions in Junos OS on page 3

Documentation

CHAPTER 2
Introduction to Network Monitoring
• Monitoring Overview on page 7

• Diagnostic Tools Overview on page 8
Monitoring Overview
Supported Platforms SRX Series, vSRX
Junos OS supports a suite of J-Web tools and CLI operational mode commands for
monitoring the system health and performance of your device. Monitoring tools and
commands display the current state of the device. To use the J-Web user interface and
CLI operational tools, you must have the appropriate access privileges.
You can use the J-Web Monitor option to monitor a device. J-Web results appear in the
browser.
You can also monitor the device with CLI operational mode commands. CLI command
output appears on the screen of your console or management device, or you can filter
the output to a file. For operational commands that display output, such as the show
commands, you can redirect the output into a filter or a file. When you display help about
these commands, one of the options listed is |, called a pipe, which allows you to filter
the command output.
For example, if you enter the show configuration command, the complete device
configuration appears on the screen. To limit the display to only those lines of the
configuration that contain address, enter the show configuration command using a pipe
into the match filter:
user@host> show configuration | match address

address-range low 192.168.3.2 high 192.168.3.254;
address-range low 192.168.71.71 high 192.168.71.254;
address 192.168.71.70/21;
address 192.168.2.1/24;
address 127.0.0.1/32;
For a complete list of the filters, type a command, followed by the pipe, followed by a
question mark (?):
user@host> show configuration | ?

Possible completions:
compare Compare configuration changes with prior version
count Count occurrences

display Show additional kinds of information

except Show only text that does not match a pattern
find Search for first occurrence of pattern
hold Hold text without exiting the prompt
last Display end of output only
match Show only text that matches a pattern
no-more Don't paginate output
request Make system-level requests
resolve Resolve IP addresses
save Save output text to file
trim Trim specified number of columns from start of line
You can specify complex expressions as an option for the match and except filters.
NOTE: To filter the output of configuration mode commands, use the filter
commands provided for the operational mode commands. In configuration
mode, an additional filter is supported.
Related • Monitoring Interfaces on page 420

Documentation
Diagnostic Tools Overview
Juniper Networks devices support a suite of J-Web tools and CLI operational mode
commands for evaluating system health and performance. Diagnostic tools and
commands test the connectivity and reachability of hosts in the network.
• Use the J-Web Diagnose options to diagnose a device. J-Web results appear in the
browser.
• Use CLI operational mode commands to diagnose a device. CLI command output
appears on the screen of your console or management device, or you can filter the
output to a file.
To use the J-Web user interface and CLI operational tools, you must have the appropriate
access privileges.
This section contains the following topics:
• J-Web Diagnostic Tools on page 8

• CLI Diagnostic Commands on page 9
J-Web Diagnostic Tools

The J-Web diagnostic tools consist of the options that appear when you select
Troubleshoot and Maintain in the task bar. Table 4 on page 9 describes the functions of
the Troubleshoot options.

Chapter 2: Introduction to Network Monitoring
Table 4: J-Web Interface Troubleshoot Options

Option Function
Troubleshoot Options
Ping Host Allows you to ping a remote host. You can configure advanced options for the ping operation.
Ping MPLS Allows you to ping an MPLS endpoint using various options.
Traceroute Allows you to trace a route between the device and a remote host. You can configure advanced options
for the traceroute operation.
Packet Capture Allows you to capture and analyze router control traffic.
Maintain Options
Files Allows you to manage log, temporary, and core files on the device.
Upgrade Allows you to upgrade and manage Junos OS packages.
Licenses Displays a summary of the licenses needed and used for each feature that requires a license. Allows you
to add licenses.
Reboot Allows you to reboot the device at a specified time.
CLI Diagnostic Commands

The CLI commands available in operational mode allow you to perform the same
monitoring, troubleshooting, and management tasks you can perform with the J-Web
user interface. Instead of invoking the tools through a graphical interface, you use
operational mode commands to perform the tasks.
You can perform certain tasks only through the CLI. For example, you can use the mtrace
command to display trace information about a multicast path from a source to a receiver,
which is a feature available only through the CLI.
To view a list of top-level operational mode commands, type a question mark (?) at the
command-line prompt.
At the top level of operational mode are the broad groups of CLI diagnostic commands
listed in Table 5 on page 9.
Table 5: CLI Diagnostic Command Summary

Command Function
Controlling the CLI Environment

set option Configures the CLI display.
Diagnosis and Troubleshooting

clear Clears statistics and protocol database information.

Table 5: CLI Diagnostic Command Summary (continued)

Command Function
mtrace Traces information about multicast paths from source to receiver.
monitor Performs real-time debugging of various Junos OS components, including the

routing protocols and interfaces.
ping Determines the reachability of a remote network host.
ping mpls Determines the reachability of an MPLS endpoint using various options.
test Tests the configuration and application of policy filters and AS path regular
expressions.
traceroute Traces the route to a remote network host.
Connecting to Other Network Systems

ssh Opens secure shell connections.
telnet Opens Telnet sessions to other hosts on the network.
Management
copy Copies files from one location on the device to another, from the device to a remote
system, or from a remote system to the device.
restart option Restarts the various system processes, including the routing protocol, interface,
and SNMP processes.
request Performs system-level operations, including stopping and rebooting the device
and loading Junos OS images.
start Exits the CLI and starts a UNIX shell.
configuration Enters configuration mode.
quit Exits the CLI and returns to the UNIX shell.
Related • MPLS Connection Checking Overview on page 541

Documentation
• Understanding Ping MPLS on page 543
• Using the J-Web Ping Host Tool on page 546
• Using the ping Command on page 544

PART 2
Network Monitoring Using SNMP

• SNMP Overview on page 13
• SNMP MIBs and Traps Supported by Junos OS on page 19
• Loading MIB Files to a Network Management System on page 79
• Configuring SNMP on page 83
• Configuring SNMPv3 on page 121
• Configuring SNMP for Routing Instances on page 159
• Configuring SNMP Remote Operations on page 177
• Tracing SNMP Activity on page 197
• SNMP FAQs on page 209


CHAPTER 3
SNMP Overview
• Understanding SNMP Implementation in Junos OS on page 13

• SNMPv3 Overview on page 16
Understanding SNMP Implementation in Junos OS
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series,
vSRX
Do you use a central network management system (NMS)? Most NMS’s use a version
of Simple Network Management Protocol (SNMP) that can monitor the status of Junos
OS devices that send unsolicited messages called traps. You can configure the IP address
of your NMS so that Junos OS can send its traps.
SNMP uses a very basic form of authentication called community strings to control access
between a manager and remote agents. Community strings are administrative names
used to group collections of devices (and the agents running on them) into common
management domains. If a manager and an agent share the same community, they can
talk to one another.
Many people associate SNMP community strings with passwords and keys because the
jobs they do are similar. As a result, SNMP communities are traditionally referred to as
strings. The community string is the first level of management authentication implemented
by the SNMP agent in Junos OS.
You might also want to configure remote logging on your device. Junos OS uses a system
log (syslog) mechanism similar to many Unix devices to forward log messages to a
specified log host address. This allows each of your devices to forward their messages
to one central host, making it easier to monitor the network as a whole. Syslog is a very
flexible and rich way of logging messages and is used by many device vendors to
supplement the information provided by SNMP traps.
A typical SNMP implementation includes three components:
• Managed device
• SNMP agent
• Network management system (NMS)

A managed device is any device on a network, also known as a network element, that is
managed by the network management system. Routers and switches are common
examples of managed devices. The SNMP agent is the SNMP process that resides on
the managed device and communicates with the network management system. The
NMS is a combination of hardware and software that is used to monitor and administer
a network.
The SNMP data is stored in a highly-structured, hierarchical format known as a

management information base (MIB). The MIB structure is based on a tree structure,
which defines a grouping of objects into related sets. Each object in the MIB is associated
with an object identifier (OID), which names the object. The “leaf” in the tree structure
is the actual managed object instance, which represents a resource, event, or activity
that occurs in your network device.
The SNMP agent exchanges network management information with SNMP manager
software running on an NMS, or host. The agent responds to requests for information
and actions from the manager. The agent also controls access to the agent’s MIB, the
collection of objects that can be viewed or changed by the SNMP manager.
The SNMP manager collects information about network connectivity, activity, and events
by polling managed devices.
Communication between the agent and the manager occurs in one of the following
forms:
• Get, GetBulk, and GetNext requests—The manager requests information from the agent.
The agent returns the information in a Get response message.
• Set requests—The manager changes the value of a MIB object controlled by the agent.
The agent indicates status in a Set response message.
• Traps notification—The agent sends traps to notify the manager of significant events
that occur on the network device.
The SNMP implementation in Junos OS contains:
• A master SNMP agent (known as the SNMP process or snmpd) that resides on the
managed device and is managed by the NMS or host.
• Various subagents that reside on different modules of Junos OS, such as the Routing
Engine, and are managed by the master SNMP agent (snmpd).
NOTE: By default, SNMP is not enabled on devices running Junos OS. For
information about enabling SNMP on a device running the Junos OS, see
“Configuring SNMP on Devices Running Junos OS” on page 90.
The SNMP implementation in Junos OS uses both standard (developed by the IETF and
documented in RFCs) and enterprise-specific (developed and supported by specific
vendors) MIBs.

Chapter 3: SNMP Overview
In Junos OS, the management data is maintained by the snmpd at one level (for example,
snmpVacmMIB and snmpUsmMIB), and the subagents at the next level (for example,
routing MIBs and RMON MIBs). However, there is another level of data that is maintained
neither by the master agent nor by the subagents. In such cases, the data is maintained
by the Junos OS processes that share the data with the subagents when polled for SNMP
data. Interface-related MIBs and Firewall MIBs are good examples of data maintained
by Junos OS processes.
When a network mangement system polls the master agent for data, the master agent
immediately shares the data with the network mangement system if the requested data
is available with the master agent or one of the subagents. However, if the requested
data does not belong to those categories that are maintained by the master agent or the
subagents, the subagent polls the Junos OS kernel or the process that maintains that
data. On receiving the required data, the subagent passes the response back to the
master agent, which in turn passes it to the NMS.
The following illustration shows the communication flow among the NMS, SNMP process
(snmpd), SNMP subagents, and the Junos OS processes.
When a significant event, most often an error or a failure, occurs on a network device,
the SNMP agent sends notifications to the SNMP manager. The SNMP implementation
in Junos OS supports two types of notifications: traps and informs. Traps are unconfirmed
notifications, whereas informs are confirmed notifications. Informs are supported only
on devices that support SNMP version 3 (SNMPv3) configuration.
Junos OS supports trap queuing to ensure that traps are not lost because of temporary
unavailability of routes. Two types of queues, destination queues and a throttle queue,
are formed to ensure delivery of traps and to control the trap traffic.
Junos OS forms a destination queue when a trap to a particular destination is returned

because the host is not reachable, and adds the subsequent traps to the same destination
to the queue. Junos OS checks for availability of routes every 30 seconds and sends the
traps from the destination queue in a round-robin fashion.
If the 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 1 minute, 2 minutes, 4 minutes, and 8 minutes. The
maximum delay between the attempts is 8 minutes, and the maximum number of

attempts is 10. After 10 unsuccessful attempts, the destination queue and all the traps
in the queue are deleted.
Junos OS also has a throttle mechanism to control the number of traps (throttle threshold;
default value of 500 traps) sent during a particular time period (throttle interval; default
of 5 seconds) and to ensure consistency in trap traffic, especially when large number of
traps are generated because of interface status changes. The throttle interval period
begins when the first trap arrives at the throttle. All traps within the trap threshold are
processed, and the traps beyond the threshold limit are queued.
The maximum size of trap queues—that is, throttle queue and destination queue put
together—is 40,000. However, on EX Series Ethernet Switches, the maximum size of the
trap queue is 1,000. The maximum size of any one queue is 20,000 for devices other
than EX Series Switches. On EX Series Switches, the maximum size of one queue is 500.
When a trap is added to the throttle queue, or if the throttle queue has exceeded the
maximum size, the trap is added back on top of the destination queue, and all subsequent
attempts from the destination queue are stopped for a 30-second period, after which
the destination queue restarts sending the traps.
Related • FAQ: SNMP Support on Junos OS

Documentation
• Configuring SNMP on Devices Running Junos OS on page 90
• Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance on
a Device Running Junos OS on page 197
• Optimizing the Network Management System Configuration for the Best Results on
page 87
• Configuring Options on Managed Devices for Better SNMP Response Time on page 88
• Managing Traps and Informs
• Using the Enterprise-Specific Utility MIB to Enhance SNMP Coverage
SNMPv3 Overview
Supported Platforms ACX Series, M Series, MX Series, PTX Series, SRX Series, T Series, vSRX
In contrast to SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2), SNMP version
3 (SNMPv3) supports authentication and encryption. SNMPv3 uses the user-based
security model (USM) for message security and the view-based access control model
(VACM) for access control. USM specifies authentication and encryption. VACM specifies
access-control rules.
USM uses the concept of a user for which security parameters (levels of security,
authentication, privacy protocols, and keys) are configured for both the agent and the
manager. Messages sent using USM are better protected than messages sent with
community strings, where passwords are sent in the clear. With USM, messages
exchanged between the manager and the agent can have data integrity checking and
data origin authentication. USM protects against message delays and message replays
by using time indicators and request IDs. Encryption is also available.

Chapter 3: SNMP Overview
To complement the USM, SNMPv3 uses the VACM, a highly granular access-control
model for SNMPv3 applications. Based on the concept of applying security policies to
the name of the groups querying the agent, the agent decides whether the group is
allowed to view or change specific MIB objects. VACM defines collections of data (called
views), groups of data users, and access statements that define which views a particular
group of users can use for reading, writing, or receiving traps.
Trap entries in SNMPv3 are created by configuring the notify, notify filter, target address,
and target parameters. The notify statement specifies the type of notification (trap) and
contains a single tag. The tag defines a set of target addresses to receive a trap. The
notify filter defines access to a collection of trap object identifiers (OIDs). The target
address defines a management application's address and other attributes to be used in
sending notifications. Target parameters define the message processing and security
parameters to be used in sending notifications to a particular management target.
To configure SNMPv3, perform the following tasks:
• Creating SNMPv3 Users on page 127
• Configuring MIB Views on page 116
• Defining Access Privileges for an SNMP Group on page 132
• Configuring SNMPv3 Traps on a Device Running Junos OS on page 139
• Configuring SNMP Informs on page 149
Related • Minimum SNMPv3 Configuration on a Device Running Junos OS on page 122

Documentation


CHAPTER 4
SNMP MIBs and Traps Supported by

Junos OS
• Enterprise-Specific SNMP MIBs Supported by Junos OS on page 19

• Standard SNMP MIBs Supported by Junos OS on page 30
• Enterprise-Specific MIBs and Supported Devices on page 47
• Standard SNMP Traps Supported by Junos OS on page 57
• Enterprise-Specific SNMP Traps Supported by Junos OS on page 64
Enterprise-Specific SNMP MIBs Supported by Junos OS
vSRX
Junos OS supports the enterprise-specific MIBs listed in Table 6 on page 19. For
information about enterprise-specific SNMP MIB objects, see the SNMP MIB Explorer.
Table 6: Enterprise-specific MIBs supported by Junos OS

Enterprise-Specific MIB Description Platforms
AAA Objects MIB Provides support for monitoring user SRX Series and vSRX
authentication, authorization, and
accounting through the RADIUS, LDAP,
SecurID, and local authentication
servers.
Access Authentication Objects MIB Provides support for monitoring firewall SRX Series and vSRX
authentication, including data about the
users trying to access firewall-protected
resources and the firewall authentication
service itself.
Alarm MIB Provides information about alarms from All platforms

the router chassis.

Table 6: Enterprise-specific MIBs supported by Junos OS (continued)

Analyzer MIB Provides information about analyzer and EX Series, QFabric system, and QFX Series
remote analyzer related to port mirroring
on the EX Series Ethernet Switches. Port
mirroring is a method used on enterprise
switches to monitor and analyze traffic
on the network. When port mirroring is
enabled, copies of all (or a sample set
of) packets are forwarded from one port
of the switch to another port on the
same switch (analyzer) or on another
switch (remote analyzer) where the
packet can be analyzed and studied.
Antivirus Objects MIB Provides information about the antivirus SRX Series and vSRX
engine, antivirus scans, and antivirus
scan-related traps.
ATM Class-of-Service MIB Provides support for ATM interfaces and ACX Series, M Series, and T Series
virtual connections.
ATM MIB Provides support for monitoring M Series, SRX Series, T Series and vSRX
Asynchronous Transfer Mode, version 2
(ATM2) virtual circuit (VC)
class-of-service (CoS) configurations.
It also provides CoS queue statistics for
all VCs that have CoS configured.
BGP4 V2 MIB Provides support for monitoring BGP All platforms

peer-received prefix counters. It is based
upon similar objects in the MIB
documented in Internet draft
draft-ietf-idr-bgp4-mibv2-03.txt,
Definitions of Managed Objects for the
Fourth Version of BGP (BGP-4), Second
Version.
Bidirectional Forwarding Detection MIB Provides support for monitoring All platforms
Bidirectional Forwarding Detection
(BFD) sessions.
Chassis Cluster MIB Provides information about objects that SRX Series and vSRX
are used whenever the state of the
control link interfaces or fabric link
interfaces changes (up to down or down
to up) in a chassis cluster deployment.
Chassis Definitions for Router Model MIB Contains the object identifiers (OIDs) ACX Series, M Series, MX Series, PTX
that are used by the Chassis MIB to Series, QFX Series, SRX 1500, SRX 550,
identify platform and chassis and T Series
components. The Chassis MIB provides
information that changes often, whereas
the Chassis Definitions for Router Model
MIB provides information that changes
less often.

Chapter 4: SNMP MIBs and Traps Supported by Junos OS

Chassis MIBs Provides support for environmental All platforms

monitoring (power supply state, board
voltages, fans, temperatures, and air
flow) and inventory support for the
chassis, System Control Board (SCB),
System and Switch Board (SSB),
Switching and Forwarding Module
(SFM), Switch Fabric Board (SFB),
Flexible PIC Concentrators (FPCs), and
PICs.
Class-of-Service MIB Provides support for monitoring ACX Series, EX Series, M Series, MX Series,
interface output queue statistics per PTX Series, QFabric system, QFX Series,
interface and per forwarding class. SRX Series, T Series, and vSRX
Configuration Management MIB Provides notification for configuration All platforms

changes as SNMP traps. Each trap
contains the time at which the
configuration change was committed,
the name of the user who made the
change, and the method by which the
change was made. A history of the last
32 configuration changes is kept in
jnxCmChgEventTable.
Destination Class Usage MIB Provides support for monitoring packet EX Series, M Series, SRX Series, T Series,
counts based on the ingress and egress and vSRX
points for traffic transiting your
networks. Ingress points are identified
by the input interface. Egress points are
identified by destination prefixes
grouped into one or more sets, known
as destination classes. One counter is
managed per interface per destination
class, up to a maximum of 16 counters
per interface.
DHCP MIB Provides SNMP support (get and trap) M Series, MX Series, and T Series
for DHCP local server and relay
configurations. It also provides support
for bindings and leases tables, and for
statistics.
DHCPv6 MIB Provides SNMP support (get and trap) M Series, MX Series, and T Series
for DHCPv6 local server and relay
configurations. It also provides support
for bindings and leases tables, and for
statistics.
Digital Optical Monitoring MIB Provides support for the SNMP Get EX Series, M Series, MX Series, PTX Series,
request for statistics and SNMP Trap and T Series
notifications for alarms.


DNS Objects MIB Provides support for monitoring DNS SRX Series and vSRX
proxy queries, requests, responses, and
failures.
Dynamic Flow Capture MIB Provides support for monitoring the M Series and T Series
operational status of dynamic flow
capture (DFC) PICs.
Ethernet MAC MIB Monitors media access control (MAC) EX Series, M Series, MX Series, QFX Series,
statistics on Gigabit Ethernet intelligent SRX1500, SRX300, SRX320, SRX340,
queuing (IQ) interfaces. It collects MAC SRX550, and T Series
statistics; for example, inoctets,
inframes, outoctets, and outframes on
each source MAC address and virtual
LAN (VLAN) ID for each Ethernet port.
Event MIB Defines a generic trap that can be ACX Series, EX Series, M Series, MX Series,
generated using an op script or event PTX Series, QFabric system, QFX Series,
policy. This MIB provides the ability to SRX1500, SRX300, SRX320, SRX340,
specify a system log string and raise a SRX550, and T Series
trap if that system log string is found.
Experimental MIB Contains object identifiers for ACX Series, M series, MX Series, and T
experimental MIBs. series
EX Series MAC Notification MIB Contains Juniper Networks' EX Series

implementation of enterprise-specific
MIB for Ethernet Mac Stats for EX Series.
EX Series SMI MIB Contains the Structure of Management EX Series

Information for Juniper Networks EX
Series platforms.
Firewall MIB Provides support for monitoring firewall ACX Series, EX Series, M Series, MX Series,
filter counters. Routers must have the PTX Series, QFabric system, QFX Series,
Internet Processor II ASIC to perform SRX1500, SRX300, SRX320, SRX340,
firewall monitoring. SRX550, and T Series
Flow Collection Services MIB Provides statistics on files, records, M Series and T Series
memory, FTP, and error states of a
monitoring services interface. It also
provides SNMP traps for unavailable
destinations, unsuccessful file transfers,
flow overloading, and memory
overloading.


Host Resources MIB Extends the hrStorageTable object, ACX Series, EX Series, M Series, MX Series,
providing a measure of the usage of each QFX Series, SRX1500, SRX300, SRX320,
file system on the router in percentage SRX340, SRX550, and T Series
format. Previously, the objects in the
hrStorageTable measured the usage in
allocation units—hrStorageUsed and
hrStorageAllocationUnits—only. Using
the percentage measurement, you can
more easily monitor and apply
thresholds on usage.
Interface Accounting Forwarding Class Extends the Juniper Enterprise Interface M Series, MX Series, SRX Series, and vSRX
MIB MIB and provides support for monitoring
statistcs data for interface accounting
and IETF standardization.
Interface MIB Extends the standard ifTable (RFC ACX Series, EX Series, M Series, MX Series,
2863) with additional statistics and PTX Series, QFabric system, QFX Series,
Juniper Networks enterprise-specific SRX1500, SRX300, SRX320, SRX340,
chassis information. SRX550, and T Series
IP Forward MIB Extends the standard IP Forwarding All platforms

Table MIB (RFC 4292) to include CIDR
forwarding information.
IPsec Generic Flow Monitoring Object Based on jnx-ipsec-monitor-mib, this MIB SRX Series and vSRX
MIB provides support for monitoring IPsec
and IPsec VPN management objects.
IPsec Monitoring MIB Provides operational and statistical M Series, SRX Series, and T Series
information related to the IPsec and IKE
tunnels on Juniper Networks routers.
IPsec VPN Objects MIB Provides support for monitoring IPsec SRX Series
and IPsec VPN management objects for
Juniper security product lines. This MIB
is an extension of
jnx-ipsec-flow-mon.mib.
IPv4 MIB Provides additional Internet Protocol All plarforms

version 4 (IPv4) address information,
supporting the assignment of identical
IPv4 addresses to separate interfaces.
IPv6 and ICMPv6 MIB Provides IPv6 and Internet Control M series, MX Series, PTX Series, SRX
Message Protocol version 6 (ICMPv6) Series, T Series, and vSRX
statistics.


L2ALD MIB Contains information about the Layer 2 EX Series, MX Series, QFX Series, and T
Address Learning Daemon (L2ALD) and Series
related traps, such as the routing
instance MAC limit trap and the interface
MAC limit trap. This MIB also provides
VLAN information in the
jnxL2aldVlanTable table for Enhanced
Layer 2 Software (ELS) EX Series and
QFX Series switches.
NOTE: Non-ELS EX Series switches

support the VLAN MIB (jnxExVlanTable
table) for VLAN information instead of
this MIB. See the SNMP MIB Explorer.
L2CP MIB Provides information about Layer 2 MX Series

Control Protocols (L2CP) based
features. Currently, Junos OS supports
only the
jnxDot1dStpPortRootProtectEnabled,
jnxDot1dStpPortRootProtectState, and
jnxPortRootProtectStateChangeTrap
objects.
L2TP MIB Provides information about Layer 2 M Series, MX Series, and T Series
Transport Protocol (L2TP) tunnels and
sessions.
LDP MIB Provides LDP statistics and defines LDP ACX Series, M Series, PTX Series, SRX
label-switched path (LSP) notifications. Series, and T Series
LDP traps support only IPv4 standards.
License MIB Extends SNMP support to licensing M Series, MX Series, SRX Series, and T
information, and introduces SNMP traps Series
that alert users when the licenses are
about to expire, expire, or when the total
number of users exceeds the number
specified in the license.
Logical Systems MIB Extend SNMP support to logical systems SRX Series
security profile through various MIBs
defined under jnxLsysSecurityProfile.
MIMSTP MIB Provides information about MSTP MX Series and T Series

instances (that is, routing instances of
type Virtual Switch/Layer 2 control, also
known as virtual contexts), MSTIs within
the MSTP instance, and VLANs
associated with the MSTI.


MPLS LDP MIB Contains object definitions as described ACX Series, EX Series, M Series, MX Series,
in RFC 3815, Definitions of Managed PTX Series, QFX Series, and T Series
Objects for the Multiprotocol Label
Switching (MPLS), Label Distribution
Protocol (LDP).
NOTE: Objects in the MPLS LDP MIB

were supported in earlier releases of
Junos OS as a proprietary LDP MIB
(mib-ldpmib.txt). Because the branch
used by the proprietary LDP
(mib-ldpmib.txt) conflicts with RFC 3812,
the proprietary LDP MIB (mib-ldpmib.txt)
has been deprecated and replaced by
the enterprise-specific MPLS LDP MIB
(mib-jnx-mpls-ldp.txt).
MPLS MIB Provides MPLS information and defines ACX Series, EX Series, M Series, MX Series,
MPLS notifications. PTX Series, QFX Series, SRX Series, and
T Series
NOTE: To collect information about
MPLS statistics on transit routers, use
the enterprise-specific RSVP MIB
(mib-jnx-rsvp.txt) instead of the
enterprise-specific MPLS MIB
(mib-jnx-mpls.txt).
MVPN MIB Contains objects that enable SNMP All platforms

manager to monitor MVPN connections
on the provider edge routers. The
enterprise-specific MVPN MIB is the
Juniper Networks extension of the IETF
standard MIBs defined in Internet draft
draft-ietf-l3vpn-mvpn-mib-03.txt,
MPLS/BGP Layer 3 VPN Multicast
Management Information Base.
NAT Objects MIB Provides support for monitoring network EX Series and SRX Series
address translation (NAT). .
NAT Resources-Monitoring MIB Provides support for monitoring NAT M Series and MX Series
pools usage and NAT rules. Notifications
of usage of NAT resources are also
provided by this MIB. This MIB is
currently supported on the Multiservices
PIC and Multiservices DPC on M Series
and MX Series routers only.
OTN Interface Management MIB Defines objects for managing Optical M Series, MX series, PTX Series, and T
Transport Network (OTN) interfaces on Series
devices running Junos OS.
Packet Forwarding Engine MIB Provides notification statistics for Packet ACX Series, EX Series, M Series, PTX
Forwarding Engines. Series, SRX Series, and T Series


Packet Mirror MIB Enables you to capture and view packet MX Series
mirroring-related information. This MIB
is currently supported by Junos OS for
MX Series routers only. Packet mirroring
traps are an extension of the standard
SNMP implementation and are only
available to SNMPv3 users.
PAE Extension MIB Extends the standard IEEE802.1x PAE EX Series

Extension MIB, and contains information
for Static MAC Authentication.
Passive Monitoring MIB Performs traffic flow monitoring and M Series and T Series
lawful interception of packets transiting
between two routers.
Ping MIB Extends the standard Ping MIB control ACX Series, EX Series, M Series, MX Series,
table (RFC 2925). Items in this MIB are QFX Series, SRX Series, and T Series
created when entries are created in
pingCtlTable of the Ping MIB. Each item
is indexed exactly as it is in the Ping MIB.
Policy Objects MIB Provides support for monitoring the SRX Series
security policies that control the flow of
traffic from one zone to another.
Power Supply Unit MIB Enables monitoring and managing of the EX Series and QFabric system
power supply on a device running Junos
OS.
PPP MIB Provides SNMP support for PPP-related M Series and MX Series
information such as the type of
authentication used, interface
characteristics, status, and statistics.
This MIB is supported on Common Edge
PPP process, jpppd.
PPPoE MIB Provides SNMP support for M Series and MX Series

PPPoE-related information such as the
type of authentication used, interface
characteristics, status, and statistics.
This MIB is supported on Common Edge
PPPoE process, jpppoed.
Pseudowire ATM MIB Extends the standard Pseudowire MIB, M Series and MX Series
and defines objects used for managing
the ATM pseudowires in Juniper
products. The enterprise-specific
Pseudowire ATM MIB is the Juniper
Networks implementation of RFC 5605,
Managed Objects for ATM over Packet
Switched Networks (PSNs).


Pseudowire TDM MIB Extends the standard Pseudowire MIB, ACX Series, M Series, and T Series
and contains information about
configuration and statistics for specific
pseudowire types. The
enterprise-specific Pseudowire TDM MIB
is the Juniper Networks implementation
of the standard Managed Objects for
TDM over Packet Switched Network MIB
(draft-ietf-pwe3-tdm-mib-08.txt).
PTP MIB Monitors the operation of PTP clocks MX Series

within the network.
Real-Time Performance Monitoring MIB Provides real-time performance-related EX Series, M Series, MX Series, SRX Series,
data and enables you to access jitter and T Series
measurements and calculations using
SNMP.
Reverse-Path-Forwarding MIB Monitors statistics for traffic that is All platforms

rejected because of
reverse-path-forwarding (RPF)
processing.
RMON Events and Alarms MIB Supports the Junos OS extensions to the All platforms
standard Remote Monitoring (RMON)
Events and Alarms MIB (RFC 2819). The
extension augments alarmTable with
additional information about each
alarm. Two new traps are also defined
to indicate when problems are
encountered with an alarm.
RSVP MIB Provides information about RSVP-traffic ACX Series, M Series, MX Series, PTX
engineering sessions that correspond to Series, and T Series
MPLS LSPs on transit routers in the
service provider core network.
NOTE: To collect information about

MPLS statistics on transit routers, use
the enterprise-specific RSVP MIB
(mib-jnx-rsvp.txt) instead of the
enterprise-specific MPLS MIB
(mib-jnx-mpls.txt).
Security Interface Extension Objects MIB Provides support for the security EX Series, SRX Series, and vSRX
management of interfaces.
Security Screening Objects MIB Defines the MIB for the Juniper Networks SRX Series and vSRX
Enterprise Firewall screen functionality.
Services PIC MIB Provides statistics for Adaptive Services M Series and T Series
(AS) PICs and defines notifications for
AS PICs.


SNMP IDP MIB Contains Juniper Networks' SRX Series and vSRX
implementation of enterprise specific
MIB for IDP.
SONET APS MIB Monitors any SONET interface that M Series and T Series
participates in Automatic Protection
Switching (APS).
SONET/SDH Interface Management MIB Monitors the current alarm for each M Series and T Series
SONET/SDH interface.
Source Class Usage MIB Counts packets sent to customers by M Series, T Series, and SRX Series
performing a lookup on the IP source
address and the IP destination address.
The Source Class Usage (SCU) MIB
makes it possible to track traffic
originating from specific prefixes on the
provider core and destined for specific
prefixes on the customer edge.
SPU Monitoring MIB Provides support for monitoring SPUs SRX Series and vSRX
on SRX5600 and SRX5800 devices.
Structure of Management Information Explains how the Juniper Networks ACX Series, EX Series, M Series, MX series,
MIB enterprise-specific MIBs are structured. QFX Series, SRX Series, T Series and vSRX
Structure of Management Information Defines a MIB branch for EX Series

MIB for EX Series Ethernet Switches switching-related MIB definitions for the
EX Series Ethernet Switches.
Structure of Management Information Contains object identifiers (OIDs) for the SRX Series and vSRX
MIB for SRX Series security branch of the MIBs used in Junos
OS for SRX Series devices, services, and
traps.
Subscriber MIB Provides SNMP support for ACX Series, MX Series, and T Series
subscriber-related information.
System Log MIB Enables notification of an SNMP EX Series, M Series, MX Series, PTX Series,
trap-based application when an QFX Series, SRX Series, and T Series
important system log message occurs.
Traceroute MIB Supports the Junos OS extensions of EX Series, M Series, MX Series, SRX Series,
traceroute and remote operations. Items T Series, and vSRX
in this MIB are created when entries are
created in the traceRouteCtlTable of the
Traceroute MIB. Each item is indexed
exactly the same way as it is in the
Traceroute MIB.


Utility MIB Provides SNMP support for exposing the EX Series, M Series, MX Series, QFabric
Junos OS data and has tables that system, QFX Series, SRX Series, T Series,
contain information about each type of and vSRX
data, such as integer and string.
Virtual Chassis MIB Contains information about the virtual EX Series and MX Series
chassis on the EX Series Ethernet
Switches and the MX Series.
VLAN MIB Contains information about prestandard EX Series and QFX Series
IEEE 802.10 VLANs and their association
with LAN emulation clients.
NOTE: For ELS EX Series switches and

QFX Series switches, VLAN information
is provided in the L2ALD MIB in the
jnxL2aldVlanTable table instead of in this
MIB. See theSNMP MIB Explorer for
details.
Non-ELS EX Series Ethernet switches

use the jnxExVlanTable table in this MIB
to provide VLAN configuration
information, and the jnxVlanTable table
in this MIB has been deprecated and is
no longer used.
VPLS MIBs Provides information about generic, M Series, MX Series, and T Series
BGP-based, and LDP-based VPLS, and
pseudowires associated with the VPLS
networks. The enterprise-specific VPLS
MIBs are Juniper Networks extensions
of the following IETF standard MIBs
defined in Internet draft
draft-ietf-l2vpn-vpls-mib-05.txt, and
are implemented as part of the
jnxExperiment branch:
• VPLS-Generic-Draft-01-MIB
implemented as
mib-jnx-vpls-generic.txt
• VPLS-BGP-Draft-01-MIB implemented
as mib-jnx-vpls-bgp.txt
• VPLS-LDP-Draft-01-MIB implemented
as mib-jnx-vpls-ldp.txt
VPN Certificate Objects MIB Provides support for monitoring the local EX Series, SRX Series, and vSRX
and CA certificates loaded on the router.
VPN MIB Provides monitoring for Layer 3 VPNs, ACX Series, EX Series, M Series, MX Series,
Layer 2 VPNs, and virtual private LAN and T Series
service (VPLS) (read access only).

For information about enterprise-specific SNMP MIB objects, see the SNMP MIB Explorer.
Related • Network Management Administration Guide

Documentation
• Enterprise-Specific SNMP Traps Supported by Junos OS on page 64
Standard SNMP MIBs Supported by Junos OS
vSRX
Junos OS supports the Standard MIBs listed in Table 7 on page 30.
NOTE: For details on SNMP MIB support on EX4600 switches, QFX Series
switches, and QFabric systems, see SNMP MIBs Support.
Table 7: Standard MIBs supported by Junos OS

Standard MIB Exceptions Platforms
IEEE 802.1ab section 12.1, Link Layer EX Series implementation of LLDP MIB EX Series and MX Series
Discovery Protocol (LLDP) MIB supports both IPv4 and IPv6
configuration.
IEEE, 802.3ad, Aggregation of Multiple Supported tables and objects: EX Series, M Series, MX Series, PTX
Link Segments Series, SRX Series, T Series, and vSRX
• dot3adAggPortTable,
dot3adAggPortListTable,
dot3adAggTable, and
dot3adAggPortStatsTable
NOTE: EX Series switches do not

support the dot3adAggPortTable and
dot3adAggPortStatsTable.
• dot3adAggPortDebugTable (only
dot3adAggPortDebugRxState,
dot3adAggPortDebugMuxState,
dot3adAggPortDebugActorSyncTransitionCount,
dot3adAggPortDebugPartnerSyncTransitionCount,
dot3adAggPortDebugActorChangeCount,
and
dot3adAggPortDebugPartnerChangeCount)
NOTE: EX Series switches do not

support the
dot3adAggPortDebugTable.
• dot3adTablesLastChanged

Table 7: Standard MIBs supported by Junos OS (continued)

IEEE, 802.1ag, Connectivity Fault Supported tables and objects: EX Series, MX Series, and QFX Series
Management
• dot1agCfmMdTableNextIndex
• dot1agCfmMdTable (except
dot1agCfmMdMhfldPermission)
• dot1agCfmMaNetTable
• dot1agCfmMaMepListTable
• dot1agCfmDefaultMdDefLevel
• dot1agCfmDefaultMdDefMhfCreation
• dot1agCfmMepTable (except
dot1agCfmMepLbrBadMsdu,
dot1agCfmMepTransmitLbmVlanPriority,
dot1agCfmMepTransmitLbmVlanDropEnable,
dot1agCfmMepTransmitLtmFlags,
dot1agCfmMepPbbTeCanReportPbbTePresence,
dot1agCfmMepPbbTeTrafficMismatchDefect,
dot1agCfmMepPbbTransmitLbmLtmReverseVid,
dot1agCfmMepPbbTeMismatchAlarm,
dot1agCfmMepPbbTeLocalMismatchDefect,
and
dot1agCfmMepPbbTeMismatchSinceReset)
• dot1agCfmLtrTable (except
dot1agCfmLtrChassisIdSubtype,
dot1agCfmLtrChassisId,
dot1agCfmLtrManAddressDomain,
dot1agCfmLtrManAddress,
dot1agCfmLtrIngressPortIdSubtype,
dot1agCfmLtrIngressPortId,
dot1agCfmLtrEgressPortIdSubtype,
dot1agCfmLtrEgressPortId, and
dot1agCfmLtrOrganizationSpecificTlv)
• dot1agCfmMepDbTable (except
dot1agCfmMebDbChassisIdSubtype,
dot1agCfmMebDbChassisId,
dot1agCfmMebDbManAddressDomain,
and dot1agCfmMebDbManAddress)
IEEE, 802.1ap, Management Information Supported tables and objects: MX Series

Base (MIB) definitions for VLAN Bridges
• ieee8021CfmStackTable
• ieee8021CfmVlanTable
• ieee8021CfmDefaultMdTable (except
ieee8021CfmDefaultMdIdPermission)
• ieee8021CfmMaCompTable (except
ieee8021CfmMaCompIdPermission)
RFC 1155, Structure and Identification of No exceptions All platforms

Management Information for
TCP/IP-based Internets
RFC 1157, A Simple Network Management No exceptions All platforms

Protocol (SNMP)


RFC 1195, Use of OSI IS-IS for Routing in Supported tables and objects: All platforms
TCP/IP and Dual Environments
• isisSystem
• isisMANAreaAddr
• isisAreaAddr
• isisSysProtSupp
• isisSummAddr
• isisCirc
• isisCircLevel
• isisPacketCount
• isisISAdj
• isisISAdjAreaAddr
• isisAdjIPAddr
• isisISAdjProtSupp
• isisRa
• isisIPRA
RFC 1212, Concise MIB Definitions No exceptions ACX Series, EX Series, M Series, MX
Series, PTX Series, SRX Series, and T
Series
RFC 1213, Management Information Base Junos OS supports the following areas: ACX Series, EX Series, M Series, MX
for Network Management of Series, PTX Series, SRX Series, and T
TCP/IP-Based Internets: MIB-II • MIB II and its SNMP version 2 Series
derivatives, including:
• Statistics counters
• IP, except for ipRouteTable, which
has been replaced by
ipCidrRouteTable (RFC 2096, IP
Forwarding Table MIB)
• SNMP management
• Interface management
• SNMPv1 Get, GetNext requests, and

version 2 GetBulk request
• Junos OS-specific secured access list
• Master configuration keywords
• Reconfigurations upon SIGHUP
RFC 1215, A Convention for Defining Traps Junos OS supports only MIB II SNMP ACX Series, EX Series, M Series, MX
for use with the SNMP version 1 traps and version 2 notifications. Series, PTX Series, SRX Series, and T
Series
RFC 1406, Definitions of Managed Objects Junos OS supports T1 MIB. ACX Series, M Series, SRX Series, and T
for the DS1 and E1 Interface Types Series
RFC 1407, Definitions of Managed Objects Junos OS supports T3 MIB. M Series and T Series
for the DS3/E3 Interface Type


RFC 1471, Definitions of Managed Objects Supported tables and objects: M Series, MX Series, and PTX Series
for the Link Control Protocol of the
Point-to-Point Protocol • pppLcp 1 object
• pppLinkStatustable table
• pppLinkConfigTable table
RFC 1657, Definitions of Managed Objects No exceptions ACX Series, EX Series, M Series, MX
for the Fourth Version of the Border Series, and T Series
Gateway Protocol (BGP-4) using SMIv2
RFC 1695, Definitions of Managed Objects No exceptions ACX Series, M Series, PTX Series, and T
for ATM Management Version 8.0 Using Series
SMIv2
RFC 1850, OSPF Version 2 Management Unsupported tables, objects, and traps: ACX Series, EX Series, M Series, MX
Information Base Series, PTX Series, SRX Series, and T
• ospfOriginateNewLsas object Series
• ospfRxNewLsas object
• The host table
• ospfOriginateLSA trap
ospfLsdbOverflow trap
ospfLsdbApproachingOverflow trap
RFC 1901, Introduction to No exceptions All platforms

Community-based SNMPv2
RFC 2011, SNMPv2 Management No exceptions ACX Series, EX Series, M Series, MX

Information Base for the Internet Protocol Series, PTX Series, and T Series
Using SMIv2

Information Base for the Transmission Series, PTX Series, SRX Series, and T
Control Protocol Using SMIv2 Series

Information Base for the User Datagram Series, PTX Series, SRX Series, and T
Protocol Using SMIv2 Series


RFC 2024, Definitions of Managed Objects Unsupported tables, objects, and traps M Series, MX Series, and T Series
for Data Link Switching Using SMIv2 with read-only access:
• dlswInterface object group

dlswSdlc object group
dlswDirLocateMacTable table
dlswDirNBTabletable
dlswDirLocateNBTable table
dlswCircuitDiscReasonLocal tabular
object
dlswCircuitDiscReasonRemote tabular
object
dlswDirMacCacheNextIndex scalar
object
dlswDirNBCacheNextIndex scalar
object
RFC 2096, IP Forwarding Table MIB The ipCidrRouteTable has been extended ACX Series, EX Series, M Series, MX
to include the tunnel name when the next Series, PTX Series, SRX Series, and T
NOTE: RFC 2096 has been replaced by hop is through an RSVP-signaled LSP. Series
RFC 4292. However, Junos OS currently
supports both RFC 2096 and RFC 4292.
RFC 2115, Management Information Base Unsupported table and objects: M Series, MX Series, SRX Series, and T
for Frame Relay DTEs Using SMIv2 Series
• frCircuitTable
• frErrTable
RFC 2233, The Interfaces Group MIB Using No exceptions ACX Series, EX Series, M Series, MX
SMIv2 Series, PTX Series, SRX Series, and T
Series
NOTE: RFC 2233 has been replaced by
RFC 2863, IF MIB. However, Junos OS
supports both RFC 2233 and RFC 2863.
RFC 2287, Definitions of System-Level Supported tables and objects: ACX Series, EX Series, M Series, MX
Managed Objects for Applications Series, PTX Series, SRX Series, and T
• sysApplInstallPkgTable Series
• sysApplInstallElmtTable
• sysApplElmtRunTable
• sysApplMapTable
RFC 2465, Management Information Base Junos OS does not support IPv6 interface ACX Series, M Series, MX Series, PTX
for IP Version 6: Textual Conventions and statistics. Series, SRX Series, and T Series
General Group (except for IPv6 interface
statistics)


RFC 2495, Definitions of Managed Unsupported tables, objects, and traps: ACX Series, M Series, SRX Series, and T
Objects for the DS1, E1, DS2, and E2 Series
Interface Types • dsx1FarEndConfigTable
• dsx1FarEndCurrentTable
• dsx1FarEndIntervalTable
• dsx1FarEndTotalTable
• dsx1FracTable
RFC 2515, Definitions of Managed Objects Unsupported table and objects: ACX Series, M Series, and T Series
for ATM Management
• atmVpCrossConnectTable
• atmVcCrossConnectTable
• aal5VccTable
RFC 2570, Introduction to Version 3 of the No exceptions ACX Series, EX Series, M Series, MX
Internet-standard Network Management Series, PTX Series, SRX Series, and T
Framework Series
RFC 2571, An Architecture for Describing No exceptions ACX Series, EX Series, M Series, MX
SNMP Management Frameworks Series, PTX Series, SRX Series, and T
(read-only access) Series

RFC 3411. However, Junos OS supports
both RFC 2571 and RFC 3411.
RFC 2572, Message Processing and No exceptions ACX Series, EX Series, M Series, MX
Dispatching for the Simple Network Series, PTX Series, SRX Series, and T
Management Protocol (SNMP) Series
(read-only access)

RFC 2576, Coexistence between Version No exceptions ACX Series, EX Series, M Series, MX
1, Version 2, and Version 3 of the Series, PTX Series, SRX Series, and T
Internet-standard Network Management Series
Framework

RFC 2578, Structure of Management No exceptions ACX Series, EX Series, M Series, MX

Information Version 2 (SMIv2) Series, PTX Series, SRX Series, and T
Series
RFC 2579, Textual Conventions for SMIv2 No exceptions ACX Series, EX Series, M Series, MX
Series


RFC 2580, Conformance Statements for No exceptions ACX Series, EX Series, M Series, MX
SMIv2 Series, PTX Series, SRX Series, and T
Series
RFC 2662, Definitions of Managed Objects No exceptions M Series, MX Series, SRX Series, and T
for ADSL Lines Series
RFC 2665, Definitions of Managed For M Series, T Series, and MX Series, the ACX Series, EX Series, M Series, MX
Objects for the Ethernet-like Interface SNMP counters do not count the Series, PTX Series, SRX Series, and T
Types Ethernet header and frame check Series
sequence (FCS). Therefore, the Ethernet
NOTE: The list of managed objects header bytes and the FCS bytes are not
specified in RFC 2665 has been updated included in the following four tables:
by RFC 3635 by including information
useful for the management of 10-Gigabit • ifInOctets
per second Ethernet interfaces. • ifOutOctets
• ifHCInOctets
• ifHCOutOctets
However, the EX switches adhere to RFC

2665.
RFC 2787, Definitions of Managed Objects Unsupported table and objects: ACX Series, EX Series, M Series, MX
for the Virtual Router Redundancy Series, PTX Series, SRX Series, and T
Protocol • vrrpStatsPacketLengthErrors Series
NOTE: Junos OS does not support this

standard for row creation and the Set
operation.
RFC 2790, Host Resources MIB Supported tables and objects: ACX Series, EX Series, M Series, MX
• hrStorageTable Series
NOTE: The file systems /, /config, /var,

and /tmp always return the same
index number. When SNMP restarts,
the index numbers for the remaining
file systems might change.
• hrSystem group
• hrSWInstalled group
• hrProcessorTable


RFC 2819, Remote Network Monitoring Supported tables and objects: ACX Series, EX Series, M Series, MX
Management Information Base Series, PTX Series, SRX Series, and T
• etherStatsTable (for Ethernet Series
interfaces only), alarmTable,
eventTable, and logTable are
supported on all devices running Junos
OS.
• historyControlTable and
etherHistoryTable (except
etherHistoryUtilization object) are
supported only on EX Series switches.
RFC 2863, The Interfaces Group MIB No exceptions ACX Series, EX Series, M Series, MX
NOTE: RFC 2863 replaces RFC 2233. Series
However, Junos OS supports both RFC
2233 and RFC 2863.
RFC 2864, The Inverted Stack Table No exceptions M Series, MX Series, PTX Series, SRX
Extension to the Interfaces Group MIB Series, and T Series
RFC 2922, The Physical Topology Supported objects: EX Series and SRX Series
(PTOPO) MIB
• ptopoConnDiscAlgorithm
• ptopoConnAgentNetAddrType
• ptopoConnAgentNetAddr
• ptopoConnMultiMacSASeen
• ptopoConnMultiNetSASeen
• ptopoConnIsStatic
• ptopoConnLastVerifyTime
• ptopoConnRowStatus
RFC 2925, Definitions of Managed Objects Supported tables and objects: ACX Series, EX Series, M Series, MX
for Remote Ping, Traceroute, and Lookup Series, PTX Series, SRX Series, and T
Operations • pingCtlTable Series
• pingResultsTable
• pingProbeHistoryTable
• pingMaxConcurrentRequests
• traceRouteCtlTable
• traceRouteResultsTable
• traceRouteProbeHistoryTable
• traceRouteHopsTable
RFC 2932, IPv4 Multicast Routing MIB No exceptions ACX Series, EX Series, M Series, MX
Series


RFC 2934, Protocol Independent Support for the pimNeighborLoss trap ACX Series, EX Series, M Series, MX
Multicast MIB for IPv4 was added in Release 11.4. Series, PTX Series, SRX Series, and T
Series
NOTE: In Junos OS, RFC 2934 is
implemented based on a draft version,
pimmib.mib, of the now standard RFC.
RFC 2981, Event MIB No exceptions ACX Series, M Series, MX Series, PTX
Series, and T Series
RFC 3014, Notification Log MIB No exceptions ACX Series, M Series, MX Series, PTX
Series, and T Series
RFC 3019, IP Version 6 Management No exceptions M Series, MX Series, PTX Series, SRX
Information Base for The Multicast Series, and T Series
Listener Discovery Protocol
RFC 3410, Introduction and Applicability No exceptions ACX Series, EX Series, M Series, MX
Statements for Internet-Standard Series, PTX Series, SRX Series, and T
Management Framework Series
RFC 3411, An Architecture for Describing No exceptions ACX Series, EX Series, M Series, MX
Simple Network Management Protocol Series, PTX Series, SRX Series, and T
(SNMP) Management Frameworks Series
NOTE: RFC 3411 replaces RFC 2571.

3411 and RFC 2571.
RFC 3412, Message Processing and No exceptions ACX Series, EX Series, M Series, MX
Dispatching for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3412 replaces RFC 2572.

3412 and RFC 2572.
RFC 3413, Simple Network Management Unsupported tables and objects: ACX Series, EX Series, M Series, MX
Protocol (SNMP) Applications Series, PTX Series, SRX Series, and T
• Proxy MIB Series
RFC 3414, User-based Security Model No exceptions ACX Series, EX Series, M Series, MX
(USM) for version 3 of the Simple Network Series, PTX Series, SRX Series, and T
Management Protocol (SNMPv3) Series
RFC 3415, View-based Access Control No exceptions ACX Series, EX Series, M Series, MX
Model (VACM) for the Simple Network Series, PTX Series, SRX Series, and T


RFC 3416, Version 2 of the Protocol No exceptions ACX Series, EX Series, M Series, MX
Operations for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3416 replaces RFC 1905,

which was supported in earlier versions
of Junos OS.
RFC 3417, Transport Mappings for the No exceptions ACX Series, EX Series, M Series, MX
Simple Network Management Protocol Series, PTX Series, SRX Series, and T
(SNMP) Series
RFC 3418, Management Information Base No exceptions ACX Series, EX Series, M Series, MX
(MIB) for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3418 replaces RFC 1907,

which was supported in earlier versions
of Junos OS.
RFC 3498, Definitions of Managed No exceptions M Series and T Series

Objects for Synchronous Optical Network
(SONET) Linear Automatic Protection
Switching (APS) Architectures
(implemented under the Juniper
Networks enterprise branch
[jnxExperiment])
RFC 3584, Coexistence between Version No exceptions ACX Series, EX Series, M Series, MX
1, Version 2, and Version 3 of the Series, PTX Series, SRX Series, and T
Internet-standard Network Management Series
Framework
RFC 3591 Managed Objects for the Supported tables and objects: M Series, MX Series, PTX Series, and T
Optical Interface Type Series
• optIfOTMnTable (except
optIfOTMnOpticalReach,
optIfOTMnInterfaceType, and
optIfOTMnOrder)
• optIfOChConfigTable (except
optIfOChDirectionality and
optIfOChCurrentStatus)
• optIfOTUkConfigTable (except
optIfOTUkTraceIdentifierAccepted,
optIfOTUkTIMDetMode,
optIfOTUkTIMActEnabled,
optIfOTUkTraceIdentifierTransmitted,
optIfOTUkDEGThr, optIfOTUkDEGM,
optIfOTUkSinkAdaptActive, and
optIfOTUkSourceAdaptActive)
• optIfODUkConfigTable (except
optIfODUkPositionSeqCurrentSize and
optIfODUkTtpPresent)


RFC 3592, Definitions of Managed Objects No exceptions M Series, MX Series, and T Series
for the Synchronous Optical
Network/Synchronous Digital Hierarchy
(SONET/SDH) Interface Type
RFC 3621, Power Ethernet MIB No exceptions EX Series
RFC 3635, Definitions of Managed Objects Unsupported tables and objects: MX Series
for the Ethernet-like Interface Types
• dot3StatsRateControlAbility
• dot3StatsRateControlStatus in
dot3StatsEntry table
NOTE: The values of the following

objects in dot3HCStatsEntry table will be
always zero for both 32-bit counters and
64-bit counters:
• dot3HCStatsSymbolErrors
• dotHCStatsInternalMacTransmitErrors
RFC 3637, Definitions of Managed Objects Unsupported tables and objects: M Series, MX Series, PTX Series, and T
for the Ethernet WAN Interface Sublayer Series
• etherWisDeviceTable,
• etherWisSectionCurrentTable
• etherWisFarEndPathCurrentTable
RFC 3811, Definitions of Textual No exceptions ACX Series, M Series, MX Series, PTX
Conventions (TCs) for Multiprotocol Label Series, SRX Series, and T Series
Switching (MPLS) Management


RFC 3812, Multiprotocol Label Switching MPLS tunnels as interfaces are not ACX Series, M Series, MX Series, PTX
(MPLS) Traffic Engineering (TE) supported. Series, and T Series
Management Information Base (MIB)
(read-only access) mplsTunnelCHopTable is supported on
ingress routers only.
NOTE: The branch used by the

proprietary LDP MIB (ldpmib.mib)
conflicts with RFC 3812. ldpmib.mib has
been deprecated and replaced by
jnx-mpls-ldp.mib.
Unsupported tables and objects:
• mplsTunnelResourceMeanRate in
TunnelResource table
• mplsTunnelResourceMaxBurstSize in
• mplsTunnelResourceMeanBurstSize in
• mplsTunnelResourceExBurstSize in
• mplsTunnelResourceWeight in
• mplsTunnelPerfTable
• mplsTunnelCRLDPResTable
RFC 3813, Multiprotocol Label Switching Unsupported tables and objects ACX Series, M Series, MX Series, PTX
(MPLS) Label Switching Router (LSR) (read-only access): Series, SRX Series, and T Series
• mplsInterfacePerfTable
• mplsInSegmentPerfTable
• mplsOutSegmentPerfTable
• mplsInSegmentMapTable
• mplsXCUp
• mplsXCDown
RFC 3826, The Advanced Encryption No exceptions ACX Series, EX Series, M Series, MX
Standard (AES) Cipher Algorithm in the Series, PTX Series, SRX Series, and T
SNMP User-based Security Model Series
RFC 3877, Alarm Management • Junos OS does not support the MX Series
Information Base alarmActiveStatsTable.
• Traps that do not conform to the
alarm model are not supported.
However, these traps can be redefined
to conform to the alarm model.


RFC 3896, Definitions of Managed Unsupported tables and objects: M Series and T Series
Objects for the DS3/E3 Interface Type
• dsx3FarEndConfigTable
• dsx3FarEndCurrentTable
• dsx3FarEndIntervalTable
• dsx3FarEndTotalTable
• dsx3FracTable
RFC 4087, IP Tunnel MIB Describes MIB objects in the following M Series, MX Series, and T Series
tables for managing tunnels of any type
over IPv4 and IPv6 networks:
• tunnelIfTable—Provides information
about the tunnels known to a router.
• tunnelInetConfigTable—Assists
dynamic creation of tunnels and
provides mapping from end-point
addresses to the current interface
index value.
NOTE: Junos OS supports MAX-ACCESS

of read-only for all the MIB objects in
tunnelIfTable and tunnelInetConfigTable
tables.
RFC 4133, Entity MIB Unsupported tables and objects: Only MX240, MX480, and MX960
routers, and EX2200 and EX3300
• entityLogicalGroup table switches
• entPhysicalMfgDate and
entPhysicalUris objects in
entityPhysical2Group table
• entLPMappingTable and
entPhysicalContainsTable in
entityMappingGroup table
• entityNotoficationsGroup table
RFC 4188, Definitions of Managed Objects • Supports 802.1D STP(1998) MX Series, EX Series, and M Series and
for Bridges • Supported subtrees and objects: T Series
• dot1dStp subtree is supported on

MX Series 3D Universal Edge
Routers.
• dot1dTpFdbAddress,
dot1dTpFdbPort, and
dot1dTpFdbStatus objects from the
dot1dTpFdbTable of the dot1dTp
subtree are supported on EX Series
Ethernet Switches.
• dot1dTpLearnedEntryDiscards and
dot1dTpAgingTime objects are
supported on M Series and T Series
routers.


RFC 4268, Entity State MIB No exceptions Only MX240, MX480, and MX960
routers, and EX2200 and EX3300
switches
RFC 4273, Definitions of Managed Objects Supported tables and objects: ACX Series, EX Series, M Series, MX
for BGP-4 Series, SRX Series, and T Series
• jnxBgpM2PrefixInPrefixesAccepted
• jnxBgpM2PrefixInPrefixesRejected
RFC 4292, IP Forwarding MIB Supported tables and objects: ACX Series, EX Series, M Series, MX
Series, PTX Series, and T Series
• inetCidrRouteTable
• inetCidrRouteNumber
• inetCidrRouteDiscards
NOTE: Junos OS currently supports

these MIB objects that will be deprecated
in future releases: ipCidrRouteTable,
ipCidrRouteNumber, and
ipCidrRouteDiscards.
RFC 4293, Management Information Base Supports only the mandatory groups. MX Series and EX Series
for the Internet Protocol (IP)
RFC 4318, Definitions of Managed Objects Supports 802.1w and 802.1t extensions EX Series, M Series, MX Series, and T
for Bridges with Rapid Spanning Tree for RSTP. Series
Protocol
RFC 4363b, Q-Bridge VLAN MIB No exceptions MX Series and EX Series
RFC 4382, MPLS/BGP Layer 3 Virtual Supported tables and objects: EX Series, M Series, MX Series, PTX
Private Network (VPN) MIB Series, and T Series
• mplsL3VpnActiveVrfs
• mplsL3VpnConfiguredVrfs
• mplsL3VpnConnectedInterfaces
• mplsL3VpnVrfConfMidRteThresh
• mplsL3VpnVrfConfHighRteThresh
• mplsL3VpnIfConfRowStatus
• mplsL3VpnIllLblRcvThrsh
• mplsL3VpnNotificationEnable
• mplsL3VpnVrfConfMaxPossRts
• mplsL3VpnVrfConfRteMxThrshTime
• mplsL3VpnVrfOperStatus
• mplsL3VpnVrfPerfCurrNumRoutes
• mplsL3VpnVrfPerfTable
• mplsL3VpnVrfRteTable
• mplsVpnVrfRTTable
• mplsL3VpnVrfTable
• mplsL3VpnIfConfTable


RFC 4444, IS-IS MIB No exceptions ACX Series, EX Series, M Series, MX

Series
RFC 4668, RADIUS Accounting Client No exceptions MX Series

Management Information Base (MIB) for
IPv6 (read-only access)
RFC 4670, RADIUS Accounting Client No exceptions MX Series

(read-only access)
RFC 4801, Definitions of Textual No exceptions M Series, MX Series, and T Series

Conventions for Generalized Multiprotocol
Label Switching (GMPLS) Management
Information Base (MIB) (read-only
access)
RFC 4802, Generalized Multiprotocol Unsupported tables and objects: M Series, MX Series, and T Series
Label Switching (GMPLS) Traffic
Engineering (TE) Management • gmplsTunnelReversePerfTable
Information Base (MIB) (read-only • gmplsTeScalars
access)
• gmplsTunnelTable
• gmplsTunnelARHopTable
• gmplsTunnelCHopTable
• gmplsTunnelErrorTable
RFC 4803, Generalized Multiprotocol Unsupported tables and objects: M Series, MX Series, and T Series
Label Switching (GMPLS) Label Switching
Router (LSR) Management Information • gmplsLabelTable
Base (MIB) (read-only access) • gmplsOutsegmentTable
NOTE: The tables in GMPLS TE (RFC

4802) and LSR (RFC 4803) MIBs are
extensions of the corresponding tables
from the MPLS TE (RFC 3812) and LSR
(RFC 3813) MIBs and use the same index
as the MPLS MIB tables.
RFC 5132, IP Multicast MIB Unsupported table: All platforms
NOTE: This RFC obsoletes RFC2932. • ipMcastZoneTable


RFC 5643, Management Information Base Unsupported tables and objects: M Series, MX Series, PTX Series, SRX
for OSPFv3 (read-only access) Series, and T Series
• ospfv3HostTable
• ospfv3CfgNbrTable
• ospfv3ExitOverflowInterval
• ospfv3ReferenceBandwidth
• ospfv3RestartSupport
• ospfv3RestartInterval
• ospfv3RestartStrictLsaChecking
• ospfv3RestartStatus
• ospfv3RestartAge
• ospfv3RestartExitReason
• ospfv3NotificationEnable
• ospfv3StubRouterSupport
• ospfv3StubRouterAdvertisement
• ospfv3DiscontinuityTime
• ospfv3RestartTime
• ospfv3AreaNssaTranslatorRole
• ospfv3AreaNssaTranslatorState
• ospfv3AreaNssaTranslatorStabInterval
• ospfv3AreaNssaTranslatorEvents
• ospfv3AreaTEEnabled
• ospfv3IfMetricValue
• ospfv3IfDemandNbrProbe
RFC 6527, Definitions of Managed Objects • Row creation ACX Series

for the Virtual Router Redundancy • The Set operation
Protocol Version 3 (VRRPv3)
• Unsupported tables and objects:
• vrrpv3StatisticsRowDiscontinuityTime
• vrrpv3StatisticsPacketLengthErrors
Internet Assigned Numbers Authority, No exceptions ACX Series, EX Series, M Series, MX

IANAiftype Textual Convention MIB Series, PTX Series, SRX Series, and T
Series
Internet draft As defined under the Juniper Networks M Series, MX Series, and T Series
draft-ietf-atommib-sonetaps-mib-10.txt, enterprise branch [jnxExperiment] only
Definitions of Managed Objects for
SONET Linear APS Architectures
Internet draft draft-ieft-bfd-mib-02.txt, (Represented by mib-jnx-bfd-exp.txt and ACX Series, EX Series, M Series, MX
Bidirectional Forwarding Detection implemented under the Juniper Networks Series, SRX Series, and T Series
Management Information Base enterprise branch [jnxExperiment]. Read
only. Includes bfdSessUp and
bfdSessDown traps. Does not support
bfdSessPerfTable and
bfdSessMapTable.)


Internet draft (Implemented under the Juniper M Series, MX Series, and T Series
draft-ietf-l3vpn-mvpn-mib-03.txt, Networks enterprise branch
MPLS/BGP Layer 3 VPN Multicast [jnxExperiment]. OID for
Management Information Base jnxMvpnExperiment is .1.3.6.1.4.1.2636.5.12.
Read only. Includes jnxMvpnNotifications
traps.)
Internet draft No exceptions EX Series, M Series, MX Series, PTX

draft-ietf-idmr-igmp-mib-13.txt, Internet Series, SRX Series, and T Series
Group Management Protocol (IGMP) MIB
Internet draft No exceptions ACX Series, EX Series, M Series, MX

draft-reeder-snmpv3-usm-3desede-00.txt, Series, PTX Series, SRX Series, and T
Extension to the User-Based Security Series
Model (USM) to Support Triple-DES EDE
in ‘Outside’ CBC Mode
Internet draft Unsupported tables and objects: ACX Series, EX Series, M Series, MX
draft-ietf-isis-wg-mib-07.txt, Series, PTX Series, SRX Series, and T
Management Information Base for IS-IS • isisISAdjTable Series
• isisISAdjAreaAddrTable
NOTE: Replaced with RFC 4444, IS-IS
• isisISAdjIPAddrTable
MIB in Junos OS Release 11.3 and later.
• isisISAdjProtSuppTable)
Internet draft Supported tables and objects: M Series, MX Series, PTX Series, and T
draft-ietf-ppvpn-mpls-vpn-mib-04.txt, Series
MPLS/BGP Virtual Private Network • mplsVpnScalars
Management Information Base Using • mplsVpnVrfTable
SMIv2
• mplsVpnPerTable
• mplsVpnVrfRouteTargetTable
Internet draft Support for ospfv3NbrTable only. M Series, MX Series, PTX Series, SRX
draft-ietf-ospf-ospfv3-mib-11.txt, Series, and T Series
Management Information Base for
OSPFv3
Internet draft No exceptions ACX Series, EX Series, M Series, MX

draft-ietf-idmr-pim-mib-09.txt, Protocol Series, PTX Series, SRX Series , and T
Independent Multicast (PIM) MIB Series
ESO Consortium MIB, which can be No exceptions ACX Series, EX Series, M Series, MX
found at http://www.snmp.com/eso/ Series, PTX Series, SRX Series, and T
Series
NOTE: The ESO Consortium MIB has
been replaced by RFC 3826.
Internet Draft P2MP MPLS-TE MIB Unsupported table: ACX Series, M Series, MX Series, PTX
(draft-ietf-mpls-p2mp-te-mib-09.txt) Series, and T Series
(read-only access) • mplsTeP2mpTunnelBranchPerfTable
For information about standard SNMP MIB objects, see the SNMP MIB Explorer.

Related • Enterprise-Specific SNMP MIBs Supported by Junos OS on page 19

Documentation
• Network Management Administration Guide
• Standard SNMP Traps Supported by Junos OS on page 57
Enterprise-Specific MIBs and Supported Devices
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, SRX Series, T Series, vSRX
NOTE: Starting with Junos OS Release 16.1, this topic has been deprecated;
refer instead to “Enterprise-Specific SNMP MIBs Supported by Junos OS” on
page 19.
Table 8 on page 47 lists the enterprise-specific MIBs that are supported on various devices
running Junos OS.
NOTE: In this table, a value of 1 in any of the platform columns (ACX, M, MX,
T, EX, PTX, and SRX) denotes that the corresponding MIB is supported on
that particular platform. A value of 0 denotes that the MIB is not supported
on the platform.
Table 8: Enterprise-Specific MIBs and Supported Devices

Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Enterprise-Specific MIB ACX M T MX EX PTX SRX340 SRX550M SRX5800
AAA Objects MIB 0 1 1 0 0 0 0 1 1
http://www.juniper.net/techpubs/en_US/junos15.1/
topics/reference/mibs/mib-jnx-user-aaa.txt
Access Authentication Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-auth.txt
Alarm MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-chassis-alarm.txt

Table 8: Enterprise-Specific MIBs and Supported Devices (continued)

Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Analyzer MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-analyzer.txt
Antivirus Objects MIB 0 0 0 0 0 0 1 0 0
topics/reference/mibs/mib-jnx-js-utm-av.txt
ATM Class-of-Service MIB 0 1 1 0 0 0 1 0 1
topics/reference/mibs/mib-jnx-atm-cos.txt
ATM MIB 1 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-atm.txt
BGP4 V2 MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-bgpmib2.txt
Bidirectional Forwarding Detection MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-bfd.txt
Chassis Forwarding MIB 1 0 0 0 1 1 1 0 0
topics/reference/mibs/mib-jnx-chassis-fwdd.txt
Chassis MIBs 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-chassis.txt
topics/reference/mibs/mib-jnx-chas-defines.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Chassis Cluster MIBs 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-jsrpd.txt
Class-of-Service MIB 1 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-cos.txt
Configuration Management MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-cfgmgmt.txt
Destination Class Usage MIB 0 1 1 0 1 0 0 1 1
topics/reference/mibs/mib-jnx-dcu.txt
DHCP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-jdhcp.txt
DHCPv6 MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-jdhcpv6.txt
Digital Optical Monitoring MIB 0 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-dom.txt
DNS Objects MIB 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-js-dns.txt
Dynamic Flow Capture MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-dfc.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Ethernet MAC MIB 0 1 1 1 1 0 0 0 1
topics/reference/mibs/jnx-mac.txt
Event MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-event.txt
EX Series MAC Notification MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-ex-mac-notification.txt
EX Series SMI MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-ex-smi.txt
Experimental MIB 1 1 1 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-exp.txt
Firewall MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-firewall.txt
Flow Collection Services MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-coll.txt
Host Resources MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-hostresources.txt
Interface MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-if-extensions.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
IP Forward MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-ipforward.txt
IPsec Generic Flow Monitoring Object MIB 0 0 0 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-ipsec-flow-mon.txt
IPsec Monitoring MIB 0 1 1 1 1 0 0 1 0
topics/reference/mibs/mib-jnx-ipsec-monitor-asp.txt
IPsec VPN Objects MIB 0 0 0 0 0 0 1 0 0
topics/reference/mibs/mib-jnx-js-ipsec-vpn.txt
IPv4 MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-ipv4.txt
IPv6 and ICMPv6 MIB 0 1 1 1 0 1 1 1 1
topics/reference/mibs/mib-jnx-ipv6.txt
L2ALD MIB 0 0 1 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2ald.txt
L2CP MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2cp-features.txt
L2TP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2tp.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
LDP MIB 1 1 1 0 0 1 0 0 1
topics/reference/mibs/mib-jnx-ldp.txt
License MIB 0 1 1 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-license.txt
Logical Systems MIB 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-lsys-securityprofile.txt
MIMSTP MIB 0 0 1 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-mimstp.txt
MPLS LDP MIB 1 1 1 1 1 1 0 0 0
topics/reference/mibs/mib-jnx-mpls-ldp.txt
MPLS MIB 1 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-mpls.txt
MVPN MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-mvpn.txt and
topics/reference/mibs/mib-jnx-l2l3vpn-mcast.txt.
NAT Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-nat.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
NAT Resources-Monitoring MIB 0 1 1 0 0 0 0 0 0
topics/reference/ mibs/mib-jnx-sp-nat.txt
OTN Interface Management MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-otn.txt
Packet Forwarding Engine MIB 1 1 1 0 1 1 1 1 1
topics/reference/mibs/mib-jnx-pfe.txt
Packet Mirror MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-js-packet-mirror.txt
PAE Extension MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-pae-extension.txt
Passive Monitoring MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-pmon.txt
Ping MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-ping.txt
Policy Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-policy.txt
Power Supply Unit MIB 0 0 0 1 0 1 0 0 0
topics/reference/mibs/mib-jnx-power-supply-unit.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
PPP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-ppp.txt
PPPoE MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-pppoe.txt
Pseudowire ATM MIB 0 1 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-pwatm.txt
Pseudowire TDM MIB 1 1 1 0 0 0 0 0 0
topics/ reference/mibs/mib-jnx-pwtdm.txt
PTP MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-timing-notifications.txt
Real-Time Performance Monitoring MIB 0 1 1 1 1 0 1 0 0
topics/reference/mibs/mib-jnx-rpm.txt
Reverse-Path-Forwarding MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-rpf.txt
RMON Events and Alarms MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-rmon.txt
RSVP MIB 1 1 1 1 0 1 0 0 0
topics/reference/mibs/mib-jnx-rsvp.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Security Interface Extension Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-if-ext.txt
Security Screening Objects MIB 0 0 0 0 0 0 0 0 1
topics/reference/mibs/mib-jnx-js-screening.txt
Services PIC MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sp.txt
SNMP IDP MIB 0 0 0 0 0 0 1 1 0
topics/reference/mibs/mib-jnx-js-idp.txt
SONET APS MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sonetaps.txt
SONET/SDH Interface Management MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sonet.txt
Source Class Usage MIB 0 1 1 0 0 0 0 0 1
topics/reference/mibs/mib-jnx-scu.txt
SPU Monitoring MIB 0 0 0 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-js-spu-monitoring.txt
Structure of Management Information MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-smi.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Subscriber MIB 1 0 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-subscriber.txt
System Log MIB 0 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-syslog.txt
Traceroute MIB 0 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-traceroute.txt
Utility MIB 0 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-util.txt
Virtual Chassis MIB 0 0 0 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-virtualchassis.txt
VLAN MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-vlan.txt
VPLS MIBs 0 1 1 1 0 0 0 0 0
• http://www.juniper.net/techpubs/en_US/junos15.1/
topics/reference/mibs/mib-jnx-vpls-generic.txt
topics/reference/mibs/mib-jnx-vpls-ldp.txt
topics/reference/mibs/mib-jnx-vpls-bgp.txt
VPN Certificate Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-cert.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
VPN MIB 1 1 1 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-vpn.txt
Related • Enterprise-Specific SNMP Traps Supported by Junos OS on page 64

Documentation
• Standard SNMP MIBs Supported by Junos OS
Standard SNMP Traps Supported by Junos OS
vSRX
This topic provides the list of standard SNMPv1 and SNMPv2 traps supported by devices
running Junos OS. For more information about traps see SNMP MIB Explorer.
Standard SNMP Version 1 Traps

Table 9 on page 57 provides an overview of the standard traps for SNMPv1. The traps
are organized first by trap category and then by trap name, and include their enterprise
ID, generic trap number, and specific trap number. The system logging severity levels are
listed for those traps that have them with their corresponding system log tag. Traps that
do not have corresponding system logging severity levels are marked with an en dash
(–) in the table.
For more information about system log messages, see the System Log Explorer. For more
information about configuring system logging, see the Junos OS System Basics
Configuration Guide.
Table 9: Standard Supported SNMP Version 1 Traps

System
Generic Specific Logging
Trap Trap Severity
Defined in Trap Name Enterprise ID Number Number Level Syslog Tag Supported On
Startup Notifications

Table 9: Standard Supported SNMP Version 1 Traps (continued)

System
Trap Trap Severity
RFC 1215, authenticationFailure 1.3.6.1.4.1.2636 4 0 Notice SNMPD_ TRAP_ All devices running
Conventions GEN_FAILURE Junos OS.
for Defining
Traps for
coldStart 1.3.6.1.4.1.2636 0 0 Critical SNMPD_TRAP_ All devices running
Use with
COLD_START Junos OS.
the SNMP
warmStart 1.3.6.1.4.1.2636 1 0 Error SNMPD_TRAP_ All devices running

WARM_START Junos OS.
Link Notifications
RFC 1215, linkDown 1.3.6.1.4.1.2636 2 0 Warning SNMP_ TRAP_ All devices running
Conventions LINK_DOWN Junos OS.
for Defining
Traps for
linkUp 1.3.6.1.4.1.2636 3 0 Info SNMP_TRAP_ All devices running
Use with
LINK_UP Junos OS.
the SNMP
Remote Operations Notifications
RFC 2925, pingProbeFailed 1.3.6.1.2.1.80.0 6 1 Info SNMP_TRAP _PING_ All devices running
Definitions PROBE_ FAILED Junos OS.
of Managed
Objects for pingTestFailed 1.3.6.1.2.1.80.0 6 2 Info SNMP_TRAP_ All devices running
Remote PING_TEST _FAILED Junos OS.
Ping,
Traceroute,
pingTestCompleted 1.3.6.1.2.1.80.0 6 3 Info SNMP_TRAP_ All devices running
and Lookup
PING_TEST_ Junos OS.
Operations
COMPLETED
traceRoutePathChange 1.3.6.1.2.1.81.0 6 1 Info SNMP_TRAP_ All devices running

TRACE_ROUTE_ Junos OS.
PATH_CHANGE
traceRouteTestFailed 1.3.6.1.2.1.81.0 6 2 Info SNMP_TRAP_ All devices running

TEST_FAILED
traceRouteTestCompleted 1.3.6.1.2.1.81.0 6 3 Info SNMP_TRAP_ All devices running

TEST_COMPLETED
RMON Alarms
RFC 2819a, fallingAlarm 1.3.6.1.2.1.16 6 2 – – All devices running
RMON MIB Junos OS.
risingAlarm 1.3.6.1.2.1.16 6 1 – – All devices running

Junos OS.


System
Trap Trap Severity
Routing Notifications
BGP 4 MIB bgpEstablished 1.3.6.1.2.1.15.7 6 1 – – M, T, MX, J, EX, and
SRX Series devices.
bgpBackwardTransition 1.3.6.1.2.1.15.7 6 2 – – M, T, MX, J, EX, and

SRX Series devices.
OSPF TRAP ospfVirtIfStateChange 1.3.6.1.2.1.14.16.2 6 1 – – M, T, MX, J, EX, and

MIB SRX Series devices.
ospfNbrStateChange 1.3.6.1.2.1.14.16.2 6 2 – – M, T, MX, J, EX, and

SRX Series devices.
ospfVirtNbrStateChange 1.3.6.1.2.1.14.16.2 6 3 – – M, T, MX, J, EX, and

SRX Series devices.
ospfIfConfigError 1.3.6.1.2.1.14.16.2 6 4 – – M, T, MX, J, EX, and

SRX Series devices.
ospfVirtIfConfigError 1.3.6.1.2.1.14.16.2 6 5 – – M, T, MX, J, EX, and

SRX Series devices.
ospfIfAuthFailure 1.3.6.1.2.1.14.16.2 6 6 – – M, T, MX, J, EX, and

SRX Series devices.
ospfVirtIfAuthFailure 1.3.6.1.2.1.14.16.2 6 7 – – M, T, MX, J, EX, and

SRX Series devices.
ospfIfRxBadPacket 1.3.6.1.2.1.14.16.2 6 8 – – M, T, MX, J, EX, and

SRX Series devices.
ospfVirtIfRxBadPacket 1.3.6.1.2.1.14.16.2 6 9 – – M, T, MX, J, EX, and

SRX Series devices.
ospfTxRetransmit 1.3.6.1.2.1.14.16.2 6 10 – – M, T, MX, J, EX, and

SRX Series devices.
ospfVirtIfTxRetransmit 1.3.6.1.2.1.14.16.2 6 11 – – M, T, MX, J, EX, and

SRX Series devices.
ospfMaxAgeLsa 1.3.6.1.2.1.14.16.2 6 13 – – M, T, MX, J, EX, and

SRX Series devices.
ospfIfStateChange 1.3.6.1.2.1.14.16.2 6 16 – – M, T, MX, J, EX, and

SRX Series devices.


System
Trap Trap Severity
VRRP Notifications
RFC 2787, vrrpTrapNewMaster 1.3.6.1.2.1.68 6 1 Warning VRRPD_NEW All devices running
Definitions MASTER_TRAP Junos OS.
of Managed
Objects for
vrrpTrapAuthFailure 1.3.6.1.2.1.68 6 2 Warning VRRPD_AUTH_ All devices running
the Virtual
FAILURE_TRAP Junos OS.
Router
Redundancy
Protocol
RFC 6527, vrrpv3NewMaster 1.3.6.1.2.1.207 6 1 Warning VRRPD_NEW_MASTER M and MX

Definitions
of Managed
vrrpv3ProtoError 1.3.6.1.2.1.207 6 2 Warning VRRPD_V3_PROTO_ERROR M and MX
Objects for
the Virtual
Router
Redundancy
Protocol
Version 3
(VRRPv3)
Standard SNMP Version 2 Traps

Table 10 on page 60 provides an overview of the standard SNMPv2 traps supported by
the Junos OS. The traps are organized first by trap category and then by trap name and
include their snmpTrapOID. The system logging severity levels are listed for those traps
that have them with their corresponding system log tag. Traps that do not have
corresponding system logging severity levels are marked with an en dash (–) in the table.
For more information about system log messages, see System Log Messages Configuration
Guide.
Table 10: Standard Supported SNMP Version 2 Traps

System
Logging
Severity
Defined in Trap Name snmpTrapOID Level Syslog Tag Supported On
Startup Notifications


System
Logging
Severity
RFC 1907, coldStart 1.3.6.1.6.3.1.1.5.1 Critical SNMPD_TRAP_ All devices running

Management COLD_START Junos OS.
Information Base
for Version 2 of
warmStart 1.3.6.1.6.3.1.1.5.2 Error SNMPD_TRAP_ All devices running
the Simple
WARM_START Junos OS.
Network
Management
Protocol authenticationFailure 1.3.6.1.6.3.1.1.5.5 Notice SNMPD_TRAP_ All devices running
(SNMPv2) GEN_FAILURE Junos OS.
Link Notifications
RFC 2863, The linkDown 1.3.6.1.6.3.1.1.5.3 Warning SNMP_TRAP_ All devices running
Interfaces Group LINK_DOWN Junos OS.
MIB
linkUp 1.3.6.1.6.3.1.1.5.4 Info SNMP_TRAP_ All devices running
LINK_UP Junos OS.

RFC 2925, pingProbeFailed 1.3.6.1.2.1.80.0.1 Info SNMP_TRAP_ All devices running
Definitions of PING_PROBE_ Junos OS.
Managed Objects FAILED
for Remote Ping,
Traceroute, and
pingTestFailed 1.3.6.1.2.1.80.0.2 Info SNMP_TRAP_PING_ All devices running
Lookup
TEST_FAILED Junos OS.
Operations
pingTestCompleted 1.3.6.1.2.1.80.0.3 Info SNMP_TRAP_PING_ All devices running

TEST_COMPLETED Junos OS.
traceRoutePathChange 1.3.6.1.2.1.81.0.1 Info SNMP_TRAP_TRACE_ All devices running

ROUTE_PATH_ Junos OS.
CHANGE
traceRouteTestFailed 1.3.6.1.2.1.81.0.2 Info SNMP_TRAP_TRACE_ All devices running

ROUTE_TEST_FAILED Junos OS.
traceRouteTestCompleted 1.3.6.1.2.1.81.0.3 Info SNMP_TRAP_TRACE_ All devices running

ROUTE_TEST_ Junos OS.
COMPLETED
RMON Alarms
RFC 2819a, RMON fallingAlarm 1.3.6.1.2.1.16.0.1 – – All devices running
MIB Junos OS.
risingAlarm 1.3.6.1.2.1.16.0.2 – – All devices running

Junos OS.


System
Logging
Severity
BGP 4 MIB bgpEstablished 1.3.6.1.2.1.15.7.1 – – All devices running
Junos OS.
bgpBackwardTransition 1.3.6.1.2.1.15.7.2 – – All devices running

Junos OS.
OSPF Trap MIB ospfVirtIfStateChange 1.3.6.1.2.1.14.16.2.1 – – All devices running

Junos OS.
ospfNbrStateChange 1.3.6.1.2.1.14.16.2.2 – – All devices running

Junos OS.
ospfVirtNbrStateChange 1.3.6.1.2.1.14.16.2.3 – – All devices running

Junos OS.
ospfIfConfigError 1.3.6.1.2.1.14.16.2.4 – – All devices running

Junos OS.
ospfVirtIfConfigError 1.3.6.1.2.1.14.16.2.5 – – All devices running

Junos OS.
ospfIfAuthFailure 1.3.6.1.2.1.14.16.2.6 – – All devices running

Junos OS.
ospfVirtIfAuthFailure 1.3.6.1.2.1.14.16.2.7 – – All devices running

Junos OS.
ospfIfRxBadPacket 1.3.6.1.2.1.14.16.2.8 – – All devices running

Junos OS.
ospfVirtIfRxBadPacket 1.3.6.1.2.1.14.16.2.9 – – All devices running

Junos OS.
ospfTxRetransmit 1.3.6.1.2.1.14.16.2.10 – – All devices running

Junos OS.
ospfVirtIfTxRetransmit 1.3.6.1.2.1.14.16.2.11 – – All devices running

Junos OS.
ospfMaxAgeLsa 1.3.6.1.2.1.14.16.2.13 – – All devices running

Junos OS.
ospfIfStateChange 1.3.6.1.2.1.14.16.2.16 – – All devices running

Junos OS.


System
Logging
Severity
MPLS Notifications
RFC 3812, mplsTunnelUp
Multiprotocol
Label Switching
(MPLS) Traffic mplsTunnelDown
Engineering (TE)
Management
mplsTunnelRerouted
Information Base
mplsTunnelReoptimized
Entity State MIB Notifications
RFC 4268, Entity entStateOperEnabled 1.3.6.1.2.1.131.0.1 Notice CHASSISD_SNMP_TRAP3 MX240, MX480, and
State MIB MX960
entStateOperDisabled 1.3.6.1.2.1.131.0.2 Notice CHASSISD_SNMP_TRAP3 MX240, MX480, and

MX960
L3VPN Notifications
RFC 4382, mplsL3VpnVrfUp
MPLS/BGP Layer
3 Virtual Private
mplsL3VpnVrfDown
Network (VPN)
mplsL3VpnVrf
RouteMidThresh
Exceeded
mplsL3VpnVrf
NumVrfRouteMax
ThreshExceeded
mplsL3VpnNum
VrfRouteMax
ThreshCleared
VRRP Notifications
RFC 2787, vrrpTrapNewMaster 1.3.6.1.2.1.68.0.1 Warning VRRPD_ All devices running
Definitions of NEWMASTER_ TRAP Junos OS.
Managed Objects
for the Virtual
vrrpTrapAuthFailure 1.3.6.1.2.1.68.0.2 Warning VRRPD_AUTH_ All devices running
Router
FAILURE_ TRAP Junos OS.
Redundancy
Protocol


System
Logging
Severity
RFC 6527, vrrpv3NewMaster 1.3.6.1.2.1.207.0.1 Warning VRRPD_NEW_MASTER M and MX

Definitions of
Managed Objects
vrrpv3ProtoError 1.3.6.1.2.1.207.0.2 Warning VRRPD_V3_PROTO_ERROR M and MX
for the Virtual
Router
Redundancy
Protocol Version 3
(VRRPv3)
Related • Enterprise-Specific SNMP Traps Supported by Junos OS on page 64

Documentation
• Configuring SNMP Trap Options and Groups on a Device Running Junos OS on page 107
Enterprise-Specific SNMP Traps Supported by Junos OS
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, T Series
This topic provides the list of Juniper Networks enterprise-specific SNMPv1and SNMPv2
traps supported on devices running Junos OS. For more information about traps see
SNMP MIB Explorer.
• Juniper Networks Enterprise-Specific SNMP Version 1 Traps on page 64

• Juniper Networks Enterprise-Specific SNMP Version 2 Traps on page 70
Juniper Networks Enterprise-Specific SNMP Version 1 Traps

The Junos OS supports enterprise-specific SNMP version 1 traps shown in
Table 11 on page 65. The traps are organized first by trap category and then by trap name.
The system logging severity levels are listed for those traps that have them. Traps that
(–).
For more information about system log messages, see the Junos OS System Log Reference
for Security Devices.

Table 11: Juniper Networks Enterprise-Specific Supported SNMP Version 1 Traps

System
Trap Trap Severity System Supported
Defined in Trap Name Enterprise ID Number Number Level Log Tag On
Chassis Notifications (Alarm Conditions)

Chassis MIB jnxPowerSupplyFailure 1.3.6.1.4.1.2636.4.1 6 1 Warning CHASSISD_ All devices
(jnx-chassis. SNMP_ running Junos
mib) TRAP OS.
jnxFanFailure 1.3.6.1.4.1.2636.4.1 6 2 Critical CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxOverTemperature 1.3.6.1.4.1.2636.4.1 6 3 Alert CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxRedundancySwitchOver 1.3.6.1.4.1.2636.4.1 6 4 Critical CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruRemoval 1.3.6.1.4.1.2636.4.1 6 5 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruInsertion 1.3.6.1.4.1.2636.4.1 6 6 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruPowerOff 1.3.6.1.4.1.2636.4.1 6 7 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruPowerOn 1.3.6.1.4.1.2636.4.1 6 8 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruFailed 1.3.6.1.4.1.2636.4.1 6 9 Warning CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruOffline 1.3.6.1.4.1.2636.4.1 6 10 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruOnline 1.3.6.1.4.1.2636.4.1 6 11 Notice CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFruCheck 1.3.6.1.4.1.2636.4.1 6 12 Warning CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.

Table 11: Juniper Networks Enterprise-Specific Supported SNMP Version 1 Traps (continued)
System
jnxFEBSwitchover 1.3.6.1.4.1.2636.4.1 6 13 Warning CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxHardDiskFailed 1.3.6.1.4.1.2636.4.1 6 14 Warning CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxHardDiskMissing 1.3.6.1.4.1.2636.4.1 6 15 Warning CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxPowerSupplyOk 1.3.6.1.4.1.2636.4.2 6 1 Critical CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxFanOK 1.3.6.1.4.1.2636.4.2 6 2 Critical CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
jnxTemperatureOK 1.3.6.1.4.1.2636.4.2 6 3 Alert CHASSISD_ All devices

SNMP_ running Junos
TRAP OS.
Configuration Notifications
Configuration jnxCmCfgChange 1.3.6.1.4.1.2636.4.5 6 1 – – All devices
Management running Junos
MIB (jnx- OS.
configmgmt.
mib)
jnxCmRescueChange 1.3.6.1.4.1.2636.4.5 6 2 – – All devices
running Junos
OS.

System
Link Notifications
Flow jnxCollUnavailableDest 1.3.6.1.4.1.2636.4.8 6 1 – – Devices that
Collection run Junos OS
Services MIB and have
(jnx-coll.mib) collector PICs
installed.
jnxCollUnavailableDestCleared 1.3.6.1.4.1.2636.4.8 6 2 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollUnsuccessfulTransfer 1.3.6.1.4.1.2636.4.8 6 3 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollFlowOverload 1.3.6.1.4.1.2636.4.8 6 4 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollFlowOverloadCleared 1.3.6.1.4.1.2636.4.8 6 5 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollMemoryUnavailable 1.3.6.1.4.1.2636.4.8 6 6 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollMemoryAvailable 1.3.6.1.4.1.2636.4.8 6 7 – – Devices that

run Junos OS
and have
collector PICs
installed.
jnxCollFtpSwitchover 1.3.6.1.4.1.2636.4.8 6 8 – – Devices that

run Junos OS
and have
collector PICs
installed.

System
Passive jnxPMonOverloadSet 1.3.6.1.4.1.2636. 6 1 – – Devices that

Monitoring 4.7.0.1 run Junos OS
MIB and have PICs
(jnx-pmon.mib) that support
passive
monitoring
installed.
jnxPMonOverloadCleared 1.3.6.1.4.1.2636. 6 2 – – Devices that

4.7.0.2 run Junos OS
and have PICs
that support
passive
monitoring
installed.
SONET APS apsEventChannelMismatch 1.3.6.1.4.1.2636. 6 3 – – Devices that

MIB (jnx- 3.24.2 run Junos OS
sonetaps. and have
mib) SONET PICs
installed.
apsEventPSBF 1.3.6.1.4.1.2636. 6 4 – – Devices that

3.24.2 run Junos OS
and have
SONET PICs
installed.
apsEventFEPLF 1.3.6.1.4.1.2636. 6 5 – – Devices that

3.24.2 run Junos OS
and have
SONET PICs
installed.
Remote Operations
PING MIB jnxPingRttThresholdExceeded 1.3.6.1.4.1.2636.4.9 6 1 – – All devices
(jnx-ping.mib) running Junos
OS.
jnxPingRttStdDevThreshold 1.3.6.1.4.1.2636.4.9 6 2 – – All devices

Exceeded running Junos
OS.
jnxPingRttJitterThreshold Exceeded 1.3.6.1.4.1.2636.4.9 6 3 – – All devices

running Junos
OS.
jnxPingEgressThreshold Exceeded 1.3.6.1.4.1.2636.4.9 6 4 – – All devices

running Junos
OS.

System
jnxPingEgressStdDev 1.3.6.1.4.1.2636.4.9 6 5 – – All devices

ThresholdExceeded running Junos
OS.
jnxPingEgressJitter 1.3.6.1.4.1.2636.4.9 6 6 – – All devices

ThresholdExceeded running Junos
OS.
jnxPingIngressThreshold Exceeded 1.3.6.1.4.1.2636.4.9 6 7 – – All devices

running Junos
OS.
jnxPingIngressStddevThreshold 1.3.6.1.4.1.2636.4.9 6 8 – – All devices

OS.
jnxPingIngressJitterThreshold 1.3.6.1.4.1.2636.4.9 6 9 – – All devices

OS.
BFD bfdSessUp 1.3.6.1.4.1. 6 1 – – All devices
Experimental 2636.5.3.1 running Junos
MIB (jnx-bfd- OS.
exp.mib)
bfdSessDown 1.3.6.1.4.1. 6 2 – – All devices
2636.5.3.1 running Junos
OS.
LDP MIB jnxLdpLspUp 1.3.6.1.4.1.2636.4.4 6 1 – – M, T, and MX

(jnx-ldp.mib) Series routers.
jnxLdpLspDown 1.3.6.1.4.1.2636.4.4 6 2 – – M, T, and MX

Series routers.
jnxLdpSesUp 1.3.6.1.4.1.2636.4.4 6 3 – – M, T, and MX

Series routers.
jnxLdpSesDown 1.3.6.1.4.1.2636.4.4 6 4 – – M, T, and MX

Series routers.

System
MPLS MIB mplsLspUp (Deprecated) 1.3.6.1.4.1.2636.3.2.4 6 1 – –

(jnx-mpls.mib)
mplsLspDown (Deprecated) 1.3.6.1.4.1.2636.3.2.4 6 2 – –
mplsLspChange (Deprecated) 1.3.6.1.4.1.2636.3.2.4 6 3 – –
mplsLspPathDown (Deprecated) 1.3.6.1.4.1.2636.3.2.4 6 4 – –
VPN MIB jnxVpnIfUp 1.3.6.1.4.1.2636. 6 1 – – M, T, and MX

(jnx-vpn.mib) 3.26 Series routers.
jnxVpnIfDown 1.3.6.1.4.1.2636. 6 2 – – M, T, and MX

3.26 Series routers.
jnxVpnPwUp 1.3.6.1.4.1.2636. 6 3 – – M, T, and MX

jnxVpnPwDown 1.3.6.1.4.1.2636. 6 4 – – M, T, and MX

RMON Alarms
RMON MIB jnxRmonAlarmGetFailure 1.3.6.1.4.1.2636.4.3 6 1 – – All devices
(jnx-rmon. running Junos
mib) OS.
jnxRmonGetOk 1.3.6.1.4.1.2636.4.3 6 2 – – All devices

running Junos
OS.
SONET Alarms
SONET MIB jnxSonetAlarmSet 1.3.6.1.4.1.2636.4.6 6 1 – – Devices that
(jnx-sonet. run Junos OS
mib) and have
SONET PICs
installed.
jnxSonetAlarmCleared 1.3.6.1.4.1.2636.4.6 6 2 – – Devices that

run Junos OS
and have
SONET PICs
installed.
Juniper Networks Enterprise-Specific SNMP Version 2 Traps

The Junos OS supports the enterprise-specific SNMP version 2 traps shown in
Table 12 on page 71. The traps are organized first by trap category and then by trap name.

The system logging severity levels are listed for those traps that have them. Traps that
(–).
For more information about system messages, see the System Log Explorer. For more
information about configuring system logging, see the Junos OS Administration Library for
Routing Devices.
Table 12: Juniper Networks Enterprise-Specific Supported SNMP Version 2 Traps

System
Logging
Severity
Source MIB Trap Name snmpTrapOID Level System Log Tag Supported On
Chassis (Alarm Conditions) Notifications

Chassis MIB jnxPowerSupplyFailure 1.3.6.1.4.1.2636.4.1.1 Alert CHASSISD_ SNMP_ All devices running Junos
(jnx-chassis. TRAP OS.
mib)
jnxFanFailure 1.3.6.1.4.1.2636.4.1.2 Critical CHASSISD_ SNMP_ All devices running Junos
TRAP OS.
jnxOverTemperature 1.3.6.1.4.1.2636.4.1.3 Critical CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruNotifAdminStatus Notice
jnxFruNotifMismatch Notice
jnxFruNotifOperStatus Notice
jnxRedundancySwitchOver 1.3.6.1.4.1.2636.4.1.4 Critical CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruRemoval 1.3.6.1.4.1.2636.4.1.5 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruInsertion 1.3.6.1.4.1.2636.4.1.6 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruPowerOff 1.3.6.1.4.1.2636.4.1.7 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruPowerOn 1.3.6.1.4.1.2636.4.1.8 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruFailed 1.3.6.1.4.1.2636.4.1.9 Warning CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruOffline 1.3.6.1.4.1.2636.4.1.10 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.

System
Logging
Severity
jnxFruOnline 1.3.6.1.4.1.2636.4.1.11 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFruCheck 1.3.6.1.4.1.2636.4.1.12 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxFEBSwitchover 1.3.6.1.4.1.2636.4.1.13 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxHardDiskFailed 1.3.6.1.4.1.2636.4.1.14 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxHardDiskMissing 1.3.6.1.4.1.2636.4.1.15 Notice CHASSISD_ SNMP_ All devices running Junos

TRAP OS.
jnxPowerSupplyOK 1.3.6.1.4.1.2636.4.2.1 Critical CHASSISD_ All devices running

SNMP_ Junos OS.
TRAP
jnxFanOK 1.3.6.1.4.1.2636.4.2.2 Critical CHASSISD_ All devices running

SNMP_ Junos OS.
TRAP
jnxTemperatureOK 1.3.6.1.4.1.2636.4.2.3 Alert CHASSISD_ All devices running

SNMP_ Junos OS.
TRAP
Configuration Notifications
Configuration jnxCmCfgChange 1.3.6.1.4.1.2636.4.5.0.1 – – All devices running Junos
Management OS.
MIB (jnx-
cfgmgmt.mib)
jnxCmRescueChange 1.3.6.1.4.1.2636.4.5.0.2 – – All devices running Junos
OS.
Link Notifications

System
Logging
Severity
Flow jnxCollUnavailableDest 1.3.6.1.4.1.2636.4.8.0.1 – – Devices that run Junos OS

Collection and have collector PICs
Services MIB installed.
(jnx-coll.mib)
jnxCollUnavailableDestCleared 1.3.6.1.4.1.2636.4.8.0.2 – – Devices that run Junos OS
and have collector PICs
installed.
jnxCollUnsuccessfulTransfer 1.3.6.1.4.1.2636.4.8.0.3 – – Devices that run Junos OS

installed.
jnxCollFlowOverload 1.3.6.1.4.1.2636.4.8.0.4 – – Devices that run Junos OS

installed.
jnxCollFlowOverloadCleared 1.3.6.1.4.1.2636.4.8.0.5 – – Devices that run Junos OS

installed.
jnxCollMemoryUnavailable 1.3.6.1.4.1.2636.4.8.0.6 – – Devices that run Junos OS

installed.
jnxCollMemoryAvailable 1.3.6.1.4.1.2636.4.8.0.7 – – Devices that run Junos OS

installed.
jnxCollFtpSwitchover 1.3.6.1.4.1.2636.4.8.0.8 – – Devices that run Junos OS

installed.
PMON MIB jnxPMonOverloadSet 1.3.6.1.4.1.2636.4.7.0.1 – – Devices that run Junos OS

(jnx-pmon.mib) and have PICs that
support passive
monitoring installed.
jnxPMonOverloadCleared 1.3.6.1.4.1.2636.4.7.0.2 – – Devices that run Junos OS

and have PICs that
support passive
monitoring installed.

System
Logging
Severity
SONET APS apsEventChannelMismatch 1.3.6.1.4.1.2636.3. – – Devices that run Junos OS

MIB (jnx- 24.2.0.3 and have SONET PICs
sonetaps.mib) installed.
apsEventPSBF 1.3.6.1.4.1.2636.3. – – Devices that run Junos OS

24.2.0.4 and have SONET PICs
installed.
apsEventFEPLF 1.3.6.1.4.1.2636.3. – – Devices that run Junos OS

24.2.0.5 and have SONET PICs
installed.

PING MIB jnxPingRttThreshold Exceeded 1.3.6.1.4.1.2636.4.9.0.1 – – All devices running Junos
(jnx-ping.mib) OS.
jnxPingRttStdDevThreshold 1.3.6.1.4.1.2636.4.9.0.2 – – All devices running Junos

Exceeded OS.
jnxPingRttJitterThreshold 1.3.6.1.4.1.2636.4.9.0.3 – – All devices running Junos

Exceeded OS.
jnxPingEgressThreshold 1.3.6.1.4.1.2636.4.9.0.4 – – All devices running Junos

Exceeded OS.
jnxPingEgressStdDevThreshold 1.3.6.1.4.1.2636.4.9.0.5 – – All devices running Junos

Exceeded OS.
jnxPingEgressJitterThreshold 1.3.6.1.4.1.2636.4.9.0.6 – – All devices running Junos

Exceeded OS.
jnxPingIngressThreshold 1.3.6.1.4.1.2636.4.9.0.7 – – All devices running Junos

Exceeded OS.
jnxPingIngressStddevThreshold 1.3.6.1.4.1.2636.4.9.0.8 – – All devices running Junos

Exceeded OS.
jnxPingIngressJitterThreshold 1.3.6.1.4.1.2636.4.9.0.9 – – All devices running Junos

Exceeded OS.
BFD bfdSessUp 1.3.6.1.4.1.2636. – – All devices running Junos
Experimental 5.3.1.0.1 OS.
MIB (jnx-bfd-
exp.mib)
bfdSessDown 1.3.6.1.4.1.2636.5.3.1.0.2 – – All devices running Junos
OS.

System
Logging
Severity
BGP4 V2 MIB jnxBgpM2Established 1.3.6.1.4.1.2636.5.1.1.1.0.1 – – All devices running Junos

(jnx-bgpmib2. OS.
mib)
jnxBgpM2BackwardTransition 1.3.6.1.4.1.2636.5.1.1.1.0.2 – – All devices running Junos
OS.
DHCP MIB jnxJdhcpLocalServer 1.3.6.1.4.1.2636.3.61.61.1.3.1 – – All devices running Junos

(jnx-dhcp.mib) DuplicateClient OS.
jnxJdhcpLocalServer 1.3.6.1.4.1.2636.3.61.61.1.3.2 – – All devices running Junos

InterfaceLimitExceeded OS.
jnxJdhcpLocalServer 1.3.6.1.4.1.2636.3.61.61.1.3.3 – – All devices running Junos

InterfaceLimitAbated OS.
jnxJdhcpLocalServer Health 1.3.6.1.4.1.2636.3.61.61.1.3.4 – – All devices running Junos

OS.
jnxJdhcpRelayInterface 1.3.6.1.4.1.2636.3.61.61.2.3.1 – – All devices running Junos

LimitExceeded OS.
jnxJdhcpRelayInterface 1.3.6.1.4.1.2636.3.61.61.2.3.2 – – All devices running Junos

LimitAbated OS.
DHCPv6MIB jnxJdhcpv6LocalServer 1.3.6.1.4.1.2636.3.62.62.2.3.1 – – All devices running Junos

(jnx-dhcpv6. InterfaceLimitExceeded OS.
mib)
jnxJdhcpv6LocalServer 1.3.6.1.4.1.2636.3.62.62.2.3.2 – – All devices running Junos

InterfaceLimitAbated OS.
jnxJdhcpv6LocalServer Health 1.3.6.1.4.1.2636.3.62.62.2.3.3 – – All devices running Junos

OS.
LDP MIB jnxLdpLspUp 1.3.6.1.4.1.2636.4.4.0.1 – – M, T, and MX Series

(jnx-ldp.mib) routers.
jnxLdpLspDown 1.3.6.1.4.1.2636.4.4.0.2 – – M, T, and MX Series

routers.
jnxLdpSesUp 1.3.6.1.4.1.2636.4.4.0.3 – – M, T, and MX Series

routers.
jnxLdpSesDown 1.3.6.1.4.1.2636.4.4.0.4 – – M, T, and MX Series

routers.

System
Logging
Severity
MPLS MIB mplsLspUp (Deprecated) 1.3.6.1.4.1.2636.3.2.4.1 – –

(jnx-mpls.mib)
mplsLspInfoUp 1.3.6.1.4.1.2636.3.2.0.1 – – M, T, and MX Series

routers.
mplsLspDown (Deprecated) 1.3.6.1.4.1.2636.3.2.4.2 – –
mplsLspInfoDown 1.3.6.1.4.1.2636.3.2.0.2 – – M, T, and MX Series

routers.
mplsLspChange (Deprecated) 1.3.6.1.4.1.2636.3.2.4.3 – –
mplsLspInfoChange 1.3.6.1.4.1.2636.3.2.0.3 – – M, T, and MX Series

routers.
mplsLspPathDown 1.3.6.1.4.1.2636.3.2.4.4 – –
(Deprecated)
mplsLspInfoPathDown 1.3.6.1.4.1.2636.3.2.0.4 – – M, T, and MX Series

routers.
mplsLspInfoPathUp 1.3.6.1.4.1.2636.3.2.0.5 – – M, T, and MX Series

routers.
VPN MIB jnxVpnIfUp 1.3.6.1.4.1.2636.3. – – M, T, and MX Series

(jnx-vpn.mib) 26.0.1 routers.
jnxVpnIfDown 1.3.6.1.4.1.2636.3. – – M, T, and MX Series

26.0.2 routers.
jnxVpnPwUp 1.3.6.1.4.1.2636.3. – – M, T, and MX Series

26.0.3 routers.
jnxVpnPwDown 1.3.6.1.4.1.2636.3.26.0.4 – – M, T, and MX Series

routers.

System
Logging
Severity
AAA MIB jnxAccessAuthAddress 1.3.6.1.4.1.2636.3.51.1.0.5 – – SRX Series devices.

(jnx-user- PoolHighThreshold
aaa.mib)
jnxAccessAuthAddress 1.3.6.1.4.1.2636.3.51.1.0.6 – – SRX Series devices.

PoolAbateThreshold

PoolOutOfAddresses

PoolOutOfMemory
jnxAccessAuthService Up 1.3.6.1.4.1.2636.3.51. – – SRX Series devices.

1.0.1
jnxAccessAuthService Down 1.3.6.1.4.1.2636.3.51. – – SRX Series devices.

1.0.2
jnxAccessAuthServer Disabled 1.3.6.1.4.1.2636.3.51. – – SRX Series devices.

1.0.3
jnxAccessAuthServer Enabled 1.3.6.1.4.1.2636.3.51. – – SRX Series devices.

1.0.4
jnxJsFwAuthFailure 1.3.6.1.4.1.2636.3.39.1.2. – – SRX Series devices.

1.0.1
Access jnxJsFwAuthServiceUp 1.3.6.1.4.1.2636.3.39.1.2. – – SRX Series devices.

Authentication 1.0.2
Methods MIB
(jnx-js-auth.
jnxJsFwAuthServiceDown 1.3.6.1.4.1.2636.3.39.1.2. – – SRX Series devices.
mib)
1.0.3
jnxJsFwAuthCapacityExceeded 1.3.6.1.4.1.2636.3.39.1.2. – – SRX Series devices.

1.0.4
jnxJsNatAddrPool 1.3.6.1.4.1.2636.3.39.1.7. – – SRX Series devices.

ThresholdStatus 1.0.1
Network jnxNatAddrPoolUtil 1.3.6.1.4.1.2636.3.59.1.2.1 – – M Series and MX Series

Address routers
Translation
Resources–Monitoring
jnxNatTrapSrcPoolName 1.3.6.1.4.1.2636.3.59.1.2.2 – – M Series and MX Series
MIB
routers
(jnxNatMIB)
jnxNatAddrPoolThresholdStatus 1.3.6.1.4.1.2636.3.59.1.0.1 – – M Series and MX Series

routers

System
Logging
Severity
Network jnxJsScreen Attack 1.3.6.1.4.1.2636.3.39.1.8. Warning RT_SCREEN_ICMP, SRX Series devices.

Address 1.0.1 RT_SCREEN_IP,
Translation RT_SCREEN_
MIB SESSION_LIMIT,
(jnx-js-nat.mib) RT_SCREEN_TCP,
RT_SCREEN_UDP
Security jnxJsScreenCfg Change 1.3.6.1.4.1.2636.3.39.1.8. – – SRX Series devices.

Screening 1.0.2
Objects MIB
(jnx-js-
screening.mib)
RMON Alarms
RMON MIB jnxRmonGetOk 1.3.6.1.4.1.2636.4. – – All devices running Junos
(jnx-rmon.mib) 3.0.2 OS.
SONET Alarms
SONET MIB jnxSonetAlarm Cleared 1.3.6.1.4.1.2636.4. – – Devices that run Junos OS
(jnx-sonet.mib) 6.0.2 and have SONET PICs
installed.
Related • Standard SNMP Traps Supported by Junos OS on page 57

Documentation

CHAPTER 5
Loading MIB Files to a Network

Management System
Loading MIB Files to a Network Management System
Supported Platforms ACX Series
For your network management system (NMS) to identify and understand the MIB objects
used by the 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 name,
IDs, and data type for the NMS.
You can download the Junos MIB package from the Junos OS Enterprise MIBs index at
http://www.juniper.net/techpubs/en_US/release-independent/junos/mibs/mibs.html . The
Junos MIB package is available in .zip and .tar packages. You can download the appropriate
format based on your requirements.
The Junos MIB package contains two folders: StandardMibs and JuniperMibs. The
StandardMibs folder contains the standard MIBs and RFCs that are supported on devices
running the Junos OS, whereas the JuniperMibs folder contains the Juniper Networks
enterprise-specific MIBs.
To load MIB files that are required for managing and monitoring devices running the Junos
OS:
1. Go to the Junos OS Enterprise MIBs index page

(http://www.juniper.net/techpubs/en_US/release-independent/junos/mibs/mibs.html).
2. Click the TAR or ZIP link under the appropriate release heading to download the Junos
MIB package for that release.
3. Decompress the file (.tar or .zip) using an appropriate utility.
4. Load the standard MIB files (from the StandardMibs folder) in the following order:

NOTE: Some of the MIB compilers that are commonly used have the
standard MIBs preloaded on them. If the standard MIBs are already loaded
on the MIB compiler that you are using, skip this step and proceed to Step
7.
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 the 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 might be dependencies that require a particular MIB to be
present on the compiler before loading some other MIB. You can find such
dependencies listed in the IMPORT section of the MIB file.
6. Load the Juniper Networks enterprise-specific SMI MIB, mib-jnx-smi.txt, and the
following optional SMI MIBs based on your requirements:
• mib-jnx-js-smi.txt—(Optional) For Juniper Security MIB tree objects
• mib-jnx-ex-smi.txt—(Optional) For EX Series Ethernet Switches
• mib-jnx-exp.txt—(Recommended) For Juniper Networks experimental MIB objects
7. Load the remaining enterprise-specific MIBs from the JuniperMibs folder.
TIP: While loading a MIB file, if the compiler returns an error message saying
that any of the objects is 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 is not loaded on
the compiler, load that MIB file, and then try to load the MIB file that failed
to load.
For example, the enterprise-specific PING MIB, mib-jnx-ping.txt, has

dependencies on RFC 2925, DiSMAN-PING-MIB, mib-rfc2925a.txt. If you try
to load mib-jnx-ping.txt before loading mib-rfc2925a.txt, the compiler returns

Chapter 5: Loading MIB Files to a Network Management System
an error message saying that certain objects in mib-jnx-ping.txt are undefined.

Load mib-rfc2925a.txt, and then try to load mib-jnx-ping.txt. The
enterprise-specific PING MIB, mib-jnx-ping.txt, then loads without any issue.
Related • Standard SNMP MIBs Supported by Junos OS

Documentation


CHAPTER 6
Configuring SNMP
• Configuration Statements at the [edit snmp] Hierarchy Level on page 84

• Optimizing the Network Management System Configuration for the Best
Results on page 87
• Configuring the System Contact on a Device Running Junos OS on page 94
• Configuring the System Location for a Device Running Junos OS on page 95
• Configuring the System Description on a Device Running Junos OS on page 95
• Configuring SNMP Details on page 96
• Configuring a Different System Name on page 97
• Configuring the Commit Delay Timer on page 98
• Filtering Duplicate SNMP Requests on page 98
• Configuring SNMP Communities on page 99
• Examples: Configuring the SNMP Community String on page 102
• Adding a Group of Clients to an SNMP Community on page 103
• Configuring a Proxy SNMP Agent on page 104
• Configuring SNMP Traps on page 105
• Configuring SNMP Trap Options on page 108
• Configuring SNMP Trap Groups on page 112
• Example: Configuring SNMP Trap Groups on page 114
• Configuring the Interfaces on Which SNMP Requests Can Be Accepted on page 114
• Example: Configuring Secured Access List Checking on page 115
• Filtering Interface Information Out of SNMP Get and GetNext Output on page 115
• Configuring Ping Proxy MIB on page 118

Configuration Statements at the [edit snmp] Hierarchy Level
This topic shows all possible configuration statements at the [edit snmp] hierarchy level
and their level in the configuration hierarchy. When you are configuring Junos OS, your
current hierarchy level is shown in the banner on the line preceding the user@host#
prompt.
[edit]
snmp {
alarm-management {
alarm-list-name list-name {
alarm-id id {
alarm-state state {
description alarm-description;
notification-id notification-id-of-alarm;
resource-prefix alarm-resource-prefix;
varbind-index varbind-index-in-alarm-varbind-list;
varbind-subtree alarm-varbind-subtree;
varbind-value alarm-varbind-value;
}
}
}
}
client-list client-list-name {
ip-addresses;
}
community community-name {
authorization authorization;
client-list-name client-list-name;
clients {
address <restrict>;
}
logical-system logical-system-name {
routing-instance routing-instance-name;
clients {
address <restrict>;
}
}
routing-instance routing-instance-name {
clients {
address <restrict>;
}
}
view view-name;
}
contact contact;
description description;
engine-id {
(local engine-id | use-default-ip-address | use-mac-address);
}
filter-duplicates;
interface [ interface-names ];

Chapter 6: Configuring SNMP
location location;
name name;
nonvolatile {
commit-delay seconds;
}
rmon {
alarm index {
falling-event-index index;
falling-threshold integer;
falling-threshold-interval seconds;
interval seconds;
request-type (get-next-request | get-request | walk-request);
rising-event-index index;
rising-threshold integer;
sample-type type;
startup-alarm alarm;
syslog-subtag syslog-subtag;
variable oid-variable;
}
event index {
community community-name;
type type;
}
}
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable> <match
regular-expression>;
flag flag;
memory-trace;
no-remote-trace;
no-default-memory-trace;
}
trap-group group-name {
categories {
category;
}
destination-port port-number;
routing-instance instance;
logical-system logical-system-name;
targets {
address;
}
version (all | v1 | v2);
}
trap-options {
agent-address outgoing-interface;
source-address address;
enterprise-oid;
logical-system logical-system-name {
}
}

}
}
v3 {
notify name {
tag tag-name;
type (trap | inform);
}
notify-filter profile-name {
oid oid (include | exclude);
}
snmp-community community-index {
community-name community-name;
security-name security-name;
tag tag-name;
}
target-address target-address-name {
address address;
address-mask address-mask;
logical-system logical-system;
port port-number;
retry-count number;
tag-list tag-list;
target-parameters target-parameters-name;
timeout seconds;
}
target-parameters target-parameters-name {
notify-filter profile-name;
parameters {
message-processing-model (v1 | v2c | v3);
security-level (authentication | none | privacy);
security-model (usm | v1 | v2c);
}
}
usm {
local-engine {
user username {
authentication-md5 {
authentication-password authentication-password;
}
authentication-none;
authentication-sha {
}
privacy-3des {
privacy-password privacy-password;
}
privacy-aes128 {
}
privacy-des {
}
privacy-none;

}
}
}
vacm {
access {
group group-name {
(default-context-prefix | context-prefix context-prefiix){
security-model (any | usm | v1 | v2c) {
security-level (authentication | none | privacy) {
notify-view view-name;
read-view view-name;
write-view view-name;
}
}
}
}
}
security-to-group {
security-model (usm | v1 | v2c) {
security-name security-name {
group group-name;
}
}
}
}
}
view view-name {
oid object-identifier (include | exclude);
}
}
Related • Understanding the SNMP Implementation in Junos OS

Documentation
• Configuring SNMP on a Device Running Junos OS
Optimizing the Network Management System Configuration for the Best Results
vSRX
You can modify your network management system configuration to optimize the response
time for SNMP queries. The following sections contain a few tips on how you can configure
the network management system:
• Changing the Polling Method from Column-by-Column to Row-by-Row on page 87

• Reducing the Number of Variable Bindings per PDU on page 88
• Increasing Timeout Values in Polling and Discovery Intervals on page 88
• Reducing Incoming Packet Rate at the snmpd on page 88
Changing the Polling Method from Column-by-Column to Row-by-Row

You can configure the network management system to use the row-by-row method for
SNMP data polling. It has been proven that the row-by-row and multiple

row-by-multiple-row polling methods are more efficient than column-by-column polling.

By configuring the network management system to use the row-by-row data polling
method, you can ensure that data for only one interface is polled in a request instead of
a single request polling data for multiple interfaces, as is the case with column-by-column
polling. Row-by-row polling also reduces the risk of requests timing out.
Reducing the Number of Variable Bindings per PDU

By reducing the number of variable bindings per protocol data unit (PDU), you can improve
the response time for SNMP requests. A request that polls for data related to multiple
objects, which are mapped to different index entries, translates into multiple requests
at the device-end because the subagent might have to poll different modules to obtain
data that are linked to different index entries. The recommended method is to ensure
that a request has only objects that are linked to one index entry instead of multiple
objects linked to different index entries.
NOTE: If responses from a device are slow, avoid using the GetBulk option
for the device, because a GetBulk request might contain objects that are
linked to various index entries and might further increase the response time.
Increasing Timeout Values in Polling and Discovery Intervals

By increasing the timeout values for polling and discovery intervals, you can increase the
queuing time at the device end and reduce the number of throttle drops that occur
because of the request timing out.
Reducing Incoming Packet Rate at the snmpd

By reducing the frequency of sending SNMP requests to a device, you can reduce the risk
of SNMP requests piling up at any particular device. Apart from reducing the frequency
of sending SNMP requests to a device, you can also increase the polling interval, control
the use of GetNext requests, and reduce the number of polling stations per device.
Related • Understanding SNMP Implementation in Junos OS on page 13

Documentation
Configuring Options on Managed Devices for Better SNMP Response Time
vSRX

The following sections contain information about configuration options on the managed
devices that can enhance SNMP performance:
• Enabling the stats-cache-lifetime Option on page 89

• Filtering Out Duplicate SNMP Requests on page 89
• Excluding Interfaces That Are Slow in Responding to SNMP Queries on page 89
Enabling the stats-cache-lifetime Option

The Junos OS provides you with an option to configure the length of time an SNMP request
stays active and queued so as to reduce the possibility of request drops during slow
response times. You can use the stats-cache-lifetime seconds option at the [edit snmp]
hierarchy level to specify the length of time that an SNMP request remains queued. The
recommended value for the stats-cache-lifetime option is in the range of 30 to 60 seconds.
NOTE: The set snmp stats-cache-lifetime seconds command is a hidden

command and is supported only on devices running Junos OS Release 9.3
and later.
Filtering Out Duplicate SNMP Requests

If a network management station retransmits a Get, GetNext, or GetBulk SNMP request
too frequently to a device, that request might interfere with the processing of previous
requests and slow down the response time of the agent. Filtering these duplicate requests
improves the response time of the SNMP agent. The Junos OS enables you to filter out
duplicate Get, GetNext, and GetBulk SNMP requests. The Junos OS uses the following
information to determine if an SNMP request is a duplicate:
• Source IP address of the SNMP request
• Source UDP port of the SNMP request
• Request ID of the SNMP request
NOTE: By default, filtering of duplicate SNMP requests is disabled on devices

running the Junos OS.
To enable filtering of duplicate SNMP requests on devices running the Junos OS, include
the filter-duplicates statement at the [edit snmp] hierarchy level:
[edit snmp]
filter-duplicates;
Excluding Interfaces That Are Slow in Responding to SNMP Queries

An interface that is slow in responding to SNMP requests for interface statistics can delay
kernel responses to SNMP requests. You can review the mib2d log file to find out how
long the kernel takes to respond to various SNMP requests. For more information about
reviewing the log file for kernel response data, see “Checking Kernel and Packet Forwarding

Engine Response” under “Monitoring SNMP Activity and Tracking Problems That Affect
SNMP Performance on a Device Running Junos OS” on page 197. If you notice that a
particular interface is slow in responding, and think that it is slowing down the kernel
from responding to SNMP requests, exclude that interface from the SNMP queries to the
device. You can exclude an interface from the SNMP queries either by configuring the
filter-interface statement or by modifying the SNMP view settings.
The following example shows a sample configuration for excluding interfaces from the
SNMP Get, GetNext, and Set operations:
[edit]
snmp {
filter-interfaces {
interfaces { # exclude the specified interfaces
interface1;
interface2;
}
all-internal-interfaces; # exclude all internal interfaces
}
}
The following example shows the SNMP view configuration for excluding the interface
with an interface index (ifIndex) value of 312 from a request for information related to
the ifTable and ifXtable objects:
[edit snmp]
view test {
oid .1 include;
oid ifTable.1.*.312 exclude;
oid ifXTable.1.*.312 exclude
}
Alternatively, you can take the interface that is slow in responding offline.

Documentation
page 87
Configuring SNMP on Devices Running Junos OS
vSRX

The following sections contain information about basic SNMP configuration and a few
examples of configuring the basic SNMP operations on devices running Junos OS:
• Configuring Basic Settings for SNMPv1 and SNMPv2 on page 91

• Configuring Basic Settings for SNMPv3 on page 91
• Configuring System Name, Location, Description, and Contact Information on page 93
Configuring Basic Settings for SNMPv1 and SNMPv2

By default, SNMP is not enabled on devices running Junos OS. To enable SNMP on devices
running Junos OS, include the community public statement at the [edit snmp] hierarchy
level.
Enabling SNMPv1 and [edit]

SNMPv2 Get and snmp {
GetNext Operations community public;
}
A community that is defined as public grants access to all MIB data to any client.
To enable SNMPv1 and SNMPv2 Set operations on the device, you must include the
following statements at the [edit snmp] hierarchy level:
Enabling SNMPv1 and [edit snmp]

SNMPv2 Set view all {
Operations oid .1;
}
community private {
view all;
authorization read-write;
}
The following example shows the basic minimum configuration for SNMPv1 and SNMPv2
traps on a device:
Configuring SNMPv1 [edit snmp]

and SNMPv2 Traps trap-group jnpr {
targets {
192.168.69.179;
}
}
Configuring Basic Settings for SNMPv3

The following example shows the minimum SNMPv3 configuration for enabling Get,
GetNext, and Set operations on a device (note that the configuration has authentication
set to md5 and privacy to none):
Enabling SNMPv3 Get, [edit snmp]

GetNext, and Set v3 {
Operations usm {
local-engine {
user jnpruser {
authentication-key "$9$guaDiQFnAuOQzevMWx7ikqP"; ## SECRET-DATA

}
privacy-none;
}
}
}
vacm {
security-to-group {
security-model usm {
security-name jnpruser {
group grpnm;
}
}
}
access {
group grpnm {
default-context-prefix {
security-model any {
security-level authentication {
read-view all;
write-view all;
}
}
}
}
}
}
}
view all {
oid .1;
}
The following example shows the basic configuration for SNMPv3 informs on a device
(the configuration has authentication and privacy set to none):
Configuring SNMPv3 [edit snmp]

Informs v3 {
usm {
remote-engine 00000063200133a2c0a845c3 {
user RU2_v3_sha_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.
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:
Converting Informs to user@host# set snmp v3 notify N1_all_tl1_informs type trap

Traps
Configuring System Name, Location, Description, and Contact Information

Junos OS enables you to include the name and location of the system, administrative
contact information, and a brief description of the system in the SNMP configuration.
NOTE: Always keep the name, location, contact, and description information
configured and updated for all your devices that are managed by SNMP.

The following example shows a typical configuration.
TIP: Use quotation marks to enclose the system name, contact, location,
and description information that contain spaces.
[edit]
snmp {
name “snmp 001”; # Overrides the system name.
contact “Juniper Berry, (650) 555 1234”; # Specifies the name and phone number of
the administrator.
location “row 11, rack C”; # Specifies the location of the device.
description “M40 router with 8 FPCs” # Configures a description for the device.
}

Documentation
page 87
Configuring the System Contact on a Device Running Junos OS
Supported Platforms ACX Series, M Series, MX Series, PTX Series, T Series
You can specify an administrative contact for each system being managed by SNMP.
This name is placed into the MIB II sysContact object. To configure a contact name,
include the contact statement at the [edit snmp] hierarchy level:
[edit snmp]
contact contact;
If the name contains spaces, enclose it in quotation marks (" ").
To define a system contact name that contains spaces:
[edit]
snmp {
contact "Juniper Berry, (650) 555-1234";
}
Related • Configuring SNMP on a Device Running Junos OS

Documentation

Configuring the System Location for a Device Running Junos OS
You can specify the location of each system being managed by SNMP. This string is
placed into the MIB II sysLocation object. To configure a system location, include the
location statement at the [edit snmp] hierarchy level:
[edit snmp]
location location;
If the location contains spaces, enclose it in quotation marks (" ").
To specify the system location:
[edit]
snmp {
location "Row 11, Rack C";
}

Documentation
Configuring the System Description on a Device Running Junos OS
You can specify a description for each system being managed by SNMP. This string is
placed into the MIB II sysDescription object. To configure a description, include the
description statement at the [edit snmp] hierarchy level:
[edit snmp]
If the description contains spaces, enclose it in quotation marks (" ").
To specify the system description:
[edit]
snmp {
description "M40 router with 8 FPCs";
}

Documentation

Configuring SNMP Details
You can use SNMP to store basic administrative details, such as a contact name and the
location of the device. Your management system can then retrieve this information
remotely, when you are troubleshooting an issue or performing an audit. In SNMP
terminology, these are the sysContact, sysDescription, and sysLocation objects found
within the system group of MIB-2 (as defined in RFC 1213, Management Information Base
for Network Management of TCP/IP-based internets: MIB-II). You can set initial values
directly in the Junos OS configuration for each system being managed by SNMP.
To set the system contact details:
1. Set the system contact details by including the contact statement at the [edit snmp]
hierarchy level, or in an appropriate configuration group as shown here.
This administrative contact is placed into the MIB II sysContact object.
[edit groups global snmp]

user@host# set contact contact
For example:

user@host# set contact "Enterprise Support, (650) 555-1234"
2. Configure a system description.
This string is placed into the MIB II sysDescription object. If the description contains
spaces, enclose it in quotation marks (" ").

user@host# set description description
For example:

user@host# set description "M10i router with 8 FPCs"
3. Configure a system location.
This string is placed into the MIB II sysLocation object. If the location contains spaces,
enclose it in quotation marks (" ").
To specify the system location:
[edit]
snmp {
location "Row 11, Rack C";
}

user@host# set location location
For example:

user@host# set location "London Corporate Office, Lab 5, Row 11, Rack C"
4. At the top level of the configuration, apply the configuration group.
If you use a configuration group, you must apply it for it to take effect.
[edit]
user@host# set apply-groups global
5. Commit the configuration.
user@host# commit
6. To verify the configuration, enter the show snmp mib walk system operational-mode
command.
The show snmp mib walk system command performs a MIB walk through of the system
table (from MIB-2 as defined in RFC 1213). The SNMP agent in Junos OS responds by
printing each row in the table and its associated value. You can use the same command
to perform a MIB walk through any part of the MIB tree supported by the agent.
user@host> show snmp mib walk system

sysDescr.0 = M10i router with 8 FPCs
sysObjectID.0 = jnxProductNameM10i
sysUpTime.0 = 173676474
sysContact.0 = Enterprise Support, (650) 555-1234
sysName.0 = host
sysLocation.0 = London Corporate Office, Lab 5, Row 11, Rack C
sysServices.0 = 4
Related • Configuring SNMP Communities on page 99

Documentation
• Configuring SNMP Traps on page 105
Configuring a Different System Name
Junos OS enables you to override the system name by including the name statement at
the [edit snmp] hierarchy level:
[edit snmp]
name name;
To specify the system name override:
[edit]
snmp {
name "snmp 1";
}


Documentation
Configuring the Commit Delay Timer
When a router or switch first receives an SNMP nonvolatile Set request, a Junos OS XML
protocol session opens and prevents other users or applications from changing the
candidate configuration (equivalent to the command-line interface [CLI]
configure exclusive command). If the router does not receive new SNMP Set requests
within 5 seconds (the default value), the candidate configuration is committed and the
Junos OS XML protocol session closes (the configuration lock is released). If the router
receives new SNMP Set requests while the candidate configuration is being committed,
the SNMP Set request is rejected and an error is generated. If the router receives new
SNMP Set requests before 5 seconds have elapsed, the commit-delay timer (the length
of time between when the last SNMP request is received and the commit is requested)
resets to 5 seconds.
By default, the timer is set to 5 seconds. To configure the timer for the SNMP Set reply
and start of the commit, include the commit-delay statement at the
[edit snmp nonvolatile] hierarchy level:
[edit snmp nonvolatile]

seconds is the length of the time between when the SNMP request is received and the
commit is requested for the candidate configuration. For more information about the
configure exclusive command and locking the configuration, see the CLI User Guide.

Documentation
Filtering Duplicate SNMP Requests
Supported Platforms PTX Series
By default, filtering duplicate get, getNext, and getBulk SNMP requests is disabled on
devices running Junos OS. If a network management station retransmits a Get, GetNext,
or GetBulk SNMP request too frequently to the router, that request might interfere with
the processing of previous requests and slow down the response time of the agent.
Filtering these duplicate requests improves the response time of the SNMP agent. Junos
OS uses the following information to determine if an SNMP request is a duplicate:
• Source IP address of the SNMP request

• Source UDP port of the SNMP request
• Request ID of the SNMP request
To filter duplicate SNMP requests, include the filter-duplicates statement at the

[edit snmp] hierarchy level:
[edit snmp]
filter-duplicates;

Documentation
• Configuring the Interfaces on Which SNMP Requests Can Be Accepted on page 114
Configuring SNMP Communities
Configuring the SNMP agent in Junos OS is a straightforward task that shares many
familiar settings common to other managed devices in your network. For example, you
need to configure Junos OS with an SNMP community string and a destination for traps.
Community strings are administrative names that group collections of devices and the
agents that are running on them together into common management domains. If a
manager and an agent share the same community, they can communicate with each
other. An SNMP community defines the level of authorization granted to its members,
such as which MIB objects are available, which operations (read-only or read-write) are
valid for those objects, and which SNMP clients are authorized, based on their source IP
addresses.
The SNMP community string defines the relationship between an SNMP server system
and the client systems. This string acts like a password to control the clients’ access to
the server.
To create a read-only SNMP community:
1. Enter the SNMP community used in your network.
If the community name contains spaces, enclose it in quotation marks (" ").
Community names must be unique.
NOTE: You cannot configure the same community name at the [edit snmp
community] and [edit snmp v3 snmp-community community-index] hierarchy
levels.
[edit groups global]

user@host# set snmp community name

This example uses the standard name public to create a community that gives limited
read-only access.

user@host# set snmp community public
2. Define the authorization level for the community.
The default authorization level for a community is read-only.
To allow Set requests within a community, you need to define that community as
authorization read-write. For Set requests, you also need to include the specific MIB
objects that are accessible with read-write privileges using the view statement. The
default view includes all supported MIB objects that are accessible with read-only
privileges. No MIB objects are accessible with read-write privileges. For more
information about the view statement, see “Configuring MIB Views” on page 116.
[edit groups global snmp community name]

user@host# set authorization authorization
This example confines the public community to read-only access. Any SNMP client
(for example, an SNMP management system) that belongs to the public community
can read MIB variables but cannot set (change) them.
[edit groups global snmp community public]

user@host# set authorization read-only
3. Define a list of clients in the community who are authorized to communicate with the
SNMP agent in Junos OS.
The clients statement lists the IP addresses of the clients (community members) that
are allowed to use this community. List the clients by IP address and prefix. Typically,
the list includes the SNMP network management system in your network or the address
of your management network. If no clients statement is present, all clients are allowed.
For address, you must specify an IPv4 or IPv6 address, not a hostname.

user@host# set clients address
The following statement defines the hosts in the 192.168.1.0/24 network as being
authorized in the public community.

user@host# set clients 192.168.1.0/24
4. Define the clients that are not authorized within the community by specifying their IP
address, followed by the restrict statement.

user@host# set clients address resrict
The following statement defines all other hosts as being restricted from the public
community.

user@host# set clients 0/0 restrict

[edit]
user@host# commit
To create a read-write SNMP community:
1. Enter the SNMP community used in your network.

user@host# set snmp community name
This example standard community string private to identify the community granted
read-write access to the SNMP agent running on the device.

user@host# set snmp community private
2. Define the authorization level for the community.

user@host# set authorization authorization
This example confines the public community to read-only access. Any SNMP client
(for example, an SNMP management system) that belongs to the public community
can read MIB variables but cannot set (change) them.

user@host# set authorization read-write
3. Define a list of clients in the community who are authorized to make changes to the
SNMP agent in Junos OS.
List the clients by IP address and prefix.

user@host# set clients address
For example:
[edit groups global snmp community private]

4. Define the clients that are not authorized within the community by specifying their IP
address, followed by the restrict statement.

user@host# set clients address resrict
The following statement defines all other hosts as being restricted from the public
community.
[edit groups global snmp community private]

user@host# set clients 0/0 restrict
[edit]

user@host# commit
Related • Adding a Group of Clients to an SNMP Community on page 103

Documentation
Examples: Configuring the SNMP Community String
Grant read-only access to all clients. With the following configuration, the system responds
to SNMP Get, GetNext, and GetBulk requests that contain the community string public:
[edit]
snmp {
community public {
authorization read-only;
}
}
Grant all clients read-write access to the ping MIB and jnxPingMIB. With the following
configuration, the system responds to SNMP Get, GetNext, GetBulk, and Set requests
that contain the community string private and specify an OID contained in the ping MIB
or jnxPingMIB hierarchy:
[edit]
snmp {
view ping-mib-view {
oid pingMIB include;
oid jnxPingMIB include;
community private {
view ping-mib-view;
}
}
}
The following configuration allows read-only access to clients with IP addresses in the
range 1.2.3.4/24, and denies access to systems in the range fe80::1:2:3:4/64:
[edit]
snmp {
community field-service {
clients {
default restrict; # Restrict access to all SNMP clients not explicitly
# listed on the following lines.
1.2.3.4/24; # Allow access by all clients in 1.2.3.4/24 except
fe80::1:2:3:4/64 restrict;# fe80::1:2:3:4/64.

}
}
}

Documentation
Adding a Group of Clients to an SNMP Community
Supported Platforms ACX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series, vSRX
Junos OS enables you to add one or more groups of clients to an SNMP community. You
can include the client-list-name name statement at the [edit snmp community
community-name] hierarchy level to add all the members of the client list or prefix list to
an SNMP community.
To define a list of clients, include the client-list statement followed by the IP addresses
of the clients at the [edit snmp] hierarchy level:
[edit snmp]
client-list client-list-name {
ip-addresses;
}
You can configure a prefix list at the [edit policy options] hierarchy level. Support for
prefix lists in the SNMP community configuration enables you to use a single list to
configure the SNMP and routing policies. For more information about the prefix-list
statement, see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
To add a client list or prefix list to an SNMP community, include the client-list-name
statement at the [edit snmp community community-name] hierarchy level:
[edit snmp community community-name]

NOTE: The client list and prefix list must not have the same name.
The following example shows how to define a client list:
[edit]
snmp {
client-list clentlist1 {
10.1.1.1/32;
10.2.2.2/32;
}
}
The following example shows how to add a client list to an SNMP community:
[edit]
snmp {
community community1 {
client-list-name clientlist1;

}
}
The following example shows how to add a prefix list to an SNMP community:
[edit]
policy-options {
prefix-list prefixlist {
10.3.3.3/32;
10.5.5.5/32;
}
}
snmp {
client-list-name prefixlist;
}
}
Related • client-list
Documentation
• client-list-name
Configuring a Proxy SNMP Agent
Supported Platforms M Series, MX Series, T Series
Starting with Release 12.3, Junos OS enables you to assign one of the devices in the
network as a proxy SNMP agent through which the network management system (NMS)
can query other devices in the network. When you configure a proxy, you can specify the
names of devices to be managed through the proxy SNMP agent.
When the NMS queries the proxy SNMP agent, the NMS specifies the community name
(for SNMPv1 and SNMPv2) or the context and security name (for SNMPv3) associated
with the device from which it requires the information.
NOTE: If you have configured authentication and privacy methods and

passwords for SNMPv3, those parameters are also specified in the query for
SNMPv3 information.
To configure a proxy SNMP agent and specify devices to be managed by the proxy SNMP
agent, you can include the following configuration statements at the [edit snmp] hierarchy
level:
proxy proxy-name{
device-name device-name;
logical-system logical-system {
routing-instance routing-instance;
}
<version-v1 | version-v2c> {
snmp-community community-name;
no-default-comm-to-v3-config;
}

version-v3 {
context context-name;
}
}
• The proxy statement enables you to specify a unique name for the proxy configuration.
• The version-v1, version-v2c, and version-v3 statements enable you to specify the SNMP
version.
• The no-default-comm-to-v3-config statement is an optional statement at the [edit

snmp proxy proxy-name <version-v1 | version-v2c>] hierarchy level that when included
in the configuration requires you to manually configure the statements at the [edit
snmp v3 snmp-community community-name] and [edit snmp v3 vacm] hierarchy levels.
If the no-default-comm-to-v3-config statement is not included at the [edit snmp proxy

proxy-name <version-v1 | version-v2c>] hierarchy level, the [edit snmp v3
snmp-community community-name] and [edit snmp v3 vacm] hierarchy level
configurations are automatically initialized.
• The logical-system and routing-instance statements are optional statements that

enable you to specify logical system and routing instance names if you want to create
proxies for logical systems or routing instances on the device.
NOTE: Starting with Junos OS Release 15.2, you must configure interface
<interface-name> statement at the [edit snmp] hierarchy level for the proxy
SNMP agent.
NOTE: The community and security configuration for the proxy should match
the corresponding configuration on the device that is to be managed.
NOTE: Because the proxy SNMP agent does not have trap forwarding
capabilities, the devices that are managed by the proxy SNMP agent send
the traps directly to the network management system.
You can use the show snmp proxy operational mode command to view proxy details on
a device. The show snmp proxy command returns the proxy names, device names, SNMP
version, community/security, and context information.
Related • proxy (snmp) on page 717

Documentation
Configuring SNMP Traps
Supported Platforms M Series, MX Series, PTX Series, T Series

Traps are unsolicited messages sent from an SNMP agent to remote network
management systems or trap receivers. Many enterprises use SNMP traps as part of a
fault-monitoring solution, in addition to system logging. In Junos OS, SNMP traps are not
forwarded by default, so you must configure a trap-group if you wish to use SNMP traps.
You can create and name a group of one or more types of SNMP traps and then define
which systems receive the group of SNMP traps.. The name of the trap group is embedded
in SNMP trap notification packets as one variable binding (varbind) known as the
community name.
To configure an SNMP trap:
1. Create a single, consistent source address that Junos OS applies to all outgoing traps
in your device.
A source address is useful, because although most Junos OS devices have a number
of outbound interfaces, using one source address helps a remote NMS to associate
the source of the traps with an individual device

user@host# set trap-options source-address address
This example uses the IP address of the loopback interface (lo0) as the source address
for all the SNMP traps that originate from the device.

user@host# set trap-options source-address lo0
2. Create a trap group in which you can list the types of traps to be forwarded and the
targets (addresses) of the receiving remote management systems.
[edit groups global snmp trap-group group-name]

user@host# set version (all | v1 | v2) targets address
This example creates a trap group called managers, allows SNMP version 2-formatted
notifications (traps) to be sent to the host at address 192.168.1.15. This statement
forwards all categories of traps.
[edit groups global snmp trap-group managers]

user@host# set version v2 targets 192.168.1.15
3. Define the specific subset of trap categories to be forwarded.
For a list of categories, see “Configuring SNMP Trap Groups” on page 112.
[edit groups global snmp trap-group group-name]

user@host# set categories category
The following statement configures the standard MIB-II authentication failures on

the agent (the device).
[edit groups global snmp trap-group managers]

user@host# set categories authentication
[edit]

user@host# commit
6. To verify the configuration, generate an authentication failure trap.
This means that the SNMP agent received a request with an unknown community.
Other traps types can also be spoofed as well.
This feature enables you to trigger SNMP traps from routers and ensure that they are
processed correctly within your existing network management infrastructure. This is
also useful for testing and debugging SNMP behavior on the switch or NMS.
Using the monitor traffic command, you can verify that the trap is sent to the network
management system.
user@host> request snmp spoof-trap spoof-trap authenticationFailure

Spoof-trap request result: trap sent successfully

Documentation
Configuring SNMP Trap Options and Groups on a Device Running Junos OS
Some carriers have more than one trap receiver that forwards traps to a central NMS.
This allows for more than one path for SNMP traps from a router to the central NMS
through different trap receivers. A device running Junos OS can be configured to send
the same copy of each SNMP trap to every trap receiver configured in the trap group.
The source address in the IP header of each SNMP trap packet is set to the address of
the outgoing interface by default. When a trap receiver forwards the packet to the central
NMS, the source address is preserved. The central NMS, looking only at the source address
of each SNMP trap packet, assumes that each SNMP trap came from a different source.
In reality, the SNMP traps came from the same router, but each left the router through
a different outgoing interface.
The statements discussed in the following sections are provided to allow the NMS to
recognize the duplicate traps and to distinguish SNMPv1 traps based on the outgoing
interface.
To configure SNMP trap options and trap groups, include the trap-options and trap-group
statements at the [edit snmp] hierarchy level:
[edit snmp]
trap-options {
}

categories {
category;
}
targets {
address;
}
}
Related • Configuring SNMP Trap Options on page 108

Documentation
Configuring SNMP Trap Options
Using SNMP trap options, you can set the source address of every SNMP trap packet
sent by the router to a single address regardless of the outgoing interface. In addition,
you can set the agent address of the SNMPv1 traps. For more information about the
contents of SNMPv1 traps, see RFC 1157.
NOTE: SNMP cannot be associated with any routing instances other than
the master routing instance.
To configure SNMP trap options, include the trap-options statement at the [edit snmp]
hierarchy level:
[edit snmp]
trap-options {
enterprise-oid
logical-system
routing-instance
}
You must also configure a trap group for the trap options to take effect. For information
about trap groups, see “Configuring SNMP Trap Groups” on page 112.
This topic contains the following sections:
• Configuring the Source Address for SNMP Traps on page 109

• Configuring the Agent Address for SNMP Traps on page 111
• Adding snmpTrapEnterprise Object Identifier to Standard SNMP Traps on page 111

Configuring the Source Address for SNMP Traps

You can configure the source address of trap packets in many ways: lo0, a valid IPv4
address or IPv6 address configured on one of the router interfaces, a logical-system
address, or the address of a routing-instance. The value lo0 indicates that the source
address of the SNMP trap packets is set to the lowest loopback address configured on
the interface lo0.
NOTE: If the source address is an invalid IPv4 or IPv6 address or is not

configured, SNMP traps are not generated.
You can configure the source address of trap packets in one of the following formats:
• A valid IPv4 address configured on one of the router interfaces
• A valid IPv6 address configured on one of the router interfaces
• lo0; that is, the lowest loopback address configured on the interface lo0
• A logical-system name
• A routing-instance name
A Valid IPv4 Address To specify a valid IPv4 interface address as the source address for SNMP traps on one
As the Source Address of the router interfaces, include the source-address statement at the [edit snmp
trap-options] hierarchy level:
[edit snmp trap-options]

address is a valid IPv4 address configured on one of the router interfaces.
A Valid IPv6 Address To specify a valid IPv6 interface address as the source address for SNMP traps on one
As the Source Address of the router interfaces, include the source-address statement at the [edit snmp
trap-options] hierarchy level:

address is a valid IPv6 address configured on one of the router interfaces.
The Lowest Loopback To specify the source address of the SNMP traps so that they use the lowest loopback
Address As the Source address configured on the interface lo0 as the source address, include the source-address
Address statement at the [edit snmp trap-options] hierarchy level:

source-address lo0;
To enable and configure the loopback address, include the address statement at the
[edit interfaces lo0 unit 0 family inet] hierarchy level:
[edit interfaces]
lo0 {
unit 0 {
family inet {

address ip-address;
}
}
}
To configure the loopback address as the source address of trap packets:
[edit snmp]
trap-options {
source-address lo0;
}
trap-group "urgent-dispatcher" {
version v2;
categories link startup;
targets {
192.168.10.22;
172.17.1.2;
}
}
[edit interfaces]
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
address 127.0.0.1/32;
}
}
}
In this example, the IP address 10.0.0.1 is the source address of every trap sent from this
router.
Logical System Name To specify a logical system name as the source address of SNMP traps, include the
as the Source Address logical-system logical-system-name statement at the [edit snmp trap-options] hierarchy
level.
For example, the following configuration sets logical system name ls1 as the source
address of SNMP traps:
[edit snmp]
trap-options{
logical-system ls1;
}
Routing Instance To specify a routing instance name as the source address of SNMP traps, include the
Name as the Source routing-instance routing-instance-name statement at the [edit snmp trap-options] hierarchy
Address level.
For example, the following configuration sets the routing instance name ri1 as the source
address for SNMP traps:
[edit snmp]
trap-options {
routing-instance ri1;
}

Configuring the Agent Address for SNMP Traps

The agent address is only available in SNMPv1 trap packets (see RFC 1157). By default,
the router’s default local address is not specified in the agent address field of the SNMPv1
trap. To configure the agent address, include the agent-address statement at the [edit
snmp trap-options] hierarchy level. Currently, the agent address can only be the address
of the outgoing interface:
[edit snmp]
trap-options {
}
To configure the outgoing interface as the agent address:
[edit snmp]
trap-options {
}
trap-group “ urgent-dispatcher” {
version v1;
targets {
192.168.10.22;
172.17.1.2;
}
}
In this example, each SNMPv1 trap packet sent has its agent address value set to the IP
address of the outgoing interface.
Adding snmpTrapEnterprise Object Identifier to Standard SNMP Traps

The snmpTrapEnterprise object helps you identify the enterprise that has defined the
trap. Typically, the snmpTrapEnterprise object appears as the last varbind in
enterprise-specific SNMP version 2 traps. However, starting Release 10.0, Junos OS
enables you to add the snmpTrapEnterprise object identifier to standard SNMP traps as
well.
To add snmpTrapEnterprise to standard traps, include the enterprise-oid statement at

the [edit snmp trap-options] hierarchy level. If the enterprise-oid statement is not included
in the configuration, snmpTrapEnterprise is added only for enterprise-specific traps.
[edit snmp]
trap-options {
enterprise-oid;
}
Related • Configuring SNMP Trap Options and Groups on a Device Running Junos OS on page 107
Documentation

Configuring SNMP Trap Groups
You can create and name a group of one or more types of SNMP traps and then define
which systems receive the group of SNMP traps. The trap group must be configured for
SNMP traps to be sent. To create an SNMP trap group, include the trap-group statement
at the [edit snmp] hierarchy level:
[edit snmp]
categories {
category;
}
targets {
address;
}
}
The trap group name can be any string and is embedded in the community name field
of the trap. To configure your own trap group port, include the destination-port statement.
The default destination port is port 162.
For each trap group that you define, you must include the target statement to define at
least one system as the recipient of the SNMP traps in the trap group. Specify the IPv4
or IPv6 address of each recipient, not its hostname.
Specify the types of traps the trap group can receive in the categories statement. For
information about the category to which the traps belong, see the “Standard SNMP Traps
Supported by Junos OS” on page 57 and “Enterprise-Specific SNMP Traps Supported by
Junos OS” on page 64 topics.
Specify the routing instance used by the trap group in the routing-instance statement.
All targets configured in the trap group use this routing instance.
A trap group can receive the following categories:
• authentication—Authentication failures
• chassis—Chassis or environment notifications
• configuration—Configuration notifications
• link—Link-related notifications (up-down transitions, DS-3 and DS-1 line status change,
IPv6 interface state change, and Passive Monitoring PIC overload)
NOTE: To send Passive Monitoring PIC overload interface traps, select the
link trap category.
• remote-operations—Remote operation notifications

• rmon-alarm—Alarm for RMON events
• routing—Routing protocol notifications
• sonet-alarms—SONET/SDH alarms
NOTE: If you omit the SONET/SDH subcategories, all SONET/SDH trap

alarm types are included in trap notifications.
• loss-of-light—Loss of light alarm notification
• pll-lock—PLL lock alarm notification
• loss-of-frame—Loss of frame alarm notification
• loss-of-signal—Loss of signal alarm notification
• severely-errored-frame—Severely errored frame alarm notification
• line-ais—Line alarm indication signal (AIS) alarm notification
• path-ais—Path AIS alarm notification
• loss-of-pointer—Loss of pointer alarm notification
• ber-defect—SONET/SDH bit error rate alarm defect notification
• ber-fault—SONET/SDH error rate alarm fault notification
• line-remote-defect-indication—Line remote defect indication alarm notification
• path-remote-defect-indication—Path remote defect indication alarm notification
• remote-error-indication—Remote error indication alarm notification
• unequipped—Unequipped alarm notification
• path-mismatch—Path mismatch alarm notification
• loss-of-cell—Loss of cell delineation alarm notification
• vt-ais—Virtual tributary (VT) AIS alarm notification
• vt-loss-of-pointer—VT loss of pointer alarm notification
• vt-remote-defect-indication—VT remote defect indication alarm notification
• vt-unequipped—VT unequipped alarm notification
• vt-label-mismatch—VT label mismatch error notification
• vt-loss-of-cell—VT loss of cell delineation notification
• startup—System warm and cold starts
• timing-events—Timing events and defects notification
• vrrp-events—Virtual Router Redundancy Protocol (VRRP) events such as new-master

or authentication failures

• startup—System warm and cold starts
• vrrp-events—Virtual Router Redundancy Protocol (VRRP) events such as new-master

or authentication failures
If you include SONET/SDH subcategories, only those SONET/SDH trap alarm types are
included in trap notifications.
The version statement allows you to specify the SNMP version of the traps sent to targets
of the trap group. If you specify v1 only, SNMPv1 traps are sent. If you specify v2 only,
SNMPv2 traps are sent. If you specify all, both an SNMPv1 and an SNMPv2 trap are sent
for every trap condition. For more information about the version statement, see version
(SNMP).
Related • Configuring SNMP Trap Options and Groups on a Device Running Junos OS on page 107
Documentation
• Example: Configuring SNMP Trap Groups on page 114
Example: Configuring SNMP Trap Groups
Set up a trap notification list named urgent-dispatcher for link and startup traps. This list
is used to identify the network management hosts (1.2.3.4 and fe80::1:2:3:4) to which
traps generated by the local router should be sent. The name specified for a trap group
is used as the SNMP community string when the agent sends traps to the listed targets.
[edit]
snmp {
trap-group "urgent-dispatcher" {
version v2;
targets {
1.2.3.4;
fe80::1:2:3:4;
}
}
}
Related • Configuring SNMP Trap Groups on page 112

Documentation
Configuring the Interfaces on Which SNMP Requests Can Be Accepted
Supported Platforms M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series

By default, all router or switch interfaces have SNMP access privileges. To limit the access
through certain interfaces only, include the interface statement at the [edit snmp]
hierarchy level:
[edit snmp]
interface [ interface-names ];
Specify the names of any logical or physical interfaces that should have SNMP access
privileges. Any SNMP requests entering the router or switch from interfaces not listed
are discarded.

Documentation
• Example: Configuring Secured Access List Checking on page 115
Example: Configuring Secured Access List Checking
SNMP access privileges are granted to only devices on interfaces so-0/0/0 and at-1/0/1.
The following example does this by configuring a list of logical interfaces:
[edit]
snmp {
interface [ so-0/0/0.0 so-0/0/0.1 at-1/0/1.0 at-1/0/1.1 ];
}
The following example grants the same access by configuring a list of physical interfaces:
[edit]
snmp {
interface [ so-0/0/0 at-1/0/1 ];
}
Related • Configuring the Interfaces on Which SNMP Requests Can Be Accepted on page 114
Documentation
Filtering Interface Information Out of SNMP Get and GetNext Output
Junos OS enables you to filter out information related to specific interfaces from the
output of SNMP Get and GetNext requests performed on interface-related MIBs such as
IF MIB, ATM MIB, RMON MIB, and the Juniper Networks enterprise-specific IF MIB.

You can use the following options of the filter-interfaces statement at the [edit snmp]
hierarchy level to specify the interfaces that you want to exclude from SNMP Get and
GetNext queries:
• interfaces—Interfaces that match the specified regular expressions.
• all-internal-interfaces—Internal interfaces.
[edit]
snmp {
filter-interfaces {
interfaces {
interface-name 1;
interface-name 2;
}
all-internal-interfaces;
}
}
Starting with Release 12.1, Junos OS provides an except option (! operator) that enables
you to filter out all interfaces except those interfaces that match all the regular expressions
prefixed with the ! mark.
For example, to filter out all interfaces except the ge interfaces from the SNMP get and
get-next results, enter the following command:
[edit snmp]
user@host# set filter-interfaces interfaces “!^~ge-.*”
user@host# commit
When this is configured, Junos OS filters out all interfaces except the ge interfaces from
the SNMP get and get-next results.
NOTE: The ! mark is supported only as the first character of the regular
expression. If it appears anywhere else in a regular expression, Junos OS
considers the regular expression invalid, and returns an error.
However, note that these settings are limited to SNMP operations, and the users can
continue to access information related to the interfaces (including those hidden using
the filter-interfaces options) using the appropriate Junos OS command-line interface
(CLI) commands.
Documentation
Configuring MIB Views
Supported Platforms ACX Series, EX4600, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series, vSRX

SNMPv3 defines the concept of MIB views in RFC 3415, View-based Access Control Model
(VACM) for the Simple Network Management Protocol (SNMP). MIB views provide an
agent better control over who can access specific branches and objects within its MIB
tree. A view consists of a name and a collection of SNMP object identifiers, which are
either explicitly included or excluded. Once defined, a view is then assigned to an SNMPv3
group or SNMPv1/v2c community (or multiple communities), automatically masking
which parts of the agent’s MIB tree members of the group or community can (or cannot)
access.
By default, an SNMP community grants read access and denies write access to all
supported MIB objects (even communities configured as authorization read-write). To
restrict or grant read or write access to a set of MIB objects, you must configure a MIB
view and associate the view with a community.
To configure MIB views, include the view statement at the [edit snmp] hierarchy level:
[edit snmp]
view view-name {
}
The view statement defines a MIB view and identifies a group of MIB objects. Each MIB
object of a view has a common object identifier (OID) prefix. Each object identifier
represents a subtree of the MIB object hierarchy. The subtree can be represented either
by a sequence of dotted integers (such as 1.3.6.1.2.1.2) or by its subtree name (such as
interfaces). A configuration statement uses a view to specify a group of MIB objects on
which to define access. You can also use a wildcard character asterisk (*) to include
OIDs that match a particular pattern in the SNMP view. To enable a view, you must
associate the view with a community.
To remove an OID completely, use the delete view all oid oid-number command but omit
the include parameter.

user@host# set view view-name oid object-identifier (include | exclude)
The following example creates a MIB view called ping-mib-view. The oid statement does
not require a dot at the beginning of the object identifier. The snmp view statement
includes the branch under the object identifier .1.3.6.1.2.1.80. This includes the entire
DISMAN-PINGMIB subtree (as defined in RFC 2925, Definitions of Managed Objects for
Remote Ping, Traceroute, and Lookup Operations), which effectively permits access to
any object under that branch.

user@host# set view ping-mib-view oid 1.3.6.1.2.1.80 include
The following example adds a second branch in the same MIB view.

user@host# set view ping-mib-view oid jnxPingMIB include
Assign a MIB view to a community that you want to control.

To associate MIB views with a community, include the view statement at the [edit snmp
community community-name] hierarchy level:
[edit snmp community community-name]

view view-name;
For more information about the Ping MIB, see RFC 2925 and PING MIB.
Related • PING MIB

Documentation
• Configuring Ping Proxy MIB on page 118
• view (Configuring a MIB View) on page 727
• view (Associating MIB View with a Community)
• oid on page 716
Configuring Ping Proxy MIB
Restrict the ping-mib community to read and write access of the Ping MIB and jnxpingMIB
only. Read or write access to any other MIB using this community is not allowed.
[edit snmp]
view ping-mib-view {
oid 1.3.6.1.2.1.80 include; #pingMIB
oid jnxPingMIB include; #jnxPingMIB
}
community ping-mib {
view ping-mib-view;
}
The following configuration prevents the no-ping-mib community from accessing Ping
MIB and jnxPingMIB objects. However, this configuration does not prevent the no-ping-mib
community from accessing any other MIB object that is supported on the device.
[edit snmp]
view no-ping-mib-view {
oid 1.3.6.1.2.1.80 exclude; # deny access to pingMIB objects
oid jnxPingMIB exclude; # deny access to jnxPingMIB objects
}
community no-ping-mib {
view ping-mib-view;
}

Documentation

• oid on page 716


CHAPTER 7
Configuring SNMPv3
• Minimum SNMPv3 Configuration on a Device Running Junos OS on page 122

• Example: SNMPv3 Configuration on page 123
• Configuring the Local Engine ID on page 126
• Creating SNMPv3 Users on page 127
• Example: Creating SNMPv3 Users on page 128
• Configuring the SNMPv3 Authentication Type on page 128
• Configuring the SNMPv3 Encryption Type on page 130
• Configuring the Access Privileges Granted to a Group on page 133
• Example: Configuring the Access Privileges Granted to a Group on page 136
• Assigning Security Model and Security Name to a Group on page 137
• Example: Security Group Configuration on page 138
• Configuring the SNMPv3 Trap Notification on page 140
• Example: Configuring SNMPv3 Trap Notification on page 141
• Configuring the Trap Notification Filter on page 141
• Configuring the Trap Target Address on page 142
• Example: Configuring the Tag List on page 145
• Defining and Configuring the Trap Target Parameters on page 146
• Configuring the Remote Engine and Remote User on page 150
• Example: Configuring the Remote Engine ID and Remote User on page 151
• Configuring the Inform Notification Type and Target Address on page 154
• Example: Configuring the Inform Notification Type and Target Address on page 155
• Configuring the SNMPv3 Community on page 156
• Example: Configuring an SNMPv3 Community on page 158

Minimum SNMPv3 Configuration on a Device Running Junos OS
Supported Platforms ACX Series, EX4600, M Series, MX Series, PTX Series, QFabric System, QFX Series, T Series
To configure the minimum requirements for SNMPv3, include the following statements
at the [edit snmp v3] and [edit snmp] hierarchy levels:
NOTE: You must configure at least one view (notify, read, or write) at the
[edit snmp view-name] hierarchy level.
[edit snmp]
view view-name {
}
[edit snmp v3]
notify name {
tag tag-name;
}
}
}
address address;
}
parameters {
}
}
usm {
local-engine {
user username {
}
}
}
vacm {
access {
group group-name {
(default-context-prefix | context-prefix context-prefix){
}

Chapter 7: Configuring SNMPv3
}
}
}
}
security-to-group {
group group-name;
}
}
}
}
Related • Creating SNMPv3 Users on page 127

Documentation
Example: SNMPv3 Configuration
Define an SNMPv3 configuration:
[edit snmp]
engine-id {
use-mac-address;
}
view jnxAlarms {
oid 1.3.6.1.4.1.2636.3.4 include;
}
view interfaces {
oid 1.3.6.1.2.1.2 include;
}
view ping-mib {
oid 1.3.6.1.2.1.80 include;
}
[edit snmp v3]
notify n1 {
tag router1; # Identifies a set of target addresses
type trap;# Defines type of notification
}
notify n2 {
tag host1;
type trap;
}
notify-filter nf1 {
oid .1 include; # Defines which traps to send
} # In this case, includes all traps

notify-filter nf2 {
oid 1.3.6.1.4.1 include; # Sends enterprise-specific traps only
}
notify-filter nf3 {
oid 1.3.6.1.2.1.1.5 include; # Sends BGP traps only
}
snmp-community index1 {
community-name "$9$JOZi.QF/AtOz3"; # SECRET-DATA
security-name john; # Matches the security name at the target parameters
tag host1; # Finds the addresses that are allowed to be used with
}
target-address ta1 {# Associates the target address with the group
# san-francisco.
address 10.1.1.1;
address-mask 255.255.255.0; # Defines the range of addresses
port 162;
tag-list router1;
target-parameters tp1; # Applies configured target parameters
}
target-address ta2 {
address 10.1.1.2;
port 162;
tag-list host1;
target-parameters tp2;
}
address 10.1.1.3;
port 162;
tag-list “router1 host1”;
}
target-parameters tp1 { # Defines the target parameters
notify-filter nf1; # Specifies which notify filter to apply
parameters {
security-model v1;
security-name john; # Matches the security name configured at the
} # [edit snmp v3 snmp-community community-index hierarchy level.
}
target-parameters tp2 {
notify-filter nf2;
parameters {
security-model v1;
security-name john;
}
}
notify-filter nf3;
parameters {
security-model v1;

security-name john;
}
}
usm {
local-engine { #Defines authentication and encryption for SNMPv3 users
user user1 {
}
privacy-des {
}
}
user user2 {
}
privacy-none;
}
user user3 {
privacy-none;
}
user user4 {
}
privacy-aes128 {
}
}
user user5 {
}
privacy-none;
}
}
}
vacm {
access {
group san-francisco { #Defines the access privileges for the group
default-context-prefix { # called san-francisco
security-model v1 {
security-level none {
notify-view ping-mib;
read-view interfaces;
write-view jnxAlarms;
}
}
}
}
}
security-to-group {
security-model v1 {

security-name john { # Assigns john to the security group

group san-francisco; # called san-francisco
}
security-name bob {
group new-york;
}
security-name elizabeth {
group chicago;
}
}
}
}

Documentation
Configuring the Local Engine ID
By default, the local engine ID uses the default IP address of the router. The local engine
ID is the administratively unique identifier for the SNMPv3 engine. This statement is
optional. To configure the local engine ID, include the engine-id statement at the [edit
snmp] hierarchy level:
[edit snmp]
engine-id {
(local engine-id-suffix | use-default-ip-address | use-mac-address);
}
• local engine-id-suffix—The engine ID suffix is explicitly configured.
• use-default-ip-address—The engine ID suffix is generated from the default IP address.
• use-mac-address—The SNMP engine identifier is generated from the Media Access

Control (MAC) address of the management interface on the router.
The local engine ID is defined as the administratively unique identifier of an SNMPv3

engine, and is used for identification, not for addressing. There are two parts of an engine
ID: prefix and suffix. The prefix is formatted according to the specifications defined in
RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks. You can configure the suffix here.
NOTE: SNMPv3 authentication and encryption keys are generated based on

the associated passwords and the engine ID. If you configure or change the
engine ID, you must commit the new engine ID before you configure SNMPv3
users. Otherwise the keys generated from the configured passwords are
based on the previous engine ID. For the engine ID, we recommend using the
master IP address of the device if the device has multiple routing engines
and has the master IP address configured. Alternatively, you can use the MAC
address of the management port if the device has only one Routing Engine.


Documentation
Creating SNMPv3 Users
Supported Platforms ACX Series, EX4600, M Series, MX Series, PTX Series, QFX Series, T Series
For each SNMPv3 user, you can specify the username, authentication type, authentication
password, privacy type, and privacy password. After a user enters a password, a key
based on the engine ID and password is generated and is written to the configuration
file. After the generation of the key, the password is deleted from this configuration file.
NOTE: You can configure only one encryption type for each SNMPv3 user.
To create users, include the user statement at the [edit snmp v3 usm local-engine]
hierarchy level:
[edit snmp v3 usm local-engine]

user username;
username is the name that identifies the SNMPv3 user.
To configure user authentication and encryption, include the following statements at

the [edit snmp v3 usm local-engine user username] hierarchy level:
[edit snmp v3 usm local-engine user username]

}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none;

Documentation
• Example: Creating SNMPv3 Users on page 128

Example: Creating SNMPv3 Users
Define SNMPv3 users:
[edit]
snmp {
v3 {
usm {
local-engine {
user user1 {
}
privacy-des {
privacy-password password;
}
}
user user2 {
}
privacy-none;
}
user user3 {
privacy-none;
}
user user4 {
}
privacy-des {
privacy-password authentication-password;
}
}
user user5 {
}
privacy-aes128 {
privacy-password authentication-password;
}
}
}
}
}
}

Documentation
Configuring the SNMPv3 Authentication Type

By default, in a Junos OS configuration the SNMPv3 authentication type is set to none.
This topic includes the following sections:
• Configuring MD5 Authentication on page 129

• Configuring SHA Authentication on page 129
• Configuring No Authentication on page 129
Configuring MD5 Authentication

To configure the message digest algorithm (MD5) as the authentication type for an
SNMPv3 user, include the authentication-md5 statement at the [edit snmp v3 usm
local-engine user username] hierarchy level:

}
authentication-password is the password used to generate the key used for authentication.
SNMPv3 has special requirements when you create plain-text passwords on a router or
switch:
• The password must be at least eight characters long.
• The password can include alphabetic, numeric, and special characters, but it cannot
include control characters.
Configuring SHA Authentication

To configure the secure hash algorithm (SHA) as the authentication type for an SNMPv3
user, include the authentication-sha statement at the [edit snmp v3 usm local-engine user
username] hierarchy level:

}
authentication-password is the password used to generate the key used for authentication.
switch:
Configuring No Authentication
To configure no authentication for an SNMPv3 user, include the authentication-none
statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

Related • Configuring the SNMPv3 Encryption Type on page 130

Documentation
Configuring the SNMPv3 Encryption Type
By default, encryption is set to none.
NOTE: Before you configure encryption, you must configure MD5 or SHA
authentication.
Before you configure the privacy-des, privacy-3des and privacy-aes128

statements, you must install the jcrypto package, and either restart the SNMP
process or reboot the router.
• Configuring the Advanced Encryption Standard Algorithm on page 130

• Configuring the Data Encryption Algorithm on page 131
• Configuring Triple DES on page 131
• Configuring No Encryption on page 131
Configuring the Advanced Encryption Standard Algorithm

To configure the Advanced Encryption Standard (AES) algorithm for an SNMPv3 user,
include the privacy-aes128 statement at the [edit snmp v3 usm local-engine user username]
hierarchy level:

privacy-aes128 {
}
privacy-password is the password used to generate the key used for encryption.
switch:

Configuring the Data Encryption Algorithm

To configure the data encryption algorithm (DES) for an SNMPv3 user, include the
privacy-des statement at the [edit snmp v3 usm local-engine user username] hierarchy
level:

privacy-des {
}
switch:
Configuring Triple DES

To configure triple DES for an SNMPv3 user, include the privacy-3des statement at the
[edit snmp v3 usm local-engine user username] hierarchy level:

privacy-3des {
}
switch:
Configuring No Encryption
To configure no encryption for an SNMPv3 user, include the privacy-none statement at
the [edit snmp v3 usm local-engine user username] hierarchy level:

privacy-none;
Related • Configuring the SNMPv3 Authentication Type on page 128

Documentation

Defining Access Privileges for an SNMP Group
The SNMP version 3 (SNMPv3) uses the view-based access control model (VACM),
which allows you to configure the access privileges granted to a group. Access is controlled
by filtering the MIB objects available for a specific operation through a predefined view.
You assign views to determine the objects that are visible for read, write, and notify
operations for a particular group, using a particular context, a particular security model
(v1, v2c, or usm), and particular security level (authenticated, privacy, or none). For
information about how to configure views, see “Configuring MIB Views” on page 116.
You define user access to management information at the [edit snmp v3 vacm] hierarchy
level. All access control within VACM operates on groups, which are collections of users
as defined by USM, or community strings as defined in the SNMPv1 and SNMPv2c security
models. The term security-name refers to these generic end users. The group to which a
specific security name belongs is configured at the [edit snmp v3 vacm security-to-group]
hierarchy level. That security name can be associated with a group defined at the [edit
snmp v3 vacm security-to-group] hierarchy level. A group identifies a collection of SNMP
users that share the same access policy. You then define the access privileges associated
with a group at the [edit snmp v3 vacm access] hierarchy level. Access privileges are
defined using views. For each group, you can apply different views depending on the
SNMP operation; for example, read (get, getNext, or getBulk) write (set), notifications,
the security level used (authentication, privacy, or none), and the security model (v1, v2c,
or usm) used within an SNMP request.
You configure members of a group with the security-name statement. For v3 packets
using USM, the security name is the same as the username. For SNMPv1 or SNMPv2c
packets, the security name is determined based on the community string. Security names
are specific to a security model. If you are also configuring VACM access policies for
SNMPv1 or SNMPv2c packets, you must assign security names to groups for each security
model (SNMPv1 or SNMPv2c) at the [edit snmp v3 vacm security-to-group] hierarchy
level. You must also associate a security name with an SNMP community at the [edit
snmp v3 snmp-community community-index] hierarchy level.
To configure the access privileges for an SNMP group, include statements at the [edit
snmp v3 vacm] hierarchy level:
[edit snmp v3 vacm]

access {
group group-name {
}
}

}
}
}
security-to-group {
group group-name;
}
}
}

Documentation
Configuring the Access Privileges Granted to a Group
• Configuring the Group on page 133

• Configuring the Security Model on page 133
• Configuring the Security Level on page 134
• Associating MIB Views with an SNMP User Group on page 134
Configuring the Group

To configure the access privileges granted to a group, include the group statement at
the [edit snmp v3 vacm access] hierarchy level:
[edit snmp v3 vacm access]

group group-name;
group-name is a collection of SNMP users that belong to a common SNMP list that defines
an access policy. Users belonging to a particular SNMP group inherit all access privileges
granted to that group.
Configuring the Security Model

To configure the security model, include the security-model statement at the [edit snmp
v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix)]
hierarchy level:
[edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix

context-prefix)]
security-model (any | usm | v1 | v2c);
• any—Any security model
• usm—SNMPv3 security model

• v1—SNMPV1 security model
• v2c—SNMPv2c security model
Configuring the Security Level

To configure the access privileges granted to packets with a particular security level,
include the security-level statement at the [edit snmp v3 vacm access group group-name
(default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 |
v2c)] hierarchy level:
[edit snmp v3 vacm access group group-name default-context-prefix security-model (any

| usm | v1 | v2c)]
• none—Provides no authentication and no encryption.
• authentication—Provides authentication but no encryption.
• privacy—Provides authentication and encryption.
NOTE: Access privileges are granted to all packets with a security level
equal to or greater than that configured. If you are configuring the SNMPv1
or SNMPv2c security model, use none as your security level. If you are
configuring the SNMPv3 security model (USM), use the authentication,
none, or privacy security level.
Associating MIB Views with an SNMP User Group

MIB views define access privileges for members of a group. Separate views can be applied
for each SNMP operation (read, write, and notify) within each security model (usm, v1,
and v2c) and each security level (authentication, none, and privacy) supported by SNMP.
To associate MIB views with an SNMP user group, include the following statements at
the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix
context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none |
privacy)] hierarchy level:
[edit snmp v3 vacm accessgroup group-name (default-context-prefix | context-prefix

context-prefix)security-model (any | usm | v1 | v2c) security-level (authentication | none
| privacy)]

NOTE: You must associate at least one view (notify, read, or write) at the
[edit snmp v3 vacm access group group-name (default-context-prefix |
context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level
(authentication | none | privacy)] hierarchy level.
You must configure the MIB view at the [edit snmp view view-name] hierarchy
level. For information about how to configure MIB views, see “Configuring
MIB Views” on page 116.
This section describes the following topics related to this configuration:
• Configuring the Notify View on page 135

• Configuring the Read View on page 135
• Configuring the Write View on page 136
Configuring the Notify View

To associate notify access with an SNMP user group, include the notify-view statement
at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix

context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none
| privacy)]
view-name specifies the notify access, which is a list of notifications that can be sent to
each user in an SNMP group. A view name cannot exceed 32 characters.
Configuring the Read View

To associate a read view with an SNMP group, include the read-view statement at the

| privacy)]
view-name specifies read access for an SNMP user group. A view name cannot exceed
32 characters.

Configuring the Write View

To associate a write view with an SNMP user group, include the write-view statement at
the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix

| privacy)]
view-name specifies write access for an SNMP user group. A view name cannot exceed
32 characters.

Documentation
• Example: Configuring the Access Privileges Granted to a Group on page 136
Example: Configuring the Access Privileges Granted to a Group
Define access privileges:
[edit snmp v3 vacm]

access {
group group1 {
security-model usm { #Define an SNMPv3 security model
security-level privacy {
notify-view nv1;
read-view rv1;
write-view wv1;
}
}
}
context-prefix lr1/ri1{ # routing instance ri1 in logical system lr1
security-level privacy {
notify-view nv1;
read-view rv1;
write-view wv1;
}
}
}
}
group group2 {
security-model usm { #Define an SNMPv3 security model

read-view rv2;
write-view wv2;
}
}
}
}
group group3 {
security-model v1 { #Define an SNMPv3 security model
read-view rv3;
write-view wv3;
}
}
}
}
}
Related • Configuring the Access Privileges Granted to a Group on page 133

Documentation
Assigning Security Model and Security Name to a Group
To assign security names to groups, include the following statements at the [edit snmp
v3 vacm security-to-group] hierarchy level:
[edit snmp v3 vacm security-to-group]

group group-name;
}
}

• Assigning Security Names to Groups on page 138
• Configuring the Group on page 138

To configure the security model, include the security-model statement at the [edit snmp
v3 vacm security-to-group] hierarchy level:
[edit snmp v3 vacm security-to-group]

• v1—SNMPv1 security model
• v2c—SNMPv2 security model

Assigning Security Names to Groups

To associate a security name with an SNMPv3 user, or a v1 or v2 community string, include
the security-name statement at the [edit snmp v3 vacm security-to-group security-model
(usm | v1 | v2c)] hierarchy level:
[edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c)]

For SNMPv3, the security-name is the username configured at the [edit snmp v3 usm
local-engine user username] hierarchy level. For SNMPv1 and SNMPv2c, the security name
is the community string configured at the [edit snmp v3 snmp-community community-index]
hierarchy level. For information about configuring usernames, see “Creating SNMPv3
Users” on page 127. For information about configuring a community string, see “Configuring
the SNMPv3 Community” on page 156.
NOTE: The USM security name is separate from the SNMPv1 and SNMPv2c
security name. If you support SNMPv1 and SNMPv2c in addition to SNMPv3,
you must configure separate security names within the security-to-group
configuration at the [edit snmp v3 vacm access] hierarchy level.
Configuring the Group

After you have created SNMPv3 users, or v1 or v2 security names, you associate them
with a group. A group is a set of security names belonging to a particular security model.
A group defines the access rights for all users belonging to it. Access rights define what
SNMP objects can be read, written to, or created. A group also defines what notifications
a user is allowed to receive.
If you already have a group that is configured with all of the view and access permissions
that you want to give a user, you can add the user to that group. If you want to give a user
view and access permissions that no other groups have, or if you do not have any groups
configured, create a group and add the user to it.
To configure the access privileges granted to a group, include the group statement at
the [edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c) security-name
security-name] hierarchy level:
[edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c) security-name

security-name]
group group-name;
group-name identifies a collection of SNMP security names that share the same access
policy. For more information about groups, see “Defining Access Privileges for an SNMP
Group” on page 132.
Example: Security Group Configuration
Supported Platforms M Series, MX Series, SRX Series, T Series, vSRX

Assign security names to groups:
vacm {
security-to-group {
security-name user1 {
group group1;
}
group group2;
}
group group3;
}
}
}
}
Related • Assigning Security Model and Security Name to a Group on page 137
Documentation
Configuring SNMPv3 Traps on a Device Running Junos OS
Supported Platforms ACX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series
In SNMPv3, you create traps and informs by configuring the notify, target-address, and
target-parameters parameters. Traps are unconfirmed notifications, whereas informs
are confirmed notifications. This section describes how to configure SNMP traps. For
information about configuring SNMP informs, see “Configuring SNMP Informs” on page 149.
The target address defines a management application’s address and parameters to be

used in sending notifications. Target parameters define the message processing and
security parameters that are used in sending notifications to a particular management
target. SNMPv3 also lets you define SNMPv1 and SNMPv2c traps.
NOTE: When you configure SNMP traps, make sure your configured access
privileges allow the traps to be sent. Access privileges are configured at the
[edit snmp v3 vacm access] and [edit snmp v3 vacm security-to-group] hierarchy
levels.
To configure SNMP traps, include the following statements at the [edit snmp v3] hierarchy
level:
[edit snmp v3]

notify name {
tag tag-name;
type trap;
}
notify-filter name {
}

address address;
port port-number;
tag-list tag-list;
}
parameters {
}
}
Related • Configuring the SNMPv3 Trap Notification on page 140

Documentation
Configuring the SNMPv3 Trap Notification
The notify statement specifies the type of notification (trap) and contains a single tag.
The tag defines a set of target addresses to receive a trap. The tag list contains one or
more tags and is configured at the [edit snmp v3 target-address target-address-name]
hierarchy level. If the tag list contains this tag, Junos OS sends a notification to all the
target addresses associated with this tag.
To configure the trap notifications, include the notify statement at the [edit snmp v3]
hierarchy level:
[edit snmp v3]

notify name {
tag tag-name;
type trap;
}
name is the name assigned to the notification.

tag-name defines the target addresses to which this notification is sent. This notification
is sent to all the target-addresses that have this tag in their tag list. The tag-name is not
included in the notification.
trap is the type of notification.
NOTE: Each notify entry name must be unique.
Junos OS supports two types of notification: trap and inform.
For information about how to configure the tag list, see “Configuring the Trap Target
Address” on page 144.
Related • Configuring SNMPv3 Traps on a Device Running Junos OS on page 139

Documentation
Example: Configuring SNMPv3 Trap Notification
Supported Platforms M Series, MX Series, PTX Series, SRX Series, T Series
Specify three sets of destinations to send traps:
[edit snmp v3]

notify n1 {
tag router1;
type trap;
}
notify n2 {
tag router2;
type trap
}
notify n3 {
tag router3;
type trap;
}

Documentation
Configuring the Trap Notification Filter

SNMPv3 uses the notify filter to define which traps (or which objects from which traps)
are sent to the network management system (NMS). The trap notification filter limits
the type of traps that are sent to the NMS.
Each object identifier represents a subtree of the MIB object hierarchy. The subtree can
be represented either by a sequence of dotted integers (such as 1.3.6.1.2.1.2) or by its
subtree name (such as interfaces). You can also use the wildcard character asterisk (*)
in the object identifier (OID) to specify object identifiers that match a particular pattern.
To configure the trap notifications filter, include the notify-filter statement at the
[edit snmp v3] hierarchy level:
[edit snmp v3]

profile-name is the name assigned to the notify filter.
By default, the OID is set to include. To define access to traps (or objects from traps),
include the oid statement at the [edit snmp v3 notify-filter profile-name] hierarchy level:
[edit snmp v3 notify-filter profile-name]

oid is the object identifier. All MIB objects represented by this statement have the specified
OID as a prefix. It can be specified either by a sequence of dotted integers or by a subtree
name.
• include—Include the subtree of MIB objects represented by the specified OID.
• exclude—Exclude the subtree of MIB objects represented by the specified OID.

Documentation
Configuring the Trap Target Address
The target address defines a management application’s address and parameters that
are used in sending notifications. It can also identify management stations that are
allowed to use specific community strings. When you receive a packet with a recognized
community string and a tag is associated with it, Junos OS looks up all the target addresses
with this tag and verifies that the source address of this packet matches one of the
configured target addresses.

NOTE: You must configure the address mask when you configure the SNMP
community.
To specify where you want the traps to be sent and define what SNMPv1 and SNMPv2cc
packets are allowed, include the target-address statement at the [edit snmp v3] hierarchy
level:
[edit snmp v3]

target-address target-address-name;
target-address-name is the string that identifies the target address.
To configure the target address properties, include the following statements at the [edit
snmp v3 target-address target-address-name] hierarchy level:
[edit snmp v3 target-address target-address-name]

address address;
port port-number;
tag-list tag-list;
This section includes the following topics:
• Configuring the Address on page 143

• Configuring the Address Mask on page 143
• Configuring the Port on page 144
• Configuring the Routing Instance on page 144
• Applying Target Parameters on page 145
Configuring the Address

To configure the address, include the address statement at the [edit snmp v3
target-address target-address-name] hierarchy level:

address address;
address is the SNMP target address.
Configuring the Address Mask

The address mask specifies a set of addresses that are allowed to use a community
string and verifies the source addresses for a group of target addresses.
To configure the address mask, include the address-mask statement at the [edit snmp
v3 target-address target-address-name] hierarchy level:


address-mask combined with the address defines a range of addresses. For information
about how to configure the community string, see “Configuring the SNMPv3 Community”
on page 156.
Configuring the Port

By default, the UDP port is set to 162. To configure a different port number, include the
port statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

port port-number;
port-number is the SNMP target port number.
Configuring the Routing Instance

Traps are sent over the default routing instance. To configure the routing instance for
sending traps, include the routing-instance statement at the [edit snmp v3 target-address
target-address-name] hierarchy level:

instance is the name of the routing instance. To configure a routing instance within a
logical system, specify the logical system name followed by the routing instance name.
Use a slash ( / ) to separate the two names (for example, test-lr/test-ri). To configure
the default routing instance on a logical system, specify the logical system name followed
by default (for example, test-lr/default).
Configuring the Trap Target Address

Each target-address statement can have one or more tags configured in its tag list. Each
tag can appear in more than one tag list. When a significant event occurs on the network
device, the tag list identifies the targets to which a notification is sent.
To configure the tag list, include the tag-list statement at the [edit snmp v3 target-address
target-address-name] hierarchy level:

tag-list “tag-list”;
tag-list specifies one or more tags as a space-separated list enclosed within double
quotes.
For an example of tag list configuration, see “Example: Configuring the Tag List” on
page 145.
For information about how to specify a tag at the [edit snmp v3 notify notify-name]
hierarchy level, see “Configuring the SNMPv3 Trap Notification” on page 140.
NOTE: When you configure SNMP traps, make sure your configured access
privileges allow the traps to be sent. Configure access privileges at the [edit
snmp v3 vacm access] hierarchy level.

Applying Target Parameters

The target-parameters statement at the [edit snmp v3] hierarchy level applies the target
parameters configured at the [edit snmp v3 target-parameters target-parameters-name]
hierarchy level.
To reference configured target parameters, include the target-parameters statement at

the [edit snmp v3 target-address target-address-name] hierarchy level:

target-parameters-name is the name associated with the message processing and security
parameters that are used in sending notifications to a particular management target.

Documentation
• Example: Configuring the Tag List on page 145
Example: Configuring the Tag List
In the following example, two tag entries (router1 and router2) are defined at the [edit
snmp v3 notify notify-name] hierarchy level. When an event triggers a notification, Junos
OS sends a trap to all target addresses that have router1 or router2 configured in their
target-address tag list. This results in the first two targets getting one trap each, and the
third target getting two traps.
[edit snmp v3]

notify n1 {
tag router1; # Identifies a set of target addresses
type trap; # Defines the type of notification
}
notify n2 {
tag router2;
type trap;
}
address 10.1.1.1;
port 162;
tag-list router1;
}

address 10.1.1.2;
port 162;
tag-list router2;
}
address 10.1.1.3;
port 162;
tag-list “router1 router2”; #Define multiple tags in the target address tag list
}

Documentation
Defining and Configuring the Trap Target Parameters
Target parameters define the message processing and security parameters that are used
in sending notifications to a particular management target.
To define a set of target parameters, include the target-parameters statement at the

[edit snmp v3] hierarchy level:
[edit snmp v3]

target-parameters-name is the name assigned to the target parameters.
To configure target parameter properties, include the following statements at the [edit
snmp v3 target-parameters target-parameter-name] hierarchy level:
[edit snmp v3 target-parameters target-parameter-name]

parameters {
message-processing-model (v1 | v2c | V3);
}
• Applying the Trap Notification Filter on page 147

• Configuring the Target Parameters on page 147

Applying the Trap Notification Filter

To apply the trap notification filter, include the notify-filter statement at the [edit snmp
v3 target-parameters target-parameter-name] hierarchy level:
[edit snmp v3 target-parameters target-parameter-name]

profile-name is the name of a configured notify filter. For information about configuring
notify filters, see “Configuring the Trap Notification Filter” on page 141.
Configuring the Target Parameters

To configure target parameter properties, include the following statements at the [edit
snmp v3 target-parameters target-parameter-name parameters] hierarchy level:
[edit snmp v3 target-parameters target-parameter-name parameters]

• Configuring the Message Processing Model on page 147

• Configuring the Security Level on page 148
• Configuring the Security Name on page 148
Configuring the Message Processing Model

The message processing model defines which version of SNMP to use when generating
SNMP notifications. To configure the message processing model, include the
message-processing-model statement at the [edit snmp v3 target-parameters
target-parameter-name parameters] hierarchy level:

• v1—SNMPv1 message processing model
• v2c—SNMPv2c message processing model
• v3—SNMPV3 message processing model

To define the security model to use when generating SNMP notifications, include the
security-model statement at the [edit snmp v3 target-parameters target-parameter-name
parameters] hierarchy level:

• v1—SNMPv1 security model

• v2c—SNMPv2c security model
Configuring the Security Level
The security-level statement specifies whether the trap is authenticated and encrypted
before it is sent.
To configure the security level to use when generating SNMP notifications, include the
security-level statement at the [edit snmp v3 target-parameters target-parameter-name

• none—No security. Provides no authentication and no encryption.
NOTE: If you are configuring the SNMPv1 or SNMPV2c security model, use
none as your security level. If you are configuring the SNMPv3 (USM)
security model, use the authentication or privacy security level.
Configuring the Security Name

To configure the security name to use when generating SNMP notifications, include the
security-name statement at the [edit snmp v3 target-parameters target-parameter-name

If the USM security model is used, the security-name identifies the user that is used when
the notification is generated. If the v1 or v2c security models are used, security-name
identifies the SNMP community used when the notification is generated.
NOTE: The access privileges for the group associated with a security name
must allow this notification to be sent.
If you are using the v1 or v2 security models, the security name at the [edit
snmp v3 vacm security-to-group] hierarchy level must match the security
name at the [edit snmp v3 snmp-community community-index] hierarchy level.

Documentation

Configuring SNMP Informs
Supported Platforms ACX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series, vSRX
Junos OS supports two types of notifications: traps and informs. With traps, the receiver
does not send any acknowledgment when it receives a trap. Therefore, the sender cannot
determine if the trap was received. A trap may be lost because a problem occurred during
transmission. To increase reliability, an inform is similar to a trap except that the inform
is stored and retransmitted at regular intervals until one of these conditions occurs:
• The receiver (target) of the inform returns an acknowledgment to the SNMP agent.
• A specified number of unsuccessful retransmissions have been attempted and the

agent discards the inform message.
If the sender never receives a response, the inform can be sent again. Thus, informs are
more likely to reach their intended destination than traps are. Informs use the same
communications channel as traps (same socket and port) but have different protocol
data unit (PDU) types.
Informs are more reliable than traps, but they consume more network, router, and switch
resources (see Figure 1 on page 149). Unlike a trap, an inform is held in memory until a
response is received or the timeout is reached. Also, traps are sent only once, whereas
an inform may be retried several times. Use informs when it is important that the SNMP
manager receive all notifications. However, if you are more concerned about network
traffic, or router and switch memory, use traps.
Figure 1: Inform Request and Response
For information about configuring SNMP traps, see “Configuring SNMPv3 Traps on a
Device Running Junos OS” on page 139.

Documentation

Configuring the Remote Engine and Remote User
To send inform messages to an SNMPv3 user on a remote device, you must first specify
the engine identifier for the SNMP agent on the remote device where the user resides.
The remote engine ID is used to compute the security digest for authenticating and
encrypting packets sent to a user on the remote host. When sending an inform message,
the agent uses the credentials of the user configured on the remote engine (inform target).
To configure a remote engine and remote user to receive and respond to SNMP informs,
include the following statements at the [edit snmp v3] hierarchy level:
[edit snmp v3]

usm {
remote-engine engine-id {
user username {
authentication-key key;
}
authentication-key key;
}
privacy-3des {
privacy-key key;
}
privacy-aes128 {
privacy-key key;
}
privacy-des {
privacy-key key;
}
privacy-none;
}
}
}
For informs, remote-engine engine-id is the identifier for the SNMP agent on the remote
device where the user resides.
For informs, user username is the user on a remote SNMP engine who receives the informs.
Informs generated can be unauthenticated, authenticated, or authenticated_and_encrypted,

depending on the security level of the SNMPv3 user configured on the remote engine
(the inform receiver). The authentication key is used for generating message
authentication code (MAC). The privacy key is used to encrypt the inform PDU part of
the message.

Documentation

• Example: Configuring the Remote Engine ID and Remote User on page 151
Example: Configuring the Remote Engine ID and Remote User
This example shows how to configure a remote engine and remote user so you can receive
and respond to SNMP inform notifications. Inform notifications can be authenticated
and encrypted. They are also more reliable than traps, another type of notification that
Junos OS supports. Unlike traps, inform notifications are stored and retransmitted at
regular intervals until one of these conditions occurs:
• The target of the inform notification returns an acknowledgment to the SNMP agent.
• A specified number of unsuccessful retransmissions have been attempted.
• Requirements on page 151

• Overview on page 151
• Configuration on page 152
• Verification on page 153
Requirements
No special configuration beyond device initialization is required before configuring this
example.
This feature requires the use of plain-text passwords valid for SNMPv3. SNMPv3 has the
following special requirements when you create plain-text passwords on a router or
switch:
Although quotation marks are not always required to enclose passwords, it is best to use
them. You need quotation marks if the password contains any spaces or possibly in the
case of certain special characters or punctuation.
Overview
Inform notifications are supported in SNMPv3 to increase reliability. For example, an
SNMP agent receiving an inform notification acknowledges the receipt.
For inform notifications, the remote engine ID identifies the SNMP agent on the remote
device where the user resides, and the username identifies the user on a remote SNMP
engine who receives the inform notifications.
Consider a scenario in which you have the values in Table 13 on page 152 to use in
configuring the remote engine ID and remote user in this example.

Table 13: Values to Use in Example

Name of Variable Value
username u10
remote engine ID 800007E5804089071BC6D10A41
authentication type authentication-md5
authentication password qol67R%?
encryption type privacy-des
privacy password m*72Jl9v
Configuration
CLI Quick To quickly configure this example, copy the following commands and paste them into a
Configuration text file, remove any line breaks and change any details necessary to match your network
configuration, copy and paste these commands into the CLI at the [edit snmp v3] hierarchy
level, and then enter commit from configuration mode.
set usm remote-engine 800007E5804089071BC6D10A41 user u10 authentication-md5

authentication-key "qol67R%?"
set usm remote-engine 800007E5804089071BC6D10A41 user u10 privacy-des privacy-key
"m*72Jl9v"
Configuring the Remote Engine and Remote User
Step-by-Step The following example requires that you navigate to various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the Junos OS CLI User Guide.
To configure the remote engine ID and remote user:
1. Configure the remote engine ID, username, and authentication type and password.
[edit snmp v3]

user@host# set usm remote-engine 800007E5804089071BC6D10A41 user u10
authentication-md5 authentication-key "qol67R%?"
2. Configure the encryption type and privacy password.
You can configure only one encryption type per SNMPv3 user.
[edit snmp v3]

user@host# set usm remote-engine 800007E5804089071BC6D10A41 user u10
privacy-des privacy-key "m*72Jl9v"

Results
In configuration mode, confirm your configuration by entering the show command. If the
output does not display the intended configuration, repeat the instructions in this example
to correct the configuration.
[edit snmp v3]

user@ host# show
usm {
remote-engine 800007E5804089071BC6D10A41 {
user u10 {
authentication-key "$9$Tz/teK8NdsLXk.f5n6p0ORev"; ## SECRET-DATA
}
privacy-des {
privacy-key "$9$/gyNCu1KvWdwYMWw2gJHkRhcrWx"; ## SECRET-DATA
}
}
}
}
After you have confirmed that the configuration is correct, enter commit from configuration
mode.
Verification
Verifying the Configuration of the Remote Engine ID and Username
Purpose Verify the status of the engine ID and user information.
Action Display information about the SNMPv3 engine ID and user.
user@host> show snmp v3

Local engine ID: 80 00 0a 4c 01 0a ff 03 e3
Engine boots: 3
Engine time: 769187 seconds
Max msg size: 65507 bytes
Engine ID: 80 00 07 e5 80 40 89 07 1b c6 d1 0a 41
User Auth/Priv Storage Status
u10 md5/des nonvolatile active
Meaning The output displays the following information:
• Local engine ID and detail about the engine
• Remote engine ID (labeled Engine ID)
• Username
• Authentication type and encryption (privacy) type that is configured for the user

• Type of storage for the username, either nonvolatile (configuration saved) or volatile
(not saved)
• Status of the new user; only users with an active status can use SNMPv3
Related • show snmp v3 on page 880

Documentation
• Configuring the SNMPv3 Encryption Type on page 130
• Configuring the SNMPv3 Authentication Type on page 128
Configuring the Inform Notification Type and Target Address
Supported Platforms ACX Series, M Series, MX Series, PTX Series, SRX Series, T Series
To configure the inform notification type and target information, include the following
statements at the [edit snmp v3] hierarchy level:
[edit snmp v3]

notify name {
tag tag-name;
}
address address;
port port-number;
retry-count number;
tag-list tag-list;
timeout seconds;
}
parameters {
}
}
notify name is the name assigned to the notification. Each notify entry name must be
unique.
tag tag-name defines the target addresses that are sent this notification. The notification
is sent to all target addresses that have this tag in their tag list. The tag-name is not
included in the notification. For information about how to configure the tag list, see
“Configuring the Trap Target Address” on page 144.

type inform is the type of notification.
target-address target-address-name identifies the target address. The target address

defines a management application’s address and parameters that are used to respond
to informs.
timeout seconds is the number of seconds to wait for an acknowledgment. If no

acknowledgment is received within the timeout period, the inform is retransmitted. The
default timeout is 15 seconds.
retry-count number is the maximum number of times an inform is transmitted if no

acknowledgment is received. The default is 3. If no acknowledgment is received after
the inform is transmitted the maximum number of times, the inform message is discarded.
message-processing-model defines which version of SNMP to use when SNMP

notifications are generated. Informs require a v3 message processing model.
security-model defines the security model to use when SNMP notifications are generated.
Informs require a usm security model.
security-model defines the security model to use when SNMP notifications are generated.
Informs require a usm security model.
security-level specifies whether the inform is authenticated and encrypted before it is

sent. For the usm security model, the security level must be one of the following:
security-name identifies the username that is used when generating the inform.

Documentation
• Example: Configuring the Inform Notification Type and Target Address on page 155
Example: Configuring the Inform Notification Type and Target Address
In the following example, target 172.17.20.184 is configured to respond to informs. The

inform timeout is 30 seconds and the maximum retransmit count is 3. The inform is sent
to all targets in the tl1 list. The security model for the remote user is usm and the remote
engine username is u10.
[edit snmp v3]

notify n1 {
type inform;
tag tl1;

}
notify-filter nf1 {
oid .1.3 include;
}
address 172.17.20.184;
retry-count 3;
tag-list tl1;
timeout 30;
}
parameters {
security-model usm;
security-level privacy;
security-name u10;
}
notify-filter nf1;
}
Related • Configuring the Inform Notification Type and Target Address on page 154
Documentation
Configuring the SNMPv3 Community
Supported Platforms ACX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, T Series
The SNMP community defines the relationship between an SNMP server system and the
client systems. This statement is optional.
To configure the SNMP community, include the snmp-community statement at the [edit
snmp v3] hierarchy level:
[edit snmp v3]

snmp-community community-index;
community-index is the index for the SNMP community.
To configure the SNMP community properties, include the following statements at the
[edit snmp v3 snmp-community community-index] hierarchy level:
[edit snmp v3 snmp-community community-index]

tag tag-name;
• Configuring the Community Name on page 157

• Configuring the Context on page 157

• Configuring the Security Names on page 157

• Configuring the Tag on page 158
Configuring the Community Name

The community name defines the SNMP community. The SNMP community authorizes
SNMPv1 or SNMPv2c clients. The access privileges associated with the configured security
name define which MIB objects are available and the operations (read, write, or notify)
allowed on those objects.
To configure the SNMP community name, include the community-name statement at

the [edit snmp v3 snmp-community community-index] hierarchy level:

community-name is the community string for an SNMPv1 or SNMPv2c community.
If unconfigured, it is the same as the community index.
If the community name contains spaces, enclose it in quotation marks (“ “).
NOTE: Community names must be unique. You cannot configure the same
community name at the [edit snmp community] and [edit snmp v3
snmp-community community-index] hierarchy levels. The configured
community name at the [edit snmp v3 snmp-community community-index]
hierarchy level is encrypted. You cannot view the community name after you
have configured it and committed your changes. In the command-line
interface (CLI), the community name is concealed.
Configuring the Context

An SNMP context defines a collection of management information that is accessible to
an SNMP entity. Typically, an SNMP entity has access to multiple contexts. A context
can be a physical or logical system, a collection of multiple systems, or even a subset of
a system. Each context in a management domain has a unique identifier.
To configure an SNMP context, include the context context-name statement at the [edit
snmp v3 snmp-community community-index] hierarchy level:

NOTE: To query a routing instance or a logical system,
Configuring the Security Names

To assign a community string to a security name, include the security-name statement
at the [edit snmp v3 snmp-community community-index] hierarchy level:

security-name is used when access control is set up. The security-to-group configuration
at the [edit snmp v3 vacm] hierarchy level identifies the group.
NOTE: This security name must match the security name configured at the
[edit snmp v3 target-parameters target-parameters-name parameters] hierarchy
level when you configure traps.
Configuring the Tag

To configure the tag, include the tag statement at the [edit snmp v3 snmp-community
community-index] hierarchy level:

tag tag-name;
tag-name identifies the address of managers that are allowed to use a community string.

Documentation
• Example: Configuring an SNMPv3 Community on page 158
Example: Configuring an SNMPv3 Community
Define an SNMP community:
[edit snmp v3]

community-name "$9$JOZi.QF/AtOz3"; # SECRET-DATA
security-name john;
tag router1; # Identifies managers that are allowed to use
# a community string
address 10.1.1.1;
address-mask 255.255.255.0; # Defines the range of addresses
port 162;
tag-list router1;
target-parameters tp1; # Applies configured target parameters
}
}
Related • Configuring the SNMPv3 Community on page 156

Documentation

CHAPTER 8
Configuring SNMP for Routing Instances
• Understanding SNMP Support for Routing Instances on page 159

• SNMP MIBs Supported for Routing Instances on page 160
• Support Classes for MIB Objects on page 170
• SNMP Traps Supported for Routing Instances on page 171
• Identifying a Routing Instance on page 172
• Enabling SNMP Access over Routing Instances on page 173
• Specifying a Routing Instance in an SNMPv1 or SNMPv2c Community on page 173
• Example: Configuring Interface Settings for a Routing Instance on page 174
• Configuring Access Lists for SNMP Access over Routing Instances on page 176
Understanding SNMP Support for Routing Instances
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.
In Junos OS:
• 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.
Before Junos OS Release 8.4, only the SNMP manager in the default routing instance
(inet.0) had access to the MIB objects
With the increase in virtual private network (VPN) service offerings, this feature is useful
particularly for service providers who need to obtain SNMP data for specific routing
instances (see Figure 2 on page 160). Service providers can use this information for their
own management needs or export the data for use by their customers.

Figure 2: SNMP Data for Routing Instances
If no routing instance is specified in the request, the SNMP agent operates as before:
• For nonrouting table objects, all instances are exposed.
• For routing table objects, only those associated with the default routing instance are
exposed.
NOTE: The actual protocol data units (PDUs) are still exchanged over the
default (inet.0) routing instance, but the data contents returned are dictated
by the routing instance specified in the request PDUs.
Related • Support Classes for MIB Objects on page 170

Documentation
SNMP MIBs Supported for Routing Instances
Table 14 on page 160 shows enterprise-specific MIB objects supported by Junos OS and
provides notes detailing how they are handled when a routing instance is specified in an
SNMP request. An en dash (–) indicates that the item is not applicable.
Table 14: MIB Support for Routing Instances (Juniper Networks MIBs)
Object Support Class Description/Notes
jnxProducts(1) – Product Object IDs

Chapter 8: Configuring SNMP for Routing Instances
Table 14: MIB Support for Routing Instances (Juniper Networks

MIBs) (continued)
jnxServices(2) – Services
jnxMibs(3) Class 3 Objects are exposed only for the default

logical system.
jnxBoxAnatomy(1)
mpls(2) Class 2 All instances within a logical system are

exposed. Data will not be segregated down
to the routing instance level.
ifJnx(3) Class 1 Only those logical interfaces (and their

parent physical interfaces) that belong to
a specific routing instance are exposed.
jnxAlarms(4) Class 3 Objects are exposed only for the default

logical system.
jnxFirewalls(5) Class 4 Data is not segregated by routing instance.

All instances are exposed.
jnxDCUs(6) Class 1 Only those logical interfaces (and their

jnxPingMIB(7) Class 3 Objects are exposed only for the default

logical system.
jnxTraceRouteMIB(8) Class 3 Objects are exposed only for the default

logical system.
jnxATM(10) Class 1 Only those logical interfaces (and their

jnxIpv6(11) Class 4 Data is not segregated by routing instance.

jnxIpv4(12) Class 1 jnxIpv4AddrTable(1). Only those logical

interfaces (and their parent physical
interfaces) that belong to a specific routing
instance are exposed.
jnxRmon(13) Class 3 jnxRmonAlarmTable(1). Objects are

exposed only for the default logical
system.
jnxLdp(14) Class 2 jnxLdpTrapVars(1). All instances within a

logical system are exposed. Data will not
be segregated down to the routing
instance level.


MIBs) (continued)
jnxCos(15) Class 3 Objects are exposed only for the default

logical system.
jnxCosIfqStatsTable(1)
jnxCosFcTable(2)
jnxCosFcIdTable(3)
jnxCosQstatTable(4)
jnxScu(16) Class 1 Only those logical interfaces (and their

jnxScuStatsTable(1) a specific routing instance are exposed.
jnxRpf(17) Class 1 Only those logical interfaces (and their

jnxRpfStatsTable(1) a specific routing instance are exposed.
jnxCfgMgmt(18) Class 3 Objects are exposed only for the default

logical system.
jnxPMon(19) Class 1 Only those logical interfaces (and their

jnxPMonFlowTable(1) a specific routing instance are exposed.
jnxPMonErrorTable(2)
jnxPMonMemoryTable(3)
jnxSonet(20) Class 1 Only those logical interfaces (and their

jnxSonetAlarmTable(1) a specific routing instance are exposed.
jnxAtmCos(21) Class 1 Only those logical interfaces (and their

jnxCosAtmVcTable(1) a specific routing instance are exposed.
jnxCosAtmScTable(2)
jnxCosAtmVcQstatsTable(3)
jnxCosAtmTrunkTable(4)
ipSecFlowMonitorMIB(22) – –
jnxMac(23) Class 1 Only those logical interfaces (and their

jnxMacStats(1) a specific routing instance are exposed.
apsMIB(24) Class 3 Objects are exposed only for the default

logical system.
jnxChassisDefines(25) Class 3 Objects are exposed only for the default

logical system.


MIBs) (continued)
jnxVpnMIB(26) Class 2 All instances within a logical system are

exposed. Data will not be segregated down
to the routing instance level.
jnxSericesInfoMib(27) Class 1 Only those logical interfaces (and their

jnxCollectorMIB(28) Class 1 Only those logical interfaces (and their

jnxHistory(29) – –
jnxSpMIB(32) Class 3 Objects are exposed only for the default

logical system.
Table 15 on page 164 shows Class 1 MIB objects (standard and enterprise-specific MIBs)
supported by Junos OS. With Class 1 objects, only those logical interfaces (and their
parent physical interfaces) that belong to a specific routing instance are exposed.

Table 15: Class 1 MIB Objects (Standard and Juniper MIBs)

Class MIB Objects
Class 1 802.3ad.mib (dot3adAgg) MIB objects:
dot3adAggTable
dot3adAggPortListTable
(dot3adAggPort)
dot3adAggPortTable
dot3adAggPortStatsTable
dot3adAggPortDebugTable
rfc2863a.mib ifTable
ifXTable
ifStackTable
rfc2011a.mib ipAddrTable
ipNetToMediaTable
rtmib.mib ipForward (ipCidrRouteTable)
rfc2665a.mib dot3StatsTable
dot3ControlTable
dot3PauseTable
rfc2495a.mib dsx1ConfigTable
dsx1CurrentTable
dsx1IntervalTable
dsx1TotalTable
dsx1FarEndCurrentTable
dsx1FarEndIntervalTable
dsx1FarEndTotalTable
dsx1FracTable ...
rfc2496a.mib dsx3 (dsx3ConfigTable)
rfc2115a.mib frDlcmiTable (and related MIB objects)
rfc3592.mib sonetMediumTable (and related MIB

objects)

Table 15: Class 1 MIB Objects (Standard and Juniper MIBs) (continued)
Class MIB Objects
rfc3020.mib mfrMIB
mfrBundleTable
mfrMibBundleLinkObjects
mfrBundleIfIndexMappingTable
(and related MIB objects)
ospf2mib.mib All objects
ospf2trap.mib All objects
bgpmib.mib All objects
rfc2819a.mib Example: etherStatsTable

Class MIB Objects
Class 1 rfc2863a.mib Examples:
ifXtable
ifStackTable
rfc2665a.mib etherMIB
rfc2515a.mib atmMIB objects
Examples:
atmInterfaceConfTable
atmVplTable
atmVclTable
rfc2465.mib ip-v6mib
Examples:
ipv6IfTable
ipv6AddrPrefixTable
ipv6NetToMediaTable
ipv6RouteTable
rfc2787a.mib vrrp mib
rfc2932.mib ipMRouteMIB
ipMRouteStdMIB
mroutemib.mib ipMRoute1MIBObjects
isismib.mib isisMIB
pimmib.mib pimMIB
msdpmib.mib msdpmib
jnx-if-extensions.mib Examples:
ifJnxTable
ifChassisTable
jnx-dcu.mib jnxDCUs
jnx-atm.mib

Class MIB Objects
Examples:
jnxAtmIfTable
jnxAtmVCTable
jnxAtmVpTable
jnx-ipv4.mib jnxipv4
Example: jnxIpv4AddrTable
jnx-cos.mib Examples:
jnxCosIfqStatsTable
jnxCosQstatTable
jnx-scu.mib Example: jnxScuStatsTable
jnx-rpf.mib Example: jnxRpfStatsTable
jnx-pmon.mib Example: jnxPMonFlowTable
jnx-sonet.mib Example: jnxSonetAlarmTable
Class 1 jnx-atm-cos.mib Examples:
jnxCosAtmVcTable
jnxCosAtmVcScTable
jnxCosAtmVcQstatsTable
jnxCosAtmTrunkTable
jnx-mac.mib Example: jnxMacStatsTable
jnx-services.mib Example: jnxSvcFlowTableAggStatsTable
jnx-coll.mib jnxCollectorMIB
Examples:
jnxCollPicIfTable
jnxCollFileEntry
supported by Junos OS. With Class 2 objects, all instances within a logical system are
exposed. Data will not be segregated down to the routing instance level.


Class MIB Objects
Class 2 rfc3813.mib mplsLsrStdMIB
Examples:
mplsInterfaceTable
mplsInSegmentTable
mplsOutSegmentTable
mplsLabelStackTable
mplsXCTable
(and related MIB objects)
igmpmib.mib igmpStdMIB
NOTE: The igmpmib.mib is the draft

version of the IGMP Standard MIB in the
experimental tree. Junos OS does not
support the original IGMP Standard MIB.
l3vpnmib.mib mplsVpnmib
jnx-mpls.mib Example: mplsLspList
jnx-ldp.mib jnxLdp
Example: jnxLdpStatsTable
jnx-vpn.mib jnxVpnMIB
jnx-bgpmib2.mib jnxBgpM2Experiment
supported by Junos OS. With Class 3, objects are exposed only for the default logical
system.


Class MIB Objects
Class 3 rfc2819a.mib rmonEvents
alarmTable
logTable
eventTable
agentxMIB
rfc2925a.mib pingmib
rfc2925b.mib tracerouteMIB
jnxchassis.mib jnxBoxAnatomy
jnx-chassis-alarm.mib jnxAlarms
jnx-ping.mib jnxPingMIB
jnx-traceroute.mib jnxTraceRouteMIB
jnx-rmon.mib jnxRmonAlarmTable
jnx-cos.mib Example: jnxCosFcTable
jnx-cfgmgmt.mib Example: jnxCfgMgmt
jnx-sonetaps.mib apsMIBObjects
jnx-sp.mib jnxSpMIB
ggsn.mib ejnmobileipABmib
rfc1907.mib snmpModules
snmpModules Examples:
snmpMIB snmpFrameworkMIB
supported by Junos OS. With Class 4 objects, data is not segregated by routing instance.


Class MIB Objects
Class 4 system Example: sysORTable
rfc2011a.mib ip (ipDefaultTTL, ipInReceives)
icmp
rfc2012a.mib tcp
tcpConnTable
ipv6TcpConnTable
rfc2013a.mib udp
udpTable
ipv6UdpTable
rfc2790a.mib hrSystem
rfc2287a.mib sysApplOBJ
jnx-firewall.mib jnxFirewalls
jnx-ipv6.mib jnxIpv6
Related • Understanding SNMP Support for Routing Instances on page 159

Documentation
Support Classes for MIB Objects
When a routing instance is specified, all routing-related MIB objects return data maintained
by the routing instance in the request. For all other MIB objects, the data returned is
segregated according to that routing instance. For example, only those interfaces assigned
to that routing instance (for example, the logical interfaces [ifls] as well as their
corresponding physical interfaces [ifds]) are exposed by the SNMP agent. Similarly,
objects with an unambiguous attachment to an interface (for example, addresses) are
segregated as well.
For those objects where the attachment is ambiguous (for example, objects in
sysApplMIB), no segregation is done and all instances are visible in all cases.
Another category of objects is visible only when no logical system is specified (only within
the default logical system) regardless of the routing instance within the default logical

system. Objects in this category are Chassis MIB objects, objects in the SNMP group,
RMON alarm, event and log groups, Ping MIB objects, configuration management objects,
and V3 objects.
In summary, to support routing instances, MIB objects fall into one of the following
categories:
• Class 1—Data is segregated according to the routing instance in the request. This is the
most granular of the segregation classes.
• Class 2—Data is segregated according to the logical system specified in the request.
The same data is returned for all routing instances that belong to a particular logical
system. Typically, this applies to routing table objects where it is difficult to extract
routing instance information or where routing instances do not apply.
• Class 3—Data is exposed only for the default logical system. The same set of data is
returned for all routing instances that belong to the default logical system. If you specify
another logical system (not the default), no data is returned. Typically this class applies
to objects implemented in subagents that do not monitor logical system changes and
register their objects using only the default context (for example, Chassis MIB objects).
• Class 4—Data is not segregated by routing instance. The same data is returned for all
routing instances. Typically, this applies to objects implemented in subagents that
monitor logical system changes and register or deregister all their objects for each
logical system change. Objects whose values cannot be segregated by routing instance
fall into this class.
See “SNMP MIBs Supported for Routing Instances” on page 160 for a list of the objects
associated with each class.

Documentation
SNMP Traps Supported for Routing Instances
You can restrict the trap receivers from receiving traps that are not related to the logical
system networks to which they belong. To do this, include the logical-system-trap-filter
statement at the [edit snmp] hierarchy level:
[edit snmp]
logical-system-trap-filter;
If the logical-system-trap-filter statement is not included in the SNMP configuration, all

traps are forwarded to the configured routing instance destinations. However, even when
this statement is configured, the trap receiver associated with the default routing instance
will receive all SNMP traps.
When configured under the trap-group object, all v1 and v2c traps that apply to routing
instances (or interfaces belonging to a routing instance) have the routing instance name
encoded in the community string. The encoding is identical to that used in request PDUs.

For traps configured under the v3 framework, the routing instance name is carried in the
context field when the v3 message processing model has been configured. For other
message processing models (v1 or v2c), the routing instance name is not carried in the
trap message header (and not encoded in the community string).

Documentation
• SNMP MIBs Supported for Routing Instances on page 160
Identifying a Routing Instance
With this feature, routing instances are identified by either the context field in v3 requests
or encoded in the community string in v1 or v2c 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
routing instance named RI is configured, an SNMP request with RI@public is processed
within the context of the RI routing instance. Access control (views, source address
restrictions, access privileges, and so on) is applied according to the actual community
string (the set of data after the @ character—in this case public). However, if the
community string RI@public is configured, the protocol data unit (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.
Also, 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 v3 requests, the name
logical system/routing instance should be identified directly in the context field.
NOTE: To identify a virtual LAN (VLAN) spanning-tree instance (VSTP on

MX Series 3D Universal Edge Routers), specify the routing instance name
followed by a double colon (::) and the VLAN ID. For example, to identify
VSTP instance for VLAN 10 in the global default routing instance, include
default::10@public in the context (SNMPv3) or community (SNMPv1 or v2)
string.


Documentation
Enabling SNMP Access over Routing Instances
To enable SNMP managers in routing instances other than the default routing instance
to access SNMP information, include the routing-instance-access statement at the [edit
snmp] hierarchy level:
[edit snmp]
routing-instance-access;
If this statement is not included in the SNMP configuration, SNMP managers from routing
instances other than the default routing instance cannot access SNMP information.

Documentation
Specifying a Routing Instance in an SNMPv1 or SNMPv2c Community
You can specify the routing instance along with the client information when you add a
client to an SNMP community. To specify the routing instance to which a client belongs,
include the routing-instance statement followed by the routing instance name and client
information in the SNMP configuration.
The following example shows the configuration statement to add routing instance test-ri
to SNMP community community1.
NOTE: Routing instances specified at the [edit snmp community

community-name] hierarchy level are added to the default logical system in
the community.
[edit snmp]
clients {
10.209.152.33/32;
}
routing-instance test-ri {
clients {
10.19.19.1/32;

}
}
}
If the routing instance is defined within a logical system, include the routing-instance
statement at the [edit snmp community community-name logical-system
logical-system-name] hierarchy level, as in the following example:
[edit snmp]
clients {
10.209.152.33/32;
}
logical-system test-LS {
routing-instance test-ri {
clients {
10.19.19.1/32;
}
}
}
}

Documentation
• Example: Configuring Interface Settings for a Routing Instance on page 174
Example: Configuring Interface Settings for a Routing Instance
This example shows an 802.3ad ae0 interface configuration allocated to a routing instance
named INFrtd:
[edit chassis]
aggregated-devices {
ethernet {
device-count 5;
}
}
[edit interfaces ae0]
vlan-tagging;
aggregated-ether-options {
minimum-links 2;
link-speed 100m;
}
unit 0 {
vlan-id 100;
family inet {
address 10.1.0.1/24;
}
}

[edit interfaces fe-1/1/0]

fastether-options {
802.3ad ae0;
}
fastether-options {
802.3ad ae0;
}
[edit routing-instances]
INFrtd {
instance-type virtual-router;
interface fe-1/1/0.0;
interface ae0.0;
protocols {
ospf {
area 0.0.0.0 {
interface all;
}
}
}
}
The following snmpwalk command shows how to retrieve SNMP-related information

from router1 and the 802.3ae bundle interface belonging to routing instance INFrtd with
the SNMP community public:
router# snmpwalk -Os router1 INFrtd@public dot3adAggTable

dot3adAggMACAddress.59 = 0:90:69:92:93:f0
dot3adAggMACAddress.65 = 0:90:69:92:93:f0
dot3adAggActorSystemPriority.59 = 0
dot3adAggActorSystemPriority.65 = 0
dot3adAggActorSystemID.59 = 0:0:0:0:0:0
dot3adAggActorSystemID.65 = 0:0:0:0:0:0
dot3adAggAggregateOrIndividual.59 = true(1)
dot3adAggAggregateOrIndividual.65 = true(1)
dot3adAggActorAdminKey.59 = 0
dot3adAggActorAdminKey.65 = 0
dot3adAggActorOperKey.59 = 0
dot3adAggActorOperKey.65 = 0
dot3adAggPartnerSystemID.59 = 0:0:0:0:0:0
dot3adAggPartnerSystemID.65 = 0:0:0:0:0:0
dot3adAggPartnerSystemPriority.59 = 0
dot3adAggPartnerSystemPriority.65 = 0
dot3adAggPartnerOperKey.59 = 0
dot3adAggPartnerOperKey.65 = 0
dot3adAggCollectorMaxDelay.59 = 0
dot3adAggCollectorMaxDelay.65 = 0

Documentation

Configuring Access Lists for SNMP Access over Routing Instances
You can create and maintain access lists to manage access to SNMP information. Access
list configuration enables you to allow or deny SNMP access to clients of a specific routing
instance.
The following example shows how to create an access list:
[edit snmp]
routing-instance-access {
access-list {
ri1 restrict;
ls1/default;
ls1/ri2;
ls1*;
}
}
The configuration given in the example:
• Restricts clients in ri1 from accessing SNMP information.
• Allows clients in ls1/default, ls1/ri2, and all other routing instances with names starting
with ls1 to access SNMP information.
You can use the wildcard character (*) to represent a string in the routing instance name.
NOTE: You cannot restrict the SNMP manager of the default routing instance
from accessing SNMP information.

Documentation

CHAPTER 9
Configuring SNMP Remote Operations
• SNMP Remote Operations Overview on page 177

• Using the Ping MIB for Remote Monitoring Devices Running Junos OS on page 180
• Starting a Ping Test on page 180
• Monitoring a Running Ping Test on page 182
• Gathering Ping Test Results on page 184
• Stopping a Ping Test on page 186
• Interpreting Ping Variables on page 186
• Using the Traceroute MIB for Remote Monitoring Devices Running Junos OS on page 187
• Starting a Traceroute Test on page 187
• Monitoring a Running Traceroute Test on page 189
• Monitoring Traceroute Test Completion on page 193
• Gathering Traceroute Test Results on page 194
• Stopping a Traceroute Test on page 195
• Interpreting Traceroute Variables on page 196
SNMP Remote Operations Overview
A SNMP remote operation is any process on the router that can be controlled remotely
using SNMP. Junos OS currently provides support for two SNMP remote operations: the
Ping MIB and Traceroute MIB, defined in RFC 2925. Using these MIBs, an SNMP client in
the network management system (NMS) can:
• Start a series of operations on a router
• Receive notification when the operations are complete
• Gather the results of each operation
Junos OS also provides extended functionality to these MIBs in the Juniper Networks
enterprise-specific extensions jnxPingMIB and jnxTraceRouteMIB. For more information
about jnxPingMIB and jnxTraceRouteMIB, see PING MIB and Traceroute MIB.

This topic covers the following sections:
• SNMP Remote Operation Requirements on page 178

• Setting SNMP Views on page 178
• Setting Trap Notification for Remote Operations on page 179
• Using Variable-Length String Indexes on page 179
• Enabling Logging on page 180
SNMP Remote Operation Requirements

To use SNMP remote operations, you should be experienced with SNMP conventions.
You must also configure Junos OS to allow the use of the remote operation MIBs.
Setting SNMP Views

All remote operation MIBs supported by Junos OS require that the SNMP clients have
read-write privileges. The default SNMP configuration of Junos OS does not provide
clients with a community string with such privileges.
To set read-write privileges for an SNMP community string, include the following
statements at the [edit snmp] hierarchy level:
[edit snmp]
community community-name {
view view-name;
}
view view-name {
}
Example: Setting SNMP Views

To create a community named remote-community that grants SNMP clients read-write
access to the Ping MIB, jnxPing MIB, Traceroute MIB, and jnxTraceRoute MIB, include the
following statements at the [edit snmp] hierarchy level:
snmp {
view remote-view {
oid 1.3.6.1.2.1.80 include; # pingMIB
oid 1.3.6.1.4.1.2636.3.7 include; # jnxPingMIB
oid 1.3.6.1.2.1.81 include; # traceRouteMIB
oid 1.3.6.1.4.1.2636.3.8 include; # jnxTraceRouteMIB
}
community remote-community {
view remote-view;
}
}
For more information about the community statement, see “Configuring SNMP
Communities” on page 99 and community (SNMP).

Chapter 9: Configuring SNMP Remote Operations
For more information about the view statement, see “Configuring MIB Views” on page 116,
view (Associating a MIB View with a Community), and view (Configuring a MIB View).
Setting Trap Notification for Remote Operations

In addition to configuring the remote operations MIB for trap notification, you must also
configure Junos OS. You must specify a target host for remote operations traps.
To configure trap notification for SNMP remote operations, include the categories and
targets statements at the [edit snmp trap-group group-name] hierarchy level:
[edit snmp trap-group group-name]

categories {
category;
}
targets {
address;
}
}
Example: Setting Trap Notification for Remote Operations

Specify 172.17.12.213 as a target host for all remote operation traps:
snmp {
trap-group remote-traps {
categories remote-operations;
targets {
172.17.12.213;
}
}
}
For more information about trap groups, see “Configuring SNMP Trap Groups” on page 112.
Using Variable-Length String Indexes

All tabular objects in the remote operations MIBs supported by Junos OS are indexed by
two variables of type SnmpAdminString. For more information about SnmpAdminString,
see RFC 2571.
Junos OS does not handle SnmpAdminString any differently from the octet string variable
type. However, the indexes are defined as variable length. When a variable length string
is used as an index, the length of the string must be included as part of the object identifier
(OID).
Example: Set Variable-Length String Indexes
To reference the pingCtlTargetAddress variable of a row in pingCtlTable where

pingCtlOwnerIndex is bob and pingCtlTestName is test, use the following object identifier
(OID):
pingMIB.pingObjects.pingCtlTable.pingCtlEntry.pingCtlTargetAddress."bob"."test"
1.3.6.1.2.1.80.1.2.1.4.3.98.111.98.4.116.101.115.116
For more information about the definition of the Ping MIB, see RFC 2925.

Enabling Logging
The SNMP error code returned in response to SNMP requests can only provide a generic
description of the problem. The error descriptions logged by the remote operations
process can often provide more detailed information about the problem and help you
to solve the problem faster. This logging is not enabled by default. To enable logging,
include the flag general statement at the [edit snmp traceoptions] hierarchy level:
[edit]
snmp {
traceoptions {
flag general;
}
}
For more information about traceoptions, see “Tracing SNMP Activity on a Device Running
Junos OS” on page 203.
If the remote operations process receives an SNMP request that it cannot accommodate,
the error is logged in the /var/log/rmopd file. To monitor this log file, issue the monitor
start rmopd command in operational mode of the command-line interface (CLI).
Related • Using the Ping MIB for Remote Monitoring Devices Running Junos OS on page 180
Documentation
• Using the Traceroute MIB for Remote Monitoring Devices Running Junos OS on page 187
Using the Ping MIB for Remote Monitoring Devices Running Junos OS
A ping test is used to determine whether packets sent from the local host reach the
designated host and are returned. If the designated host can be reached, the ping test
provides the approximate round-trip time for the packets. Ping test results are stored in
pingResultsTable and pingProbeHistoryTable.
RFC 2925 is the authoritative description of the Ping MIB in detail and provides the ASN.1
MIB definition of the Ping MIB.
Related • SNMP Remote Operations Overview on page 177

Documentation
• Starting a Ping Test on page 180
• Monitoring a Running Ping Test on page 182
• Gathering Ping Test Results on page 184
• Stopping a Ping Test on page 186
• Interpreting Ping Variables on page 186
Starting a Ping Test

Before you start a ping test, configure a Ping MIB view. This allows SNMP Set requests
on pingMIB. To start a ping test, create a row in pingCtlTable and set pingCtlAdminStatus
to enabled. The minimum information that must be specified before setting
pingCtlAdminStatus to enabled is:
• pingCtlOwnerIndexSnmpAdminString
• pingCtlTestNameSnmpAdminString
• pingCtlTargetAddressInetAddress
• pingCtlTargetAddressTypeInetAddressType
• pingCtlRowStatusRowStatus
For all other values, defaults are chosen unless otherwise specified. pingCtlOwnerIndex
and pingCtlTestName are used as the index, so their values are specified as part of the
object identifier (OID). To create a row, set pingCtlRowStatus to createAndWait or
createAndGo on a row that does not already exist. A value of active for pingCtlRowStatus
indicates that all necessary information has been supplied and the test can begin;
pingCtlAdminStatus can be set to enabled. An SNMP Set request that sets
pingCtlRowStatus to active will fail if the necessary information in the row is not specified
or is inconsistent. For information about how to configure a view, see “Setting SNMP
Views” on page 178.
There are two ways to start a ping test:
• Using Multiple Set Protocol Data Units (PDUs) on page 181

• Using a Single Set PDU on page 181
Using Multiple Set Protocol Data Units (PDUs)

You can use multiple Set request PDUs (multiple PDUs, with one or more varbinds each)
and set the following variables in this order to start the test:
• pingCtlRowStatus to createAndWait
• All appropriate test variables
• pingCtlRowStatus to active
Junos OS now verifies that all necessary information to run a test has been specified.
• pingCtlAdminStatus to enabled
Using a Single Set PDU

You can use a single Set request PDU (one PDU, with multiple varbinds) to set the
following variables to start the test:
• pingCtlRowStatus to createAndGo
• pingCtlAdminStatus to enabled

Monitoring a Running Ping Test
When pingCtlAdminStatus is successfully set to enabled, the following is done before

the acknowledgment of the SNMP Set request is sent back to the client:
• pingResultsEntry is created if it does not already exist.
• pingResultsOperStatus transitions to enabled.
For more information, see the following sections:
• pingResultsTable on page 182

• pingProbeHistoryTable on page 183
• Generating Traps on page 184
pingResultsTable
While the test is running, pingResultsEntry keeps track of the status of the test. The value
of pingResultsOperStatus is enabled while the test is running and disabled when it has
stopped.
The value of pingCtlAdminStatus remains enabled until you set it to disabled. Thus, to
get the status of the test, you must examine pingResultsOperStatus.
The pingCtlFrequency variable can be used to schedule many tests for one pingCtlEntry.
After a test ends normally (you did not stop the test) and the pingCtlFrequency number
of seconds has elapsed, the test is started again just as if you had set pingCtlAdminStatus
to enabled. If you intervene at any time between repeated tests (you set
pingCtlAdminStatus to disabled or pingCtlRowStatus to notInService), the repeat feature
is disabled until another test is started and ends normally. A value of 0 for
pingCtlFrequency indicates this repeat feature is not active.
pingResultsIpTgtAddr and pingResultsIpTgtAddrType are set to the value of the resolved

destination address when the value of pingCtlTargetAddressType is dns. When a test
starts successfully and pingResultsOperStatus transitions to enabled:
• pingResultsIpTgtAddr is set to null-string.
• pingResultsIpTgtAddrType is set to unknown.
pingResultsIpTgtAddr and pingResultsIpTgtAddrType are not set until

pingCtlTargetAddress can be resolved to a numeric address. To retrieve these values,
poll pingResultsIpTgtAddrType for any value other than unknown after successfully setting
pingCtlAdminStatus to enabled.
At the start of a test, pingResultsSentProbes is initialized to 1 and the first probe is sent.
pingResultsSentProbes increases by 1 each time a probe is sent.
As the test runs, every pingCtlTimeOut seconds, the following occur:
• pingProbeHistoryStatus for the corresponding pingProbeHistoryEntry in

pingProbeHistoryTable is set to requestTimedOut.

• A pingProbeFailed trap is generated, if necessary.
• An attempt is made to send the next probe.
NOTE: No more than one outstanding probe exists for each test.
For every probe, you can receive one of the following results:
• The target host acknowledges the probe with a response.
• The probe times out; there is no response from the target host acknowledging the
probe.
• The probe could not be sent.
Each probe result is recorded in pingProbeHistoryTable. For more information about

pingProbeHistoryTable, see “pingProbeHistoryTable” on page 183.
When a response is received from the target host acknowledging the current probe:
• pingResultsProbeResponses increases by 1.
• The following variables are updated:
• pingResultsMinRtt—Minimum round-trip time
• pingResultsMaxRtt—Maximum round-trip time
• pingResultsAverageRtt—Average round-trip time
• pingResultsRttSumOfSquares—Sum of squares of round-trip times
• pingResultsLastGoodProbe—Timestamp of the last response
NOTE: Only probes that result in a response from the target host
contribute to the calculation of the round-trip time (RTT) variables.
When a response to the last probe is received or the last probe has timed out, the test is
complete.
pingProbeHistoryTable
An entry in pingProbeHistoryTable (pingProbeHistoryEntry) represents a probe result and
is indexed by three variables:
• The first two variables, pingCtlOwnerIndex and pingCtlTestName, are the same ones
used for pingCtlTable, which identifies the test.
• The third variable, pingProbeHistoryIndex, is a counter to uniquely identify each probe

result.

The maximum number of pingProbeHistoryTable entries created for a given test is limited
by pingCtlMaxRows. If pingCtlMaxRows is set to 0, no pingProbeHistoryTable entries are
created for that test.
Each time a probe result is determined, a pingProbeHistoryEntry is created and added to

pingProbeHistoryTable. pingProbeHistoryIndex of the new pingProbeHistoryEntry is 1
greater than the last pingProbeHistoryEntry added to pingProbeHistoryTable for that test.
pingProbeHistoryIndex is set to 1 if this is the first entry in the table. The same test can be
run multiple times, so this index keeps growing.
If pingProbeHistoryIndex of the last pingProbeHistoryEntry added is 0xFFFFFFFF, the next

pingProbeHistoryEntry added has pingProbeHistoryIndex set to 1.
The following are recorded for each probe result:
• pingProbeHistoryResponse—Time to live (TTL)
• pingProbeHistoryStatus—What happened and why
• pingProbeHistoryLastRC—Return code (RC) value of ICMP packet
• pingProbeHistoryTime—Timestamp when probe result was determined
When a probe cannot be sent, pingProbeHistoryResponse is set to 0. When a probe times

out, pingProbeHistoryResponse is set to the difference between the time when the probe
was discovered to be timed out and the time when the probe was sent.
Generating Traps
For any trap to be generated, the appropriate bit of pingCtlTrapGeneration must be set.
You must also configure a trap group to receive remote operations. A trap is generated
under the following conditions:
• A pingProbeFailed trap is generated every time pingCtlTrapProbeFailureFilter number

of consecutive probes fail during the test.
• A pingTestFailed trap is generated when the test completes and at least

pingCtlTrapTestFailureFilter number of probes fail.
• A pingTestCompleted trap is generated when the test completes and fewer than
pingCtlTrapTestFailureFilter probes fail.
NOTE: A probe is considered a failure when pingProbeHistoryStatus of the

probe result is anything besides responseReceived.
For information about how to configure a trap group to receive remote operations, see
“Configuring SNMP Trap Groups” on page 112 and “Example: Setting Trap Notification
for Remote Operations” on page 179.
Gathering Ping Test Results

You can either poll pingResultsOperStatus to find out when the test is complete or request
that a trap be sent when the test is complete. For more information about
pingResultsOperStatus, see “pingResultsTable” on page 182. For more information about
Ping MIB traps, see “Generating Traps” on page 184.
The statistics calculated and then stored in pingResultsTable include:
• pingResultsMinRtt—Minimum round-trip time
• pingResultsMaxRtt—Maximum round-trip time
• pingResultsAverageRtt—Average round-trip time
• pingResultsProbeResponses—Number of responses received
• pingResultsSentProbes—Number of attempts to send probes
• pingResultsRttSumOfSquares—Sum of squares of round-trip times
• pingResultsLastGoodProbe—Timestamp of the last response
You can also consult pingProbeHistoryTable for more detailed information about each
probe. The index used for pingProbeHistoryTable starts at 1, goes to 0xFFFFFFFF, and
wraps to 1 again.
For example, if pingCtlProbeCount is 15 and pingCtlMaxRows is 5, then upon completion

of the first run of this test, pingProbeHistoryTable contains probes like those in
Table 19 on page 185.
Table 19: Results in pingProbeHistoryTable: After the First Ping Test

pingProbeHistoryIndex Probe Result
11 Result of 11th probe from run 1
Upon completion of the first probe of the second run of this test, pingProbeHistoryTable
will contain probes like those in Table 20 on page 185.
Table 20: Results in pingProbeHistoryTable: After the First Probe of the

Second Test

Table 20: Results in pingProbeHistoryTable: After the First Probe of the

Second Test (continued)
16 Result of 1st probe from run 2
Upon completion of the second run of this test, pingProbeHistoryTable will contain probes
like those in Table 21 on page 186.
Table 21: Results in pingProbeHistoryTable: After the Second Ping Test

History entries can be deleted from the MIB in two ways:
• More history entries for a given test are added and the number of history entries exceeds
pingCtlMaxRows. The oldest history entries are deleted to make room for the new ones.
• You delete the entire test by setting pingCtlRowStatus to destroy.
Stopping a Ping Test
To stop an active test, set pingCtlAdminStatus to disabled. To stop the test and remove
its pingCtlEntry, pingResultsEntry, and any pingHistoryEntry objects from the MIB, set
pingCtlRowStatus to destroy.
Interpreting Ping Variables
This section clarifies the ranges for the following variables that are not explicitly specified
in the Ping MIB:

• pingCtlDataSize—The value of this variable represents the total size of the payload (in
bytes) of an outgoing probe packet. This payload includes the timestamp (8 bytes)
that is used to time the probe. This is consistent with the definition of pingCtlDataSize
(maximum value of 65,507) and the standard ping application.
If the value of pingCtlDataSize is between 0 and 8 inclusive, it is ignored and the payload
is 8 bytes (the timestamp). The Ping MIB assumes all probes are timed, so the payload
must always include the timestamp.
For example, if you wish to add an additional 4 bytes of payload to the packet, you
must set pingCtlDataSize to 12.
• pingCtlDataFill—The first 8 bytes of the data segment of the packet is for the timestamp.
After that, the pingCtlDataFill pattern is used in repetition. The default pattern (when
pingCtlDataFill is not specified) is (00, 01, 02, 03 ... FF, 00, 01, 02, 03 ... FF, ...).
• pingCtlMaxRows—The maximum value is 255.
• pingMaxConcurrentRequests—The maximum value is 500.
• pingCtlTrapProbeFailureFilter and pingCtlTrapTestFailureFilter—A value of 0 for

pingCtlTrapProbeFailureFilter or pingCtlTrapTestFailureFilter is not well defined by the
Ping MIB. If pingCtlTrapProbeFailureFilter is 0, pingProbeFailed traps will not be
generated for the test under any circumstances. If pingCtlTrapTestFailureFilter is 0,
pingTestFailed traps will not be generated for the test under any circumstances.
Using the Traceroute MIB for Remote Monitoring Devices Running Junos OS
Supported Platforms ACX Series, M Series, MX Series, QFX Series, SRX Series, T Series
A traceroute test approximates the path packets take from the local host to the remote
host.
RFC 2925 is the authoritative description of the Traceroute MIB in detail and provides
the ASN.1 MIB definition of the Traceroute MIB.
Related • SNMP Remote Operations Overview on page 177

Documentation
Starting a Traceroute Test

Before you start a traceroute test, configure a Traceroute MIB view. This allows SNMP
Set requests on tracerouteMIB. To start a test, create a row in traceRouteCtlTable and
set traceRouteCtlAdminStatus to enabled. You must specify at least the following before
setting traceRouteCtlAdminStatus to enabled:
• traceRouteCtlOwnerIndexSnmpAdminString
• traceRouteCtlTestNameSnmpAdminString
• traceRouteCtlTargetAddressInetAddress
• traceRouteCtlRowStatusRowStatus
For all other values, defaults are chosen unless otherwise specified.
traceRouteCtlOwnerIndex and traceRouteCtlTestName are used as the index, so their
values are specified as part of the OID. To create a row, set traceRouteCtlRowStatus to
createAndWait or createAndGo on a row that does not already exist. A value of active for
traceRouteCtlRowStatus indicates that all necessary information has been specified and
the test can begin; traceRouteCtlAdminStatus can be set to enabled. An SNMP Set request
that sets traceRouteCtlRowStatus to active will fail if the necessary information in the
row is not specified or is inconsistent. For information about how to configure a view, see
“Setting SNMP Views” on page 178.
There are two ways to start a traceroute test:
• Using Multiple Set PDUs on page 188

• Using a Single Set PDU on page 188
Using Multiple Set PDUs

You can use multiple Set request PDUs (multiple PDUs, with one or more varbinds each)
and set the following variables in this order to start the test:
• traceRouteCtlRowStatus to createAndWait
• traceRouteCtlRowStatus to active
The Junos OS now verifies that all necessary information to run a test has been specified.
• traceRouteCtlAdminStatus to enabled
Using a Single Set PDU

You can use a single Set request PDU (one PDU, with multiple varbinds) to set the
following variables to start the test:
• traceRouteCtlRowStatus to createAndGo
• traceRouteCtlAdminStatus to enabled

Related • Using the Traceroute MIB for Remote Monitoring Devices Running Junos OS on page 187
Documentation
Monitoring a Running Traceroute Test
When traceRouteCtlAdminStatus is successfully set to enabled, the following is done

before the acknowledgment of the SNMP Set request is sent back to the client:
• traceRouteResultsEntry is created if it does not already exist.
• traceRouteResultsOperStatus transitions to enabled.
For more information, see the following sections:
• traceRouteResultsTable on page 189

• traceRouteProbeResultsTable on page 190
• traceRouteHopsTable on page 191
• Generating Traps on page 192
traceRouteResultsTable
While the test is running, this traceRouteResultsTable keeps track of the status of the
test. The value of traceRouteResultsOperStatus is enabled while the test is running and
disabled when it has stopped.
The value of traceRouteCtlAdminStatus remains enabled until you set it to disabled. Thus,
to get the status of the test, you must examine traceRouteResultsOperStatus.
The traceRouteCtlFrequency variable can be used to schedule many tests for one
traceRouteCtlEntry. After a test ends normally (you did not stop the test) and
traceRouteCtlFrequency number of seconds has elapsed, the test is started again just as
if you had set traceRouteCtlAdminStatus to enabled. If you intervene at any time between
repeated tests (you set traceRouteCtlAdminStatus to disabled or traceRouteCtlRowStatus
to notInService), the repeat feature is disabled until another test is started and ends
normally. A value of 0 for traceRouteCtlFrequency indicates this repeat feature is not
active.
traceRouteResultsIpTgtAddr and traceRouteResultsIpTgtAddrType are set to the value

of the resolved destination address when the value of traceRouteCtlTargetAddressType

is dns. When a test starts successfully and traceRouteResultsOperStatus transitions to

enabled:
• traceRouteResultsIpTgtAddr is set to null-string.
• traceRouteResultsIpTgtAddrType is set to unknown.
traceRouteResultsIpTgtAddr and traceRouteResultsIpTgtAddrType are not set until

traceRouteCtlTargetAddress can be resolved to a numeric address. To retrieve these
values, poll traceRouteResultsIpTgtAddrType for any value other than unknown after
successfully setting traceRouteCtlAdminStatus to enabled.
At the start of a test, traceRouteResultsCurHopCount is initialized to traceRouteCtlInitialTtl,

and traceRouteResultsCurProbeCount is initialized to 1. Each time a probe result is
determined, traceRouteResultsCurProbeCount increases by 1. While the test is running,
the value of traceRouteResultsCurProbeCount reflects the current outstanding probe for
which results have not yet been determined.
The traceRouteCtlProbesPerHop number of probes is sent for each time-to-live (TTL)

value. When the result of the last probe for the current hop is determined, provided that
the current hop is not the destination hop, traceRouteResultsCurHopCount increases by
1, and traceRouteResultsCurProbeCount resets to 1.
At the start of a test, if this is the first time this test has been run for this traceRouteCtlEntry,
traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses are initialized to
0.
At the end of each test execution, traceRouteResultsOperStatus transitions to disabled,

and traceRouteResultsTestAttempts increases by 1. If the test was successful in
determining the full path to the target, traceRouteResultsTestSuccesses increases by 1,
and traceRouteResultsLastGoodPath is set to the current time.
traceRouteProbeResultsTable
Each entry in traceRouteProbeHistoryTable is indexed by five variables:
• The first two variables, traceRouteCtlOwnerIndex and traceRouteCtlTestName, are the

same ones used for traceRouteCtlTable and to identify the test.
• The third variable, traceRouteProbeHistoryIndex, is a counter, starting from 1 and

wrapping at FFFFFFFF. The maximum number of entries is limited by
traceRouteCtlMaxRows.
• The fourth variable, traceRouteProbeHistoryHopIndex, indicates which hop this probe

is for (the actual time-to-live or TTL value). Thus, the first traceRouteCtlProbesPerHop
number of entries created when a test starts have a value of traceRouteCtlInitialTtl for
traceRouteProbeHistoryHopIndex.
• The fifth variable, traceRouteProbeHistoryProbeIndex, is the probe for the current hop.
It ranges from 1 to traceRouteCtlProbesPerHop.
While a test is running, as soon as a probe result is determined, the next probe is sent. A
maximum of traceRouteCtlTimeOut seconds elapses before a probe is marked with

status requestTimedOut and the next probe is sent. There is never more than one
outstanding probe per traceroute test. Any probe result coming back after a probe times
out is ignored.
Each probe can:
• Result in a response from a host acknowledging the probe
• Time out with no response from a host acknowledging the probe
• Fail to be sent
Each probe status is recorded in traceRouteProbeHistoryTable with

traceRouteProbeHistoryStatus set accordingly.
Probes that result in a response from a host record the following data:
• traceRouteProbeHistoryResponse—Round-trip time (RTT)
• traceRouteProbeHistoryHAddrType—The type of HAddr (next argument)
• traceRouteProbeHistoryHAddr—The address of the hop
All probes, regardless of whether a response for the probe is received, have the following
recorded:
• traceRouteProbeHistoryStatus—What happened and why
• traceRouteProbeHistoryLastRC—Return code (RC) value of the ICMP packet
• traceRouteProbeHistoryTime—Timestamp when the probe result was determined
When a probe cannot be sent, traceRouteProbeHistoryResponse is set to 0. When a probe

times out, traceRouteProbeHistoryResponse is set to the difference between the time
when the probe was discovered to be timed out and the time when the probe was sent.
traceRouteHopsTable
Entries in traceRouteHopsTable are indexed by three variables:
• The first two, traceRouteCtlOwnerIndex and traceRouteCtlTestName, are the same

ones used for traceRouteCtlTable and identify the test.
• The third variable, traceRouteHopsHopIndex, indicates the current hop, which starts
at 1 (not traceRouteCtlInitialTtl).
When a test starts, all entries in traceRouteHopsTable with the given

traceRouteCtlOwnerIndex and traceRouteCtlTestName are deleted. Entries in this table
are only created if traceRouteCtlCreateHopsEntries is set to true.
A new traceRouteHopsEntry is created each time the first probe result for a given TTL is
determined. The new entry is created whether or not the first probe reaches a host. The
value of traceRouteHopsHopIndex is increased by 1 for this new entry.

NOTE: Any traceRouteHopsEntry can lack a value for

traceRouteHopsIpTgtAddress if there are no responses to the probes with the
given TTL.
Each time a probe reaches a host, the IP address of that host is available in the probe
result. If the value of traceRouteHopsIpTgtAddress of the current traceRouteHopsEntry
is not set, then the value of traceRouteHopsIpTgtAddress is set to this IP address. If the
value of traceRouteHopsIpTgtAddress of the current traceRouteHopsEntry is the same
as the IP address, then the value does not change. If the value of
traceRouteHopsIpTgtAddress of the current traceRouteHopsEntry is different from this
IP address, indicating a path change, a new traceRouteHopsEntry is created with:
• traceRouteHopsHopIndex variable increased by 1
• traceRouteHopsIpTgtAddress set to the IP address
NOTE: A new entry for a test is added to traceRouteHopsTable each time

a new TTL value is used or the path changes. Thus, the number of entries
for a test may exceed the number of different TTL values used.
When a probe result is determined, the value traceRouteHopsSentProbes of the current

traceRouteHopsEntry increases by 1. When a probe result is determined, and the probe
reaches a host:
• The value traceRouteHopsProbeResponses of the current traceRouteHopsEntry is

increased by 1.
• The following variables are updated:
• traceRouteResultsMinRtt—Minimum round-trip time
• traceRouteResultsMaxRtt—Maximum round-trip time
• traceRouteResultsAverageRtt—Average round-trip time
• traceRouteResultsRttSumOfSquares—Sum of squares of round-trip times
• traceRouteResultsLastGoodProbe—Timestamp of the last response
NOTE: Only probes that reach a host affect the round-trip time values.
Generating Traps
For any trap to be generated, the appropriate bit of traceRouteCtlTrapGeneration must
be set. You must also configure a trap group to receive remote operations. Traps are
generated under the following conditions:

• traceRouteHopsIpTgtAddress of the current probe is different from the last probe with
the same TTL value (traceRoutePathChange).
• A path to the target could not be determined (traceRouteTestFailed).
A path to the target was determined (traceRouteTestCompleted).
For information about how to configure a trap group to receive remote operations, see
“Configuring SNMP Trap Groups” on page 112 and “Example: Setting Trap Notification
for Remote Operations” on page 179.
Monitoring Traceroute Test Completion
When a test is complete, traceRouteResultsOperStatus transitions from enabled to

disabled. This transition occurs in the following situations:
• The test ends successfully. A probe result indicates that the destination has been
reached. In this case, the current hop is the last hop. The rest of the probes for this hop
are sent. When the last probe result for the current hop is determined, the test ends.
• traceRouteCtlMaxTtl threshold is exceeded. The destination is never reached. The test

ends after the number of probes with TTL value equal to traceRouteCtlMaxttl have
been sent.
• traceRouteCtlMaxFailures threshold is exceeded. The number of consecutive probes

that end with status requestTimedOut exceeds traceRouteCtlMaxFailures.
• You end the test. You set traceRouteCtlAdminStatus to disabled or delete the row by
setting traceRouteCtlRowStatus to destroy.
• You misconfigured the traceroute test. A value or variable you specified in

traceRouteCtlTable is incorrect and will not allow a single probe to be sent. Because
of the nature of the data, this error could not be determined until the test was started;
that is, until after traceRouteResultsOperStatus transitioned to enabled. When this
occurs, one entry is added to traceRouteProbeHistoryTable with
traceRouteProbeHistoryStatus set to the appropriate error code.
If traceRouteCtlTrapGeneration is set properly, either the traceRouteTestFailed or

traceRouteTestCompleted trap is generated.
Documentation

Gathering Traceroute Test Results
You can either poll traceRouteResultsOperStatus to find out when the test is complete
or request that a trap be sent when the test is complete. For more information about
traceResultsOperStatus, see “traceRouteResultsTable” on page 189. For more information
about Traceroute MIB traps, see the Generating Traps section in “Monitoring a Running
Traceroute Test” on page 189.
Statistics are calculated on a per-hop basis and then stored in traceRouteHopsTable.

They include the following for each hop:
• traceRouteHopsIpTgtAddressType—Address type of host at this hop
• traceRouteHopsIpTgtAddress—Address of host at this hop
• traceRouteHopsMinRtt—Minimum round-trip time
• traceRouteHopsMaxRtt—Maximum round-trip time
• traceRouteHopsAverageRtt—Average round-trip time
• traceRouteHopsRttSumOfSquares—Sum of squares of round-trip times
• traceRouteHopsSentProbes—Number of attempts to send probes
• traceRouteHopsProbeResponses—Number of responses received
• traceRouteHopsLastGoodProbe—Timestamp of last response
You can also consult traceRouteProbeHistoryTable for more detailed information about
each probe. The index used for traceRouteProbeHistoryTable starts at 1, goes to
0xFFFFFFFF, and wraps to 1 again.
For example, assume the following:
• traceRouteCtlMaxRows is 10.
• traceRouteCtlProbesPerHop is 5.
• There are eight hops to the target (the target being number eight).
• Each probe sent results in a response from a host (the number of probes sent is not
limited by traceRouteCtlMaxFailures).
In this test, 40 probes are sent. At the end of the test, traceRouteProbeHistoryTable would
have a history of probes like those in Table 22 on page 194.
Table 22: traceRouteProbeHistoryTable

HistoryIndex HistoryHopIndex HistoryProbeIndex
31 7 1
32 7 2

Table 22: traceRouteProbeHistoryTable (continued)

HistoryIndex HistoryHopIndex HistoryProbeIndex
33 7 3
34 7 4
35 7 5
36 8 1
37 8 2
38 8 3
39 8 4
40 8 5
Documentation
Stopping a Traceroute Test
To stop an active test, set traceRouteCtlAdminStatus to disabled. To stop a test and

remove its traceRouteCtlEntry, traceRouteResultsEntry, traceRouteProbeHistoryEntry,
and traceRouteProbeHistoryEntry objects from the MIB, set traceRouteCtlRowStatus to
destroy.
Documentation

Interpreting Traceroute Variables
This topic contains information about the ranges for the following variables that are not
explicitly specified in the Traceroute MIB:
• traceRouteCtlMaxRows—The maximum value for traceRouteCtlMaxRows is 2550. This

represents the maximum TTL (255) multiplied by the maximum for
traceRouteCtlProbesPerHop (10). Therefore, the traceRouteProbeHistoryTable
accommodates one complete test at the maximum values for one traceRouteCtlEntry.
Usually, the maximum values are not used and the traceRouteProbeHistoryTable is
able to accommodate the complete history for many tests for the same
traceRouteCtlEntry.
• traceRouteMaxConcurrentRequests—The maximum value is 50. If a test is running, it

has one outstanding probe. traceRouteMaxConcurrentRequests represents the maximum
number of traceroute tests that have traceRouteResultsOperStatus with a value of
enabled. Any attempt to start a test with traceRouteMaxConcurrentRequests tests
running will result in the creation of one probe with traceRouteProbeHistoryStatus set
to maxConcurrentLimitReached and that test will end immediately.
• traceRouteCtlTable—The maximum number of entries allowed in this table is 100. Any

attempt to create a 101st entry will result in a BAD_VALUE message for SNMPv1 and a
RESOURCE_UNAVAILABLE message for SNMPv2.
Documentation

CHAPTER 10
Tracing SNMP Activity
• Tracing SNMP Activity on a Device Running Junos OS on page 203
• Example: Tracing SNMP Activity on page 206
Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance on
a Device Running Junos OS
vSRX
The following sections contain information about monitoring the SNMP activity on devices
running the Junos OS and identifying problems that might impact the SNMP performance
on devices running Junos OS:
• Checking for MIB Objects Registered with the snmpd on page 197
• Tracking SNMP Activity on page 199
• Monitoring SNMP Statistics on page 200
• Checking CPU Utilization on page 201
• Checking Kernel and Packet Forwarding Engine Response on page 202
Checking for MIB Objects Registered with the snmpd

For the SNMP process to be able to access data related to a MIB object, the MIB object
must be registered with the snmpd. When an SNMP subagent comes online, it tries to
register the associated MIB objects with the snmpd. The snmpd maintains a mapping of
the objects and the subagents with which the objects are associated. However, the
registration attempt fails occasionally, and the objects remain unregistered with the
snmpd until the next time the subagent restarts and successfully registers the objects.
When a network management system polls for data related to objects that are not
registered with the snmpd, the snmpd returns either a noSuchName error (for SNMPv1
objects) or a noSuchObject error (for SNMPv2 objects).

You can use the following commands to check for MIB objects that are registered with
the snmpd:
• show snmp registered-objects—Creates a /var/log/snmp_reg_objs file that contains

the list of registered objects and their mapping to various subagents.
• file show /var/log/snmp_reg_objs—Displays the contents of the /var/log/snmp_reg_objs

file.
The following example shows the steps for creating and displaying the
/var/log/snmp_reg_objs file:
user@host> show snmp registered-objects

user@host> file show /var/log/snmp_reg_objs
--------------------------------------------------------------
Registered MIB Objects
root_name =
--------------------------------------------------------------
.1.2.840.10006.300.43.1.1.1.1.2 (dot3adAggMACAddress) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.3 (dot3adAggActorSystemPriority) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.4 (dot3adAggActorSystemID) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.5 (dot3adAggAggregateOrIndividual)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.6 (dot3adAggActorAdminKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.7 (dot3adAggActorOperKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.8 (dot3adAggPartnerSystemID) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.9 (dot3adAggPartnerSystemPriority)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.10 (dot3adAggPartnerOperKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.1.1.11 (dot3adAggCollectorMaxDelay) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.1.2.1.1 (dot3adAggPortListPorts) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.2 (dot3adAggPortActorSystemPriority)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.3 (dot3adAggPortActorSystemID) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.4 (dot3adAggPortActorAdminKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.5 (dot3adAggPortActorOperKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.6 (dot3adAggPortPartnerAdminSystemPriority)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.7 (dot3adAggPortPartnerOperSystemPriority)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.8 (dot3adAggPortPartnerAdminSystemID)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.9 (dot3adAggPortPartnerOperSystemID)
(/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.10 (dot3adAggPortPartnerAdminKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.11 (dot3adAggPortPartnerOperKey) (/var/run/mib2d-11)
.1.2.840.10006.300.43.1.2.1.1.12 (dot3adAggPortSelectedAggID) (/var/run/mib2d-11)
---(more)---
NOTE: The /var/log/snmp_reg_objs file contains only those objects that are
associated with the Junos OS processes that are up and running and registered
with the snmpd, at the time of executing the show snmp registered-objects
command. If a MIB object related to a Junos OS process that is up and running
is not shown in the list of registered objects, you might want to restart the
software process to retry object registration with the snmpd.

Chapter 10: Tracing SNMP Activity
Tracking SNMP Activity

SNMP tracing operations track activity of SNMP agents and record the information in
log files. The logged event descriptions provide detailed information to help you solve
problems faster. By default, Junos OS does not trace any SNMP activity. To enable
tracking of SNMP activities on a device running Junos OS, include the traceoptions
statement at the [edit snmp] hierarchy level.
A sample traceoptions configuration might look like:
[edit snmp]
set traceoptions flag all;
When the traceoptions flag all statement is included at the [edit snmp] hierarchy level,
the following log files are created:
• snmpd
• mib2d
• rmopd
You can use the show log log-filename operational mode command to view the contents
of the log file. In the snmpd log file (see the following example), a sequence of >>>
represents an incoming packet, whereas a sequence of <<< represents an outgoing
packet. Note that the request response pair might not follow any sequence if there are
multiple network management systems polling the device at the same time. You can
use the source and request ID combinations to match requests and responses. However,
note that no response log is created in the log file if the SNMP master agent or the SNMP
subagent has not responded to a request.
A careful analysis of the request-response time can help you identify and understand
delayed responses.
Reviewing a Log File
The following example shows the output for the show log snmpd command:
user@host> show log snmpd

Apr 12 06:40:03 snmpd[7ee783df] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Apr 12 06:40:03 snmpd[7ee783df] >>> Get-Bulk-Request
Apr 12 06:40:03 snmpd[7ee783df] >>> Source: 10.209.63.42
Apr 12 06:40:03 snmpd[7ee783df] >>> Destination: 10.209.2.242
Apr 12 06:40:03 snmpd[7ee783df] >>> Version: SNMPv2
Apr 12 06:40:03 snmpd[7ee783df] >>> Request_id: 0x7ee783df
Apr 12 06:40:03 snmpd[7ee783df] >>> Community: public
Apr 12 06:40:03 snmpd[7ee783df] >>> Non-repeaters: 0
Apr 12 06:40:03 snmpd[7ee783df] >>> Max-repetitions: 10
Apr 12 06:40:03 snmpd[7ee783df] >>> OID : jnxContentsType.6.1.2.0
Apr 12 06:40:03 snmpd[7ee783df] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Apr 12 06:40:03 snmpd[7ee783df] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Apr 12 06:40:03 snmpd[7ee783df] <<< Get-Response
Apr 12 06:40:03 snmpd[7ee783df] <<< Source: 10.209.63.42
Apr 12 06:40:03 snmpd[7ee783df] <<< Destination: 10.209.2.242
Apr 12 06:40:03 snmpd[7ee783df] <<< Version: SNMPv2
Apr 12 06:40:03 snmpd[7ee783df] <<< Request_id: 0x7ee783df
Apr 12 06:40:03 snmpd[7ee783df] <<< Community: public

Apr 12 06:40:03 snmpd[7ee783df] <<< Error: status=0 / vb_index=0

Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< OID : jnxContentsType.7.1.0.0
Apr 12 06:40:03 snmpd[7ee783df] <<< type : Object
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iFPC.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxChassisTempSensor.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iFPC.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxChassisTempSensor.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iRE.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxPCMCIACard.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iRE.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxPCMCIACard.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iHCM.0
Apr 12 06:40:03 snmpd[7ee783df] <<<
Apr 12 06:40:03 snmpd[7ee783df] <<< value: jnxM10iHCM.0
Apr 12 06:40:03 snmpd[7ee783df] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Apr 12 06:40:03 snmpd[7ee783e0] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Apr 12 06:40:03 snmpd[7ee783e0] >>> Get-Bulk-Request
Apr 12 06:40:03 snmpd[7ee783e0] >>> Source: 10.209.63.42
Apr 12 06:40:03 snmpd[7ee783e0] >>> Destination: 10.209.2.242
Apr 12 06:40:03 snmpd[7ee783e0] >>> Version: SNMPv2
Apr 12 06:40:03 snmpd[7ee783e0] >>> Request_id: 0x7ee783e0
Apr 12 06:40:03 snmpd[7ee783e0] >>> Community: public
Apr 12 06:40:03 snmpd[7ee783e0] >>> Non-repeaters: 0
Apr 12 06:40:03 snmpd[7ee783e0] >>> Max-repetitions: 10
Apr 12 06:40:03 snmpd[7ee783e0] >>> OID : jnxContentsType.12.2.0.0
Apr 12 06:40:03 snmpd[7ee783e0] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
……
……
Monitoring SNMP Statistics

The show snmp statistics extensive operational mode command provides you with an
option to review SNMP traffic, including traps, on a device. Output for the show snmp

statistics extensive command shows real-time values and can be used to monitor values
such as throttle drops, currently active, max active, not found, time out, max latency,
current queued, total queued, and overflows. You can identify slowness in SNMP
responses by monitoring the currently active count, because a constant increase in the
currently active count is directly linked to slow or no response to SNMP requests.
Sample Output for 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 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
Checking CPU Utilization

High CPU usage of the software processes that are being queried, such as snmpd or
mib2d, is another factor that can lead to slow response or no response. You can use the
show system processes extensive operational mode command to check the CPU usage
levels of the Junos OS processes.
Sample Output of show system processes extensive Command

user@host> show system processes extensive
last pid: 1415; load averages: 0.00, 0.00, 0.00 up 0+02:20:54 10:26:25
117 processes: 2 running, 98 sleeping, 17 waiting
Mem: 180M Active, 54M Inact, 39M Wired, 195M Cache, 69M Buf, 272M Free
Swap: 1536M Total, 1536M Free

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
11 root 1 171 52 0K 12K RUN 132:09 95.21% idle
1184 root 1 97 0 35580K 9324K select 4:16 1.61% chassisd
177 root 1 -8 0 0K 12K mdwait 0:51 0.00% md7
119 root 1 -8 0 0K 12K mdwait 0:20 0.00% md4
13 root 1 -20 -139 0K 12K WAIT 0:16 0.00% swi7: clock sio
1373 root 1 96 0 15008K 12712K select 0:09 0.00% snmpd
1371 root 1 96 0 9520K 5032K select 0:08 0.00% jdiameterd
12 root 1 -40 -159 0K 12K WAIT 0:07 0.00% swi2: net
1375 root 2 96 0 15016K 5812K select 0:06 0.00% pfed
49 root 1 -8 0 0K 12K mdwait 0:05 0.00% md0
1345 root 1 96 0 10088K 4480K select 0:05 0.00% l2ald
1181 root 1 96 0 1608K 908K select 0:05 0.00% bslockd
23 root 1 -68 -187 0K 12K WAIT 0:04 0.00% irq10: fxp1
30 root 1 171 52 0K 12K pgzero 0:04 0.00% pagezero
1344 root 1 4 0 39704K 11444K kqread 0:03 0.00% rpd
1205 root 1 96 0 3152K 912K select 0:03 0.00% license-check
1372 root 1 96 0 28364K 6696K select 0:03 0.00% dcd
1374 root 1 96 0 11764K 7632K select 0:02 0.00% mib2d
1405 user 1 96 0 15892K 11132K select 0:02 0.00% cli
139 root 1 -8 0 0K 12K mdwait 0:02 0.00% md5
22 root 1 -80 -199 0K 12K WAIT 0:02 0.00% irq9: cbb1 fxp0
1185 root 1 96 0 4472K 2036K select 0:02 0.00% alarmd
4 root 1 -8 0 0K 12K - 0:02 0.00% g_down
3 root 1 -8 0 0K 12K - 0:02 0.00% g_up
43 root 1 -16 0 0K 12K psleep 0:02 0.00% vmkmemdaemon
1377 root 1 96 0 3776K 2256K select 0:01 0.00% irsd
48 root 1 -16 0 0K 12K - 0:01 0.00% schedcpu
99 root 1 -8 0 0K 12K mdwait 0:01 0.00% md3
953 root 1 96 0 4168K 2428K select 0:01 0.00% eventd
1364 root 1 96 0 4872K 2808K select 0:01 0.00% cfmd
15 root 1 -16 0 0K 12K - 0:01 0.00% yarrow
1350 root 1 96 0 31580K 7248K select 0:01 0.00% cosd
1378 root 1 96 0 19776K 6292K select 0:01 0.00% lpdfd
...
Checking Kernel and Packet Forwarding Engine Response

As mentioned in “Understanding SNMP Implementation in Junos OS” on page 13, some
SNMP MIB data are maintained by the kernel or Packet Forwarding Engine. For such data
to be available for the network management system, the kernel has to provide the required
information to the SNMP subagent in mib2d. A slow response from the kernel can cause
a delay in mib2d returning the data to the network management system. Junos OS adds
an entry in the mib2d log file every time that an interface takes more than 10,000
microseconds to respond to a request for interface statistics. You can use the show log
log-filename | grep “kernel response time” command to find out the response time taken
by the kernel.
Checking the Kernel Response Time

user@host> show log mib2d | grep “kernel response time”
Aug 17 22:39:37 == kernel response time for
COS_IPVPN_DEFAULT_OUTPUT-t1-7/3/0:10:27.0-o: 9.126471 sec, range
(0.000007, 11.000806)
Aug 17 22:39:53 == kernel response time for

COS_IPVPN_DEFAULT_INPUT-t1-7/2/0:5:15.0-i: 5.387321 sec, range

(0.000007, 11.000806)
Aug 17 22:39:53 == kernel response time for ct1-6/1/0:9:15: 0.695406

sec, range (0.000007, 11.000806)
Aug 17 22:40:04 == kernel response time for t1-6/3/0:6:19: 1.878542

sec, range (0.000007, 11.000806)
Aug 17 22:40:22 == kernel response time for lsq-7/0/0: 2.556592 sec,

range (0.000007, 11.000806)

Documentation
page 87
Tracing SNMP Activity on a Device Running Junos OS
Supported Platforms ACX Series, EX4600, M Series, MX Series, PTX Series, QFX Series, T Series
SNMP tracing operations track activity for SNMP agents and record the information in
log files. The logged error descriptions provide detailed information to help you solve
problems faster.
By default, Junos OS does not trace any SNMP activity. If you include the traceoptions
statement at the [edit snmp] hierarchy level, the default tracing behavior is:
• Important activities are logged in files located in the /var/log directory. Each log is
named after the SNMP agent that generates it. Currently, the following log files are
created in the /var/log directory when the traceoptions statement is used:
• chassisd
• craftd
• ilmid
• mib2d
• rmopd
• serviced
• snmpd
• When a trace file named filename reaches its maximum size, it is renamed filename.0,
then filename.1, and so on, until the maximum number of trace files is reached. Then
the oldest trace file is overwritten. (For more information about how log files are created,
see the System Log Explorer.)

• Log files can be accessed only by the user who configured the tracing operation.
You cannot change the directory (/var/log) in which trace files are located. However,
you can customize the other trace file settings by including the following statements at
the [edit snmp] hierarchy level:
[edit snmp]
traceoptions {
file <files number> <match regular-expression> <size size> <world-readable |
no-world-readable>;
flag flag;
memory-trace;
no-remote-trace;
no-default-memory-trace;
}
These statements are described in the following sections:
• Configuring the Number and Size of SNMP Log Files on page 204
• Configuring Access to the Log File on page 204
• Configuring a Regular Expression for Lines to Be Logged on page 205
• Configuring the Trace Operations on page 205
Configuring the Number and Size of SNMP Log Files

By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamed filename.0,
then filename.1, and so on, until there are three trace files. Then the oldest trace file
(filename.2) is overwritten.
You can configure the limits on the number and size of trace files by including the following
statements at the [edit snmp traceoptions] hierarchy level:
[edit snmp traceoptions]

file files number size size;
For example, set the maximum file size to 2 MB, and the maximum number of files to 20.
When the file that receives the output of the tracing operation (filename) reaches 2 MB,
filename is renamed filename.0, and a new file called filename is created. When the new
filename reaches 2 MB, filename.0 is renamed filename.1 and filename is renamed
filename.0. This process repeats until there are 20 trace files. Then the oldest file
(filename.19) is overwritten by the newest file (filename.0).
The number of files can be from 2 through 1000 files. The file size of each file can be from
10 KB through 1 gigabyte (GB).
Configuring Access to the Log File

By default, log files can be accessed only by the user who configured the tracing operation.
To specify that any user can read all log files, include the file world-readable statement
at the [edit snmp traceoptions] hierarchy level:

file world-readable;

To explicitly set the default behavior, include the file no-world-readable statement at the
[edit snmp traceoptions] hierarchy level:

file no-world-readable;
Configuring a Regular Expression for Lines to Be Logged

By default, the trace operation output includes all lines relevant to the logged activities.
You can refine the output by including the match statement at the [edit snmp traceoptions
file filename] hierarchy level and specifying a regular expression (regex) to be matched:

file filename match regular-expression;
Configuring the Trace Operations

By default, only important activities are logged. You can specify which trace operations
are to be logged by including the following flag statement (with one or more tracing
flags) at the [edit snmp traceoptions] hierarchy level:

flag {
all;
configuration;
database;
events;
general;
interface-stats;
nonvolatile-sets;
pdu;
policy;
protocol-timeouts;
routing-socket;
server;
subagent;
timer;
varbind-error;
}
Table 23 on page 205 describes the meaning of the SNMP tracing flags.
Table 23: SNMP Tracing Flags

Flag Description Default Setting
all Log all operations. Off
configuration Log reading of the configuration at the Off

[edit snmp] hierarchy level.
database Log events involving storage and retrieval in the Off

events database.
events Log important events. Off

Table 23: SNMP Tracing Flags (continued)

Flag Description Default Setting
general Log general events. Off
interface-stats Log physical and logical interface statistics. Off
nonvolatile-set Log nonvolatile SNMP set request handling. Off
pdu Log SNMP request and response packets. Off
policy Log policy processing. Off
protocol-timeouts Log SNMP response timeouts. Off
routing-socket Log routing socket calls. Off
server Log communication with processes that are Off

generating events.
subagent Log subagent restarts. Off
timer Log internal timer events. Off
varbind-error Log variable binding errors. Off
To display the end of the log for an agent, issue the show log agentd | last operational
mode command:
[edit]
user@host# run show log agentd | last
where agent is the name of an SNMP agent.

Documentation
• Example: Tracing SNMP Activity on page 206
• Configuring SNMP
Example: Tracing SNMP Activity
Trace information about SNMP packets:
[edit]
snmp {
traceoptions {
file size 10k files 5;
flag pdu;

flag protocol-timeouts;
flag varbind-error;
}
}

Documentation
• Tracing SNMP Activity on a Device Running Junos OS on page 203


CHAPTER 11
SNMP FAQs
• Junos OS SNMP FAQ Overview on page 209

• Junos OS SNMP FAQs on page 210
Junos OS SNMP FAQ Overview
Supported Platforms EX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, SRX Series, T Series
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 enables 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 the Junos OS.
The 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 – Acombination 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 the Junos OS uses a master SNMP agent (known as an SNMP
process or snmpd) that resides on the managed device. Various subagents reside on
different modules of the Junos OS as well (such as the Routing Engine), and these
subagents are managed by the snmpd.

Related • Junos OS SNMP FAQs on page 210

Documentation
Junos OS SNMP FAQs
Supported Platforms EX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, SRX Series, T Series
This Frequently Asked Questions technology overview covers these SNMP-related areas:
• Junos OS SNMP Support FAQs on page 210

• Junos OS MIBs FAQs on page 211
• Junos OS SNMP Configuration FAQs on page 218
• SNMPv3 FAQs on page 222
• SNMP Interaction with Juniper Networks Devices FAQs on page 224
• SNMP Traps and Informs FAQs on page 226
• Junos OS Dual Routing Engine Configuration FAQs on page 232
• SNMP Support for Routing Instances FAQs on page 233
• SNMP Counters FAQs on page 234
Junos OS SNMP Support FAQs

This section presents frequently asked questions and answers related to SNMP support
on Junos OS.
Which SNMP versions does Junos OS support?
Junos OS supports SNMP version 1 (SNMPv1), version 2 (SNMPv2c), and version 3

(SNMPv3). By default, SNMP is disabled on a Juniper Networks device.
Which ports (sockets) does SNMP use?
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 the Junos OS platforms?
No, SNMP support is not different among the Junos OS platforms. SNMP configuration,
interaction, and behavior are the same on any Junos OS device. The only difference that
might occur across platforms is MIB support.
See also SNMP MIB Explorer for a list of MIBs that are supported across the 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.

Chapter 11: SNMP FAQs
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
Junos OS MIBs FAQs

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” on page 30.
For a list of Juniper Networks enterprise-specific MIBs, see “Enterprise-Specific SNMP

MIBs Supported by Junos OS” on page 19.
Do MIB files reside on the Junos OS devices?
No, MIB files do not reside on the 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/en_US/release-independent/junos/mibs/mibs.html .
How do I compile and load the Junos OS MIBs onto an SNMP manager or NMS?
For your network management systems (NMSs) 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 OS MIB package from the Enterprise-Specific MIBs and
Traps section at
http://www.juniper.net/techpubs/en_US/release-independent/junos/mibs/mibs.html or
http://www.juniper.net/techpubs/software/junos/index.html .
The Junos OS 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 might be
dependencies that require a particular standard MIB to be present on the compiler before
loading a particular enterprise-specific MIB.
The Junos OS 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 OS MIB package.
3. Decompress the file (.tar or .zip) using an appropriate utility.
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.
4. Load the standard MIB files from the StandardMibs folder.
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 might 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, load the missing file or files first,
then try to load the MIB file that failed.
The system might 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 does Junos OS support?
The Junos OS supports SMIv1 for SNMPv1 MIBs, and SMIv2 for SNMPv2c and enterprise
MIBs.
Does Junos OS support MIB II?
Yes, Junos OS supports MIB II, the second version of the MIB standard.
The features of MIB II include:
• Additions that reflect new operational requirements.
• Backward 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. Go to
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 the 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 OS Technical Documentation.
See “Enterprise-Specific SNMP MIBs Supported by Junos OS” on page 19 and “Standard
SNMP MIBs Supported by Junos OS” on page 30 documents to view the list of MIBs and
supported Junos OS devices.
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 itself 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.
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?
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, the device tries to keep the ifIndex persistent on a
best effort basis. For Junos OS Release 10.0 and earlier, the ifIndex is not persistent when
there is a software upgrade to Junos OS Release 10.1 and later.
Is it possible to set the ifAdminStatus?
SNMP is not allowed to set the ifAdminStatus.
Which MIB objects support SNMP set operations?
The 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 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 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 24 on page 217.

Table 24: 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) 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
jnxOperatingCPU (RE1)
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.
jnxOperatingBuffer (RE0) 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
jnxOperatingBuffer (RE1)
jnxOperatingCPU, the alarm entry monitoring RE1 is removed if the router or switch
has only one Routing Engine.
sysApplElmtRunCPU Monitors the CPU usage for each Junos OS software process. Multiple instances of
the same process are monitored and indexed separately.
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
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, the 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
Junos OS SNMP Configuration FAQs

This section presents frequently asked questions and answers related to Junos OS SNMP
configuration.
Can the 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;
}
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 (SRX Series
Services Gateways) 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;
}
}
}
}
}
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-name test123 {
group test1;
}
security-name juniper {
group test1;
}
}
}

access {
group test1 {
read-view all;
}
}
}
context-prefix MGMT_10 {
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 {
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;
logical-system LDP-VPLS {
routing-instance vpls-server1;
}
}

trap-group server1 {
targets {
116.197.179.22;
}
}
routing-instance-access;
traceoptions {
flag all;
}
}
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 might 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:
• snmpd
• mib2d
• rmopd
Related • Junos OS SNMP Support FAQs on page 210

Documentation
• Junos OS MIBs FAQs on page 211
• SNMPv3 FAQs on page 222
• SNMP Interaction with Juniper Networks Devices FAQs on page 224
• SNMP Traps and Informs FAQs on page 226
• SNMP Support for Routing Instances FAQs on page 233
• SNMP Counters FAQs on page 234
SNMPv3 FAQs
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. However, if
both routing engines have the same engine ID and the routing engine with lesser
snmpEngineBoots value is selected as the master routing engine during the switchover
process, the snmpEngineBoots value of the master routing engine is synchronized with
the snmpEngineBoots value of the other routing engine.
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.
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 {
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;
target-parameters TP2_v3_sha_none;

}
target-parameters TP2_v3_sha_none {
parameters {
security-model usm;
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.
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
SNMP Interaction with Juniper Networks Devices FAQs

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:
• The number of variable bindings in a protocol data unit (PDU)
• 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.

Frequent polling of a large number of counters, especially statistics, can impact the
device. We recommend the following optimization on the SNMP managers:
• Use the row-by-row polling method, not the column-by-column method.
• Reduce the number of variable bindings per PDU.
• Increase timeout values in polling and discovery intervals.
• Reduce the incoming packet rate at the SNMP process (snmpd).
For better SNMP response on the device, the Junos OS does 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:
Throttle drops: 27084, Duplicate request drops: 0
V3 Input:
Output:
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
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 the SNMP process restarts on 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 FAQs

This section presents frequently asked questions and answers related to SNMP traps
and informs.
Does the Junos OS impose any rate limiting on SNMP trap generation?
The 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 1, 2, 4, and 8 minutes. The maximum delay between the
attempts is 8 minutes, and the maximum number of attempts is 10. After 10 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 5 seconds). This helps
ensure consistency in trap traffic, especially when a large number 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 40,000 traps. The maximum size of any one queue is 20,000 traps. When a
trap is added to the throttle queue, or if the throttle queue has exceeded the maximum
size, the trap is moved to the 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 Juniper Networks EX Series Ethernet Switch, the maximum
size of all trap queues (the throttle queue and the destination queue) is 1,000
traps. The maximum size for any one queue on the EX Series is 500 traps.
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 the Junos
OS?
No, SNMP traps on the 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 the Junos OS.
The following example shows a sample configuration for receiving only link, vrrp-events,
services, and otn-alarms traps:
[edit snmp]
trap-group jnpr {
categories {
link;
vrrp-events;
services;
otn-alarms;
}
targets {
192.168.69.179;
}

The 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 SNMPv1 and SNMPv2 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 {
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;
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;
}

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 device’s 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 5 minutes. If the system up time is less than
5 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, such as the names of the traps, it
must first compile and understand the MIBs and then parse the MIB OIDs.
In the 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
documents.
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-spoof-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;
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 device to tell
the device 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
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?
For Ethernet and ATM types of interfaces, 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.

For SONET types of interfaces with PPP encapsulation, Junos OS does send link down
traps for a logical interface if the physical interface is down. When the physical interface
and logical interfaces come back up, traps are sent for both the physical and logical
interfaces indicating link up.
For SONET types of interfaces with HDLC encapsulation, Junos OS does not send link
down traps for a logical interface if the physical interface is down. When the physical
interface and logical interfaces come back up, traps are sent for both the physical and
logical interfaces indicating link up.
For channelize interfaces with PPP encapsulation, Junos OS does send link down traps
for a logical interface if the physical interface is down. When the physical interface and
logical interfaces come back up, traps are sent for both the physical and logical interfaces
indicating link up.
For channelize interfaces with HDLC encapsulation, Junos OS does not send link down
traps for a logical interface if the physical interface is down. When the physical interface
and logical interfaces come back up, traps are sent for both the physical and logical
interfaces indicating link up.
Related
Documentation
Junos OS Dual Routing Engine Configuration FAQs

This section presents frequently asked questions and answers related to the configuration
of dual Routing Engines.
The SNMP configuration should be identical between the Routing Engines when
configuring for continued communication. However, we recommend having separate
Routing Engine IDs configured for each Routing Engine, when using SNMPv3.
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 normal behavior. Each Routing Engine runs its own SNMP process (snmpd)
agent, allowing each Routing Engine to maintain its own engine boots.
Is there a way to identify that an address belongs to RE0, RE1, or the master Routing
Engine management interface (fxp0) by looking at an SNMP walk?
No. When you do an SNMP walk on the device, it only displays the master Routing Engine
management interface address.
What is the best way to tell if the current IP address belongs to fxp0 or a Routing
Engine, from a CLI session?
Routing Engines are mapped with the fxp0 interface. This means that when you query
RE0, the ifTable reports the fxp0 interface address of RE0 only. Similarly, if you query
RE1, the ifTable reports the fxp0 interface address of RE1 only.
When there is a failover, the master hostname is changed since the hostname belongs
to the Routing Engine. Is this correct?

Yes. You can configure the same hostname or different hostnames. Either would work.
If only the master IP address is configured (for example, 192.168.2.5), and the sysDescr.0
object has the same string configured on both of the Routing Engines, then even after a
switchover, the sysDescr.0 object returns the same value. The following sample shows
the results you get by using the snmpget command:
bng-junos-pool02: /c/svivek/PR_BRANCH/src> snmpget -c jnpr -v2c 192.168.2.5

sysDescr.0 system.sysDescr.0 = foo
SNMP Support for Routing Instances FAQs

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, the 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
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 @ character—in 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
SNMP Counters FAQs

This section presents frequently asked questions and answers related to SNMP counters.
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 sublayer 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 command does not clear the
statistics that 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


PART 3
Remote Monitoring (RMON) with SNMP

• RMON Overview on page 239
• Configuring RMON Alarms and Events on page 243
• Monitoring RMON Alarms and Events on page 251
• Using RMON to Monitor Network Service Quality on page 257


CHAPTER 12
RMON Overview
• Understanding RMON Alarms on page 239

• Understanding RMON Events on page 241
Understanding RMON Alarms
An RMON alarm identifies:
• A specific MIB object that is monitored.
• The frequency of sampling.
• The method of sampling.
• The thresholds against which the monitored values are compared.
An RMON alarm can also identify a specific eventTable entry to be triggered when a
threshold is crossed.
Configuration and operational values are defined in alarmTable in RFC 2819. Additional
operational values are defined in Juniper Networks enterprise-specific extensions to
alarmTable (jnxRmonAlarmTable).
This topic covers the following sections:
• alarmTable on page 239

• jnxRmonAlarmTable on page 240
alarmTable
alarmTable in the RMON MIB allows you to monitor and poll the following:
• alarmIndex—The index value for alarmTable that identifies a specific entry.
• alarmInterval—The interval, in seconds, over which data is sampled and compared

with the rising and falling thresholds.
• alarmVariable—The MIB variable that is monitored by the alarm entry.
• alarmSampleType—The method of sampling the selected variable and calculating the

value to be compared against the thresholds.

• alarmValue—The value of the variable during the last sampling period. This value is
compared with the rising and falling thresholds.
• alarmStartupAlarm—The alarm sent when the entry is first activated.
• alarmRisingThreshold—The upper threshold for the sampled variable.
• alarmFallingThreshold—The lower threshold for the sampled variable.
• alarmRisingEventIndex—The eventTable entry used when a rising threshold is crossed.
• alarmFallingEventIndex—The eventTable entry used when a falling threshold is crossed.
• alarmStatus—Method for adding and removing entries from the table. It can also be
used to change the state of an entry to allow modifications.
NOTE: If this object is not set to valid, the associated event alarm does not
take any action.
jnxRmonAlarmTable
The jnxRmonAlarmTable is a Juniper Networks enterprise-specific extension to alarmTable.
It provides additional operational information and includes the following objects:
• jnxRmonAlarmGetFailCnt—The number of times the internal Get request for the variable
monitored by this entry has failed.
• jnxRmonAlarmGetFailTime—The value of sysUpTime when an internal Get request for

the variable monitored by this entry last failed.
• jnxRmonAlarmGetFailReason—The reason an internal Get request for the variable

monitored by this entry last failed.
• jnxRmonAlarmGetOkTime—The value of sysUpTime when an internal Get request for

the variable monitored by this entry succeeded and the entry left the getFailure state.
• jnxRmonAlarmState—The current state of this RMON alarm entry.
To view the Juniper Networks enterprise-specific extensions to the RMON Events and
Alarms and Event MIB, see
http://www.juniper.net/techpubs/en_US/junos16.1/topics/reference/mibs/mib-jnx-rmon.txt.
For more information about the Juniper Networks enterprise-specific extensions to the
RMON Events and Alarms MIB, see “RMON Events and Alarms MIB” in the Network
Management Administration Guide.
Related • Understanding RMON Events on page 241

Documentation
• Configuring an RMON Alarm Entry and Its Attributes on page 244
• Using alarmTable to Monitor MIB Objects on page 251

Chapter 12: RMON Overview
Understanding RMON Events
Supported Platforms ACX Series, M Series, MX Series, SRX Series, T Series
An RMON event allows you to log the crossing of thresholds of other MIB objects. It is
defined in eventTable for the RMON MIB.
This section covers the following topics:
• eventTable on page 241
eventTable
eventTable contains the following objects:
• eventIndex—An index that uniquely identifies an entry in eventTable. Each entry defines
one event that is generated when the appropriate conditions occur.
• eventDescription—A comment describing the event entry.
• eventType—Type of notification that the probe makes about this event.
• eventCommunity—Trap group used if an SNMP trap is to be sent. If eventCommunity

is not configured, a trap is sent to each trap group configured with the rmon-alarm
category.
• eventLastTimeSent—Value of sysUpTime when this event entry last generated an

event.
• eventOwner—Any text string specified by the creating management application or the

command-line interface (CLI). Typically, it is used to identify a network manager (or
application) and can be used for fine access control between participating management
applications.
• eventStatus—Status of this event entry.
NOTE: If this object is not set to valid, no action is taken by the associated
event entry. When this object is set to valid, all previous log entries
associated with this entry (if any) are deleted.
Related • Understanding RMON Alarms on page 239

Documentation
• Configuring an RMON Event Entry and Its Attributes on page 248


CHAPTER 13
Configuring RMON Alarms and Events
• Understanding RMON Alarms and Events Configuration on page 243

• Minimum RMON Alarm and Event Entry Configuration on page 244
• Example: Configuring an RMON Alarm and Event Entry on page 249
Understanding RMON Alarms and Events Configuration
Supported Platforms ACX Series, M Series, MX Series, SRX Series, T Series
Junos OS supports monitoring routers from remote devices. These values are measured
against thresholds and trigger events when the thresholds are crossed. You configure
remote monitoring (RMON) alarm and event entries to monitor the value of a MIB object.
To configure RMON alarm and event entries, you include statements at the [edit snmp]
hierarchy level of the configuration:
[edit snmp]
rmon {
alarm index {
description text-description;
interval seconds;
sample-type (absolute-value | delta-value);
startup-alarm (falling-alarm | rising-alarm | rising-or-falling-alarm);
event index {
type type;
}
}
}


Documentation
Minimum RMON Alarm and Event Entry Configuration
To enable RMON on the router, you must configure an alarm entry and an event entry.
To do this, include the following statements at the [edit snmp rmon] hierarchy level:
[edit snmp rmon]

alarm index {
sample-type type;
}
event index;
Related • Understanding RMON Alarms and Events Configuration on page 243

Documentation
Configuring an RMON Alarm Entry and Its Attributes
An alarm entry monitors the value of a MIB variable. You can configure how often the
value is sampled, the type of sampling to perform, and what event to trigger if a threshold
is crossed.
This section discusses the following topics:
• Configuring the Alarm Entry on page 245

• Configuring the Description on page 245
• Configuring the Falling Event Index or Rising Event Index on page 245
• Configuring the Falling Threshold or Rising Threshold on page 246
• Configuring the Interval on page 246
• Configuring the Falling Threshold Interval on page 246
• Configuring the Request Type on page 247
• Configuring the Sample Type on page 247
• Configuring the Startup Alarm on page 247

Chapter 13: Configuring RMON Alarms and Events
• Configuring the System Log Tag on page 248

• Configuring the Variable on page 248
Configuring the Alarm Entry

An alarm entry monitors the value of a MIB variable. The rising-event-index,
rising-threshold, sample-type, and variable statements are mandatory. All other
statements are optional.
To configure the alarm entry, include the alarm statement and specify an index at the
[edit snmp rmon] hierarchy level:
[edit snmp rmon]

alarm index {
interval seconds;
startup-alarm (falling-alarm | rising alarm | rising-or-falling-alarm);
}
index is an integer that identifies an alarm or event entry.
Configuring the Description

The description is a text string that identifies the alarm entry.
To configure the description, include the description statement and a description of the
alarm entry at the [edit snmp rmon alarm index] hierarchy level:
[edit snmp rmon alarm index]

Configuring the Falling Event Index or Rising Event Index

The falling event index identifies the event entry that is triggered when a falling threshold
is crossed. The rising event index identifies the event entry that is triggered when a rising
threshold is crossed.
To configure the falling event index or rising event index, include the falling-event-index
or rising-event-index statement and specify an index at the [edit snmp rmon alarm index]
hierarchy level:

index can be from 0 through 65,535. The default for both the falling and rising event index
is 0.

Configuring the Falling Threshold or Rising Threshold

The falling threshold is the lower threshold for the monitored variable. When the current
sampled value is less than or equal to this threshold, and the value at the last sampling
interval is greater than this threshold, a single event is generated. A single event is also
generated if the first sample after this entry becomes valid is less than or equal to this
threshold, and the associated startup alarm is equal to falling-alarm or
rising-or-falling-alarm. After a falling event is generated, another falling event cannot be
generated until the sampled value rises above this threshold and reaches the rising
threshold. You must specify the falling threshold as an integer. Its default is 20 percent
less than the rising threshold.
By default, the rising threshold is 0. The rising threshold is the upper threshold for the
monitored variable. When the current sampled value is greater than or equal to this
threshold, and the value at the last sampling interval is less than this threshold, a single
event is generated. A single event is also generated if the first sample after this entry
becomes valid is greater than or equal to this threshold, and the associated startup-alarm
is equal to rising-alarm or rising-or-falling-alarm. After a rising event is generated, another
rising event cannot be generated until the sampled value falls below this threshold and
reaches the falling threshold. You must specify the rising threshold as an integer.
To configure the falling threshold or rising threshold, include the falling-threshold or

rising-threshold statement at the [edit snmp rmon alarm index] hierarchy level:

integer can be a value from -2,147,483,647 through 2,147,483,647.
Configuring the Interval

The interval represents the period of time, in seconds, over which the monitored variable
is sampled and compared with the rising and falling thresholds.
To configure the interval, include the interval statement and specify the number of seconds
at the [edit snmp rmon alarm index] hierarchy level:

interval seconds;
seconds can be a value from 1 through 2,147,483,647. The default is 60 seconds.
Configuring the Falling Threshold Interval

The falling threshold interval represents the interval between samples when the rising
threshold is crossed. Once the alarm crosses the falling threshold, the regular sampling
interval is used.
NOTE: You cannot configure the falling threshold interval for alarms that
have the request type set to walk-request.

To configure the falling threshold interval, include the falling-threshold interval statement
at the [edit snmp rmon alarm index] hierarchy level and specify the number of seconds:

seconds can be a value from 1 through 2,147,483,647. The default is 60 seconds.
Configuring the Request Type

By default an RMON alarm can monitor only one object instance (as specified in the
configuration). You can configure a request-type statement to extend the scope of the
RMON alarm to include all object instances belonging to a MIB branch or to include the
next object instance after the instance specified in the configuration.
To configure the request type, include the request-type statement at the [edit snmp rmon
alarm index] hierarchy level and specify get-next-request, get-request, or walk-request:

walk extends the RMON alarm configuration to all object instances belonging to a MIB
branch. next extends the RMON alarm configuration to include the next object instance
after the instance specified in the configuration.
Configuring the Sample Type

The sample type identifies the method of sampling the selected variable and calculating
the value to be compared against the thresholds. If the value of this object is
absolute-value, the value of the selected variable is compared directly with the thresholds
at the end of the sampling interval. If the value of this object is delta-value, the value of
the selected variable at the last sample is subtracted from the current value, and the
difference is compared with the thresholds.
To configure the sample type, include the sample-type statement and specify the type
of sample at the [edit snmp rmon alarm index] hierarchy level:

• absolute-value—Actual value of the selected variable is compared against the

thresholds.
• delta-value—Difference between samples of the selected variable is compared against

the thresholds.
Configuring the Startup Alarm

The startup alarm identifies the type of alarm that can be sent when this entry is first
activated. You can specify it as falling-alarm, rising-alarm, or rising-or-falling-alarm.
To configure the startup alarm, include the startup-alarm statement and specify the type
of alarm at the [edit snmp rmon alarm index] hierarchy level:

startup-alarm (falling-alarm | rising-alarm | rising-or-falling-alarm);

• falling-alarm—Generated if the first sample after the alarm entry becomes active is
less than or equal to the falling threshold.
• rising-alarm—Generated if the first sample after the alarm entry becomes active is
greater than or equal to the rising threshold.
• rising-or-falling-alarm—Generated if the first sample after the alarm entry becomes

active satisfies either of the corresponding thresholds.
The default is rising-or-falling-alarm.
Configuring the System Log Tag

The syslog-subtag statement specifies the tag to be added to the system log message.
You can specify a string of not more than 80 uppercase characters as the system log
tag.
To configure the system log tag, include the syslog-subtag statement at the [edit snmp
rmon alarm index] hierarchy level:

Configuring the Variable

The variable identifies the MIB object that is being monitored.
To configure the variable, include the variable statement and specify the object identifier
or object name at the [edit snmp rmon alarm index] hierarchy level:

oid-variable is a dotted decimal (for example, 1.3.6.1.2.1.2.1.2.2.1.10.1) or MIB object name

(for example, ifInOctets.1).
Configuring an RMON Event Entry and Its Attributes
An event entry generates a notification for an alarm entry when its rising or falling threshold
is crossed. You can configure the type of notification that is generated. To configure the
event entry, include the event statement at the [edit snmp rmon] hierarchy level. All
statements except the event statement are optional.
[edit snmp rmon]

event index {
type type;
}
index identifies an entry event.
community-name is the trap group that is used when generating a trap. If that trap group
has the rmon-alarm trap category configured, a trap is sent to all the targets configured
for that trap group. The community string in the trap matches the name of the trap group.

If nothing is configured, all the trap groups are examined, and traps are sent using each
group with the rmon-alarm category set.
description is a text string that identifies the entry.
The type variable of an event entry specifies where the event is to be logged. You can
specify the type as one of the following:
• log—Adds the event entry to the logTable.
• log-and-trap—Sends an SNMP trap and creates a log entry.
• none—Sends no notification.
• snmptrap—Sends an SNMP trap.
The default for the event entry type is log-and-trap.

Documentation
• Understanding RMON Alarms on page 239
• Example: Configuring an RMON Alarm and Event Entry on page 249
Example: Configuring an RMON Alarm and Event Entry
Configure an RMON alarm and event entry:
[edit snmp]
rmon {
alarm 100 {
description “input traffic on fxp0”;
falling-event-index 100;
interval 60;
rising-event-index 100;
sample-type delta-value;
startup-alarm rising-or-falling-alarm;
variable ifInOctets.1;
}
event 100 {
community bedrock;
description” emergency events”;
type log-and-trap;
}
}

Documentation


CHAPTER 14
Monitoring RMON Alarms and Events
• Using alarmTable to Monitor MIB Objects on page 251

• Using eventTable to Log Alarms on page 254
Using alarmTable to Monitor MIB Objects
Supported Platforms LN Series, M Series, MX Series, T Series
To use alarmTable to monitor a MIB object, perform the following tasks:
• Creating an Alarm Entry on page 251

• Configuring the Alarm MIB Objects on page 251
• Activating a New Row in alarmTable on page 254
• Modifying an Active Row in alarmTable on page 254
• Deactivating a Row in alarmTable on page 254
Creating an Alarm Entry

To create an alarm entry, first create a new row in alarmTable using the alarmStatus
object. For example, create alarm #1 using the UCD command-line utilities:
snmpset -Os -v2c router community alarmStatus.1 i createRequest
Configuring the Alarm MIB Objects

Once you have created the new row in alarmTable, configure the following Alarm MIB
objects:
NOTE: Other than alarmStatus, you cannot modify any of the objects in the
entry if the associated alarmStatus object is set to valid.
• alarmInterval on page 252

• alarmVariable on page 252
• alarmSampleType on page 252
• alarmValue on page 252
• alarmStartupAlarm on page 252

• alarmRisingThreshold on page 253

• alarmFallingThreshold on page 253
• alarmOwner on page 253
• alarmRisingEventIndex on page 253
• alarmFallingEventIndex on page 253
alarmInterval
The interval, in seconds, over which data is sampled and compared with the rising and
falling thresholds. For example, to set alarmInterval for alarm #1 to 30 seconds, use the
following SNMP Set request:
snmpset -Os -v2c router community alarmInterval.1 i 30
alarmVariable
The object identifier of the variable to be sampled. During a Set request, if the supplied
variable name is not available in the selected MIB view, a badValue error is returned. If at
any time the variable name of an established alarmEntry is no longer available in the
selected MIB view, the probe changes the status of alarmVariable to invalid. For example,
to identify ifInOctets.61 as the variable to be monitored, use the following SNMP Set
request:
snmpset -Os -v2c router community alarmVariable.1 o .1.3.6.1.2.1.2.2.1.10.61
alarmSampleType
The method of sampling the selected variable and calculating the value to be compared
against the thresholds. If the value of this object is absoluteValue, the value of the selected
variable is compared directly with the thresholds at the end of the sampling interval. If
the value of this object is deltaValue, the value of the selected variable at the last sample
is subtracted from the current value, and the difference is compared with the thresholds.
For example, to set alarmSampleType for alarm #1 to deltaValue, use the following SNMP
Set request:
snmpset -Os -v2c router community alarmSampleType.1 i deltaValue
alarmValue
The value of the variable during the last sampling period. This value is compared with
the rising and falling thresholds. If the sample type is deltaValue, this value equals the
difference between the samples at the beginning and end of the period. If the sample
type is absoluteValue, this value equals the sampled value at the end of the period.
alarmStartupAlarm
An alarm that is sent when this entry is first set to valid. If the first sample after this entry
becomes valid is greater than or equal to risingThreshold, and alarmStartupAlarm is equal
to risingAlarm or risingOrFallingAlarm, then a single rising alarm is generated. If the first
sample after this entry becomes valid is less than or equal to fallingThreshold and
alarmStartupAlarm is equal to fallingAlarm or risingOrFallingAlarm, then a single falling

Chapter 14: Monitoring RMON Alarms and Events
alarm is generated. For example, to set alarmStartupAlarm for alarm #1 to

risingOrFallingAlarm, use the following SNMP Set request:
snmpset -Os -v2c router community alarmStartupAlarm.1 i risingOrFallingAlarm
alarmRisingThreshold
A threshold for the sampled variable. When the current sampled value is greater than or
equal to this threshold, and the value at the last sampling interval is less than this
threshold, a single event is generated. A single event is also generated if the first sample
after this entry becomes valid is greater than or equal to this threshold, and the associated
alarmStartupAlarm is equal to risingAlarm or risingOrFallingAlarm. After a rising event is
generated, another rising event cannot be generated until the sampled value falls below
this threshold and reaches alarmFallingThreshold. For example, to set
alarmRisingThreshold for alarm #1 to 100000, use the following SNMP Set request:
snmpset -Os -v2c router community alarmRisingThreshold.1 i 100000
alarmFallingThreshold
A threshold for the sampled variable. When the current sampled value is less than or
equal to this threshold, and the value at the last sampling interval is greater than this
after this entry becomes valid is less than or equal to this threshold, and the associated
alarmStartupAlarm is equal to fallingAlarm or risingOrFallingAlarm. After a falling event
is generated, another falling event cannot be generated until the sampled value rises
above this threshold and reaches alarmRisingThreshold. For example, to set
alarmFallingThreshold for alarm #1 to 10000, use the following SNMP Set request:
snmpset -Os -v2c router community alarmFallingThreshold.1 i 10000
alarmOwner
Any text string specified by the creating management application or the command-line
interface (CLI). Typically, it is used to identify a network manager (or application) and
can be used for fine access control between participating management applications.
alarmRisingEventIndex
The index of the eventEntry object that is used when a rising threshold is crossed. If there
is no corresponding entry in eventTable, then no association exists. If this value is zero,
no associated event is generated because zero is not a valid event index. For example,
to set alarmRisingEventIndex for alarm #1 to 10, use the following SNMP Set request:
snmpset -Os -v2c router community alarmRisingEventIndex.1 i 10
alarmFallingEventIndex
The index of the eventEntry object that is used when a falling threshold is crossed. If there
is no corresponding entry in eventTable, then no association exists. If this value is zero,
no associated event is generated because zero is not a valid event index. For example,
to set alarmFallingEventIndex for alarm #1 to 10, use the following SNMP Set request:
snmpset -Os -v2c router community alarmFallingEventIndex.1 i 10

Activating a New Row in alarmTable

To activate a new row in alarmTable, set alarmStatus to valid using an SNMP Set request:
snmpset -Os -v2c router community alarmStatus.1 i valid
Modifying an Active Row in alarmTable

To modify an active row, first set alarmStatus to underCreation using an SNMP Set request:
snmpset -Os -v2c router community alarmStatus.1 i underCreation
Then change the row contents using an SNMP Set request:
snmpset -Os -v2c router community alarmFallingThreshold.1 i 1000
Finally, activate the row by setting alarmStatus to valid using an SNMP Set request:
snmpset -Os -v2c router community alarmStatus.1 i valid
Deactivating a Row in alarmTable

To deactivate a row in alarmTable, set alarmStatus to invalid using an SNMP Set request:
snmpset -Os -v2c router community alarmStatus.1 i invalid

Documentation
Using eventTable to Log Alarms
To use eventTable to log alarms, perform the following tasks:
• Creating an Event Entry on page 254

• Configuring the MIB Objects on page 255
• Activating a New Row in eventTable on page 256
• Deactivating a Row in eventTable on page 256
Creating an Event Entry

The RMON eventTable controls the generation of notifications from the router.
Notifications can be logs (entries to logTable and syslogs) or SNMP traps. Each event
entry can be configured to generate any combination of these notifications (or no
notification). When an event specifies that an SNMP trap is to be generated, the trap
group that is used when sending the trap is specified by the value of the associated
eventCommunity object. Consequently, the community in the trap message will match
the value specified by eventCommunity. If nothing is configured for eventCommunity, a
trap is sent using each trap group that has the rmon-alarm category configured.

Chapter 14: Monitoring RMON Alarms and Events
Configuring the MIB Objects

Once you have created the new row in eventTable, set the following objects:
NOTE: The eventType object is required. All other objects are optional.
• eventType on page 255

• eventCommunity on page 255
• eventOwner on page 255
• eventDescription on page 256
eventType
The type of notification that the router generates when the event is triggered.
This object can be set to the following values:
• log—Adds the event entry to logTable.
• log-and-trap—Sends an SNMP trap and creates a log entry.
• none—Sends no notification.
• snmptrap—Sends an SNMP trap.
For example, to set eventType for event #1 to log-and-trap, use the following SNMP Set
request:
snmpset -Os -v2c router community eventType.1 i log-and-trap
eventCommunity
The trap group that is used when generating a trap (if eventType is configured to send
traps). If that trap group has the rmon-alarm trap category configured, a trap is sent to
all the targets configured for that trap group. The community string in the trap matches
the name of the trap group (and hence, the value of eventCommunity). If nothing is
configured, traps are sent to each group with the rmon-alarm category set. For example,
to set eventCommunity for event #1 to boy-elroy, use the following SNMP Set request:
snmpset -Os -v2c router community eventCommunity.1 s "boy-elroy"
NOTE: The eventCommunity object is optional. If you do not set this object,
then the field is left blank.
eventOwner
interface (CLI). Typically, it is used to identify a network manager (or application) and
can be used for fine access control between participating management applications.

For example, to set eventOwner for event #1 to george jetson, use the following SNMP
Set request:
snmpset -Os -v2c router community eventOwner.1 s "george jetson"
NOTE: The eventOwner object is optional. If you do not set this object, then
the field is left blank.
eventDescription
interface (CLI). The use of this string is application dependent.
For example, to set eventDescription for event #1 to spacelys sprockets, use the following
SNMP Set request:
snmpset -Os -v2c router community eventDescription.1 s "spacelys sprockets"
NOTE: The eventDescription object is optional. If you do not set this object,
then the field is left blank.
Activating a New Row in eventTable

To activate the new row in eventTable, set eventStatus to valid using an SNMP Set request
such as:
snmpset -Os -v2c router community eventStatus.1 i valid
Deactivating a Row in eventTable

To deactivate a row in eventTable, set eventStatus to invalid using an SNMP Set request
such as:
snmpset -Os -v2c router community eventStatus.1 i invalid

Documentation

CHAPTER 15
Using RMON to Monitor Network Service

Quality
• Understanding RMON for Monitoring Service Quality on page 257

• Understanding Measurement Points, Key Performance Indicators, and Baseline
Values on page 261
• Defining and Measuring Network Availability on page 262
• Measuring Health on page 268
• Measuring Performance on page 274
Understanding RMON for Monitoring Service Quality
Health and performance monitoring can benefit from the remote monitoring of SNMP
variables by the local SNMP agents running on each router. The SNMP agents compare
MIB values against predefined thresholds and generate exception alarms without the
need for polling by a central SNMP management platform. This is an effective mechanism
for proactive management, as long as the thresholds have baselines determined and set
correctly. For more information, see RFC 2819, Remote Network Monitoring MIB.
• Setting Thresholds on page 257

• RMON Command-Line Interface on page 258
• RMON Event Table on page 259
• RMON Alarm Table on page 259
• Troubleshooting RMON on page 260
Setting Thresholds
By setting a rising and a falling threshold for a monitored variable, you can be alerted
whenever the value of the variable falls outside of the allowable operational range. (See
Figure 3 on page 258.)

Figure 3: Setting Thresholds
Events are only generated when the threshold is first crossed in any one direction rather
than after each sample period. For example, if a rising threshold crossing event is raised,
no more threshold crossing events will occur until a corresponding falling event. This
considerably reduces the quantity of alarms that are produced by the system, making it
easier for operations staff to react when alarms do occur.
To configure remote monitoring, specify the following pieces of information:
• The variable to be monitored (by its SNMP object identifier)
• The length of time between each inspection
• A rising threshold
• A falling threshold
• A rising event
• A falling event
Before you can successfully configure remote monitoring, you should identify what
variables need to be monitored and their allowable operational range. This requires some
period of baselining to determine the allowable operational ranges. An initial baseline
period of at least three months is not unusual when first identifying the operational ranges
and defining thresholds, but baseline monitoring should continue over the life span of
each monitored variable.
RMON Command-Line Interface

Junos OS provides two mechanisms you use to control the Remote Monitoring agent on
the router: command-line interface (CLI) and SNMP. To configure an RMON entry using
the CLI, include the following statements at the [edit snmp] hierarchy level:
rmon {
alarm index {
description;
falling-event-index;
falling-threshold;
intervals;
rising-event-index;

Chapter 15: Using RMON to Monitor Network Service Quality
rising-threshold;
startup-alarm (falling | rising | rising-or-falling);
variable;
}
event index {
community;
description;
type (log | trap | log-and-trap | none);
}
}
If you do not have CLI access, you can configure remote monitoring using the SNMP
Manager or management application, assuming SNMP access has been granted. (See
Table 25 on page 259.) To configure RMON using SNMP, perform SNMP Set requests to
the RMON event and alarm tables.
RMON Event Table

Set up an event for each type that you want to generate. For example, you could have
two generic events, rising and falling, or many different events for each variable that is
being monitored (for example, temperature rising event, temperature falling event, firewall
hit event, interface utilization event, and so on). Once the events have been configured,
you do not need to update them.
Table 25: RMON Event Table

Field Description
eventDescription Text description of this event
eventType Type of event (for example, log, trap, or log and trap)
eventCommunity Trap group to which to send this event (as defined in the Junos OS
configuration, which is not the same as the community)
eventOwner Entity (for example, manager) that created this event
eventStatus Status of this row (for example, valid, invalid, or createRequest)
RMON Alarm Table

The RMON alarm table stores the SNMP object identifiers (including their instances) of
the variables that are being monitored, together with any rising and falling thresholds
and their corresponding event indexes. To create an RMON request, specify the fields
shown in Table 26 on page 259.
Table 26: RMON Alarm Table

Field Description
alarmStatus Status of this row (for example, valid, invalid, or createRequest)

Table 26: RMON Alarm Table (continued)

Field Description
alarmInterval Sampling period (in seconds) of the monitored variable
alarmVariable OID (and instance) of the variable to be monitored
alarmValue Actual value of the sampled variable
alarmSampleType Sample type (absolute or delta changes)
alarmStartupAlarm Initial alarm (rising, falling, or either)
alarmRisingThreshold Rising threshold against which to compare the value
alarmFallingThreshold Falling threshold against which to compare the value
alarmRisingEventIndex Index (row) of the rising event in the event table
alarmFallingEventIndex Index (row) of the falling event in the event table
Both the alarmStatus and eventStatus fields are entryStatus primitives, as defined in RFC
2579, Textual Conventions for SMIv2.
Troubleshooting RMON
You troubleshoot the RMON agent, rmopd, that runs on the router by inspecting the
contents of the Juniper Networks enterprise RMON MIB, jnxRmon, which provides the
extensions listed in Table 27 on page 260 to the RFC 2819 alarmTable.
Table 27: jnxRmon Alarm Extensions

Field Description
jnxRmonAlarmGetFailCnt Number of times the internal Get request for the variable failed
jnxRmonAlarmGetFailTime Value of sysUpTime when the last failure occurred
jnxRmonAlarmGetFailReason Reason why the Get request failed
jnxRmonAlarmGetOkTime Value of sysUpTime when the variable moved out of failure state
jnxRmonAlarmState Status of this alarm entry
Monitoring the extensions in this table provides clues as to why remote alarms may not
behave as expected.
Related • Understanding Measurement Points, Key Performance Indicators, and Baseline Values
Documentation on page 261

Understanding Measurement Points, Key Performance Indicators, and Baseline Values
This chapter topic provides guidelines for monitoring the service quality of an IP network.
It describes how service providers and network administrators can use information
provided by Juniper Networks routers to monitor network performance and capacity. You
should have a thorough understanding of the SNMP and the associated MIB supported
by Junos OS.
NOTE: For a good introduction to the process of monitoring an IP network,

see RFC 2330, Framework for IP Performance Metrics.
• Measurement Points on page 261

• Basic Key Performance Indicators on page 262
• Setting Baselines on page 262
Measurement Points
Defining the measurement points where metrics are measured is equally as important
as defining the metrics themselves. This section describes measurement points within
the context of this chapter and helps identify where measurements can be taken from
a service provider network. It is important to understand exactly where a measurement
point is. Measurement points are vital to understanding the implication of what the actual
measurement means.
An IP network consists of a collection of routers connected by physical links that are all
running the Internet Protocol. You can view the network as a collection of routers with
an ingress (entry) point and an egress (exit) point. See Figure 4 on page 261.
• Network-centric measurements are taken at measurement points that most closely

map to the ingress and egress points for the network itself. For example, to measure
delay across the provider network from Site A to Site B, the measurement points should
be the ingress point to the provider network at Site A and the egress point at Site B.
• Router-centric measurements are taken directly from the routers themselves, but be
careful to ensure that the correct router subcomponents have been identified in
advance.
Figure 4: Network Entry Points

NOTE: Figure 4 on page 261 does not show the client networks at customer
premises, but they would be located on either side of the ingress and egress
points. Although this chapter does not discuss how to measure network
services as perceived by these client networks, you can use measurements
taken for the service provider network as input into such calculations.
Basic Key Performance Indicators

For example, you could monitor a service provider network for three basic key performance
indicators (KPIs):
• Availability measures the “reachability” of one measurement point from another

measurement point at the network layer (for example, using ICMP ping). The underlying
routing and transport infrastructure of the provider network will support the availability
measurements, with failures highlighted as unavailability.
• Health measures the number and type of errors that are occurring on the provider
network, and can consist of both router-centric and network-centric measurements,
such as hardware failures or packet loss.
• Performance of the provider network measures how well it can support IP services (for
example, in terms of delay or utilization).
Setting Baselines
How well is the provider network performing? We recommend an initial three-month
period of monitoring to identify a network’s normal operational parameters. With this
information, you can recognize exceptions and identify abnormal behavior. You should
continue baseline monitoring for the lifetime of each measured metric. Over time, you
must be able to recognize performance trends and growth patterns.
Within the context of this chapter, many of the metrics identified do not have an allowable
operational range associated with them. In most cases, you cannot identify the allowable
operational range until you have determined a baseline for the actual variable on a specific
network.
Related • Understanding RMON for Monitoring Service Quality on page 257

Documentation
Defining and Measuring Network Availability

• Defining Network Availability on page 263

• Measuring Availability on page 265
Defining Network Availability

Availability of a service provider’s IP network can be thought of as the reachability between
the regional points of presence (POP), as shown in Figure 5 on page 263.
Figure 5: Regional Points of Presence
With the example above, when you use a full mesh of measurement points, where every
POP measures the availability to every other POP, you can calculate the total availability
of the service provider’s network. This KPI can also be used to help monitor the service
level of the network, and can be used by the service provider and its customers to
determine if they are operating within the terms of their service-level agreement (SLA).
Where a POP may consist of multiple routers, take measurements to each router as
shown in Figure 6 on page 263.
Figure 6: Measurements to Each Router
Measurements include:

• Path availability—Availability of an egress interface B1 as seen from an ingress interface

A1.
• Router availability—Percentage of path availability of all measured paths terminating

on the router.
• POP availability—Percentage of router availability between any two regional POPs, A

and B.
• Network availability—Percentage of POP availability for all regional POPs in the service
provider’s network.
To measure POP availability of POP A to POP B in Figure 6 on page 263, you must measure
the following four paths:
Path A1 => B1
Path A1 => B2
Path A2 => B1
Path A2 => B2
Measuring availability from POP B to POP A would require a further four measurements,
and so on.
A full mesh of availability measurements can generate significant management traffic.

From the sample diagram above:
• Each POP has two co-located provider edge (PE) routers, each with 2xSTM1 interfaces,
for a total of 18 PE routers and 36xSTM1 interfaces.
• There are six core provider (P) routers, four with 2xSTM4 and 3xSTM1 interfaces each,
and two with 3xSTM4 and 3xSTM1 interfaces each.
This makes a total of 68 interfaces. A full mesh of paths between every interface is:
[n x (n–1)] / 2 gives [68 x (68–1)] / 2=2278 paths
To reduce management traffic on the service provider’s network, instead of generating

a full mesh of interface availability tests (for example, from each interface to every other
interface), you can measure from each router’s loopback address. This reduces the
number of availability measurements required to a total of one for each router, or:
[n x (n–1)] / 2 gives [24 x (24–1)] / 2=276 measurements
This measures availability from each router to every other router.
Monitoring the SLA and the Required Bandwidth

A typical SLA between a service provider and a customer might state:
A Point of Presence is the connection of two back-to-back provider edge routers to separate
core provider routers using different links for resilience. The system is considered to be
unavailable when either an entire POP becomes unavailable or for the duration of a
Priority 1 fault.
An SLA availability figure of 99.999 percent for a provider’s network would relate to a
down time of approximately 5 minutes per year. Therefore, to measure this proactively,

you would have to take availability measurements at a granularity of less than one every
five minutes. With a standard size of 64 bytes per ICMP ping request, one ping test per
minute would generate 7680 bytes of traffic per hour per destination, including ping
responses. A full mesh of ping tests to 276 destinations would generate 2,119,680 bytes
per hour, which represents the following:
• On an OC3/STM1 link of 155.52 Mbps, a utilization of 1.362 percent
• On an OC12/STM4 link of 622.08 Mbps, a utilization of 0.340 percent
With a size of 1500 bytes per ICMP ping request, one ping test per minute would generate
180,000 bytes per hour per destination, including ping responses. A full mesh of ping
tests to 276 destinations would generate 49,680,000 bytes per hour, which represents
the following:
• On an OC3/STM1 link, 31.94 percent utilization
• On an OC12/STM4 link, 7.986 percent utilization
Each router can record the results for every destination tested. With one test per minute
to each destination, a total of 1 x 60 x 24 x 276 = 397,440 tests per day would be
performed and recorded by each router. All ping results are stored in the
pingProbeHistoryTable (see RFC 2925) and can be retrieved by an SNMP performance
reporting application (for example, service performance management software from
InfoVista, Inc., or Concord Communications, Inc.) for post processing. This table has a
maximum size of 4,294,967,295 rows, which is more than adequate.
Measuring Availability
There are two methods you can use to measure availability:
• Proactive—Availability is automatically measured as often as possible by an operational

support system.
• Reactive—Availability is recorded by a Help desk when a fault is first reported by a user

or a fault monitoring system.
This section discusses real-time performance monitoring as a proactive monitoring

solution.
Real-Time Performance Monitoring
Juniper Networks provides a real-time performance monitoring (RPM) service to monitor

real-time network performance. Use the J-Web Quick Configuration feature to configure
real-time performance monitoring parameters used in real-time performance monitoring
tests. (J-Web Quick Configuration is a browser-based GUI that runs on Juniper Networks
routers. For more information, see the J-Web Interface User Guide.)
Configuring Real-Time Performance Monitoring
Some of the most common options you can configure for real-time performance
monitoring tests are shown in Table 28 on page 266.

Table 28: Real-Time Performance Monitoring Configuration Options

Field Description
Request Information
Probe Type Type of probe to send as part of the test. Probe types can be:
• http-get
• http-get-metadata
• icmp-ping
• icmp-ping-timestamp
• tcp-ping
• udp-ping
Interval Wait time (in seconds) between each probe transmission.

The range is 1 to 255 seconds.
Test Interval Wait time (in seconds) between tests. The range is 0 to
86400 seconds.
Probe Count Total number of probes sent for each test. The range is 1 to
15 probes.
Destination Port TCP or UDP port to which probes are sent. Use number 7—a
standard TCP or UDP port number—or select a port number
from 49152 through 65535.
DSCP Bits Differentiated Services code point (DSCP) bits. This value
must be a valid 6-bit pattern. The default is 000000.
Data Size Size (in bytes) of the data portion of the ICMP probes. The
range is 0 to 65507 bytes.
Data Fill Contents of the data portion of the ICMP probes. Contents
must be a hexadecimal value. The range is 1 to 800h.
Maximum Probe Thresholds

Successive Lost Probes Total number of probes that must be lost successively to
trigger a probe failure and generate a system log message.
The range is 0 to 15 probes.
Lost Probes Total number of probes that must be lost to trigger a probe
failure and generate a system log message. The range is 0 to
15 probes.
Round Trip Time Total round-trip time (in microseconds) from the Services
Router to the remote server, which, if exceeded, triggers a
probe failure and generates a system log message. The range
is 0 to 60,000,000 microseconds.
Jitter Total jitter (in microseconds) for a test, which, if exceeded,

triggers a probe failure and generates a system log message.
The range is 0 to 60,000,000 microseconds.

Table 28: Real-Time Performance Monitoring Configuration

Options (continued)
Field Description
Standard Deviation Maximum allowable standard deviation (in microseconds)

for a test, which, if exceeded, triggers a probe failure and
generates a system log message. The range is 0 to
60,000,000 microseconds.
Egress Time Total one-way time (in microseconds) from the router to the
remote server, which, if exceeded, triggers a probe failure and
Ingress Time Total one-way time (in microseconds) from the remote server
to the router, which, if exceeded, triggers a probe failure and
Jitter Egress Time Total outbound-time jitter (in microseconds) for a test, which,
if exceeded, triggers a probe failure and generates a system
log message. The range is 0 to 60,000,000 microseconds.
Jitter Ingress Time Total inbound-time jitter (in microseconds) for a test, which,
if exceeded, triggers a probe failure and generates a system
log message. The range is 0 to 60,000,000 microseconds.
Egress Standard Deviation Maximum allowable standard deviation of outbound times

(in microseconds) for a test, which, if exceeded, triggers a
probe failure and generates a system log message. The range
is 0 to 60,000,000 microseconds.
Ingress Standard Deviation Maximum allowable standard deviation of inbound times (in
microseconds) for a test, which, if exceeded, triggers a probe
failure and generates a system log message. The range is 0
to 60,000,000 microseconds.
Displaying Real-Time Performance Monitoring Information
For each real-time performance monitoring test configured on the router, monitoring
information includes the round-trip time, jitter, and standard deviation. To view this
information, select Monitor > RPM in the J-Web interface, or enter the show services rpm
command-line interface (CLI) command.
To display the results of the most recent real-time performance monitoring probes, enter
the show services rpm probe-results CLI command:
user@host> show services rpm probe-results

Owner: p1, Test: t1
Target address: 10.8.4.1, Source address: 10.8.4.2, Probe type: icmp-ping
Destination interface name: lt-0/0/0.0
Test size: 10 probes
Probe results:
Response received, Sun Jul 10 19:07:34 2005
Rtt: 50302 usec
Results over current test:

Probes sent: 2, Probes received: 1, Loss percentage: 50

Measurement: Round trip time
Minimum: 50302 usec, Maximum: 50302 usec, Average: 50302 usec,
Jitter: 0 usec, Stddev: 0 usec
Results over all tests:
Measuring Health
Supported Platforms LN Series, M Series, MX Series, T Series
You can monitor health metrics reactively by using fault management software such as
SMARTS InCharge, Micromuse Netcool Omnibus, or Concord Live Exceptions. We
recommend that you monitor the health metrics shown in Table 29 on page 268.
Table 29: Health Metrics
Metric: Errors in
Description Number of inbound packets that contained errors, preventing them

from being delivered
MIB name IF-MIB (RFC 2233)
Variable name ifInErrors
Variable OID .1.3.6.1.31.2.2.1.14
Frequency (mins) 60
Allowable range To be baselined
Managed objects Logical interfaces
Metric: Errors out
Description Number of outbound packets that contained errors, preventing

them from being transmitted

Table 29: Health Metrics (continued)

Variable name ifOutErrors
Variable OID .1.3.6.1.31.2.2.1.20
Frequency (mins) 60
Metric: Discards in
Description Number of inbound packets discarded, even though no errors were

detected
Variable name ifInDiscards
Variable OID .1.3.6.1.31.2.2.1.13
Frequency (mins) 60
Metric: Unknown protocols
Description Number of inbound packets discarded because they were of an

unknown protocol
Variable name ifInUnknownProtos
Variable OID .1.3.6.1.31.2.2.1.15
Frequency (mins) 60
Metric: Interface operating status
Description Operational status of an interface


Variable name ifOperStatus
Variable OID .1.3.6.1.31.2.2.1.8
Frequency (mins) 15
Allowable range 1 (up)
Metric: Label Switched Path (LSP) state
Description Operational state of an MPLS label-switched path
MIB name MPLS-MIB
Variable name mplsLspState
Variable OID mplsLspEntry.2
Frequency (mins) 60
Allowable range 2 (up)
Managed objects All label-switched paths in the network
Metric: Component operating status
Description Operational status of a router hardware component
MIB name JUNIPER-MIB
Variable name jnxOperatingState
Variable OID .1.3.6.1.4.1.2636.1.13.1.6
Frequency (mins) 60
Allowable range 2 (running) or 3 (ready)
Managed objects All components in each Juniper Networks router
Metric: Component operating temperature
Description Operational temperature of a hardware component, in Celsius
Variable name jnxOperatingTemp


Variable OID .1.3.6.1.4.1.2636.1.13.1.7
Frequency (mins) 60
Managed objects All components in a chassis
Metric: System up time
Description Time, in milliseconds, that the system has been operational.
MIB name MIB-2 (RFC 1213)
Variable name sysUpTime
Variable OID .1.3.6.1.1.3
Frequency (mins) 60
Allowable range Increasing only (decrement indicates a restart)
Managed objects All routers
Metric: No IP route errors
Description Number of packets that could not be delivered because there was
no IP route to their destination.
Variable name ipOutNoRoutes
Variable OID ip.12
Frequency (mins) 60
Managed objects Each router
Metric: Wrong SNMP community names
Description Number of incorrect SNMP community names received
Variable name snmpInBadCommunityNames


Variable OID snmp.4
Frequency (hours) 24
Metric: SNMP community violations
Description Number of valid SNMP communities used to attempt invalid

operations (for example, attempting to perform SNMP Set requests)
Variable name snmpInBadCommunityUses
Variable OID snmp.5
Frequency (hours) 24
Metric: Redundancy switchover
Description Total number of redundancy switchovers reported by this entity
Variable name jnxRedundancySwitchoverCount
Variable OID jnxRedundancyEntry.8
Frequency (mins) 60
Managed objects All Juniper Networks routers with redundant Routing Engines
Metric: FRU state
Description Operational status of each field-replaceable unit (FRU)
Variable name jnxFruState


Variable OID jnxFruEntry.8
Frequency (mins) 15
Allowable range 2 through 6 for ready/online states. See jnxFruOfflineReason in the

event of a FRU failure.
Managed objects All FRUs in all Juniper Networks routers.
Metric: Rate of tail-dropped packets
Description Rate of tail-dropped packets per output queue, per forwarding class,
per interface.
MIB name JUNIPER-COS-MIB
Variable name jnxCosIfqTailDropPktRate
Variable OID jnxCosIfqStatsEntry.12
Frequency (mins) 60
Managed objects For each forwarding class per interface in the provider network,
when CoS is enabled.
Metric: Interface utilization: octets received
Description Total number of octets received on the interface, including framing

characters.
MIB name IF-MIB
Variable name ifInOctets
Variable OID .1.3.6.1.2.1.2.2.1.10.x
Frequency (mins) 60
Managed objects All operational interfaces in the network
Metric: Interface utilization: octets transmitted
Description Total number of octets transmitted out of the interface, including

framing characters.
MIB name IF-MIB


Variable name ifOutOctets
Variable OID .1.3.6.1.2.1.2.2.1.16.x
Frequency (mins) 60
NOTE: Byte counts vary depending on interface type, encapsulation used

and PIC supported. For example, with vlan-ccc encapsulation on a 4xFE, GE,
or GE 1Q PIC, the byte count includes framing and control word overhead.
(See Table 30 on page 274.)
Table 30: Counter Values for vlan-ccc Encapsulation

input (Unit
PIC Type Encapsulation Level) Output (Unit Level) SNMP
4xFE vlan-ccc Frame (no frame Frame (including FCS and ifInOctets,
check sequence control word) ifOutOctets
[FCS])
GE vlan-ccc Frame (no FCS) Frame (including FCS and ifInOctets,

control word) ifOutOctets
GE IQ vlan-ccc Frame (no FCS) Frame (including FCS and ifInOctets,

control word) ifOutOctets
SNMP traps are also a good mechanism to use for health management. For more
information, see ““Standard SNMP Traps Supported by Junos OS” on page 57” and
““Enterprise-Specific SNMP Traps Supported by Junos OS” on page 64.”
• SNMB MIB Explorer
Measuring Performance

The performance of a service provider’s network is usually defined as how well it can
support services, and is measured with metrics such as delay and utilization. We suggest
that you monitor the following performance metrics using applications such as InfoVista
Service Performance Management or Concord Network Health (see Table 31 on page 275).
Table 31: Performance Metrics
Metric: Average delay
Description Average round-trip time (in milliseconds) between two

measurement points.
MIB name DISMAN-PING-MIB (RFC 2925)
Variable name pingResultsAverageRtt
Variable OID pingResultsEntry.6
Frequency (mins) 15 (or depending upon ping test frequency)
Managed objects Each measured path in the network
Metric: Interface utilization
Description Utilization percentage of a logical connection.
MIB name IF-MIB
Variable name (ifInOctets & ifOutOctets) * 8 / ifSpeed
Variable OID ifTable entries
Frequency (mins) 60
Metric: Disk utilization
Description Utilization of disk space within the Juniper Networks router
MIB name HOST-RESOURCES-MIB (RFC 2790)
Variable name hrStorageSize – hrStorageUsed
Variable OID hrStorageEntry.5 – hrStorageEntry.6
Frequency (mins) 1440

Table 31: Performance Metrics (continued)

Managed objects All Routing Engine hard disks
Metric: Memory utilization
Description Utilization of memory on the Routing Engine and FPC.
MIB name JUNIPER-MIB (Juniper Networks enterprise Chassis MIB)
Variable name jnxOperatingHeap
Variable OID Table for each component
Frequency (mins) 60
Managed objects All Juniper Networks routers
Metric: CPU load
Description Average utilization over the past minute of a CPU.
MIB name JUNIPER-MIB (Juniper Networks enterprise Chassis MIB)
Variable name jnxOperatingCPU
Variable OID Table for each component
Frequency (mins) 60
Managed objects All Juniper Networks routers
Metric: LSP utilization
Description Utilization of the MPLS label-switched path.
MIB name MPLS-MIB
Variable name mplsPathBandwidth / (mplsLspOctets * 8)
Variable OID mplsLspEntry.21 and mplsLspEntry.3
Frequency (mins) 60

Table 31: Performance Metrics (continued)

Managed objects All label-switched paths in the network
Metric: Output queue size
Description Size, in packets, of each output queue per forwarding class, per
interface.
MIB name JUNIPER-COS-MIB
Variable name jnxCosIfqQedPkts
Variable OID jnxCosIfqStatsEntry.3
Frequency (mins) 60
Managed objects For each forwarding class per interface in the network, once CoS is
enabled.
• Measuring Class of Service on page 277

• Inbound Firewall Filter Counters per Class on page 278
• Monitoring Output Bytes per Queue on page 279
• Dropped Traffic on page 280
Measuring Class of Service

You can use class-of-service (CoS) mechanisms to regulate how certain classes of
packets are handled within your network during times of peak congestion. Typically you
must perform the following steps when implementing a CoS mechanism:
• Identify the type of packets that is applied to this class. For example, include all
customer traffic from a specific ingress edge interface within one class, or include all
packets of a particular protocol such as voice over IP (VoIP).
• Identify the required deterministic behavior for each class. For example, if VoIP is
important, give VoIP traffic the highest priority during times of network congestion.
Conversely, you can downgrade the importance of Web traffic during congestion, as
it may not impact customers too much.
With this information, you can configure mechanisms at the network ingress to monitor,
mark, and police traffic classes. Marked traffic can then be handled in a more deterministic
way at egress interfaces, typically by applying different queuing mechanisms for each
class during times of network congestion. You can collect information from the network
to provide customers with reports showing how the network is behaving during times of
congestion. (See Figure 7 on page 278.)

Figure 7: Network Behavior During Congestion
To generate these reports, routers must provide the following information:
• Submitted traffic—Amount of traffic received per class.
• Delivered traffic—Amount of traffic transmitted per class.
• Dropped traffic—Amount of traffic dropped because of CoS limits.
The following section outlines how this information is provided by Juniper Networks
routers.
Inbound Firewall Filter Counters per Class

Firewall filter counters are a very flexible mechanism you can use to match and count
inbound traffic per class, per interface. For example:
firewall {
filter f1 {
term t1 {
from {
dscp af11;
}
then {
# Assured forwarding class 1 drop profile 1 count inbound-af11;
accept;
}
}
}
}
For example, Table 32 on page 278 shows additional filters used to match the other classes.
Table 32: Inbound Traffic Per Class

DSCP Value Firewall Match Condition Description
10 af11 Assured forwarding class 1 drop profile 1
12 af12 Assured forwarding class 1 drop profile 2

Table 32: Inbound Traffic Per Class (continued)

DSCP Value Firewall Match Condition Description
18 af21 Best effort class 2 drop profile 1
Any packet with a CoS DiffServ code point (DSCP) conforming to RFC 2474 can be
counted in this way. The Juniper Networks enterprise-specific Firewall Filter MIB presents
the counter information in the variables shown in Table 33 on page 279.
Table 33: Inbound Counters

Indicator Name Inbound Counters
MIB jnxFirewalls
Table jnxFirewallCounterTable
Index jnxFWFilter.jnxFWCounter
Variables jnxFWCounterPacketCount
jnxFWCounterByteCount
Description Number of bytes being counted pertaining to the specified firewall filter
counter
SNMP version SNMPv2
This information can be collected by any SNMP management application that supports
SNMPv2. Products from vendors such as Concord Communications, Inc., and InfoVista,
Inc., provide support for the Juniper Networks Firewall MIB with their native Juniper
Networks device drivers.
Monitoring Output Bytes per Queue

You can use the Juniper Networks enterprise ATM CoS MIB to monitor outbound traffic,
per virtual circuit forwarding class, per interface. (See Table 34 on page 279.)
Table 34: Outbound Counters for ATM Interfaces

Indicator Name Outbound Counters
MIB JUNIPER-ATM-COS-MIB
Variable jnxCosAtmVcQstatsOutBytes
Index ifIndex.atmVclVpi.atmVclVci.jnxCosFcId

Table 34: Outbound Counters for ATM Interfaces (continued)

Description Number of bytes belonging to the specified forwarding class that were
transmitted on the specified virtual circuit.
SNMP version SNMPv2
Non-ATM interface counters are provided by the Juniper Networks enterprise-specific

CoS MIB, which provides information shown in Table 35 on page 280.
Table 35: Outbound Counters for Non-ATM Interfaces

MIB JUNIPER-COS-MIB
Table jnxCosIfqStatsTable
Index jnxCosIfqIfIndex.jnxCosIfqFc
Variables jnxCosIfqTxedBytes
jnxCosIfqTxedPkts
Description Number of transmitted bytes or packets per interface per forwarding

class
SNMP version SNMPv2
Dropped Traffic
You can calculate the amount of dropped traffic by subtracting the outbound traffic from
the incoming traffic:
Dropped = Inbound Counter – Outbound Counter
You can also select counters from the CoS MIB, as shown in Table 36 on page 280.
Table 36: Dropped Traffic Counters

Indicator Name Dropped Traffic
MIB JUNIPER-COS-MIB
Table jnxCosIfqStatsTable
Index jnxCosIfqIfIndex.jnxCosIfqFc
Variables jnxCosIfqTailDropPkts
jnxCosIfqTotalRedDropPkts

Table 36: Dropped Traffic Counters (continued)

Indicator Name Dropped Traffic
Description The number of tail-dropped or RED-dropped packets per interface per

forwarding class
SNMP version SNMPv2


PART 4
Health Monitoring with SNMP

• Configuring Health Monitoring on page 285


CHAPTER 16
Configuring Health Monitoring
• Configuring Health Monitoring on Devices Running Junos OS on page 285

• Example: Configuring Health Monitoring on page 288
Configuring Health Monitoring on Devices Running Junos OS
As the number of devices managed by a typical network management system (NMS)

grows and the complexity of the devices themselves increases, it becomes increasingly
impractical for the NMS to use polling to monitor the devices. A more scalable approach
is to rely on network devices to notify the NMS when something requires attention.
On Juniper Networks routers, RMON alarms and events provide much of the infrastructure
needed to reduce the polling overhead from the NMS. However, with this approach, 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. In
addition, some MIB object instances that need monitoring are set only at initialization or
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 (for file system
usage, CPU usage, and memory usage) and includes support for unknown or dynamic
object instances (such as Junos OS processes).
Health monitoring is designed to minimize user configuration requirements. To configure

health monitoring entries, include the health-monitor statement at the [edit snmp]
hierarchy level:
[edit snmp]
health-monitor {
falling-threshold percentage;
interval seconds;
rising-threshold percentage;
idp {
interval seconds;
}
}

Configuring monitoring events at the [edit snmp health-monitor] hierarchy level sets
polling intervals for the overall system health. If you set these same options at the [edit
snmp health-monitor idp] hierarchy level, an SNMP event is generated by the device if
the percentage of dataplane memory utilized by the intrusion detection and prevention
(IDP) system rises above or falls below your settings.
You can use the show snmp health-monitor operational command to view information
about health monitor alarms and logs.
This topic describes the minimum required configuration and discusses the following
tasks for configuring the health monitor:
• Monitored Objects on page 286

• Minimum Health Monitoring Configuration on page 287
• Log Entries and Traps on page 288
Monitored Objects
When you configure the health monitor, monitoring information for certain object instances
is available, as shown in Table 37 on page 286.
Table 37: Monitored Object Instances

Object Description
n
jxHrStoragePercentUsed1. Monitors the following file system on the router or switch:
/dev/ad0s1a:
This is the root file system mounted on /.
n
jxHrStoragePercentUsed2
. Monitors the following file system on the router or switch:
/dev/ad0s1e:
This is the configuration file system mounted on /config.
jnxOperatingCPU Monitors CPU usage for Routing Engines (RE0 and RE1). The index values assigned
(RE0) to Routing Engines depend on whether the Chassis MIB uses a zero-based or
ones-based indexing scheme. Because the indexing scheme is configurable, the
proper index is determined when the router or switch is initialized and when there
jnxOperatingCPU
is a configuration change. If the router or switch has only one Routing Engine, the
(RE1)
alarm entry monitoring RE1 is removed after five failed attempts to obtain the CPU
value.
jnxOperatingBuffer Monitors the amount of memory available on Routing Engines (RE0 and RE1).
(RE0) 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
jnxOperatingBuffer
router or switch has only one Routing Engine.
(RE1)

Chapter 16: Configuring Health Monitoring
Table 37: Monitored Object Instances (continued)

Object Description
sysApplElmtRunCPU Monitors the CPU usage for each Junos OS process (also called daemon). Multiple
instances of the same process are monitored and indexed separately.
sysAppE
lm
l tRunMemory Monitors the memory usage for each Junos OS process. Multiple instances of the
same process are monitored and indexed separately.
Minimum Health Monitoring Configuration

To enable health monitoring on the router or switch, include the health-monitor statement
at the [edit snmp] hierarchy level:
[edit snmp]
health-monitor;
Configuring the Falling Threshold or Rising Threshold

The falling threshold is the lower threshold (expressed as a percentage of the maximum
possible value) for the monitored variable. When the current sampled value is less than
or equal to this threshold, and the value at the last sampling interval is greater than this
after this entry becomes valid is less than or equal to this threshold. After a falling event
is generated, another falling event cannot be generated until the sampled value rises
above this threshold and reaches the rising threshold. You must specify the falling
threshold as a percentage of the maximum possible value. The default is 70 percent.
By default, the rising threshold is 80 percent of the maximum possible value for the
monitored object instance. The rising threshold is the upper threshold for the monitored
variable. When the current sampled value is greater than or equal to this threshold, and
the value at the last sampling interval is less than this threshold, a single event is
generated. A single event is also generated if the first sample after this entry becomes
valid is greater than or equal to this threshold. After a rising event is generated, another
rising event cannot be generated until the sampled value falls below this threshold and
reaches the falling threshold. You must specify the rising threshold as a percentage of
the maximum possible value for the monitored variable.
To configure the falling threshold or rising threshold, include the falling-threshold or

rising-threshold statement at the [edit snmp health-monitor] hierarchy level:
[edit snmp health-monitor]

percentage can be a value from 1 through 100.
The falling and rising thresholds apply to all object instances monitored by the health
monitor.


The interval represents the period of time, in seconds, over which the object instance is
sampled and compared with the rising and falling thresholds.
To configure the interval, include the interval statement and specify the number of seconds
at the [edit snmp health-monitor] hierarchy level:
[edit snmp health-monitor]

interval seconds;
seconds can be a value from 1 through 2147483647. The default is 300 seconds
(5 minutes).
Log Entries and Traps

The system log entries generated for any health monitor events (thresholds crossed,
errors, and so on) have a corresponding HEALTHMONITOR tag rather than a generic
SNMPD_RMON_EVENTLOG tag. However, the health monitor sends generic RMON
risingThreshold and fallingThreshold traps.

Documentation
• Example: Configuring Health Monitoring on page 288
• Understanding Device Management Functions in Junos OS
• health-monitor on page 667
Example: Configuring Health Monitoring
Configure the health monitor:
[edit snmp]
health-monitor {
interval 600;
}
In this example, the sampling interval is every 600 seconds (10 minutes), the falling
threshold is 85 percent of the maximum possible value for each object instance monitored,
and the rising threshold is 75 percent of the maximum possible value for each object
instance monitored.
Related • Configuring Health Monitoring on Devices Running Junos OS on page 285

Documentation

PART 5
Gathering Statistics for Accounting

Purposes Using Accounting Options,
Source Class Usage and Destination Class
Usage Options
• Accounting Options, Source Class Usage and Destination Class Usage Options
Overview on page 291
• Configuring Accounting Options, Source Class Usage and Destination Class Usage
Options on page 295


CHAPTER 17
Accounting Options, Source Class Usage

and Destination Class Usage Options
Overview
• Accounting Options Overview on page 291

• Understanding Source Class Usage and Destination Class Usage Options on page 292
Accounting Options Overview
An accounting profile represents common characteristics of collected accounting data,

including the following:
• Collection interval
• File to contain accounting data
• Specific fields and counter names on which to collect statistics
You can configure multiple accounting profiles, as described in Table 38 on page 291.
Table 38: Types of Accounting Profiles

Type of Profile Description
Interface profile Collects the specified error and statistic information.
Filter profile Collects the byte and packet counts for the counter names
specified in the filter profile.
MIB profile Collects selected MIB statistics and logs them to a specified
file.
Routing Engine profile Collects selected Routing Engine statistics and logs them to
a specified file.
Class usage profile Collects class usage statistics and logs them to a specified
file.

Related • Understanding Device Management Functions in Junos OS on page 3

Documentation
• Accounting Options Configuration
• Configuring Accounting-Data Log Files on page 304
• Configuring the Interface Profile
• Configuring the Filter Profile on page 312
• Configuration Statements at the [edit accounting-options] Hierarchy Level on page 295
Understanding Source Class Usage and Destination Class Usage Options
You can maintain packet counts based on the entry and exit points for traffic passing
through your network. Entry and exit points are identified by source and destination
prefixes grouped into disjoint sets defined as source classes and destination classes. You
can define classes based on a variety of parameters, such as routing neighbors,
autonomous systems, and route filters.
Source class usage (SCU) counts packets sent to customers by performing lookups on
the IP source address and the IP destination address. SCU makes it possible to track
traffic originating from specific prefixes on the provider core and destined for specific
prefixes on the customer edge. You must enable SCU accounting on both the inbound
and outbound physical interfaces.
Destination class usage (DCU) counts packets from customers by performing lookups
of the IP destination address. DCU makes it possible to track traffic originating from the
customer edge and destined for specific prefixes on the provider core router.
On T Series Core Routers and M320 Multiservice Edge Routers, the source class and
destination classes are not carried across the platform fabric. The implications of this
are as follows:
• On T Series and M320 routers, SCU and DCU accounting is performed before the packet
enters the fabric.
• On T Series and M320 routers, DCU is performed before output filters are evaluated.
• On M Series platforms, DCU is performed after output filters are evaluated.
• If an output filter drops traffic on M Series devices, the dropped packets are excluded
from DCU statistics.
• If an output filter drops traffic on T Series and M320 routers, the dropped packets are
included in DCU statistics.
NOTE: SCU and DCU is supported on PTX series routers when enhanced-mode
is configured on the chassis.

Chapter 17: Accounting Options, Source Class Usage and Destination Class Usage Options Overview
On MX Series platforms with MPC/MIC interfaces, SCU and DCU are performed after
output filters are evaluated. Packets dropped by output filters are not included in SCU
or DCU statistics.
On MX Series platforms with non-MPC/MIC interfaces, SCU and DCU are performed
before output filters are evaluated. Packets dropped by output filters are included in SCU
and DCU statistics.
On PTX Series platforms, SCU and DCU accounting is performed before output filters
are evaluated. Packets dropped by output filters are included in SCU and DCU statistics.
On Enhanced Scaling FPCs (T640-FPC1-ES, T640-FPC2-ES, T640-FPC3-ES,

T640-FPC4-1P-ES , and T1600-FPC4-ES), the source class accounting is performed at
ingress. Starting with Junos OS Release 14.2, the SCU accounting is performed at ingress
on a T4000 Type 5 FPC. The implications of this are as follows:
• SCU accounting is performed when packets traverse from T4000 Type 5 FPC (ingress
FPC) to Enhanced Scaling FPCs (egress FPC).
• SCU accounting is performed when packets traverse from Enhanced Scaling FPCs
(ingress FPC) to T4000 Type 5 FPC (egress FPC).
NOTE: When the interface statistics are cleared and then the routing engine
is replaced, the SCU and DCU statistics will not match the statistics of the
previous routing engine.
For more information about source class usage, see the Routing Policies, Firewall Filters,
and Traffic Policers Feature Guide, the Junos OS Network Interfaces Library for Routing
Devices, and the Junos OS, Release 15.1.
Related • Example: Grouping Source and Destination Prefixes into a Forwarding Class
Documentation
• Configuring SCU or DCU on page 316
• Configuring SCU on a Virtual Loopback Tunnel Interface on page 318
• Configuring Class Usage Profiles on page 319
• Configuring the MIB Profile on page 322
• Configuring the Routing Engine Profile on page 324


CHAPTER 18
Configuring Accounting Options, Source

Class Usage and Destination Class Usage
Options

• Accounting Options Configuration on page 296
• Configuring the Interface Profile on page 309
• Example: Configuring a Filter Profile on page 313
• Example: Configuring Interface-Specific Firewall Counters and Filter Profiles on page 314
Configuration Statements at the [edit accounting-options] Hierarchy Level
Supported Platforms LN Series, M Series, MX Series, SRX Series, T Series
This topic shows all possible configuration statements at the [edit accounting-options]
hierarchy level and their level in the configuration hierarchy. When you are configuring
Junos OS, your current hierarchy level is shown in the banner on the line preceding the
user@host# prompt.
[edit]
accounting-options {
class-usage-profile profile-name {
file filename;
interval minutes;
destination-classes {
destination-class-name;
}
source-classes {

source-class-name;
}
}
file filename {
archive-sites {
}
files number;
nonpersistent;
size bytes;
start-time time;
transfer-interval minutes;
}
filter-profile profile-name {
counters {
counter-name;
}
file filename;
interval minutes;
}
}
interface-profile profile-name {
fields {
field-name;
}
file filename;
interval minutes;
}
mib-profile profile-name {
file filename;
interval seconds;
object-names {
mib-object-name;
}
operation operation-name;
}
routing-engine-profile profile-name {
fields {
field-name;
}
file filename;
interval minutes;
}
Related • Accounting Options Overview on page 291

Documentation
Accounting Options Configuration

Chapter 18: Configuring Accounting Options, Source Class Usage and Destination Class Usage Options
• Accounting Options—Full Configuration on page 297

• Minimum Accounting Options Configuration on page 300
Accounting Options—Full Configuration

To configure accounting options, include the following statements at the [edit
accounting-options] hierarchy level:
file filename;
interval minutes;
}
source-classes {
source-class-name;
}
file filename {
archive-sites {
site-name;
}
files number;
nonpersistent;
size bytes;
source-classes time;
}
counters {
counter-name;
}
file filename;
interval minutes;
}
}
flat-file-profile profile-name{
fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;

descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
input-mcast-packets;
}
fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;

}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
}
overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;
output-errors;
output-packets;
outputv6-bytes;
outputv6-packets;
}
}
file filename;
format (csv | ipdr)
interval minutes;
schema-version schema-name;
}
fields {
field-name;
}
file filename;
interval minutes;
}
file filename;

interval seconds;
object-names {
mib-object-name;
}
}
fields {
field-name;
}
file filename;
interval minutes;
}
}
}
By default, accounting options are disabled.
NOTE: Do not configure MIB objects related to interface octets or packets

for a MIB profile, because doing so can cause the SNMP walk or a CLI show
command to time out.
Minimum Accounting Options Configuration

To enable accounting options on the router, you must perform at least the following
tasks:
• Configure accounting options by including a file statement and one or more

source-class-usage, destination-class-profile, filter-profile, interface-profile, mib-profile,
or routing-engine-profile statements at the [edit accounting-options] hierarchy level:
[edit]
file filename;
interval minutes;
source-classes {
source-class-name;
}
}
file filename {
archive-sites {
site-name;
}
files number;
size bytes;
}
counters {
counter-name;
}

file filename;
interval minutes;
}
fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
}
overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;
output-errors;
output-packets;
outputv6-bytes;
outputv6-packets;

}
}
file filename;
format (csv | ipdr)
interval minutes;
}
fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
}
overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;

output-errors;
output-packets;
outputv6-bytes;
outputv6-packets;
}
}
file filename;
format (csv | ipdr)
interval minutes;
}
fields {
field-name;
}
file filename;
interval minutes;
}
file filename;
interval minutes;
object-names {
mib-object-name;
}
}
fields {
field-name;
}
file filename;
interval minutes;
}
}
}
• Apply the profiles to the chosen interfaces or filters.
Apply an interface profile to a physical or logical interface by including the

accounting-profile statement at either the [edit interfaces interface-name] or the [edit
interfaces interface-name unit logical-unit-number] hierarchy level.
[edit interfaces]
interface-name {
accounting-profile profile-name;
unit logical-unit-number {
}
}
NOTE: You do not apply destination class profiles to interfaces. Although

the interface needs to have the destination-class-usage statement
configured, the destination class profile automatically finds all interfaces
with the destination class configured.

Apply a filter profile to a firewall filter by including the accounting-profile statement at

the [edit firewall filter filter-name] hierarchy level:
[edit firewall]
filter filter-name {
}
You do not need to apply the Routing Engine profile to an interface because the
statistics are collected on the Routing Engine itself.

Documentation
Configuring Accounting-Data Log Files
An accounting profile specifies what statistics to collect and write to a log file. To configure
an accounting-data log file, include the file statement at the [edit accounting-options]
hierarchy level:
[edit accounting-options]
cleanup-interval {
interval days;
}
file filename {
archive-sites {
site-name;
}
backup-on-failure (master-and-slave | master-only);
files number;
nonpersistent;
push-backup-to-master;
size bytes;
start-time time;
}
where filename is the name of the file in which to write accounting data.
If the filename contains spaces, enclose it in quotation marks (" "). The filename cannot
contain a forward slash (/). The file is created in the /var/log directory and can contain
data from multiple profiles.

All accounting-data log files include header and trailer sections that start with a # in the
first column. The header contains the file creation time, the hostname, and the columns
that appear in the file. The trailer contains the time that the file was closed.
Whenever any configured value changes that affects the columns in a file, the file creates
a new profile layout record that contains a new list of columns.
You must configure the file size; all other properties are optional.
• Configuring How Long Backup Files Are Retained on page 305

• Configuring the Maximum Size of the File on page 305
• Configuring Archive Sites for the Files on page 306
• Configuring Local Backup for Accounting Files on page 306
• Configuring Files to Be Compressed on page 307
• Configuring the Maximum Number of Files on page 307
• Configuring the Storage Location of the File on page 307
• Configuring Files to Be Saved After a Change in Mastership on page 308
• Configuring the Start Time for File Transfer on page 308
• Configuring the Transfer Interval of the File on page 308
Configuring How Long Backup Files Are Retained

You can configure how many days the files are retained in the local directory before they
are deleted.
NOTE: Files saved to the /var/log/pfedBackup directory are always

compressed to conserve local storage, regardless of whether the compress
statement is configured.
To configure retention for backup files:
• Specify the number of days.
user@host# set cleanup-interval interval days
NOTE: Files are retained for 1 day if you do not configure this option.
This value, whether configured or default, applies to all configured files at the [edit
accounting-options file] hierarchy level.
Configuring the Maximum Size of the File

To configure the maximum size of the file:
• Specify the size.

[edit accounting-options file filename]

size bytes;
The size statement is the maximum size of the log file, in bytes, kilobytes (KB), megabytes
(MB), or gigabytes (GB). The minimum value for bytes is 256 KB. You must configure
bytes; the remaining attributes are optional.
Configuring Archive Sites for the Files

After a file reaches its maximum size or the transfer-interval time is exceeded, the file is
closed, renamed, and, if you configured an archive site, transferred to a remote host.
To configure the sites where files are archived:
• Specify one or more site names.

user@host# set archive-sites site-name
where site-name is any valid FTP URL. For more information about specifying valid FTP
URLs, see the Junos OS Administration Library. You can specify more than one URL, in
any order. When a file is archived, the router or switch attempts to transfer the file to the
first URL in the list, trying the next site in the list only if the transfer does not succeed.
The log file is stored at the archive site with a filename of the format
router-name_log-filename_timestamp.
Configuring Local Backup for Accounting Files

You can configure the router to save a copy of the accounting file locally when the normal
transfer of the files to the archive site fails. The file is saved to the /var/log/pfedBackup
directory of the relevant Routing Engine. You must specify whether only the files from
the master Routing Engine are saved or files are saved from both the master Routing
Engine and the backup (slave) Routing Engine.

To configure local backup in the event of failure:
• Specify local backup and which files are saved.

user@host# set backup-on-failure (master-and-slave | master-only)
Disabling this feature deletes the backed-up accounting files from the directory.
NOTE: When you do not configure this option, the file is saved on failure into
the local directory specified as the last site in the list of archive sites.

Configuring Files to Be Compressed

By default, accounting files are transferred in an uncompressed format. To conserve
resources during transmission and on the archive site, you can configure compression
for the files.

To configure the router to compress accounting files when they are transferred:
• Specify compression.

user@host# set compress
Configuring the Maximum Number of Files

To configure the maximum number of files:
• Specify the number.

user@host# set files number
When a log file reaches its maximum size, it is renamed filename.0, then filename.1, and
so on, until the maximum number of log files is reached. Then the oldest log file is
overwritten. The minimum value for number is 3 and the default value is 10.
Configuring the Storage Location of the File

On J Series Services Routers, the files are stored by default on the compact flash drive.
Alternatively, you can configure the files to be stored in the mfs/var/log directory (on
DRAM) instead of the cf/var/log directory (on the compact flash drive).
To configure the storage location on DRAM:
• Specify nonpersistent storage.

user@host# set nonpersistent
This feature is useful for minimizing read/write traffic on the router’s compact flash drive.
NOTE: If log files for accounting data are stored on DRAM, these files are lost
when you reboot the router. We recommend that you back up these files
periodically.

Configuring Files to Be Saved After a Change in Mastership

You can configure the router to save the accounting files from the new backup Routing
Engine to the new master Routing Engine when a change in mastership occurs. The files
are stored in the /var/log/pfedBackup directory on the router. The master Routing Engine
includes these accounting files with its own current accounting files when it transfers
the files from the backup directory to the archive site at the next transfer interval. Configure
this option when the new backup Routing Engine is not able to connect to the archive
site; for example, when the site is not connected by means of an out-of-band interface
or the path to the site is routed through a line card.
To configure the backup Routing Engine files to be saved when mastership changes:
• Specify the backup.

user@host# set push-backup-to-master
NOTE: The backup Routing Engine’s files on the master Routing Engine are
sent at each interval even though the files remain the same. If this is more
activity than you want, consider using the backup-on-failure master-and-slave
statement instead.
Configuring the Start Time for File Transfer

To configure the start time for transferring files:
• Specify the time.

user@host# set start-time YYYY-MM-DD.hh:mm
For example, 10:00 a.m. on January 30, 2007 is represented as 2007-01-30.10:00.
Configuring the Transfer Interval of the File

To configure the interval at which files are transferred:
• Specify the interval.

user@host# set transfer-interval minutes
The range for transfer-interval is 5 through 2880 minutes. The default is 30 minutes.
TIP:
Junos OS saves the existing log file and creates a new file at the configured
transfer intervals irrespective of whether:
• The file has reached the maximum size.

• An archive site is configured.
When you have a relatively small transfer interval configured and if no archive
site is configured, data can be lost as Junos OS overwrites the log files when
the maximum number of log files is reached. To ensure that the log
information is saved for a reasonably long time:
• Configure an archive site to archive the log files every time a new log file is
created.
• Configure the maximum value (2880 minutes) for transfer-interval so that

new files are created less frequently; that is, only when the file exceeds the
maximum size limit or once in 2 days.

Documentation
Configuring the Interface Profile
An interface profile specifies the information collected and written to a log file. You can
configure a profile to collect error and statistic information for input and output packets
on a particular physical or logical interface.
To configure an interface profile, include the interface-profile statement at the

[edit accounting-options] hierarchy level:
fields {
field-name;
}
file filename;
interval minutes;
}
By default, the Packet Forwarding Engine (PFE) periodically collects the statistics for all
interfaces. To improve the performance, you can optionally disable the periodic refresh
by including the periodic-refresh disable statement at the [edit accounting-options]
hierarchy level.
Each accounting profile must have a unique profile-name. To apply a profile to a physical
or logical interface, include the accounting-profile statement at either the [edit interfaces

interface-name] or the [edit interfaces interface-name unit logical-unit-number] hierarchy

level. You can also apply an accounting profile at the [edit firewall family family-type filter
filter-name] hierarchy level. For more information, see the Routing Policies, Firewall Filters,
and Traffic Policers Feature Guide.
To configure an interface profile, perform the tasks described in the following sections:
• Configuring Fields on page 310

• Configuring the File Information on page 310
• Example: Configuring the Interface Profile on page 311
Configuring Fields
An interface profile must specify what statistics are collected. To configure which statistics
should be collected for an interface, include the fields statement at the [edit
accounting-options interface-profile profile-name] hierarchy level:
[edit accounting-options interface-profile profile-name]

fields {
field-name;
}
Configuring the File Information

Each accounting profile logs its statistics to a file in the /var/log directory.
To configure which file to use, include the file statement at the [edit accounting-options
interface-profile profile-name] hierarchy level:

file filename;
You must specify a file statement for the interface profile that has already been configured
at the [edit accounting-options] hierarchy level.

Each interface with an accounting profile enabled has statistics collected once per interval
time specified for the accounting profile. Statistics collection time is scheduled evenly
over the configured interval. To configure the interval, include the interval statement at
the [edit accounting-options interface-profile profile-name] hierarchy level:

interval minutes;
NOTE: The minimum interval allowed is 1 minute. Configuring a low interval

in an accounting profile for a large number of interfaces might cause serious
performance degradation.
The range for the interval statement is 1 through 2880 minutes. The default is 30 minutes.

Example: Configuring the Interface Profile

Configure the interface profile:
[edit]
file if_stats {
size 40 files 5;
}
interface-profile if_profile1 {
file if_stats;
interval 30;
fields {
input-bytes;
output-bytes;
input-packets;
output-packets;
input-multicast;
output-multicast;
}
}
interface-profile if_profile2 {
file if_stats;
interval 30;
fields {
input-bytes;
output-bytes;
input-packets;
output-packets;
input-multicast;
output-multicast;
}
}
interfaces {
xe-1/0/0 {
accounting-profile if_profile1;
unit 0 {
accounting-profile if_profile2;
...
}
}
}
}
The two interface profiles, if-profile1 and if-profile2, write data to the same file, if-stats.
The if-stats file might look like the following:
#FILE CREATED 976823478 2000-12-14-19:51:18

#hostname host
#profile-layout
if_profile2,epoch-timestamp,interface-name,snmp-index,input-bytes,output-bytes,
input-packets,output-packets,input-multicast,output-multicast
#profile-layout
if_profile1,epoch-timestamp,interface-name,snmp-index,input-bytes,output-bytes,
input-packets
if_profile2,976823538,xe-1/0/0.0,8,134696815,3681534,501088,40723,0,0
if_profile1,976823538,xe-1/0/0,7,134696815,3681534,501088

...
#FILE CLOSED 976824378 2000-12-14-20:06:18

Documentation
Configuring the Filter Profile
A filter profile specifies error and statistics information collected and written to a file. A
filter profile must specify counter names for which statistics are collected.
To configure a filter profile, include the filter-profile statement at the [edit

counters {
counter-name;
}
file filename;
interval minutes;
}
To apply the filter profile, include the accounting-profile statement at the [edit firewall
filter filter-name] hierarchy level.
To configure a filter profile, perform the tasks described in the following sections:
• Configuring the Counters on page 312

Configuring the Counters

Statistics are collected for all counters specified in the filter profile. To configure the
counters, include the counters statement at the [edit accounting-options filter-profile
profile-name] hierarchy level:
[edit accounting-options filter-profile profile-name]

counters {
}


filter-profile profile-name] hierarchy level:

file filename;
You must specify a filename for the filter profile that has already been configured at the
[edit accounting-options] hierarchy level.
NOTE: The limit on the total number of characters per line in a log file equals
1023. If this limit is exceeded, the output written to the log file is incomplete.
Ensure that you limit the number of counters or requested data so that this
character limit is not exceeded.
NOTE: If the configured file size or transfer interval is exceeded, Junos OS

closes the file and starts a new one. By default, the transfer interval value is
30 minutes. If the transfer interval is not configured, Junos OS closes the file
and starts a new one when the file size exceeds its configured value or the
default transfer interval value exceeds 30 minutes. To avoid transferring files
every 30 minutes, specify a different value for the transfer interval.

Each filter with an accounting profile enabled has statistics collected once per interval
time specified for the accounting profile. Statistics collection time is scheduled evenly
over the configured interval. To configure the interval, include the interval statement at
the [edit accounting-options filter-profile profile-name] hierarchy level:

interval;
NOTE: The minimum interval allowed is 1 minute. Configuring a low interval

in an accounting profile for a large number of filters might cause serious
performance degradation.

Documentation
Example: Configuring a Filter Profile

Configure a filter profile:
[edit]
file fw_accounting {
size 500k files 4;
}
filter-profile fw_profile1 {
file fw_accounting;
interval 60;
counters {
counter1;
counter2;
counter3;
}
}
}
firewall {
filter myfilter {
accounting-profile fw_profile1;
...
term accept-all {
then {
count counter1;
accept;
}
}
}
}
The filter profile, fw-profile1, writes data to the file fw_accounting. The file might look like
the following:
#FILE CREATED 976825278 2000-12-14-20:21:18
#hostname host
#profile-layout
fw_profile1,epoch-timestamp,filter-name,counter-name,packet-count,byte-count
fw_profile1,976826058,myfilter,counter1,163,10764
...
#FILE CLOSED 976826178 2000-12-14-20:36:18
Related • Configuring the Filter Profile on page 312

Documentation
• Example: Configuring Interface-Specific Firewall Counters and Filter Profiles on page 314
Example: Configuring Interface-Specific Firewall Counters and Filter Profiles
To collect and log count statistics collected by firewall filters on a per-interface basis,
you must configure a filter profile and include the interface-specific statement at the
[edit firewall filter filter-name] hierarchy level.
Configure the firewall filter accounting profile:

file cust1_accounting {
size 500k;
}
filter-profile cust1_profile {
file cust1_accounting;
interval 1;
counters {
r1;
}
}
Configure the interface-specific firewall counter:
[edit firewall]
filter f3 {
accounting-profile cust1_profile;
interface-specific;
term f3-term {
then {
count r1;
accept;
}
}
}
Apply the firewall filter to an interface:
[edit interfaces]
xe-1/0/0 {
unit 0 {
family inet {
filter {
input f3;
output f3;
}
address 20.20.20.30/24;
}
}
}
The following example shows the contents of the cust1_accounting file in the /var/log
folder that might result from the preceding configuration:
#FILE CREATED 995495212 2001-07-18-22:26:52
#hostname host
#profile-layout cust1_profile,epoch-timestamp,interfaces,filter-name,
counter-name,packet-count,byte-count
cust1_profile,995495572,xe-1/0/0.0,f3-xe-1/0/0.0-i,r1-xe-1/0/0.0-i,5953,1008257
cust1_profile,995495602,xe-1/0/0.0,f3-xe-1/0/0.0-o,r1-xe-1/0/0.0-o,5929,1006481
...
If the interface-specific statement is not included in the configuration, the following output
might result:
#FILE CREATED 995495212 2001-07-18-22:26:52
#hostname host
#profile-layout cust1_profile,epoch-timestamp,interfaces,filter-name,
counter-name,packet-count,byte-count

cust1_profile,995495572,xe-1/0/0.0,f3,r1,5953,1008257
cust1_profile,995495632,xe-1/0/0.0,f3,r1,5929,1006481
Related • Configuring the Filter Profile on page 312

Documentation
Configuring SCU or DCU
To configure SCU or DCU, perform the following tasks described in this section:
NOTE: We recommend that you stop the network traffic on an interface

before you modify the DCU or SCU configuration for that interface. Modifying
the DCU or SCU configuration without stopping the traffic might corrupt the
DCU or SCU statistics. Before you restart the traffic after modifying the
configuration, enter the clear interfaces statistics command.
• Creating Prefix Route Filters in a Policy Statement on page 316

• Applying the Policy to the Forwarding Table on page 316
• Enabling Accounting on Inbound and Outbound Interfaces on page 316
Creating Prefix Route Filters in a Policy Statement

To define prefix router filters:
[edit policy-options]
policy-statement scu-1 {
term term1;
from {
route-filter 192.0.2.0/24 or longer;
}
then source-class gold;
}
Applying the Policy to the Forwarding Table

To apply the policy to the forwarding table:
[edit]
routing-options {
forwarding-table {
export scu-1;
}
}
Enabling Accounting on Inbound and Outbound Interfaces

To enable accounting on inbound and outbound interfaces:
[edit]

interfaces {
so-6/1/0 {
unit 0 {
family inet;
accounting {
destination-class-usage;
source-class-usage {
output;
}
}
}
}
}
[edit]
interfaces {
xe-0/1/0 {
unit 0 {
family inet6 {
accounting {
input;
}
}
}
}
}
}
Optionally, you can include the input and output statements on a single interface as
shown:
[edit]
interfaces {
xe-0/1/2 {
unit 0 {
family inet6 {
accounting {
input;
output;
}
}
}
}
}
}
For more information about configuring route filters and source classes in a routing policy,
see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide and the Junos
OS Network Interfaces Library for Routing Devices.
Related • Understanding Source Class Usage and Destination Class Usage Options on page 292
Documentation

Configuring SCU on a Virtual Loopback Tunnel Interface
To configure source class usage on the virtual loopback tunnel interface, perform the
tasks described in the following sections:
• Example: Configuring a Virtual Loopback Tunnel Interface on a Provider Edge Router

Equipped with a Tunnel PIC on page 318
• Example: Mapping the VRF Instance Type to the Virtual Loopback Tunnel
Interface on page 318
• Example: Sending Traffic Received from the Virtual Loopback Interface Out the Source
Class Output Interface on page 319
Example: Configuring a Virtual Loopback Tunnel Interface on a Provider Edge Router Equipped
with a Tunnel PIC
Define a virtual loop interface on a provider edge router with a Tunnel PIC:
[edit interfaces]
vt-0/3/0 {
unit 0 {
family inet {
accounting {
input;
}
}
}
}
}
Example: Mapping the VRF Instance Type to the Virtual Loopback Tunnel Interface
Map the VRF instance type to the virtual loopback tunnel interface:
[edit]
routing-instances {
VPN-A {
instance-type vrf;
interface at-2/1/1.0;
interface vt-0/3/0.0;
route-distinguisher 10.255.14.225;
vrf-import import-policy-name;
vrf-export export-policy-name;
protocols {
bgp {
group to-r4 {
local-address 10.27.253.1;
peer-as 400;

neighbor 10.27.253.2;
}
}
}
}
}
NOTE: For SCU and DCU to work, do not include the vrf-table-label statement
at the [edit routing-instances instance-name] hierarchy level.
Example: Sending Traffic Received from the Virtual Loopback Interface Out the Source Class
Output Interface
Send traffic received from the virtual loopback tunnel interface out of the source class
output interface:
[edit interfaces]
at-1/1/0 {
unit 0 {
family inet {
accounting {
output;
}
}
}
}
}
For more information about configuring source class usage on the virtual loopback tunnel
interface, see the Junos OS Network Interfaces Library for Routing Devices.
Documentation
Configuring Class Usage Profiles
To collect class usage statistics, perform the tasks described in these sections:
• Configuring a Class Usage Profile on page 320


• Creating a Class Usage Profile to Collect Source Class Usage Statistics on page 320
• Creating a Class Usage Profile to Collect Destination Class Usage Statistics on page 321
Configuring a Class Usage Profile

You can configure the class usage profile to collect statistics for particular source and
destination classes.
To configure the class usage profile to filter by source classes, include the source-classes
statement at the [edit accounting-options class-usage-profile profile-name] hierarchy
level:
[edit accounting-options class-usage-profile profile-name]

source-classes {
source-class-name;
}
To configure the class usage profile to filter by destination classes, include the
destination-classes statement at the [edit accounting-options class-usage-profile

}

To specify which file to use, include the file statement at the [edit accounting-options
class-usage-profile profile-name] hierarchy level:

file filename;
You must specify a filename for the source class usage profile that has already been
configured at the [edit accounting-options] hierarchy level. You can also specify a filename
for the destination class usage profile configured at the [edit accounting-options] hierarchy
level.

Each interface with a class usage profile enabled has statistics collected once per interval
specified for the accounting profile. Statistics collection time is scheduled evenly over
the configured interval. To configure the interval, include the interval statement at the
[edit accounting-options class-usage-profile profile-name] hierarchy level:

interval;
Creating a Class Usage Profile to Collect Source Class Usage Statistics

To create a class usage profile to collect source class usage statistics:
[edit]

class-usage-profile scu-profile1;
file usage-stats;
interval 15;
source-classes {
gold;
silver;
bronze;
}
}
The class usage profile, scu-profile1, writes data to the file usage_stats. The file might
look like the following:
#FILE CREATED 976825278 2000-12-14-20:21:18
#profile-layout, scu_profile,epoch-timestamp,interface-name,source-class,
packet-count,byte-count
scu_profile,980313078,xe-1/0/0.0,gold,82,6888
scu_profile,980313078,xe-1/0/0.0,silver,164,13776
scu_profile,980313078,xe-1/0/0.0,bronze,0,0
scu_profile,980313678,xe-1/0/0.0,gold,82,6888
scu_profile,980313678,xe-1/0/0.0,silver,246,20664
scu_profile,980313678,xe-1/0/0.0,bronze,0,0
Creating a Class Usage Profile to Collect Destination Class Usage Statistics

To create a class usage profile to collect destination class usage statistics:
[edit]
class-usage-profile dcu-profile1;
file usage-stats
interval 15;
gold;
silver;
bronze;
}
}
The class usage profile, dcu-profile1, writes data to the file usage-stats. The file might
look like the following:
#FILE CREATED 976825278 2000-12-14-20:21:18
#profile-layout, dcu_profile,epoch-timestamp,interface-name,destination-class,
packet-count,byte-count
dcu_profile,980313078,xe-1/0/0.0,gold,82,6888
dcu_profile,980313078,xe-1/0/0.0,silver,164,13776
dcu_profile,980313078,xe-1/0/0.0,bronze,0,0
dcu_profile,980313678,xe-1/0/0.0,gold,82,6888
dcu_profile,980313678,xe-1/0/0.0,silver,246,20664
dcu_profile,980313678,xe-1/0/0.0,bronze,0,0
...
#FILE CLOSED 976826178 2000-12-14-20:36:18
Documentation

Configuring the MIB Profile
The MIB profile collects MIB statistics and logs them to a file. The MIB profile specifies
the SNMP operation and MIB object names for which statistics are collected.
To configure a MIB profile, include the mib-profile statement at the [edit

file filename;
interval minutes;
object-names {
mib-object-name;
}
}
To configure a MIB profile, perform the tasks described in the following sections:

• Configuring the MIB Operation on page 323
• Configuring MIB Object Names on page 323
• Example: Configuring a MIB Profile on page 323

mib-profile profile-name] hierarchy level:
[edit accounting-options mib-profile profile-name]

file filename;
You must specify a filename for the MIB profile that has already been configured at the
[edit accounting-options] hierarchy level.

A MIB profile has statistics collected once per interval time specified for the profile.
Statistics collection time is scheduled evenly over the configured interval. To configure
the interval, include the interval statement at the [edit accounting-options mib-profile

interval;

Configuring the MIB Operation

A MIB profile must specify the operation that is used to collect MIB statistics. To configure
which operation is used to collect MIB statistics, include the operation statement at the
[edit accounting-options mib-profile profile-name] hierarchy level:

You can configure a get, get-next, or walk operation. The default operation is walk.
Configuring MIB Object Names

A MIB profile must specify the MIB objects for which statistics are to be collected. To
configure the MIB objects for which statistics are collected, include the objects-names
statement at the [edit accounting-options mib-profile profile-name] hierarchy level:

object-names {
mib-object-name;
}
You can include multiple MIB object names in the configuration.
NOTE: In Junos OS Release 15.1X49-D10 and later, do not configure MIB

objects related to interface octets or packets for a MIB profile, because it can
cause the SNMP walk or a CLI show command to time out.
Example: Configuring a MIB Profile

Configure a MIB profile:
mib-profile mstatistics {
file stats;
interval 60;
operation walk;
objects-names {
ipCidrRouteStatus;
}
}
Release History Table Release Description
15.1X49-D10 In Junos OS Release 15.1X49-D10 and later, do not configure MIB objects
related to interface octets or packets for a MIB profile, because it can
cause the SNMP walk or a CLI show command to time out.
Documentation

Configuring the Routing Engine Profile
The Routing Engine profile collects Routing Engine statistics and logs them to a file. The
Routing Engine profile specifies the fields for which statistics are collected.
To configure a Routing Engine profile, include the routing-engine-profile statement at the

[edit accounting-options] hierarchy level:
fields {
field-name;
}
file filename;
interval minutes;
}
To configure a Routing Engine profile, perform the tasks described in the following
sections:
• Configuring Fields on page 324

• Example: Configuring a Routing Engine Profile on page 325
Configuring Fields
A Routing Engine profile must specify what statistics are collected. To configure which
statistics should be collected for the Routing Engine, include the fields statement at the
[edit accounting-options routing-engine-profile profile-name] hierarchy level:
[edit accounting-options routing-engine-profile profile-name]

fields {
field-name;
}

routing-engine-profile profile-name] hierarchy level:

file filename;
You must specify a filename for the Routing Engine profile that has already been configured
at the [edit accounting-options] hierarchy level.


A Routing Engine profile has statistics collected once per interval time specified for the
profile. Statistics collection time is scheduled evenly over the configured interval. To
configure the interval, include the interval statement at the [edit accounting-options
routing-engine-profile profile-name] hierarchy level:

interval;
The range for interval is 1 through 2880 minutes. The default is 30 minutes.
Example: Configuring a Routing Engine Profile

Configure a Routing Engine profile:
file my-file {
size 300k;
}
routing-engine-profile profile-1 {
file my-file;
fields {
host-name;
date;
time-of-day;
uptime;
cpu-load-1;
cpu-load-5;
cpu-load-15;
}
}
Documentation


PART 6
Configuring Monitoring Options

• Configuring Interface Alarms on page 329
• Using RPM to Measure Network Performance on page 341
• Configuring IP Monitoring on page 367


CHAPTER 19
Configuring Interface Alarms
• Alarm Overview on page 329

• Example: Configuring Interface Alarms on page 335
• Monitoring Active Alarms on a Device on page 338
• Monitoring Alarms on page 339
Alarm Overview
Supported Platforms SRX Series
Alarms alert you to conditions on a network interface, on the device chassis, or in the
system software that might prevent the device from operating normally. You can set the
conditions that trigger alarms on an interface. Chassis and system alarm conditions are
preset.
An active alarm lights the ALARM LED on the front panel of the device. You can monitor
active alarms from the J-Web user interface or the CLI. When an alarm condition triggers
an alarm, the device lights the yellow (amber) ALARM LED on the front panel. When the
condition is corrected, the light turns off.
• Alarm Types on page 329

• Alarm Severity on page 330
• Alarm Conditions on page 330
Alarm Types
The device supports three types of alarms:
• Interface alarms indicate a problem in the state of the physical links on fixed or installed
Physical Interface Modules (PIMs). To enable interface alarms, you must configure
them.
• Chassis alarms indicate a failure on the device or one of its components. Chassis alarms
are preset and cannot be modified.

• System alarms indicate a missing rescue configuration or software license, where valid.
System alarms are preset and cannot be modified, although you can configure them
to appear automatically in the J-Web user interface or CLI.
Starting with Junos OS Release 15.1X49-D60, a new system alarm is introduced to

indicate that the PICs (I/O card or SPC) have failed to come online during system start
time.
NOTE: Run the following commands when the CLI prompt indicates that
an alarm has been raised:
• show system alarms
• show chassis alarms
• show chassis fpc pic-status
For more information about the CLI commands, see show system alarms, show chassis
alarms, and show chassis fpc (View).
Alarm Severity
Alarms have two severity levels:
• Major (red)—Indicates a critical situation on the device that has resulted from one of
the following conditions. A red alarm condition requires immediate action.
• One or more hardware components have failed.
• One or more hardware components have exceeded temperature thresholds.
• An alarm condition configured on an interface has triggered a critical warning.
• Minor (yellow)—Indicates a noncritical condition on the device that, if left unchecked,

might cause an interruption in service or degradation in performance. A yellow alarm
condition requires monitoring or maintenance.
A missing rescue configuration or software license generates a yellow system alarm.
Alarm Conditions
To enable alarms on a device interface, you must select an alarm condition and an alarm
severity. In contrast, alarm conditions and severity are preconfigured for chassis alarms
and system alarms.
NOTE: For information about chassis alarms for your device, see the Hardware
Guide for your device.

Chapter 19: Configuring Interface Alarms
• Interface Alarm Conditions on page 331

• System Alarm Conditions on page 334
Interface Alarm Conditions
Table 39 on page 331 lists the interface conditions, sorted by interface type, that you can
configure for an alarm. You can configure each alarm condition to trigger either a major
(red) alarm or minor a (yellow) alarm. The corresponding configuration option is included.
For the services stateful firewall filters (NAT, IDP, and IPsec), which operate on an internal
adaptive services module within a device, you can configure alarm conditions on the
integrated services and services interfaces.
Table 39: Interface Alarm Conditions

Configuration
Interface Alarm Condition Description Option
DS1 (T1) Alarm indication signal (AIS) The normal T1 traffic signal contained a defect ais
condition and has been replaced by the AIS. A
transmission interruption occurred at the remote
endpoint or upstream of the remote endpoint. This
all-ones signal is transmitted to prevent
consequential downstream failures or alarms.
Yellow alarm The remote endpoint is in yellow alarm failure. This ylw
condition is also known as a far-end alarm failure.
Ethernet Link is down The physical link is unavailable. link-down
Integrated Hardware or software failure On the adaptive services module, either the hardware failure
services associated with the module or the software that
drives the module has failed.

Table 39: Interface Alarm Conditions (continued)

Configuration
Serial Clear-to-send (CTS) signal The remote endpoint of the serial link is not cts-absent
absent transmitting a CTS signal. The CTS signal must be
present before data can be transmitted across a
serial link.
Data carrier detect (DCD) signal The remote endpoint of the serial link is not dcd-absent
absent transmitting a DCD signal. Because the DCD signal
transmits the state of the device, no signal probably
indicates that the remote endpoint of the serial link
is unavailable.
Data set ready (DSR) signal The remote endpoint of the serial link is not dsr-absent
absent transmitting a DSR signal. The DSR signal indicates
that the remote endpoint is ready to receive and
transmit data across the serial link.
Loss of receive clock The clock signal from the remote endpoint is not loss-of-rx-clock
present. Serial connections require clock signals to
be transmitted from one endpoint and received by
the other endpoint of the link.
Loss of transmit clock The local clock signal is not present. Serial loss-of-tx-clock
connections require clock signals to be transmitted
from one endpoint and received by the other endpoint
of the link.
Services Services module hardware A hardware problem has occurred on the device's hw-down
down services module. This error typically means that one
or more of the CPUs on the module has failed.
Services link down The link between the device and its services module linkdown
is unavailable.
Services module held in reset The device's services module is stuck in reset mode. pic-hold-reset
If the services module fails to start up five or more
times in a row, the services module is held in reset
mode. Startup fails when the amount of time from
CPU release to CPU halt is less than 300 seconds.
Services module reset The device's services module is resetting. The module pic-reset
resets after it crashes or is reset from the CLI, or when
it takes longer than 60 seconds to start up.
Services module software down A software problem has occurred on the device's sw-down
services module.


Configuration
E3 Alarm indication signal (AIS) The normal E3 traffic signal contained a defect ais
Loss of signal (LOS) No remote E3 signal is being received at the E3 los

interface.
Out of frame (OOF) An OOF condition has existed for 10 seconds. This oof
alarm applies only to E3 interfaces configured in
frame mode. The OOF failure is cleared when no OOF
or LOS defects have occurred for 20 seconds.
Remote defect indication An AIS, LOS, or OOF condition exists. This alarm rdi
applies only to E3 interfaces configured in frame
mode.


Configuration
T3 (DS3) Alarm indication signal The normal T3 traffic signal contained a defect ais
Excessive number of zeros The bit stream received from the upstream host has exz
more consecutive zeros than are allowed in a T3
frame.
Far-end receive failure (FERF) The remote endpoint of the connection has failed. A ferf
FERF differs from a yellow alarm, because the failure
can be any failure, not just an OOF or LOS failure.
Idle alarm The Idle signal is being received from the remote idle
endpoint.
Line code violation Either the line encoding along the T3 link is corrupted lcv
or a mismatch between the encoding at the local
and remote endpoints of a T3 connection occurred.
Loss of frame (LOF) An OOF or loss-of-signal LOS condition has existed lof
for 10 seconds. The LOF failure is cleared when no
OOF or LOS defects have occurred for 20 seconds.
A LOF failure is also called a red failure.
Loss of signal (LOS) No remote T3 signal is being received at the T3 los

interface.
Phase-locked loop out of lock The clocking signals for the local and remote pll
endpoints no longer operate in lock-step.
Yellow alarm The remote endpoint is in yellow alarm failure. This ylw
condition is also known as a far-end alarm failure.
System Alarm Conditions
Table 40 on page 334 lists the two preset system alarms, the condition that triggers each
alarm, and the action you take to correct the condition.
Table 40: System Alarm Conditions and Corrective Actions

Alarm Type Alarm Condition Corrective Action
Configuration The rescue configuration is not set. Set the rescue configuration.

Table 40: System Alarm Conditions and Corrective Actions (continued)

Alarm Type Alarm Condition Corrective Action
License You have configured at least one software Install a valid license key.
feature that requires a feature license, but no
valid license for the feature is currently
installed.
NOTE: This alarm indicates that you are in

violation of the software license agreement.
You must install a valid license key to be in
compliance with all agreements.
15.1X49-D60 Starting with Junos OS Release 15.1X49-D60, a new system alarm is

introduced to indicate that the PICs (I/O card or SPC) have failed to
come online during system start time.
Related • Example: Configuring Interface Alarms on page 335

Documentation
• System Log Messages
Example: Configuring Interface Alarms
This example shows how to configure interface alarms.

Requirements
Before you begin:
• Establish basic connectivity.
• Configure network interfaces. See Interfaces Feature Guide for Security Devices.
• Select the network interface on which to apply an alarm and the condition you want
to trigger the alarm. See “Alarm Overview” on page 329.

Overview
In this example, you enable interface alarms by explicitly setting alarm conditions. You
configure the system to generate a red interface alarm when a yellow alarm is detected
on a DS1 link. You configure the system to generate a red interface alarm when a link-down
failure is detected on an Ethernet link.
For a serial link, you set cts-absent and dcd-absent to yellow to signify either the CST or
the DCD signal is not detected. You set loss-of-rx-clock and loss-of-tx-clock to red alarm
to signify either the receiver clock signal or the transmission clock signal is not detected.
For a T3 link, you set the interface alarm to red when the remote endpoint is experiencing
a failure. You set exz to yellow alarm when the upstream bit has more consecutive zeros
than are permitted in a T3 interface. You then set a red alarm when there is loss-of-signal
on the interface.
Finally, you configure the system to display active system alarms whenever a user with
the login class admin logs in to the device.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level,
and then enter commit from configuration mode.
set chassis alarm ds1 ylw red

set chassis alarm ethernet link-down red
set chassis alarm serial cts-absent yellow dcd-absent yellow
set chassis alarm serial loss-of-rx-clock red loss-of-tx-clock red
set chassis alarm t3 ylw red exz yellow los red
set system login class admin login-alarms
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure interface alarms:
1. Configure an alarm.
[edit]
user@host# edit chassis alarm
2. Specify the interface alarms on a DS1 and an Ethernet link.
[edit chassis alarm]

user@host# set ds1 ylw red
user@host# set ethernet link–down red
3. Specify the interface alarms on a serial link.

user@host# set serial cts-absent yellow
user@host# set serial dcd-absent yellow

user@host# set serial loss-of-rx-clock red

user@host# set serial loss-of-tx-clock red
4. Specify the interface alarms on a T3 link.

user@host# set t3 ylw red
user@host# set t3 exz yellow
user@host# set t3 los red
5. Configure the system to display active system alarms.
[edit]
user@host# edit system login
user@host# set class admin login-alarms
Results From configuration mode, confirm your configuration by entering the show chassis alarms
and show system login commands. If the output does not display the intended
configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show chassis alarms
t3 {
exz yellow;
los red;
ylw red;
}
ds1 {
ylw red;
}
ethernet {
link-down red;
}
serial {
loss-of-rx-clock red;
loss-of-tx-clock red;
dcd-absent yellow;
cts-absent yellow;
}
[edit]
user@host# show system login
show system login
show system login
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Verifying the Alarm Configurations
Purpose Confirm that the configuration is working properly.
Verify that the alarms are configured.

Action From configuration mode, enter the show chassis alarms command. Verify that the output
shows the intended configuration of the alarms.
Related • Alarm Overview on page 329

Documentation
Monitoring Active Alarms on a Device
Purpose Use to monitor and filter alarms on a Juniper Networks device.
Action Select Monitor>Events and Alarms>View Alarms in the J-Web user interface. The J-Web
View Alarms page displays the following information about preset system and chassis
alarms:
• Type—Type of alarm: System, Chassis, or All.
• Severity—Severity class of the alarm: Minor or Major.
• Description—Description of the alarm.
• Time—Time that the alarm was registered.
To filter which alarms appear, use the following options:
• Alarm Type—Specifies which type of alarm to monitor: System, Chassis, or All. System
alarms include FRU detection alarms (power supplies removed, for instance). Chassis
alarms indicate environmental alarms such as temperature.
• Severity—Specifies the alarm severity that you want to monitor: Major, Minor, or All. A
major (red) alarm condition requires immediate action. A minor (yellow) condition
requires monitoring and maintenance.
• Description—Specifies the alarms you want to monitor. Enter a brief synopsis of the
alarms that you want to monitor.
• Date From—Specifies the beginning of the date range that you want to monitor. Set
the date using the calendar pick tool.
• To—Specifies the end of the date range that you want to monitor. Set the date using
the calendar pick tool.
• Go—Executes the options that you specified.
• Reset—Clears the options that you specified.
Alternatively, you can enter the following show commands in the CLI editor:

Related • Alarm Overview on page 329

Documentation
• Example: Configuring Interface Alarms on page 335
Monitoring Alarms
Purpose Use the monitoring functionality to view the alarms page.
Action To monitor alarms select Monitor>Events and Alarms>View Alarms in the J-Web user
interface.
Meaning Table 41 on page 339 summarizes key output fields in the alarms page.
Table 41: Alarms Monitoring Page

Field Value Additional Information
Alarm Filter
Alarm Type Specifies the type of alarm to monitor: —
• System– System alarms include FRU

detection alarms (power supplies
removed, for instance).
• Chassis– Chassis alarms indicate
environmental alarms such as
temperature.
• All– Indicates to display all the types of
alarms.
Severity Specifies the alarm severity that you want —

to monitor
• Major– A major (red) alarm condition

requires immediate action.
• Minor– A minor (yellow) condition requires
monitoring and maintenance.
• All– Indicates to display all the severities.
Description Enter a brief synopsis of the alarms you want —

to monitor.
Date From Specifies the beginning of the date range —

that you want to monitor. Set the date using
the calendar pick tool.
To Specifies the end of the date range that you —

want to monitor. Set the date using the
calendar pick tool.
Go Executes the options that you specified. —

Table 41: Alarms Monitoring Page (continued)

Reset Clears the options that you specified. —
Alarm Details Displays the following information about —

each alarm:
• Type– Type of alarm: System, Chassis, or

All.
• Severity– Severity class of the alarm:
Minor or Major.
• Description– Description of the alarm.
• Time– Time that the alarm was registered.
Related • Monitoring Active Alarms on a Device on page 338

Documentation
• Monitoring Events on page 471
• Monitoring Security Events by Policy on page 453

CHAPTER 20
Using RPM to Measure Network

Performance
• RPM Overview on page 341

• IPv6 RPM Probes on page 345
• Guidelines for Configuring RPM Probes for IPv6 on page 345
• RPM Support for VPN Routing and Forwarding on page 347
• Example: Configuring Basic RPM Probes on page 347
• Example: Configuring RPM Using TCP and UDP Probes on page 351
• Example: Configuring RPM Probes for BGP Monitoring on page 354
• Directing RPM Probes to Select BGP Devices on page 356
• Configuring IPv6 RPM Probes on page 357
• Tuning RPM Probes on page 358
• RPM Configuration Options on page 358
• Monitoring RPM Probes on page 362
RPM Overview
Supported Platforms SRX1500, SRX300, SRX320, SRX340, vSRX
The real-time performance monitoring (RPM) feature allows network operators and
their customers to accurately measure the performance between two network endpoints.
With the RPM tool, you configure and send probes to a specified target and monitor the
analyzed results to determine packet loss, round-trip time, and jitter.
RPM allows you to perform service-level monitoring. When RPM is configured on a device,
the device calculates network performance based on packet response time, jitter, and
packet loss. These values are gathered by Hypertext Transfer Protocol (HTTP) GET
requests, Internet Control Message Protocol (ICMP) requests, and TCP and UDP requests,
depending on the configuration.
• RPM Probes on page 342

• RPM Tests on page 342

• Probe and Test Intervals on page 342

• Jitter Measurement with Hardware Timestamping on page 343
• RPM Statistics on page 343
• RPM Thresholds and Traps on page 344
• RPM for BGP Monitoring on page 345
RPM Probes
You gather RPM statistics by sending out probes to a specified probe target, identified
by an IP address or URL. When the target receives the probe, it generates responses,
which are received by the device. By analyzing the transit times to and from the remote
server, the device can determine network performance statistics.
The device sends out the following probe types:
• HTTP GET request at a target URL
• HTTP GET request for metadata at a target URL
• ICMP echo request to a target address (the default)
• ICMP timestamp request to a target address
• UDP ping packets to a target device
• UDP timestamp requests to a target address
• TCP ping packets to a target device
UDP and TCP probe types require that the remote server be configured as an RPM receiver
so that it generates responses to the probes.
The RPM probe results are also available in the form of MIB objects through the SNMP
protocol.
RPM Tests
Each probed target is monitored over the course of a test. A test represents a collection
of probes, sent out at regular intervals, as defined in the configuration. Statistics are then
returned for each test. Because a test is a collection of probes that have been monitored
over some amount of time, test statistics such as standard deviation and jitter can be
calculated and included with the average probe statistics.
Probe and Test Intervals

Within a test, RPM probes are sent at regular intervals, configured in seconds. When the
total number of probes has been sent and the corresponding responses received, the
test is complete. You can manually set the probe interval for each test to control how
the RPM test is conducted.
After all the probes for a particular test have been sent, the test begins again. The time
between tests is the test interval. You can manually set the test interval to tune RPM
performance.

Chapter 20: Using RPM to Measure Network Performance
NOTE: On SRX340 devices, the RPM server operation with icmp is not
supported. The RPM server works fine with TCP and UDP.
Jitter Measurement with Hardware Timestamping

Jitter is the difference in relative transit time between two consecutive probes.
You can timestamp the following RPM probes to improve the measurement of latency
or jitter:
• ICMP ping
• ICMP ping timestamp
• UDP ping
• UDP ping timestamp
NOTE: The device supports hardware timestamping of UDP ping and UDP
ping timestamp RPM probes only if the destination port is UDP-ECHO (port
7).
Timestamping takes place during the forwarding process of the device originating the
probe (the RPM client), but not on the remote device that is the target of the probe (the
RPM server).
The supported encapsulations on a device for timestamping are Ethernet including VLAN,
synchronous PPP, and Frame Relay. The only logical interface supported is an lt services
interface.
RPM probe generation with hardware timestamp can be retrieved through the SNMP
protocol.
RPM Statistics
At the end of each test, the device collects the statistics for packet round-trip time, packet
inbound and outbound times (for ICMP timestamp probes only), and probe loss as shown
in Table 42 on page 343.
Table 42: RPM Statistics

RPM Statistics Description
Round-Trip Times
Minimum round-trip time Shortest round-trip time from the Juniper Networks device to the remote server, as
measured over the course of the test
Maximum round-trip time Longest round-trip time from the Juniper Networks device to the remote server, as

Table 42: RPM Statistics (continued)

RPM Statistics Description
Average round-trip time Average round-trip time from the Juniper Networks device to the remote server, as
Standard deviation round-trip time Standard deviation of the round-trip times from the Juniper Networks device to the
remote server, as measured over the course of the test
Jitter Difference between the maximum and minimum round-trip times, as measured
over the course of the test
Inbound and Outbound Times (ICMP Timestamp Probes Only)

Minimum egress time Shortest one-way time from the Juniper Networks device to the remote server, as
Maximum ingress time Shortest one-way time from the remote server to the Juniper Networks device, as
Average egress time Average one-way time from the Juniper Networks device to the remote server, as
Average ingress time Average one-way time from the remote server to the Juniper Networks device, as
Standard deviation egress time Standard deviation of the one-way times from the Juniper Networks device to the
remote server, as measured over the course of the test
Standard deviation ingress time Standard deviation of the one-way times from the remote server to the Juniper
Networks device, as measured over the course of the test
Egress jitter Difference between the maximum and minimum outbound times, as measured
over the course of the test
Ingress jitter Difference between the maximum and minimum inbound times, as measured over
the course of the test
Probe Counts
Probes sent Total number of probes sent over the course of the test
Probe responses received Total number of probe responses received over the course of the test
Loss percentage Percentage of probes sent for which a response was not received
RPM Thresholds and Traps

You can configure RPM threshold values for the round-trip times, ingress (inbound) times,
and egress (outbound) times that are measured for each probe, as well as for the standard
deviation and jitter values that are measured for each test. Additionally, you can configure
threshold values for the number of successive lost probes within a test and the total
number of lost probes within a test.

If the result of a probe or test exceeds any threshold, the device generates a system log
message and sends any Simple Network Management Protocol (SNMP) notifications
(traps) that you have configured.
RPM for BGP Monitoring

When managing peering networks that are connected using Border Gateway Protocol
(BGP), you might need to find out if a path exists between the Juniper Networks device
and its configured BGP neighbors. You can ping each BGP neighbor manually to determine
the connection status, but this method is not practical when the device has a large number
of BGP neighbors configured.
In the device, you can configure RPM probes to monitor the BGP neighbors and determine
if they are active.
Related • RPM Configuration Options on page 358

Documentation
• Determine What Causes Jitter and Latency on the Multilink Bundle on page 589
IPv6 RPM Probes
Supported Platforms vSRX
Starting with Junos OS Release 15.1X49-D10, Route Engine-based RPM can send and
receive IPv6 probe packets to monitor performance on IPv6 networks.
A probe request is a standard IPv6 packet with corresponding TCP, UDP, and ICMPv6
headers. A probe response is also a standard IPv6 packet with corresponding TCP, UDP,
and ICMPv6 headers. No RPM header is appended to the standard packet for RE-based
RPM. An IPv6-based RPM test occurs between an IPv6 RPM client and IPv6 RPM server.
NOTE: You can have both IPv4 tests and IPv6 tests in the same probe.
Related • Guidelines for Configuring RPM Probes for IPv6 on page 345
Documentation
• Configuring IPv6 RPM Probes on page 357
Guidelines for Configuring RPM Probes for IPv6
Starting with Junos OS Release 15.1X49-D10, you can configure RPM Probes for IPv6.
Keep the following guidelines in mind when you configure IPv6 addresses for RPM
destinations or servers:

• IPv6 RPM uses ICMPv6 probe requests. You cannot configure ICMP or ICMP timestamp
probe types.
• Only Routing Engine-based RPM is supported for IPv6 targets including VRF support,
specification of the size of the data portion of ICMPv6 probes, data pattern, and traffic
class.
• You can configure probes with a combination of IPv4 and IPv6 tests. However, an
individual test must be either IPv4 or IPv6.
• Routing Engine-based RPM does not support hardware-based, or one-way

hardware-based timestamping.
• We recommend that you include the probe-limit statement at the [edit services rpm]
hierarchy level to set the limit on concurrent probes to 10. Higher concurrent probes
can result in higher spikes.
• SNMP set operation is permitted only on ICMP probes and it is not supported for other
probe types.
• The following table describes the IPv6 special address prefixes that you cannot
configure in a probe.
IPV6 Address Type IPV6 Address Prefix
Node-Scoped Unicast ::1/128 is the loopback address
::/128 is the unspecified address
IPv4-Mapped Addresses ::FFFF:0:0/96
IPv4-Compatible Addresses :<ipv4-address>/96
Link-Scoped Unicast fe80::/10
Unique-Local fc00::/7
Documentation Prefix 2001:db8::/32
6to4 2002::/16
6bone 5f00::/8
ORCHID 2001:10::/28
Teredo 2001::/32
Default Route ::/0
Multicast ff00::/8

• In Routing Engine-based RPM, route-trip time (RTT) spikes might occur because of
queuing delays, even with a single test.
• Since RPM might open TCP and UDP ports to communicate between the RPM server
and RPM client, we recommend that you use firewalls and distributed denial-of-service
(DDoS) attack filters to protect against security threats.
Related • Configuring IPv6 RPM Probes on page 357

Documentation
RPM Support for VPN Routing and Forwarding
Real-time performance monitoring (RPM) is supported on all Juniper Network devices.
VRF in a Layer 3 VPN implementation allows multiple instances of a routing table to

coexist within the same device at the same time. Because the routing instances are
independent, the same or overlapping IPv4 or IPv6 addresses can be used without
conflicting each other.
RPM ICMP and UDP probe with VPN routing and forwarding (VRF) has been improved.
In previous releases, the RPM probes specified to a VRF table were not handled by the
real-time forwarding process (FWDD-RT). In Junos OS Release 10.0, RPM probes specified
to a VRF table are handled by the FWDD-RT, thereby providing more accurate results.
This feature supports RPM ICMP and UDP probes configured with routing instances of
type VRF.
Related • RPM Overview on page 341

Documentation
Example: Configuring Basic RPM Probes
This example shows how to configure basic RPM probes to measure performance between
two network endpoints.

Requirements
Before you begin:

Overview
In this example, you configure basic probes for two RPM owners, customerA and
customerB. You configure the RPM test as icmp-test for customerA with a test interval
of 15 seconds and specify a probe type as icmp-ping-timestamp, a probe timestamp,
and a target address as 192.178.16.5. You then configure the RPM thresholds and
corresponding SNMP traps to catch ingress (inbound) times greater than 3000
microseconds.
Then you configure the RPM test as http-test for customerB with a test interval of 30
seconds and specify a probe type as http-get and a target URL as http://customerB.net.
Finally, you configure RPM thresholds and corresponding SNMP traps as probe-failure
and test-failure to catch three or more successive lost probes and total lost probes of
10.
Configuration
set services rpm probe customerA test icmp-test probe-interval 15

set services rpm probe customerA test icmp-test probe-type icmp-ping-timestamp
set services rpm probe customerA test icmp-test hardware-timestamp
set services rpm probe customerA test icmp-test target address 192.178.16.5
set services rpm probe customerA test icmp-test thresholds ingress-time 3000
set services rpm probe customerA test icmp-test traps ingress-time-exceeded
set services rpm probe customerB test http-test probe-interval 30
set services rpm probe customerB test http-test probe-type http-get
set services rpm probe customerB test http-test target url http://customerB.net
set services rpm probe customerB test http-test thresholds successive-loss 3
set services rpm probe customerB test http-test thresholds total-loss 10
set services rpm probe customerB test http-test traps probe-failure
set services rpm probe customerB test http-test traps test-failure
To configure basic RPM probes:
1. Configure the RPM.
[edit]
user@host# edit services rpm
2. Configure the RPM owners.
[edit services rpm]

user@host# set probe customerA
user@host# set probe customerB

3. Configure the RPM test for customerA.
[edit services rpm]

user@host# edit probe customerA
user@host# set test icmp-test probe-interval 15
user@host# set test icmp-test probe-type icmp-ping-timestamp
4. Specify a probe timestamp and a target address.
[edit services rpm probe customerA]

user@host# set test icmp-test hardware-timestamp
user@host# set test icmp-test target address 192.178.16.5
5. Configure RPM thresholds and corresponding SNMP traps.

user@host# set test icmp-test thresholds ingress-time 3000
user@host# set test icmp-test traps ingress-time-exceeded
6. Configure the RPM test for customerB.
[edit]
user@host# edit services rpm probe customerB
user@host# set test http-test probe-interval 30
7. Specify a probe type and a target URL.
[edit services rpm probe customerB]

user@host# set test http-test probe-type http-get
user@host# set test http-test target url http://customerB.net
8. Configure RPM thresholds and corresponding SNMP traps.
[edit services rpm probe customerB]

user@host# set test http-test thresholds successive-loss 3
user@host# set test http-test thresholds total-loss 10
user@host# set test http-test traps probe-failure
user@host# set test http-test traps test-failure
Results From configuration mode, confirm your configuration by entering the show services rpm
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
[edit]
user@host# show services rpm
probe customerA {
test icmp-test {
probe-type icmp-ping-timestamp;
target address 192.0.2.2;
probe-interval 15;
thresholds {
ingress-time 3000;
}
traps ingress-time-exceeded;
hardware-timestamp;
}
}
probe customerB {
test http-test {

probe-type http-get
target url http://customerB.net;
probe-interval 30;
thresholds {
successive-loss 3;
total-loss 10;
}
traps [ probe-failure test-failure ];
}
}
Verification
Confirm that the configuration is working properly.
• Verifying RPM Services on page 350

• Verifying RPM Statistics on page 350
Verifying RPM Services
Purpose Verify that the RPM configuration is within the expected values.
Action From configuration mode, enter the show services rpm command. The output shows the
values that are configured for RPM on the device.
Verifying RPM Statistics
Purpose Verify that the RPM probes are functioning and that the RPM statistics are within expected
values.
Action From configuration mode, enter the show services rpm probe-results command.
user@host> show services rpm probe-results
Owner: customerD, Test: icmp-test

Probe type: icmp-ping-timestamp
Minimum Rtt: 312 usec, Maximum Rtt: 385 usec, Average Rtt: 331 usec,
Jitter Rtt: 73 usec, Stddev Rtt: 27 usec
Minimum egress time: 0 usec, Maximum egress time: 0 usec,
Average egress time: 0 usec, Jitter egress time: 0 usec,
Stddev egress time: 0 usec
Minimum ingress time: 0 usec, Maximum ingress time: 0 usec,
Average ingress time: 0 usec, Jitter ingress time: 0 usec,
Stddev ingress time: 0 usec
Owner: customerE, Test: http-test

Target address: 192.176.17.4, Target URL: http://customerB.net,
Probe type: http-get
Minimum Rtt: 1093 usec, Maximum Rtt: 1372 usec, Average Rtt: 1231 usec,
Jitter Rtt: 279 usec, Stddev Rtt: 114 usec
Owner: Rpm-Bgp-Owner, Test: Rpm-Bgp-Test-1

Target address: 10.209.152.37, Probe type: icmp-ping, Test size: 5 probes

Routing Instance Name: LR1/RI1
Probe results:
Response received, Fri Oct 28 05:20:23 2005
Rtt: 662 usec
Results over current test:
Results over all tests:

Documentation
Example: Configuring RPM Using TCP and UDP Probes
This example shows how to configure RPM using TCP and UDP probes.

Requirements
Before you begin:
• Configure the probe owner, the test, and the specific parameters of the RPM probe.
See “Example: Configuring Basic RPM Probes” on page 347.
Overview
In this example, you configure both the host (device A) and the remote device (device
B) to act as TCP and UDP servers. You configure a probe for customerC, which uses TCP
packets. Device B is configured as an RPM server for both TCP and UDP packets, using
an lt services interface as the destination interface, and ports 50000 and 50037,
respectively.

CAUTION: Use probe classification with caution, because improper

configuration can cause packets to be dropped.
Configuration
{device A}
set services rpm probe customerC test tcp-test probe-interval 5
set services rpm probe customerC test tcp-test probe-type tcp-ping
set services rpm probe customerC test tcp-test target address 192.162.45.6
set services rpm probe customerC test tcp-test destination-interface lt-0/0/0
set services rpm probe customerC test tcp-test destination-port 50000
{device B}
set services rpm probe-server tcp port 50000
set services rpm probe-server udp port 50037
To configure RPM using TCP and UDP probes:
1. Configure the RPM owner on device A.
{device A}
[edit]
user@host# set probe customerC
2. Configure the RPM test.
{device A}
[edit services rpm]
user@host# edit services rpm probe customerC
user@host# set test tcp-test probe-interval 5
3. Set the probe type.
{device A}
[edit services rpm probe customerC]
user@host# set test tcp-test probe-type tcp-ping
4. Specify the target address.
{device A}
user@host# set test tcp-test target address 192.162.45.6
5. Configure the destination interface.
{device A}

user@host# set test tcp-test destination-interface It-0/0/0
6. Configure port 50000 as the TCP port to which the RPM probes are sent.
{device A}
user@host# set test tcp-test destination-port 50000
7. Configure device B to act as a TCP server using port 50000.
{device B}
[edit]
user@host# set probe-server tcp port 50000
8. Configure device B to act as a UDP server using port 50037.
{device B}
[edit services rpm]
user@host# set probe-server udp port 50037
[edit]
probe customerC {
test tcp-test {
probe-type tcp-ping;
target address 192.162.45.6;
probe-interval 5;
destination-port 50000;
destination-interface lt-0/0/0.0;
}
}
probe-server {
tcp {
port 50000;
}
udp {
port 50037;
}
}
Verification
Verifying RPM Probe Servers
Verify that the device is configured to receive and transmit TCP and UDP RPM probes
on the correct ports.

Action From configuration mode, enter the show services rpm active-servers command. The
output shows a list of the protocols and corresponding ports for which the device is
configured as an RPM server.
user@host> show services rpm active-servers
Protocol: TCP, Port: 50000
Protocol: UDP, Port: 50037

Documentation
Example: Configuring RPM Probes for BGP Monitoring
This example shows how to configure RPM probes to monitor BGP neighbors.

Requirements
Before you begin:
• Configure the BGP parameters under RPM configuration to send RPM probes to BGP
neighbors. See “Example: Configuring Basic RPM Probes” on page 347.
• Use TCP or UDP probes by configure both the probe server (Juniper Networks device)
and the probe receiver (the remote device) to transmit and receive RPM probes on the
same TCP or UDP port. See “Example: Configuring RPM Using TCP and UDP Probes”
on page 351.
Overview
In this example, you specify a hexadecimal value that you want to use for the data portion
of the RPM probe as ABCD123. ( It ranges from 1 through 2048 characters.) You specify
the data size of the RPM probe as 1024 bytes. ( The value ranges from 0 through 65,507.)
Then you configure destination port 50000 as the TCP port to which the RPM probes
are sent. You specify the number of probe results to be saved in the probe history as 25.
(It ranges from 0 through 255, and the default is 50.) You set the probe count to 5 and
probe interval as 1. (The probe count ranges from 1 through 15, and the default is 1; and

the probe interval ranges from 1 through 255, and the default is 3.) You then specify
tcp-ping as the type of probe to be sent as part of the test.
Finally, you set the test interval as 60. The value ranges from 0 through 86,400 seconds
for the interval between tests.
Configuration
set services rpm bgp data-fill ABCD123 data-size 1024

set services rpm bgp destination-port 50000 history-size 25
set services rpm bgp probe-count 5 probe-interval 1
set services rpm bgp probe-type tcp-ping test-interval 60
To configure RPM probes to monitor BGP neighbors:
1. Configure the RPM and BGP.
[edit]
user@host# edit services rpm bgp
2. Specify a hexadecimal value.
[edit services rpm bgp]

user@host# set data-fill ABCD123
3. Specify the data size of the RPM probe.

user@host# set data-size 1024
4. Configure the destination port.

user@host# set destination-port 50000
5. Specify the number of probes.

user@host# set history-size 25
6. Set the probe count and probe interval.

user@host# set probe-count 5 probe-interval 1
7. Specify the type of probe.

user@host# set probe-type tcp-ping

NOTE: If you do not specify the probe type the default ICMP probes are
sent.
8. Set the test interval.

user@host# set test-interval 60
[edit]
bgp {
probe-type tcp-ping;
probe-count 5;
probe-interval 1;
test-interval 60;
history-size 25;
data-size 1024;
data-fill ABCD123;
}
Verification
Verifying RPM Probes for BGP Monitoring
Verify that the RPM probes for BGP monitoring is configured.
Action From configuration mode, enter the show services rpm command.

Documentation
• Directing RPM Probes to Select BGP Devices on page 356
Directing RPM Probes to Select BGP Devices

If a device has a large number of BGP neighbors configured, you can direct (filter) the
RPM probes to a selected group of BGP neighbors rather than to all the neighbors. To
identify the BGP devices to receive RPM probes, you can configure routing instances.
The following example requires you to navigate various levels in the configuration
hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
To direct RPM probes to select BGP neighbors:
1. Configure routing instance RI1 to send RPM probes to BGP neighbors within the routing
instance.

user@host# set routing-instances RI1
2. If you are done configuring the device, enter commit from configuration mode.

Documentation
Configuring IPv6 RPM Probes
Starting with Junos OS Release 15.1X49-D10, you can configure IPv6 destination addresses
for an IPv6-based RPM probe test.
To configure an IPv6 RPM test:
1. Specify the RPM probe owner for the probe you want to configure as an IPv6 test.
[edit services rpm]

user@host# edit probe customerA
2. Specify a name for the test.

user@host# edit test ipv6-test
3. Specify the probe type.
[edit services rpm probe customerA test ipv6-test]

user@host# set probe-type icmp6-ping
4. Specify the target address for the test.
[edit services rpm probe customerA test ipv6-test]

user@host# set target inet6-address 2001::2
5. Configure the remaining RPM test parameters.

Related • Guidelines for Configuring RPM Probes for IPv6 on page 345
Documentation
Tuning RPM Probes
After configuring an RPM probe, you can set parameters to control probe functions, such
as the interval between probes, the total number of concurrent probes that a system
can handle, and the source address used for each probe packet. See “Example: Configuring
Basic RPM Probes” on page 347.
The following example requires you to navigate various levels in the configuration
hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
To tune RPM probes:
1. Set the maximum number of concurrent probes allowed on the system to 10.
[edit services rpm]

user@host# set probe-limit 10
2. Access the ICMP probe of customer A.
[edit]
user@host# edit services rpm probe customerA test icmp-test
3. Set the time between probe transmissions to 15 seconds.
[edit services rpm probe customerA test icmp-test]

user@host# set probe-interval 15
4. Set the number of probes within a test to 10.

user@host# set probe-count 10
5. Set the source address for each probe packet to 192.168.2.9. If you do not explicitly
configure a source address, the address on the outgoing interface through which the
probe is sent is used as the source address.

user@host# set source-address 192.168.2.9

Documentation
RPM Configuration Options

You can configure real-time performance monitoring (RPM) parameters. See

Table 43 on page 359 for a summary of the configuration options.
Table 43: RPM Configuration Summary

Field Function Your Action
Performance Probe Owners

Owner Name Identifies an RPM owner for which one or more RPM Type the name of the RPM owner.
(required) tests are configured. In most implementations, the
owner name identifies a network on which a set of
tests is being run (a particular customer, for example).
Identification
Test name (required) Uniquely identifies the RPM test Type the name of the RPM test.
Target (Address or IPv4 or IPv6 address or URL of probe target Type the IPv4 address, in dotted decimal
URL) (required) notation, IPv6 address, or the URL of the probe
target. If the target is a URL, type a fully formed
URL that includes http://.
Source Address Explicitly configured IPv4 or IPv6 address to be used Type the source address to be used for the
as the probe source address probe. If the source address is not one of the
device's assigned addresses, the packet uses
the outgoing interface's address as its source.
Routing Instance Particular routing instance over which the probe is Type the routing instance name. The routing
sent instance applies only to probes of type icmp ,
icmp6-ping, and icmp-timestamp. The default
routing instance is inet.0.
History Size Number of probe results saved in the probe history Type a number between 0 and 255. The default
history size is 50 probes.
Request Information
Probe Type (required) Specifies the type of probe to send as part of the test. Select the desired probe type from the list:
• http-get
• icmp6-ping
• icmp-ping
• tcp-ping
• udp-ping
Interval Sets the wait time (in seconds) between each probe Type a number between 1 and 255 (seconds).
transmission
Test Interval Sets the wait time (in seconds) between tests. Type a number between 0 and 86400
(required) (seconds).
Probe Count Sets the total number of probes to be sent for each Type a number between 1 and 15.
test.

Table 43: RPM Configuration Summary (continued)

Destination Port Specifies the TCP or UDP port to which probes are Type the number 7—a standard TCP or UDP
sent. port number—or a port number from 49152
through 65535.
To use TCP or UDP probes, you must configure the
remote server as a probe receiver. Both the probe
server and the remote server must be Juniper
Networks devices configured to receive and transmit
RPM probes on the same TCP or UDP port.
DSCP Bits Specifies the Differentiated Services code point Type a valid 6–bit pattern.
(DSCP) bits. This value must be a valid 6–bit pattern.
The default is 000000.
Data Size Specifies the size of the data portion of the ICMP Type a size (in bytes) between 0 and 65507.
probes.
Data Fill Specifies the contents of the data portion of the ICMP Type a hexadecimal value between 1 and 800h
probes. to use as the contents of the ICMP probe data.
Hardware Timestamp Enables timestamping of RPM probe messages. You To enable timestamping, select the check box.
can timestamp the following RPM probes to improve
the measurement of latency or jitter:
• ICMP ping
• ICMP ping timestamp
• UDP ping—destination port UDP-ECHO (port 7)
only
• UDP ping timestamp—destination port UDP-ECHO
(port 7) only
Maximum Probe Thresholds

Successive Lost Sets the total number of probes that must be lost Type a number between 0 and 15.
Probes successively to trigger a probe failure and generate a
system log message.
Lost Probes Sets the total number of probes that must be lost to Type a number between 0 and 15.
trigger a probe failure and generate a system log
message.
Round Trip Time Sets the total round-trip time (in microseconds), from Type a number between 0 and 60,000,000
the device to the remote server, that triggers a probe (microseconds).
failure and generates a system log message.
Jitter Sets the total jitter (in microseconds), for a test, that Type a number between 0 and 60,000,000
triggers a probe failure and generates a system log (microseconds).
message.
Standard Deviation Sets the maximum allowable standard deviation (in Type a number between 0 and 60,000,000
microseconds) for a test, which, if exceeded, triggers (microseconds).
a probe failure and generates a system log message.


Egress Time Sets the total one-way time (in microseconds), from Type a number between 0 and 60,000,000
the device to the remote server, that triggers a probe (microseconds).
Ingress Time Sets the total one-way time (in microseconds), from Type a number between 0 and 60,000,000
the remote server to the device, that triggers a probe (microseconds)
Jitter Egress Time Sets the total outbound-time jitter (in microseconds), Type a number between 0 and 60,000,000
for a test, that triggers a probe failure and generates (microseconds)
a system log message.
Jitter Ingress Time Sets the total inbound-time jitter (in microseconds), Type a number between 0 and 60,000,000
for a test, that triggers a probe failure and generates (microseconds).
a system log message.
Egress Standard Sets the maximum allowable standard deviation of Type a number between 0 and 60,000,000
Deviation outbound times (in microseconds) for a test, which, (microseconds).
if exceeded, triggers a probe failure and generates a
system log message.
Ingress Standard Sets the maximum allowable standard deviation of Type a number between 0 and 60,000,000
Deviation inbound times (in microseconds) for a test, which, if (microseconds).
exceeded, triggers a probe failure and generates a
system log message.
Traps
Egress Jitter Generates SNMP traps when the threshold for jitter • To enable SNMP traps for this condition,
Exceeded in outbound time is exceeded. select the check box.
• To disable SNMP traps, clear the check box.
Egress Standard Generates SNMP traps when the threshold for • To enable SNMP traps for this condition,
Deviation Exceeded standard deviation in outbound times is exceeded. select the check box.
Egress Time Generates SNMP traps when the threshold for • To enable SNMP traps for this condition,
Exceeded maximum outbound time is exceeded. select the check box.
Ingress Jitter Generates SNMP traps when the threshold for jitter • To enable SNMP traps for this condition,
Exceeded in inbound time is exceeded. select the check box.
Ingress Standard Generates SNMP traps when the threshold for • To enable SNMP traps for this condition,
Deviation Exceeded standard deviation in inbound times is exceeded. select the check box.
Ingress Time Generates traps when the threshold for maximum • To enable SNMP traps for this condition,
Exceeded inbound time is exceeded. select the check box.


Jitter Exceeded Generates traps when the threshold for jitter in • To enable SNMP traps for this condition,
round-trip time is exceeded. select the check box.
Probe Failure Generates traps when the threshold for the number • To enable SNMP traps for this condition,
of successive lost probes is reached. select the check box.
RTT Exceeded Generates traps when the threshold for maximum • To enable SNMP traps for this condition,
round-trip time is exceeded. select the check box.
Standard Deviation Generates traps when the threshold for standard • To enable SNMP traps for this condition,
Exceeded deviation in round-trip times is exceeded. select the check box.
Test Completion Generates traps when a test is completed. • To enable SNMP traps for this condition,
select the check box.
Test Failure Generates traps when the threshold for the total • To enable SNMP traps for this condition,
number of lost probes is reached. select the check box.
Performance Probe Server

TCP Probe Server Specifies the port on which the device is to receive Type the number 7—a standard TCP or UDP
and transmit TCP probes. port number—or a port number from 49160
through 65535.
UDP Probe Server Specifies the port on which the device is to receive Type the number 7—a standard TCP or UDP
and transmit UDP probes. port number—or a port number from 49160
through 65535.

Documentation
• Example: Configuring RPM Using TCP and UDP Probes on page 351
Monitoring RPM Probes
The RPM information includes the round-trip time, jitter, and standard deviation values
for each configured RPM test on the device. To view these RPM properties, select
Troubleshoot>RPM>View RPM in the J-Web user interface, or in configuration mode enter
the show command:

[edit]
user@host# run show services rpm probe-results
In addition to the RPM statistics for each RPM test, the J-Web user interface displays the
round-trip times and cumulative jitter graphically. Figure 8 on page 363 shows sample
graphs for an RPM test.
Figure 8: Sample RPM Graphs
In Figure 8 on page 363, the round-trip time and jitter values are plotted as a function of
the system time. Large spikes in round-trip time or jitter indicate a slower outbound
(egress) or inbound (ingress) time for the probe sent at that particular time.
Table 44 on page 363 summarizes key output fields in RPM displays.
Table 44: Summary of Key RPM Output Fields

Field Values Additional Information
Currently Running Tests

Graph Click the Graph link to display the graph (if it is not already
displayed) or to update the graph for a particular test.
Owner Configured owner name of the RPM test. –
Test Name Configured name of the RPM test. –

Table 44: Summary of Key RPM Output Fields (continued)

Probe Type Type of RPM probe configured for the specified test: –
• http-get
• icmp-ping
• icmp6-ping
• tcp-ping
• udp-ping
Target IPv4 address, IPv6 address, or URL of the remote –

Address server that is being probed by the RPM test.
Source Explicitly configured IPv4 or IPv6 source address that If no source address is configured, the RPM probe packets
Address is included in the probe packet headers. use the outgoing interface as the source address, and
the Source Address field is empty.
Minimum Shortest round-trip time from the Juniper Networks –

RTT device to the remote server, as measured over the
course of the test.
Maximum Longest round-trip time from the Juniper Networks –

course of the test.
Average Average round-trip time from the Juniper Networks –

course of the test.
Standard Standard deviation of round-trip times from the –

Deviation Juniper Networks device to the remote server, as
RTT measured over the course of the test.
Probes Total number of probes sent over the course of the –

Sent test.
Loss Percentage of probes sent for which a response was –

Percentage not received.
Round-Trip Time for a Probe

Samples Total number of probes used for the data set. The Juniper Networks device maintains records of the
most recent 50 probes for each configured test. These
50 probes are used to generate RPM statistics for a
particular test.
Earliest System time when the first probe in the sample was –
Sample received.
Latest System time when the last probe in the sample was –
Sample received.

Table 44: Summary of Key RPM Output Fields (continued)

Mean Value Average round-trip time for the 50-probe sample. –
Standard Standard deviation of the round-trip times for the –

Deviation 50-probe sample.
Lowest Shortest round-trip time from the device to the remote –

Value server, as measured over the 50-probe sample.
Time of System time when the lowest value in the 50-probe –

Lowest sample was received.
Sample
Highest Longest round-trip time from the Juniper Networks –

Value device to the remote server, as measured over the
50-probe sample.
Time of System time when the highest value in the 50-probe –

Highest sample was received.
Sample
Cumulative Jitter for a Probe

Samples Total number of probes used for the data set. The Juniper Networks device maintains records of the
most recent 50 probes for each configured test. These
50 probes are used to generate RPM statistics for a
particular test.
Earliest System time when the first probe in the sample was –
Sample received.
Latest System time when the last probe in the sample was –
Sample received.
Mean Value Average jitter for the 50-probe sample. –
Standard Standard deviation of the jitter values for the 50-probe –

Deviation sample.
Lowest Smallest jitter value, as measured over the 50-probe –

Value sample.
Time of System time when the lowest value in the 50-probe –

Lowest sample was received.
Sample
Highest Highest jitter value, as measured over the 50-probe –

Value sample.
Time of System time when the highest jitter value in the –

Highest 50-probe sample was received.
Sample


Documentation

CHAPTER 21
Configuring IP Monitoring
• IP Monitoring Overview on page 367

• Understanding IP Monitoring Test Parameters on page 368
• Example: Configuring IP Monitoring on SRX Series Devices on page 369
• Understanding IP Monitoring Through Redundant Ethernet Interface Link Aggregation
Groups on page 371
• Example: Configuring IP Monitoring on SRX Series Devices on page 372
• Example: Configuring Chassis Cluster Redundancy Group IP Address
Monitoring on page 377
IP Monitoring Overview
This feature monitors IP on standalone SRX Series devices or a chassis cluster redundant
Ethernet (reth) interface. Existing RPM probes are sent to an IP address to check for
reachability. The user takes action based on the reachability result. Supported action
currently is preferred static route injection to system route table.
The actions supported are:
• Adding or deleting a new static route that has a higher priority (lower preference) value
than a route configured through the CLI command set routing-options static route
• Defining multiple probe names under the same IP monitoring policy. If any probe fails,
the action is taken. If all probes are reachable, the action is reverted
• Configuring multiple tests in one RPM probe. All tests must fail for the RPM probe to
be considered unreachable. If at least one test reaches its target, the RPM probe is
considered reachable
• Configuring multiple failure thresholds in one RPM test. If one threshold is reached, the
test fails. If no thresholds are reached, the test succeeds.
• Specifying the no-preempt option. If the no-preempt option is specified, the policy
does not perform preemptive failback when it is in a failover state or when the RPM
probe test recovers from a failure.

• Setting preferred metric values. If the preferred metric value is set, during failover, the
route is injected with the set preferred metric value.
• Enabling and disabling interfaces.
• Interface-Enable—On a physical or logical interface, when the interface-enable

action is configured, the initial state of the interface is disable after startup, and it
continues to remain in the disable state as long as the associated RPM probe is in
the pass state. When the associated RPM probe fails, the configured physical and
logical interfaces are enabled.
• Interface-Disable—On a physical or logical interface, when the interface-disable

action is configured, the interface state remains unchanged. When the associated
RPM probe fails, the physical and logical interfaces are disabled.
NOTE: Multiple probe names and actions can be defined for the same IP
monitoring policy.
Related • Understanding IP Monitoring Test Parameters on page 368

Documentation
Understanding IP Monitoring Test Parameters
Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX550M, vSRX
Each probed target is monitored over the course of a test, which represents a collection
of probes during which statistics such as standard deviation and jitter are collected are
calculated. During a test, probes are generated and responses collected at a rate defined
by the probe interval, the number of seconds between probes.
NOTE: To avoid flap, an action is reverted only at the end of a test cycle.
During the test cycle, if no threshold is reached, the action is reverted. Although
action-failover takes place based on a predefined condition of a monitored
IP, when the condition is reversed, the IP becomes reachable on the original
route, and the newly added route is deleted. Recovery is performed only when
all RPM probes report the IP as reachable.
Table 45 on page 368 lists the test parameters and its default values:
Table 45: Test Parameters and Default Values

Parameter Default Value
probe-count 1
probe-interval 3 seconds
test-interval 1 second

Chapter 21: Configuring IP Monitoring
Table 46 on page 369 lists the supported threshold and its description:
Table 46: Threshold Supported and Description

Threshold Description
Successive-Loss Successive loss count of probes
Total-Loss Total probe lost count
Related • IP Monitoring Overview on page 367

Documentation
Example: Configuring IP Monitoring on SRX Series Devices
This example shows how to monitor IP on SRX300, SRX320, SRX340, SRX550M, and
SRX1500 devices.

Requirements
Before you begin:
Configure the following RPM options for RPM test:
• target-address
• probe-count
• probe-interval
• test-interval
• thresholds
• next-hop
Overview
This example shows how to set up IP monitoring on an SRX Series device.
Configuration
CLI Quick To quickly configure this example, copy the following commands, past them into a text
Configuration file, remove any line breaks, change any details to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.

set services rpm probe Probe-Payment-Server test paysvr target address 1.1.1.10
set services rpm probe Probe-Payment-Server test paysvr probe-count 10
set services rpm probe Probe-Payment-Server test paysvr probe-interval 5
set services rpm probe Probe-Payment-Server test paysvr test-interval 5
set services rpm probe Probe-Payment-Server test paysvr thresholds successive-loss 10
set services rpm probe Probe-Payment-Server test paysvr next-hop 2.2.2.1
set services ip-monitoring policy Payment-Server-Tracking match rpm-probe
Probe-Payment-Server
set services ip-monitoring policy Payment-Server-Tracking then preferred-route route
1.1.1.0/24 next-hop 1.1.1.99
To configure IP monitoring on an SRX Series Services Gateway:
1. Configure the target address under the RPM probe.
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr target address
1.1.1.10
2. Configure the probe count under the RPM probe.
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr probe-count
10
3. Configure the probe interval (in seconds) under the RPM probe.
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr probe-interval
5
4. Configure the test interval (in seconds) under the RPM probe.
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr test-interval
5
5. Configure the threshold successive loss count under the RPM
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr thresholds
successive-loss 10
6. Configure the next-hop IP address under the RPM probe.
[edit ]
user@host# set services rpm probe Probe-Payment-Server test paysvr next-hop
2.2.2.1
7. Configure the IP monitoring policy under services.
[edit ]
user@host# set services ip-monitoring policy Payment-Server-Tracking match
rpm-probe Probe-Payment-Server

NOTE: The following steps are not mandatory. You can configure
interface actions and route actions independently, or you can configure
both the interface action and the route action together in one IP
monitoring policy.
8. Configure the IP monitoring preferred route under services.
[edit ]
user@host# set services ip-monitoring policy Payment-Server-Tracking then
preferred-route route 1.1.1.0/24 preferred-metric 4
9. Configure the IP monitoring interface actions.
• Enable
[edit ]
interface ge-0/0/1 enable
• Disable
[edit ]
interface fe-0/0/[4-6] disable
10. Configure the no-preempt option.
[edit ]
user@host# set services ip-monitoring policy Payment-Server-Tracking no-preempt
Verification
Verifying IP Monitoring
Purpose Verify the IP monitoring status of a policy.
Action To verify the configuration is working properly, enter the following command:
show services ip-monitoring status <policy-name>

Documentation
• Understanding IP Monitoring Test Parameters on page 368
Understanding IP Monitoring Through Redundant Ethernet Interface Link Aggregation

Groups
IP monitoring checks the reachability of an upstream device. It is designed to check the

end-to-end connectivity of configured IP addresses and allows a redundancy group (RG)
to automatically failover when the monitored IP address is not reachable through the

redundant Ethernet. Both the primary and secondary devices in the chassis cluster monitor
specific IP addresses to determine whether an upstream device in the network is
reachable.
A redundant Ethernet interface contains physical interfaces from both the primary and
secondary nodes in the SRX Series chassis cluster. In a redundant Ethernet interface,
two physical interfaces are configured with each node contributing one physical interface.
In a redundant Ethernet interface LAG, more than two physical interfaces are configured
in the redundant Ethernet interface.

Documentation
Example: Configuring IP Monitoring on SRX Series Devices
Supported Platforms SRX1500, SRX5600, SRX5800, vSRX
This example shows how to monitor IP on SRX1500, SRX5600, and SRX5800 devices
with chassis cluster enabled.

Requirements
• You need two SRX5800 Services Gateways with identical hardware configurations,
one SRX Series device and one EX8208 Ethernet Switch.
• Physically connect the two SRX5800 devices (back-to-back for the fabric and control
ports) and ensure that they are the same models. Configure/add these two devices in
a cluster.
Overview
IP address monitoring checks end-to-end reachability of configured IP address and allows
a redundancy group to automatically fail over when not reachable through the child link
of redundant Ethernet interface (known as a reth) interface. Redundancy groups on both
devices in a cluster can be configured to monitor specific IP addresses to determine
whether an upstream device in the network is reachable.
This example shows how to set up IP monitoring on an SRX Series device.
NOTE: IP monitoring is not supported on an NP-IOC card.
NOTE: IP monitoring does not support MIC online/offline status on SRX

devices.

Topology
Figure 9 on page 373 shows the topology used in this example.
Figure 9: IP Monitoring on an SRX Series Device Topology Example
In this example, two SRX5800 devices in a chassis cluster are connected to an SRX650
device through an EX8208 Ethernet Switch. The example shows how the redundancy
groups can be configured to monitor key upstream resources reachable through redundant
Ethernet interfaces on either node in a cluster.
Configuration
• Configuring IP Monitoring on SRX Series Device on page 374
Configuration file, remove any line breaks, change any details to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
set chassis cluster reth-count 1

set chassis cluster redundancy-group 0 node 0 priority 254
set chassis cluster redundancy-group 1 ip-monitoring global-weight 255
set chassis cluster redundancy-group 1 ip-monitoring global-threshold 80
set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3
set chassis cluster redundancy-group 1 ip-monitoring retry-count 10

set chassis cluster redundancy-group 1 ip-monitoring family inet 192.0.2.0 weight

80
set chassis cluster redundancy-group 1 ip-monitoring family inet 192.0.2.0
interface reth0.0 secondary-ip-address 198.51.100.1
set interfaces ge-0/0/1 gigether-options redundant-parent reth0
set interfaces ge-4/0/1 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 192.0.2.0/24
set routing-options static route 192.0.2.0/24 next-hop 198.51.100.1
Configuring IP Monitoring on SRX Series Device
To configure IP monitoring on an SRX Series device:
1. Specify the number of redundant Ethernet interfaces.
{primary:node0}[edit]
user@host# set chassis cluster reth-count 1
2. Specify a redundancy group's priority for primacy on each node of the cluster. The
higher number takes precedence.
user@host# set chassis cluster redundancy-group 0 node 0 priority 254
3. Configure the redundant Ethernet interfaces to redundancy-group 1.
user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
user@host# set interfaces reth0 unit 0 family inet address 198.51.100.0/24
4. Assign child interfaces for the redundant Ethernet interfaces from node 0 and node
1.
user@host# set interfaces ge-0/0/1 gigether-options redundant-parent reth0
user@host# set interfaces ge-4/0/1 gigether-options redundant-parent reth0
5. Configure the static route to the IP address that is to be monitored.
user@host# set routing-options static route 192.0.2.0/24 next-hop 198.51.100.1
6. Configure IP monitoring under redundancy-group 1 with global weight and global

threshold.
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-weight
255
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-threshold
80
7. Specify the retry interval.

user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3
8. Specify the retry count.
user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-count 10
9. Assign a weight to the IP address to be monitored, and configure a secondary IP

address that will be used to send ICMP packets from the secondary node to track
the IP being monitored.
user@host# set chassis cluster redundancy-group 1 ip-monitoring family inet
192.0.2.0 weight 80
user@host# set chassis cluster redundancy-group 1 ip-monitoring family inet
192.0.2.0 interface reth0.0 secondary-ip-address 198.51.100.2
NOTE:
• The redundant Ethernet (reth0) IP address, 198.51.100.0/24, is used
to send ICMP packets from node 0 to check the reachability of the

monitored IP.
• The secondary IP address, 198.51.100.2, should belong to the same

network as the reth0 IP address.
• The secondary IP address is used to send ICMP packets from node 1

to check the reachability of the monitored IP.
Verification
Confirm the configuration is working properly.
• Verifying Chassis Cluster Status—Before Failover on page 375

• Verifying Chassis Cluster IP Monitoring Status—Before Failover on page 376
• Verifying Chassis Cluster Status—After Failover on page 376
• Verifying Chassis Cluster IP Monitoring Status—After Failover on page 377
Verifying Chassis Cluster Status—Before Failover
Purpose Verify the chassis cluster status, failover status, and redundancy group information before
failover.

Action From operational mode, enter the show chassis cluster status command.
show chassis cluster status
Cluster ID: 11
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 0

node0 254 primary no no
node1 1 secondary no no

Verifying Chassis Cluster IP Monitoring Status—Before Failover
Purpose Verify the IP status being monitored from both nodes and the failover count for both
nodes before failover.
Action From operational mode, enter the show chassis cluster ip-monitoring status
redundancy-group 1 command.
show chassis cluster ip-monitoring status redundancy-group 1
node0:
--------------------------------------------------------------------------
Redundancy group: 1
IP address Status Failure count Reason

192.0.2.0 reachable 0 n/a
node1:
--------------------------------------------------------------------------
Redundancy group: 1

Verifying Chassis Cluster Status—After Failover
Purpose Verify the chassis cluster status, failover status, and redundancy group information after
failover.
NOTE: If the IP address is not reachable, the following output will be

displayed.

Action From operational mode, enter the show chassis cluster status command.
show chassis cluster status
Cluster ID: 11
Node Priority Status Preempt Manual failover


Verifying Chassis Cluster IP Monitoring Status—After Failover
Purpose Verify the IP status being monitored from both nodes and the failover count for both
nodes after failover.
Action From operational mode, enter the show chassis cluster ip-monitoring status
redundancy-group 1 command.
show chassis cluster ip-monitoring status redundancy-group 1
node0:
--------------------------------------------------------------------------
Redundancy group: 1

192.0.2.0 unreachable 1 unknown
node1:
--------------------------------------------------------------------------
Redundancy group: 1

Related • Example: Configuring an Active/Passive Chassis Cluster on SRX Series Services Gateways
Documentation
Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring
This example shows how to configure redundancy group IP address monitoring for an
SRX Series device in a chassis cluster.



Requirements
Before you begin:
• Set the chassis cluster node ID and cluster ID. See Example: Setting the Chassis Cluster
Node ID and Cluster ID for SRX Series Devices
• Configure the chassis cluster management interface. See Example: Configuring the
Chassis Cluster Management Interface.
• Configure the chassis cluster fabric. See Example: Configuring the Chassis Cluster Fabric
Interfaces.
Overview
You can configure redundancy groups to monitor upstream resources by pinging specific
IP addresses that are reachable through redundant Ethernet interfaces on either node
in a cluster. You can also configure global threshold, weight, retry interval, and retry count
parameters for a redundancy group. When a monitored IP address becomes unreachable,
the weight of that monitored IP address is deducted from the redundancy group IP
address monitoring global threshold. When the global threshold reaches 0, the global
weight is deducted from the redundancy group threshold. The retry interval determines
the ping interval for each IP address monitored by the redundancy group. The pings are
sent as soon as the configuration is committed. The retry count sets the number of
allowed consecutive ping failures for each IP address monitored by the redundancy group.
In this example, you configure the following settings for redundancy group 1:
• IP address to monitor—10.1.1.10
• IP address monitoring global-weight—100
• IP address monitoring global-threshold—200
NOTE: The threshold applies cumulatively to all IP addresses monitored

by the redundancy group.
• IP address retry-interval—3 seconds
• IP address retry-count—10
• Weight—150
• Redundant Ethernet interface—reth1.0
• Secondary IP address—10.1.1.101

Configuration
user@host#
set chassis cluster redundancy-group 1 ip-monitoring global-weight 100
set chassis cluster redundancy-group 1 ip-monitoring global-threshold 200
set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3
set chassis cluster redundancy-group 1 ip-monitoring retry-count 10
set chassis cluster redundancy-group 1 ip-monitoring family inet 10.1.1.10 weight 150
interface reth1.0 secondary-ip-address 10.1.1.101
Step-by-Step To configure redundancy group IP address monitoring:

Procedure
1. Specify a global monitoring weight.
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-weight
100
2. Specify the global monitoring threshold.
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-threshold
200
3. Specify the retry interval.
user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3
4. Specify the retry count.
user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-count 10
5. Specify the IP address to be monitored, weight, redundant Ethernet interface, and

secondary IP address.
user@host# set chassis cluster redundancy-group 1 ip-monitoring family inet 10.1.1.10
weight 100 interface reth1.0 secondary-ip-address 10.1.1.101
Results From configuration mode, confirm your configuration by entering the show chassis cluster
redundancy-group 1 command. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).
user@host# show chassis cluster redundancy-group 1

ip-monitoring {
global-weight 100;
global-threshold 200;
family {
inet {
10.1.1.10 {
weight 100;
interface reth1.0 secondary-ip-address 10.1.1.101;
}
}
}
}
Verification
Verifying the Status of Monitored IP Addresses for a Redundancy Group
Purpose Verify the status of monitored IP addresses for a redundancy group.
Action From operational mode, enter the show chassis cluster ip-monitoring status command.
For information about a specific group, enter the show chassis cluster ip-monitoring status
redundancy-group command.
{primary:node0}
user@host> show chassis cluster ip-monitoring status
node0:
--------------------------------------------------------------------------
Redundancy group: 1
Global threshold: 200
Current threshold: -120
IP address Status Failure count Reason Weight

10.1.1.10 reachable 0 n/a 220
10.1.1.101 reachable 0 n/a 100
node1:
--------------------------------------------------------------------------
Redundancy group: 1

10.1.1.10 reachable 0 n/a 220
10.1.1.101 reachable 0 n/a 100
Related • Understanding Chassis Cluster Redundancy Group Interface Monitoring

Documentation
• Understanding Chassis Cluster Redundancy Group IP Address Monitoring
• Understanding Chassis Cluster Redundancy Group Failover

PART 7
Monitoring Common Security Features

• Displaying Real-Time Information from Device to Host on page 383
• Monitoring Application Layer Gateways Features on page 389
• Monitoring Interfaces and Switching Functions on page 415
• Monitoring NAT on page 433
• Monitoring Security Policies on page 445
• Monitoring Events, Services and System on page 471
• Monitoring Unified Threat Management Features on page 481
• Monitoring VPNs on page 495


CHAPTER 22
Displaying Real-Time Information from

Device to Host
• Displaying Real-Time Monitoring Information on page 383

• Displaying Multicast Path Information on page 385
Displaying Real-Time Monitoring Information
To display real-time monitoring information about each device between the device and
a specified destination host, enter the traceroute monitor command with the following
syntax:
user@host> traceroute monitor host <count number> <inet | inet6> <interval seconds>
<no-resolve> <size bytes><source source-address> <summary>
Table 47 on page 383 describes the traceroute monitor command options.
Table 47: CLI traceroute monitor Command Options

Option Description
host Sends traceroute packets to the hostname or IP address you specify.
count number (Optional) Limits the number of ping requests, in packets, to send in summary mode. If you do
not specify a count, ping requests are continuously sent until you press Q.
inet (Optional) Forces the traceroute packets to an IPv4 destination.
inet6 (Optional) Forces the traceroute packets to an IPv6 destination.
interval seconds (Optional) Sets the interval between ping requests, in seconds. The default value is 1 second.
no-resolve (Optional) Suppresses the display of the hostnames of the hops along the path.
size bytes (Optional) Sets the size of the ping request packet. The size can be from 0 through 65,468 bytes.
The default packet size is 64 bytes.
source address (Optional) Uses the source address that you specify, in the traceroute packet.

Table 47: CLI traceroute monitor Command Options (continued)

Option Description
summary (Optional) Displays the summary traceroute information.
To quit the traceroute monitor command, press Q.
The following is sample output from a traceroute monitor command:
user@host> traceroute monitor host2
My traceroute [v0.69]
host (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00)
Wed Mar 14 23:14:11 2007
Keys: Help Display mode Restart statistics Order of fields quit
Packets
Pings
Host Loss% Snt
Last Avg Best Wrst StDev
1. 173.24.232.66 0.0% 5
9.4 8.6 4.8 9.9 2.1
2. 173.24.232.66 0.0% 5
7.9 17.2 7.9 29.4 11.0
3. 173.24.232.66 0.0% 5
9.9 9.3 8.7 9.9 0.5
4. 173.24.232.66 0.0% 5
9.9 9.8 9.5 10.0 0.2
Table 48 on page 384 summarizes the output fields of the display.
Table 48: CLI traceroute monitor Command Output Summary

Field Description
host Hostname or IP address of the device issuing the traceroute monitor command.
psizesize Size of ping request packet, in bytes.
Keys
Help Displays the Help for the CLI commands.
Press H to display the Help.
Display mode Toggles the display mode.
Press D to toggle the display mode
Restart statistics Restarts the traceroute monitor command.
Press R to restart the traceroute monitor command.
Order of fields Sets the order of the displayed fields.
Press O to set the order of the displayed fields.

Chapter 22: Displaying Real-Time Information from Device to Host
Table 48: CLI traceroute monitor Command Output Summary (continued)

Field Description
quit Quits the traceroute monitor command.
Press Q to quit the traceroute monitor command.
Packets
number Number of the hop (device) along the route to the final destination host.
Host Hostname or IP address of the device at each hop.
Loss% Percent of packet loss. The number of ping responses divided by the number of ping
requests, specified as a percentage.
Pings
Snt Number of ping requests sent to the device at this hop.
Last Most recent round-trip time, in milliseconds, to the device at this hop.
Avg Average round-trip time, in milliseconds, to the device at this hop.
Best Shortest round-trip time, in milliseconds, to the device at this hop.
Wrst Longest round-trip time, in milliseconds, to the device at this hop.
StDev Standard deviation of round-trip times, in milliseconds, to the device at this hop.
Related • Displaying Log and Trace Files on page 531

Documentation
Displaying Multicast Path Information
To display information about a multicast path from a source to the device, enter the
mtrace from-source command with the following syntax:
user@host> mtrace from-source source host <extra-hops number> <group address>

<interval seconds> <max-hops number> <max-queries number> <response host>
<routing-instance routing-instance-name> <ttl number> <wait-time seconds> <loop>
<multicast-response | unicast-response> <no-resolve> <no-router-alert> <brief |
detail>
Table 49 on page 385 describes the mtrace from-source command options.
Table 49: CLI mtrace from-source Command Options

Option Description
source host Traces the path to the specified hostname or IP address.

Table 49: CLI mtrace from-source Command Options (continued)

Option Description
extra-hops number (Optional) Sets the number of extra hops to trace past nonresponsive devices. Specify
a value from 0 through 255.
group address (Optional) Traces the path for the specified group address. The default value is 192.0.2.0.
interval seconds (Optional) Sets the interval between statistics gathering. The default value is 10.
max-hops number (Optional) Sets the maximum number of hops to trace toward the source. Specify a
value from 0 through 255. The default value is 32.
max-queries number (Optional) Sets the maximum number of query attempts for any hop. Specify a value
from 1 through 32. The default value is 3.
response host (Optional) Sends the response packets to the specified hostname or IP address. By
default, the response packets are sent to the device.
routing-instance (Optional) Traces the routing instance you specify.

routing-instance-name
ttl number (Optional) Sets the time-to-live (TTL) value in the IP header of the query packets.
Specify a hop count from 0 through 255. The default value for local queries to the all
routers multicast group is 1. Otherwise, the default value is 127.
wait-time seconds (Optional) Sets the time to wait for a response packet. The default value is 3 seconds.
loop (Optional) Loops indefinitely, displaying rate and loss statistics. To quit the mtrace
command, press Ctrl-C.
multicast-response (Optional) Forces the responses to use multicast.
unicast-response (Optional) Forces the response packets to use unicast.
no-resolve (Optional) Does not display hostnames.
no-router-alert (Optional) Does not use the device alert IP option in the IP header.
brief (Optional) Does not display packet rates and losses.
detail (Optional) Displays packet rates and losses if a group address is specified.
The following is sample output from the mtrace from-source command:
user@host> mtrace from-source source 192.1.4.1 group 224.1.1.1
Mtrace from 192.1.4.1 to 192.1.30.2 via group 224.1.1.1 Querying full reverse
path... * * 0 ? (192.1.30.2) -1 ? (192.1.30.1) PIM thresh^ 1 -2
routerC.mycompany.net (192.1.40.2) PIM thresh^ 1 -3 hostA.mycompany.net
(192.1.4.1) Round trip time 22 ms; total ttl of 2 required. Waiting to accumulate
statistics...Results after 10 seconds: Source Response Dest Overall
Packet Statistics For Traffic From 192.1.4.1 192.1.30.2 Packet

Chapter 22: Displaying Real-Time Information from Device to Host
192.1.4.1 To 224.1.1.1 v __/ rtt 16 ms Rate Lost/Sent =

Pct Rate 192.168.195.37 192.1.40.2 routerC.mycompany.net v ^
ttl 2 0/0 = -- 0 pps 192.1.40.1 192.1.30.1
? v \__ ttl 3 ?/0
0 pps 192.1.30.2 192.1.30.2 Receiver Query Source
Each line of the trace display is usually in the following format (depending on the options
selected and the responses from the devices along the path):
hop-number host (ip-address) protocolttl
NOTE: The packet statistics gathered from Juniper Networks devices and
routing nodes always display as 0.
Table 50: CLI mtrace from-source Command Output Summary

Field Description
hop-number Number of the hop (device) along the path.
host Hostname, if available, or IP address of the device. If the no-resolve option was entered
in the command, the hostname is not displayed.
ip-address IP address of the device.
protocol Protocol used.
ttl TTL threshold.
Round trip time milliseconds ms Total time between the sending of the query packet and the receiving of the response
packet.
total ttl of number required Total number of hops required to reach the source.
Source Source IP address of the response packet.
Response Dest Response destination IP address.
Overall Average packet rate for all traffic at each hop.
Packet Statistics For Traffic From Number of packets lost, number of packets sent, percentage of packets lost, and average
packet rate at each hop.
Receiver IP address receiving the multicast packets.
Query Source IP address of the host sending the query packets.
Related • Monitoring Overview on page 7

Documentation


CHAPTER 23
Monitoring Application Layer Gateways

Features
• Monitoring H.323 ALG Information on page 389

• Monitoring MGCP ALGs on page 390
• Monitoring SCCP ALGs on page 393
• Monitoring SIP ALGs on page 396
• Monitoring Voice ALG H.323 on page 400
• Monitoring Voice ALG MGCP on page 402
• Monitoring Voice ALG SCCP on page 405
• Monitoring Voice ALG SIP on page 408
• Monitoring Voice ALG Summary on page 413
Monitoring H.323 ALG Information
Purpose View the H.323 ALG counters information.
Action Select Monitor>ALGs>H323 in the J-Web user interface, or enter the show security alg
h323 counters command.
Table 51 on page 389 summarizes key output fields in the H.323 counters display.
Table 51: Summary of Key H.323 Counters Output Fields

H.323 Counters Information

Packets Number of H.323 ALG packets received. –
received
Packets Number of H.323 ALG packets dropped. –

dropped

Table 51: Summary of Key H.323 Counters Output Fields (continued)

RAS Number of incoming RAS (Endpoint Registration, –

message Admission, and Status) messages per second per
received gatekeeper received and processed.
Q.931 Counter for Q.931 message received. –

message
received
H.245 Counter for H.245 message received. –

message
received
Number of Total number of H.323 ALG calls. –

calls
Number of Number of active H.323 ALG calls. This counter displays the number of call legs and might
active calls not display the exact number of voice calls that are
active. For instance, for a single active voice call
between two endpoints, this counter might display a
value of 2.
H.323 Error Counters

Decoding Number of decoding errors. –
errors
Message Error counter for message flood dropped. –

flood
dropped
NAT errors H.323 ALG Network Address Translation (NAT) errors. –
Resource H.323 ALG resource manager errors. –

manager
errors

Documentation
• Monitoring Interfaces on page 420
Monitoring MGCP ALGs
• Monitoring MGCP ALG Calls on page 391

• Monitoring MGCP ALG Counters on page 391
• Monitoring MGCP ALG Endpoints on page 393

Chapter 23: Monitoring Application Layer Gateways Features
Monitoring MGCP ALG Calls
Purpose View information about MGCP ALG calls.
Action Select Monitor>ALGs>MGCP>Calls in the J-Web user interface. To view detailed

information, select the endpoint on the MGCP calls page.
Alternatively, enter the show security alg mgcp calls command.
Table 52 on page 391 summarizes key output fields in the MGCP calls display.
Table 52: Summary of Key MGCP Calls Output Fields

MGCP Calls Information

Endpoint@GW Endpoint name. –
Zone • trust—Trust zone. –

• untrust—Untrust zone.
Call ID Call identifier for ALG MGCP. –
RM Group Resource manager group ID. –
Call Duration Duration for which connection is active. –
Connection Id Connection identifier for MGCP ALG calls. –
Calls Details: Endpoint

Local SDP IP address of the MGCP ALG local call owner, as –
per the Session Description Protocol (SDP).
Remote SDP Remote IP address of the MGCP ALG remote call –

owner, as per the Session Description Protocol
(SDP).
Monitoring MGCP ALG Counters
Purpose View MGCP ALG counters information.
Action Select Monitor>ALGs>MGCP>Counters in the J-Web user interface, or enter the show
security alg mgcp counters command.
Table 53 on page 392 summarizes key output fields in the MGCP counters display.

Table 53: Summary of Key MGCP Counters Output Fields

MGCP Counters Information

Packets received Number of MGCP ALG packets received. –
Packets dropped Number of MGCP ALG packets dropped. –
Message received Number of MGCP ALG messages received. –
Number of connections Number of MGCP ALG connections. –
Number of active Number of active MGCP ALG connections. –

connections
Number of calls Number of MGCP ALG calls. –
Number of active calls Number of MGCP ALG active calls. –
Number of active Number of active transactions. –

transactions
Number of Number of MGCP ALG retransmissions. –

re-transmission
Error Counters
Unknown-method MGCP ALG unknown method errors. –
Decoding error MGCP ALG decoding errors. –
Transaction error MGCP ALG transaction errors. –
Call error MGCP ALG counter errors. –
Connection error MGCP ALG connection errors. –
Connection flood drop MGCP ALG connection flood drop errors. –
Message flood drop MGCP ALG message flood drop errors. –
IP resolve error MGCP ALG IP address resolution errors. –
NAT error MGCP ALG Network Address Translation (NAT) –

errors.
Resource manager error MGCP ALG resource manager errors. –

Monitoring MGCP ALG Endpoints
Purpose View information about MGCP ALG endpoints.
Action Select Monitor>ALGs>MGCP>Endpoints in the J-Web user interface. To view detailed

information, select the gateway on the MGCP endpoints page.
Alternatively, enter the show security alg mgcp endpoints command.
Table 54 on page 393 summarizes key output fields in the MGCP endpoints display.
Table 54: Summary of Key MGCP Endpoints Output Fields

MGCP Endpoints
Gateway IP address of the gateway. –
Zone • trust—Trust zone. –

IP IP address. –
Endpoints: Gateway name

Endpoint Endpoint name. –
Transaction Transaction identifier. –

#
Call # Call identifier. –
Notified The certificate authority (CA) currently controlling the –

Entity gateway.

Documentation
Monitoring SCCP ALGs
• Monitoring SCCP ALG Calls on page 394

• Monitoring SCCP ALG Counters on page 394

Monitoring SCCP ALG Calls
Purpose View information about SCCP ALG calls.
Action Select Monitor>ALGs>SCCP>Calls in the J-Web user interface. To view detailed

information, select the client IP address on the SCCP calls page.
Alternatively, enter the show security alg sccp calls command.
Table 55 on page 394 summarizes key output fields in the SCCP calls display.
Table 55: Summary of Key SCCP Calls Output Fields

SCCP Calls Information

Client IP IP address of the client. –
Zone Client zone identifier. –
Call IP address of the call manager. –

Manager
Conference Conference call identifier. –

ID
RM Group Resource manager group identifier. –
Monitoring SCCP ALG Counters
Purpose View SCCP ALG counters information.
Action Select Monitor>ALGs>SCCP>Count in the J-Web user interface, or enter the show security
alg sccp counters command.
Table 56 on page 394 summarizes key output fields in the SCCP counters display.
Table 56: Summary of Key SCCP Counters Output Fields

SCCP Counters Information

Clients Number of SCCP ALG clients currently registered. –
currently
registered
Active calls Number of active SCCP ALG calls. –

Table 56: Summary of Key SCCP Counters Output Fields (continued)

Total calls Total number of SCCP ALG calls. –
Packets Number of SCCP ALG packets received. –

received
PDUs Number of SCCP ALG protocol data units (PDUs) –

processed processed.
Current call Number of calls per second. –

rate
Error counters
Packets Number of packets dropped by the SCCP ALG. –
dropped
Decode SCCP ALG decoding errors. –

errors
Protocol Number of protocol errors. –

errors
Address Number of Network Address Translation (NAT) errors –

translation encountered by SCCP ALG.
errors
Policy Number of packets dropped because of a failed policy –

lookup lookup.
errors
Unknown Number of unknown protocol data units (PDUs). –

PDUs
Maximum Number of times the maximum SCCP calls limit was –

calls exceeded.
exceed
Maximum Number of times the maximum SCCP call rate –

call rate exceeded.
exceed
Initialization Number of initialization errors. –

errors
Internal Number of internal errors. –

errors
Unsupported Number of unsupported feature errors. –

feature

Table 56: Summary of Key SCCP Counters Output Fields (continued)

Non Number of nonspecific errors. –

specific
error

Documentation
Monitoring SIP ALGs
• Monitoring SIP ALG Calls on page 396

• Monitoring SIP ALG Counters on page 397
• Monitoring SIP ALG Rate Information on page 399
• Monitoring SIP ALG Transactions on page 400
Monitoring SIP ALG Calls
Purpose View information about SIP ALG calls.
Action Select Monitor>ALGs>SIP>Calls in the J-Web user interface. To view detailed information,
select the Call Leg on the SIP calls page.
Alternatively, enter the show security alg sip calls detail command.
Table 57 on page 396 summarizes key output fields in the SIP calls display.
Table 57: Summary of Key SIP Calls Output Fields

SIP Calls Information

Call Leg Call length identifier. –
Zone Client zone identifier. –
RM Group Resource manager group identifier. –
Local Tag Local tag for the SIP ALG User Agent server. –

Table 57: Summary of Key SIP Calls Output Fields (continued)

Remote Remote tag for the SIP ALG User Agent server. –
Tag
Monitoring SIP ALG Counters
Purpose View SIP ALG counters information.
Action Select Monitor>ALGs>SIP>Count in the J-Web user interface, or enter the show security
alg sip counters command.
Table 58 on page 397 summarizes key output fields in the SIP counters display.
Table 58: Summary of Key SIP Counters Output Fields

SIP Counters Information

INVITE Number of INVITE requests sent. An INVITE request is sent to invite another user to
participate in a session.
CANCEL Number of CANCEL requests sent. A user can send a CANCEL request to cancel a pending
INVITE request. A CANCEL request has no effect if the
SIP server processing the INVITE had sent a final
response for the INVITE before it received the CANCEL.
ACK Number of ACK requests sent. The user from whom the INVITE originated sends an
ACK request to confirm reception of the final response
to the INVITE request.
BYE Number of BYE requests sent. A user sends a BYE request to abandon a session. A
BYE request from either user automatically terminates
the session.
REGISTER Number of REGISTER requests sent. A user sends a REGISTER request to a SIP registrar
server to inform it of the current location of the user. A
SIP registrar server records all the information it receives
in REGISTER requests and makes this information
available to any SIP server attempting to locate a user.
OPTIONS Number of OPTIONS requests sent. An OPTION message is used by the User Agent (UA)
to obtain information about the capabilities of the SIP
proxy. A server responds with information about what
methods, session description protocols, and message
encoding it supports.
INFO Number of INFO requests sent. An INFO message is used to communicate mid-session
signaling information along the signaling path for the
call.

Table 58: Summary of Key SIP Counters Output Fields (continued)

MESSAGE Number of MESSAGE requests sent. SIP messages consist of requests from a client to a
server and responses to the requests from a server to
a client with the purpose of establishing a session (or
a call).
NOTIFY Number of NOTIFY requests sent. A NOTIFY message is sent to inform subscribers of
changes in state to which the subscriber has a
subscription.
REFER Number of REFER requests sent. A REFER request is used to refer the recipient (identified
by the Request-URI) to a third party by the contact
information provided in the request.
SUBSCRIBE Number of SUBSCRIBE requests sent. A SUBSCRIBE request is used to request current state
and state updates from a remote node.
UPDATE Number of UPDATE requests sent. An UPDATE request is used to create a temporary
opening in the firewall (pinhole) for new or updated
Session Description Protocol (SDP) information. The
following header fields are modified: Via, From, To,
Call-ID, Contact, Route, and Record-Route.
SIP Error Counters

Total SIP ALG total packets received. –
Pkt-in
Total Pkt Number of packets dropped by the SIP ALG. –

dropped on
error
Transaction SIP ALG transaction errors. –

error
Call error SIP ALG call errors. –
IP resolve SIP ALG IP address resolution errors. –

error
NAT error SIP ALG NAT errors. –
Resource SIP ALG resource manager errors. –

manager
error
RR header Number of times the SIP ALG RR (Record-Route) –

exceeded headers exceeded the maximum limit.
max

Table 58: Summary of Key SIP Counters Output Fields (continued)

Contact Number of times the SIP ALG contact header exceeded –

header the maximum limit.
exceeded
max
Call SIP ALG calls dropped because of call limits. –

dropped
due to limit
SIP stack SIP ALG stack errors. –

error
Monitoring SIP ALG Rate Information
Purpose View SIP ALG rate information.
Action Select Monitor>ALGs>SIP>Rate in the J-Web user interface, or enter the show security
alg sip rate command.
Table 59 on page 399 summarizes key output fields in the SIP rate display.
Table 59: Summary of Key SIP Rate Output Fields

SIP Rate Information

CPU ticks per SIP ALG CPU ticks per microsecond. –
microseconds is
Time taken for Time, in microseconds, that the last SIP ALG message –
the last needed to transit the network.
message in
microseconds is
Number of Total number of SIP ALG messages transiting the –

messages in 10 network in 10 minutes.
minutes
Time taken by Total time, in microseconds, during an interval of less –

the messages in than 10 minutes for the specified number of SIP ALG
10 minutes messages to transit the network.
Rate Number of SIP ALG messages per second transiting –

the network.

Monitoring SIP ALG Transactions
Purpose View information about SIP ALG transactions.
Action Select Monitor>ALGs>SIP>Transactions in the J-Web user interface, or enter the show
security alg sip transactions command.
Table 60 on page 400 summarizes key output fields in the SIP transactions display.
Table 60: Summary of Key SIP Transactions Output Fields

SIP Transactions Information

Transaction • UAS—SIP ALG User Agent server transaction name. –
Name • UAC—SIP ALG User Agent client transaction name.
Method The method to be performed on the resource. Possible –

methods:
• INVITE—Initiate call
• ACK—Confirm final response
• BYE—Terminate and transfer call
• CANCEL—Cancel searches and “ringing”
• OPTIONS—Features support by the other side
• REGISTER—Register with location service

Documentation
Monitoring Voice ALG H.323
Purpose Use the monitoring functionality to view the ALG H.323 page.
Action To monitor ALG H.323 select Monitor>Security>Voice ALGs>H.323 in the J-Web user
interface.
Meaning Table 61 on page 400 summarizes key output fields in the ALG H.323 page.
Table 61: ALG H.323 Monitoring Page

Virtual Chassis Member Display the list of virtual chassis member. Select one of the virtual chassis
members listed.

Table 61: ALG H.323 Monitoring Page (continued)

Refresh Interval (30 sec) Displays the time interval set for page refresh. Select the time interval from the
drop-down list.
Refresh Displays the option to refresh the page. –
Clear Provides an option to clear the monitor summary. Click clear to clear the monitor
summary.
H.323 Counter Summary

Category Displays the following categories: –
• Packets received—Number of ALG H.323 packets

received.
• Packets dropped—Number of ALG H.323 packets
dropped.
• RAS message received Number of incoming RAS
(Registration, Admission, and Status) messages per
second per gatekeeper received and processed.
• Q.931 message received—Counter for Q.931 message
received.
• H.245 message received— Counter for H.245 message
received.
• Number of calls—Total number of ALG H.323 calls.
• Number of active calls—Number of active ALG H.323
calls.
• Number of DSCP Marked—Number of DSCP Marked on
ALG H.323 calls.
Count Provides count of response codes for each H.323 counter –

summary category.
H.323 Error Counter

• Decoding errors—Number of decoding errors.

• Message flood dropped—Error counter for message flood
dropped.
• NAT errors—H.323 ALG NAT errors.
• Resource manager errors—H.323 ALG resource manager
errors.
• DSCP Marked errors—H.323 ALG DSCP marked errors.
Count Provides count of response codes for each H.323 error –

counter category.
Counter Summary Chart

Packets Received Provides the graphical representation of the packets –
received.

Table 61: ALG H.323 Monitoring Page (continued)

H.323 Message Counter

• RRQ—Registration Request message counter.

• RCF—Registration Confirmation Message.
• ARQ—Admission Request message counter.
• ACF—Admission Confirmation
• URQ—Unregistration Request.
• UCF—Unregistration Confirmation.
• DRQ—Disengage Request.
• DCF—Disengage Confirmation.
• Oth RAS—Other incoming Registration, Admission, and
Status messages message counter.
• Setup—Timeout value, in seconds, for the response of
the outgoing setup message.
• Alert—Alert message type.
• Connect—Connect setup process.
• CallProd—Number of call production messages sent.
• Info—Number of info requests sent.
• RelCmpl—Number of Rel Cmpl message ssent.
• Facility—Number of facility messages sent.
• Empty—Empty capabilities to the support message
counter.
• OLC—Open Local Channel message counter.
• OLC ACK—Open Local Channel Acknowledge message
counter.
• Oth H245—Other H.245 message counter
Count Provides count of response codes for each H.323 message –

counter category.
Related • Monitoring Voice ALG Summary on page 413

Documentation
Monitoring Voice ALG MGCP
Purpose Use the monitoring functionality to view the voice ALG MGCP page.

Action To monitor ALG MGCP, select Monitor>Security>Voice ALGs>MGCP in the J-Web user
interface.
Meaning Table 62 on page 403 summarizes key output fields in the voice ALG MGCP page.
Table 62: Voice ALG MGCP Monitoring Page

Virtual Chassis Member Displays the list of virtual chassis member. Select one of the virtual chassis members
listed.
Refresh Interval (30 sec) Displays the time interval set for page Select the time interval from the
refresh. drop-down list.
Clear Provides an option to clear the monitor Click Clear to clear the monitor summary.
summary.
Counters
MGCP Counters Summary

• Packets Received—Number of ALG MGCP

packets received.
• Packets Dropped— Number of ALG MGCP
packets dropped.
• Message received— Number of ALG MGCP
messages received.
• Number of connections— Number of ALG
MGCP connections.
• Number of active connections— Number
of active ALG MGCP connections.
• Number of calls— Number of ALG MGCP
calls.
• Number of active calls— Number of active
ALG MGCP calls.
• Number of active transactions— Number
of active transactions.
• Number of transactions— Number of
transactions.
• Number of re-transmission—Number of
ALG MGCP retransmissions.
• Number of active endpoints— Number of
MGCP active enpoints.
• Number of DSCP marked— Number of
MGCP DSCPs marked.
Count Provides the count of response codes for –

each MGCP counter summary category.

Table 62: Voice ALG MGCP Monitoring Page (continued)

MGCP Error Counter

• Unknown-method— MGCP ALG unknown

method errors.
• Decoding error— MGCP ALG decoding
errors.
• Transaction error— MGCP ALG transaction
errors.
• Call error— MGCP ALG call ounter errors.
• Connection error— MGCP ALG connection
errors.
• Connection flood drop— MGCP ALG
connection flood drop errors.
• Message flood drop— MGCP ALG message
flood drop error.
• IP resolve error— MGCP ALG IP address
resolution errors.
• NAT error— MGCP ALG NAT errors.
• Resource manager error— MGCP ALG
resource manager errors.
• DSCP Marked error— MGCP ALG DSCP
marked errors.
Count Provides the count of response codes for –

each summary error counter category.
Counter Summary Chart Displays the Counter Summary Chart. –
MGCP Packet Counters

• CRCX— Create Connection

• MDCX— Modify Connection
• DLCX— Delete Connection
• AUEP— Audit Endpoint
• AUCX— Audit Connection
• NTFY— Notify MGCP
• RSIP— Restart in Progress
• EPCF— Endpoint Configuration
• RQNT— Request for Notification
• 000-199—Respond code is 0-199
• 200-299—Respond code is 200-299
• 300-399—Respond code is 300-399
Count Provides count of response codes for each –

MGCP packet counter category.

Table 62: Voice ALG MGCP Monitoring Page (continued)

Calls
Endpoint@GW Displays the endpoint name. –
Zone Displays the following options: –
• trust—Trust zone.
Endpoint IP Displays the endpoint IP address. –
Call ID Displays the call identifier for ALG MGCP. –
RM Group Displays the resource manager group ID. –
Call Duration Displays the duration for which connection –

is active.

Documentation
Monitoring Voice ALG SCCP
Purpose Use the monitoring functionality to view the voice ALG SCCP page.
Action To monitor voice ALG SCCP, select Monitor>Security>Voice ALGs>SCCP in the J-Web
user interface.
Meaning Table 63 on page 405 summarizes key output fields in the voice ALG SCCP page.
Table 63: Voice ALG SCCP Monitoring Page

Virtual Chassis Member Displays the list of virtual chassis member. Select one of the virtual chassis
members listed.
Refresh Interval (30 sec) Displays the time interval set for page refresh. Select the time interval from the
drop-down list.

Table 63: Voice ALG SCCP Monitoring Page (continued)

Clear Provides an option to clear the monitor summary. Click Clear to clear the monitor
summary.
SCCP Call Statistics

• Active client sessions— Number of active SCCP ALG

client sessions.
• Active calls— Number of active SCCP ALG calls.
• Total calls— Total number of SCCP ALG calls.
• Packets received— Number of SCCP ALG packets
received.
• PDUs processed— Number of SCCP ALG protocol
data units (PDUs) processed.
• Current call rate— Number of calls per second.
• DSCPs Marked— Number of DSCP marked.
Count Provides count of response codes for each SCCP call –

statistics category.
Call Statistics Chart Displays the Call Statistics chart. –
SCCP Error Counters

Table 63: Voice ALG SCCP Monitoring Page (continued)

• Packets dropped— Number of packets dropped by

the SCCP ALG.
• Decode errors— Number of SCCP ALG decoding
errors.
• Protocol errors— Number of protocol errors.
• Address translation errors— Number of NAT errors
encountered by SCCP ALG.
• Policy lookup errors— Number of packets dropped
because of a failed policy lookup.
• Unknown PDUs— Number of unknown PDUs.
• Maximum calls exceed— Number of times the
maximum SCCP calls limit was exceeded.
• Maximum call rate exceed— Number of times the
maximum SCCP call rate was exceeded.
• Initialization errors— Number of initialization errors.
• Internal errors— Number of internal errors.
• Nonspecific errors— Number of nonspecific errors.
• No active calls to be deleted— Number of no active
calls to be deleted.
• No active client sessions to be deleted— Number of
no active client sessions to be deleted.
• Session cookie created error— Number of session
cookie created errors.
Invalid NAT cookies deleted— Number of invalid NAT
cookies deleted.
NAT cookies not found— Number of NAT cookies not
found.
• DSCP Marked Error— Number of DSCP marked errors.
Count Provides count of response codes for each SCCP error –

counter category.
Calls
Client IP Displays the IP address of the client. –
Zone Displays the client zone identifier. –
Call Manager Displays the IP address of the call manager. –
Conference ID Displays the conference call identifier. –
RM Group Displays the resource manager group identifier. –

Documentation

Monitoring Voice ALG SIP
Purpose Use the monitoring functionality to view the voice ALG SIP page.
Action To monitor voice ALG SIP select Monitor>Security>Voice ALGs>SIP in the J-Web user
interface.
Meaning Table 64 on page 408 summarizes key output fields in the voice ALG SIP page.
Table 64: Voice ALG SIP Monitoring Page

Virtual Chassis Member Displays the list of virtual chassis members. Select one of the virtual
chassis members listed.
Refresh Interval (30 sec) Displays the time interval set for page refresh. Select the time interval
from the drop-down list.
Clear Provides an option to clear the monitor summary. Click Clear to clear the
monitor summary.
Counters
SIP Counters Information

Table 64: Voice ALG SIP Monitoring Page (continued)

Method Displays the SIP counter information. The available options are: –
• BYE— Number of BYE requests sent. A user sends a BYE request

to abandon a session. A BYE request from either user
automatically terminates the session.
• REGISTER— Number of REGISTER requests sent. A user sends
a REGISTER request to a SIP registrar server to inform it of the
current location of the user. The SIP registrar server records all
the information it receives in REGISTER requests and makes
this information available to any SIP server attempting to locate
a user.
• OPTIONS— Number of OPTIONS requests sent. An OPTION
message is used by the User Agent (UA) to obtain information
about the capabilities of the SIP proxy. A server responds with
information about what methods, session description protocols,
and message encoding it supports.
• INFO— Number of INFO requests sent. An INFO message is used
to communicate mid-session signaling information along the
signaling path for the call.
• MESSAGE— Number of MESSAGE requests sent. SIP messages
consist of requests from a client to the server and responses to
the requests from the server to a client for the purpose of
establishing a session (or a call).
SIP Counters Information (continued)


Method • NOTIFY— Number of NOTIFY requests sent. A NOTIFY message –

is sent to inform subscribers about the change in state of the
subscription.
• PRACK— Number of PRACK requests sent. The PRACK request
plays the same role as the ACK request, but for provisional
responses.
• PUBLISH— Number of PUBLISH requests sent. The PUBLISH
request is used for publishing the event state. PUBLISH is similar
to REGISTER that allows a user to create, modify, and remove
state in another entity which manages this state on behalf of
the user.
• REFER— Number of REFER requests sent. A REFER request is
used to refer the recipient (identified by the Request-URI) to a
third party identified by the contact information provided in the
request.
• SUBSCRIBE— Number of SUBSCRIBE requests sent. A
SUBSCRIBE request is used to request current state and state
information updates from a remote node.
• UPDATE— Number of UPDATE requests sent. An UPDATE
request is used to create a temporary opening in the firewall
(pinhole) for new or updated Session Description Protocol
(SDP) information. The following header fields are modified:
Via, From, To, Call-ID, Contact, Route, and Record-Route.
• BENOTIFY— Number of BENOTIFY requests sent. A BENOTIFY
request is used to reduce the unnecessary SIP signaling traffic
on application servers. Applications that do not need a response
for a NOTIFY request can enhance performance by enabling
BENOTIFY.
• SERVICE— Number of SERVICE requests sent. The SERVICE
method is used by a SIP client to request a service from a SIP
server. It is a standard SIP message and will be forwarded until
it reaches the server or end user that is performing the service.
• OTHER— Number of OTHER requests sent.
T, RT Displays the transmit and retransmit method. –
1xx, RT Displays one transmit and retransmit method. –
2xx, RT Displays two transmit and retransmit methods. –
3xx, RT Displays three transmit and retransmit methods. –
4xx, RT Displays four transmit and retransmit methods. –
5xx, RT Displays five transmit and retransmit methods. –
6xx, RT Displays six transmit and retransmit methods. –
Calls
Call ID Displays the call ID. –


Method Displays the call method used. –
State Displays the state of the ALG SIP. –
Group ID Displays the group identifier. –
Invite Method Chart Displays the invite method chart. The available options are: –
• T/RT
• 1xx/ RT
• 2xx/ RT
• 3xx/ RT
• 4xx/ RT
• 5xx/ RT
• 6xx/ RT
SIP Error Counters


Category Displays the SIP error counters. The available options are: –
• Total Pkt-in— Number of SIP ALG total packets received.

• Total Pkt dropped on error— Number of packets dropped by the
SIP ALG.
• Call error— SIP Number of ALG call errors.
• IP resolve error— Number of SIP ALG IP address resolution errors.
• NAT error— SIP Number of ALG NAT errors.
• Resource manager error— Number of SIP ALG resource manager
errors.
• RR header exceeded max— Number of times the SIP ALG RR
(Record-Route) headers exceeded the maximum limit.
• Contact header exceeded max— Number of times the SIP ALG
contact header exceeded the maximum limit.
• Call dropped due to limit— Number of SIP ALG calls dropped
because of call limits.
• SIP stack error— Number of SIP ALG stack errors.
• SIP Decode error— Number of SIP ALG decode errors.
• SIP unknown method error— Number of SIP ALG unknow method
errors.
• SIP DSCP marked—SIP ALG DSCP marked.
• SIP DSCP marked error— Number of SIP ALG DSCPs marked.
• RTO message sent— Number of SIP ALG marked RTO messages
sent.
• RTO message received— Number of SIP ALG RTO messages
received.
• RTO buffer allocation failure— Number of SIP ALG RTO buffer
allocation failures.
• RTO buffer transmit failure— Number of SIP ALG RTO buffer
transmit failures.
• RTO send processing error— Number of SIP ALG RTO send
processing errors.
• RTO receiving processing error— Number of SIP ALG RTO
receiving processing errors.
• RTO receive invalid length— Number of SIP ALG RTOs receiving
invalid length.
• RTO receive call process error— Number of SIP ALG RTO receiving
call process errors.
• RTO receive call allocation error— Number of SIP ALG RTO
receiving call allocation error.
• RTO receive call register error— Number of SIP ALG RTO receiving
call register errors.
• RTO receive invalid status error— Number of SIP ALG RTO
receiving register errors.
Count Provides count of response codes for each SIP ALG counter –
category.


Documentation
Monitoring Voice ALG Summary
Purpose Use the monitoring functionality to view the voice ALG summary page.
Action To monitor voice ALG summary, select Monitor>Security>Voice ALGs>Summary in the

J-Web user interface.
Meaning Table 65 on page 413 summarizes key output fields in the voice ALG summary page.
Table 65: Voice ALG Summary Monitoring Page

Virtual Chassis Member Display the list of virtual chassis member. Select one of the virtual chassis
members listed.
Refresh Interval (30 sec) Displays the time interval set for page Select the time interval from the
refresh. drop-down list.
Clear Provides an option to clear the monitor Click Clear to clear the monitor
summary. summary.
Protocol Name Displays the protocols configured. –
Total Calls Displays the total number of calls. –
Number of Active Calls Displays the number of active calls. –
Number of Received Packets Displays the number of packets received. –
Number of Errors Displays the number of errors. –
H.323 Calls Chart Displays the H.323 calls chart. –
MGCP Calls Chart Displays the MGCP calls chart. –
SCCP Calls Chart Displays the SCCP calls chart. –
SIP Calls Chart Displays the SIP calls chart. –

Related • Monitoring Voice ALG H.323 on page 400

Documentation

CHAPTER 24
Monitoring Interfaces and Switching

Functions
• Displaying Real-Time Interface Information on page 415

• Monitoring Address Pools on page 417
• Monitoring Ethernet Switching on page 418
• Monitoring GVRP on page 419
• Monitoring MPLS Traffic Engineering Information on page 421
• Monitoring PPP on page 427
• Monitoring PPPoE on page 427
• Monitoring Spanning Tree on page 431
• Monitoring the WAN Acceleration Interface on page 432
Displaying Real-Time Interface Information
Enter the monitor interface command to display real-time traffic, error, alarm, and filter
statistics about a physical or logical interface:
user@host> monitor interface (interface-name | traffic)
Replace interface-name with the name of a physical or logical interface. If you specify the
traffic option, statistics for all active interfaces display.
The real-time statistics update every second. The Current delta and Delta columns display
the amount the statistics counters have changed since the monitor interface command
was entered or since you cleared the delta counters. Table 66 on page 416 and
Table 67 on page 416 list the keys you use to control the display using the interface-name
and traffic options. (The keys are not case sensitive.)

Table 66: CLI monitor interface Output Control Keys

Key Action
c Clears (returns to 0) the delta counters in the Current delta column. The
statistics counters are not cleared.
f Freezes the display, halting the update of the statistics and delta counters.
i Displays information about a different interface. You are prompted for the
name of a specific interface.
n Displays information about the next interface. The device scrolls through the
physical and logical interfaces in the same order in which they are displayed
by the show interfaces terse command.
q or ESC Quits the command and returns to the command prompt.
t Thaws the display, resuming the update of the statistics and delta counters.
Table 67: CLI monitor interface traffic Output Control Keys

Key Action
b Displays the statistics in units of bytes and bytes per second (bps).
c Clears (returns to 0) the delta counters in the Delta column. The statistics
counters are not cleared.
d Displays the Delta column instead of the rate column—in bps or packets per
second (pps).
p Displays the statistics in units of packets and packets per second (pps).
q or ESC Quits the command and returns to the command prompt.
r Displays the rate column—in bps and pps—instead of the Delta column.
The following are sample displays from the monitor interface command:
user@host> monitor interface fe-0/0/0
host1 Seconds: 5 Time: 04:38:40

Delay: 3/0/10
Interface: fe-0/0/0, Enabled, Link is Up
Encapsulation: Ethernet, Speed: 1000mbps
Traffic statistics: Current delta
Input bytes: 885405423 (3248 bps) [2631]
Output bytes: 137411893 (3344 bps) [10243]
Input packets: 7155064 (2 pps) [28]
Output packets: 636071 (1 pps) [23]
Error statistics:
Input errors: 0 [0]
Input drops: 0 [0]

Chapter 24: Monitoring Interfaces and Switching Functions
Input framing errors: 0 [0]

Policed discards: 0 [0]
L3 incompletes: 0 [0]
L2 channel errors: 0 [0]
L2 mismatch timeouts: 0 [0]
Carrier transitions: 1 [0]
Output errors: 0 [0]
Output drops: 0 [0]
Aged packets: 0 [0]
Active alarms : None
Active defects: None
Input MAC/Filter statistics:
Unicast packets 73083 [16]
Broadcast packets 3629058 [5]
Multicast packets 3511364 [3]
Oversized frames 0 [0]
Packet reject count 0 [0]
DA rejects 0 [0]
SA rejects 0 [0]
Output MAC/Filter Statistics:
Unicast packets 629555 [28]
Broadcast packets 6494 Multicast packet [0]
NOTE: The output fields that display when you enter the monitor interface
interface-name command are determined by the interface you specify.
user@host> monitor interface traffic
Interface Link Input packets (pps) Output packets (pps)

fe-0/0/0 Up 42334 (5) 23306 (3)
fe-0/0/1 Up 587525876 (12252) 589621478 (12891)

Documentation
Monitoring Address Pools
Purpose Use the monitoring functionality to view the Address Pools page.
Action To monitor Address Pools, select Monitor>Access>Address Pools in the J-Web user
interface.
Meaning Table 68 on page 417 summarizes key output fields in the Address Pools page.
Table 68: Address Pools Monitoring Page

Address Pool Properties

Address Pool Name Displays the name of the address pool. -

Table 68: Address Pools Monitoring Page (continued)

Network Address Displays the IP network address of the -

address pool.
Address Ranges Displays the name, the lower limit, and -

the upper limit of the address range.
Primary DNS Displays the primary-dns IP address. -
Secondary DNS Displays the secondary-dns IP address. -
Primary WINS Displays the primary-wins IP address. -
Secondary WINS Displays the secondary-wins IP address. -
Address Pool Address Assignment

IP Address Displays the IP address of the address -
pool.
Hardware Address Displays the hardware MAC address of -

the address pool.
Host/User Displays the user name using the address -

pool.
Type Displays the authentication type used by The authentication types can be
the address pool extended authentication (XAuth) or IKE
Authentication.

Documentation
• Threats Monitoring Report on page 486
Monitoring Ethernet Switching
Purpose View information about the Ethernet Switching interface details.
Action Select Monitor>Switching>Ethernet Switching in the J-Web user interface, or enter the
following CLI commands:
• show ethernet-switching table
• show ethernet-switching mac-learning-log
Table 69 on page 419 summarizes the Ethernet Switching output fields.

Table 69: Summary of Ethernet Switching Output Fields

VLAN The VLAN for which Ethernet Switching is enabled. -
MAC Address The MAC address associated with the VLAN. If a -

VLAN range has been configured for a VLAN, the
output displays the MAC addresses for the entire
series of VLANs that were created with that name.
Type The type of MAC address. Values are: -
• static—The MAC address is manually created.

• learn—The MAC address is learned dynamically
from a packet's source MAC address.
• flood—The MAC address is unknown and flooded
to all members.
Age The time remaining before the entry ages out and is -
removed from the Ethernet switching table.
Interfaces Interface associated with learned MAC addresses -

or All-members (flood entry).
VLAN-ID The VLAN ID. -
MAC Address The learned MAC address. -
Time Timestamp when the MAC address was added or -

deleted from the log.
State Indicates the MAC address learned on the interface. -

Documentation
Monitoring GVRP
Purpose Use the monitoring functionality to view the GVRP page.
Action To monitor GVRP select Monitor>Switching>GVRP in the J-Web user interface.
Meaning Table 70 on page 420 summarizes key output fields in the GVRP page.

Table 70: GVRP Monitoring Page

Global GVRP Configuration

GVRP Status Displays whether GVRP is enabled or –
disabled.
GVRP Timer Displays the GVRP timer in millisecond. –
Join The number of milliseconds the interfaces –

must wait before sending VLAN
advertisements.
Leave The number of milliseconds an interface –

must wait after receiving a Leave message
to remove the interface from the VLAN
specified in the message.
Leave All The interval in milliseconds at which Leave –

All messages are sent on interfaces. Leave
All messages maintain current GVRP VLAN
membership information in the network.
GVRP Interface Details

Interface Name The interface on which GVRP is configured. –
Protocol Status Displays whether GVRP is enabled or –

disabled.
Related • Monitoring Ethernet Switching on page 418

Documentation
• Monitoring Spanning Tree on page 431
Monitoring Interfaces
Purpose View general information about all physical and logical interfaces for a device.
Action Select Monitor>Interfaces in the J-Web user interface. The J-Web Interfaces page displays
the following details about each device interface:
• Port—Indicates the interface name.
• Admin Status—Indicates whether the interface is enabled (Up) or disabled (Down).
• Link Status—Indicates whether the interface is linked (Up) or not linked (Down).
• Address—Indicates the IP address of the interface.
• Zone—Indicates whether the zone is an untrust zone or a trust zone.

• Services—Indicates services that are enabled on the device, such as HTTP and SSH.
• Protocols—Indicates protocols that are enabled on the device, such as BGP and IGMP.
• Input Rate graph—Displays interface bandwidth utilization. Input rates are shown in
bytes per second.
• Output Rate graph—Displays interface bandwidth utilization. Output rates are shown
in bytes per second.
• Error Counters chart—Displays input and output error counters in the form of a bar
chart.
• Packet Counters chart—Displays the number of broadcast, unicast, and multicast

packet counters in the form of a pie chart. (Packet counter charts are supported only
for interfaces that support MAC statistics.)
To change the interface display, use the following options:
• Port for FPC—Controls the member for which information is displayed.
• Start/Stop button—Starts or stops monitoring the selected interfaces.
• Show Graph—Displays input and output packet counters and error counters in the form
of charts.
• Pop-up button—Displays the interface graphs in a separate pop-up window.
• Details—Displays extensive statistics about the selected interface, including its general
status, traffic information, IP address, I/O errors, class-of-service data, and statistics.
• Refresh Interval—Indicates the duration of time after which you want the data on the
page to be refreshed.
• Clear Statistics—Clears the statistics for the selected interface.
Alternatively, you can enter the following show commands in the CLI to view interface
status and traffic statistics:
• show interfaces terse
NOTE: On SRX Series devices, on configuring identical IPs on a single

interface, you will not see a warning message; instead, you will see a syslog
message.
• show interfaces detail
• show interfaces extensive
• show interfaces interface-name
Monitoring MPLS Traffic Engineering Information

• Monitoring MPLS Interfaces on page 422

• Monitoring MPLS LSP Information on page 422
• Monitoring MPLS LSP Statistics on page 423
• Monitoring RSVP Session Information on page 424
• Monitoring MPLS RSVP Interfaces Information on page 426
Monitoring MPLS Interfaces
Purpose View the interfaces on which MPLS is configured, including operational state and any
administrative groups applied to an interface.
Action Select Monitor>MPLS>Interfaces in the J-Web user interface, or enter the show mpls
interface command.
Table 71 on page 422 summarizes key output fields in the MPLS interface information
display.
Table 71: Summary of Key MPLS Interface Information Output Fields

Interface Name of the interface on which MPLS is –

configured.
State State of the specified interface: Up or Dn (down). –
Administrative groups Administratively assigned colors of the MPLS link –

configured on the interface.
Monitoring MPLS LSP Information
Purpose View all label-switched paths (LSPs) configured on the services router, including all
inbound (ingress), outbound (egress), and transit LSP information.
Action Select Monitor>MPLS>LSP Information in the J-Web user interface, or enter the show
mpls lsp command.
Table 72 on page 422 summarizes key output fields in the MPLS LSP information display.
Table 72: Summary of Key MPLS LSP Information Output Fields

Ingress LSP Information about LSPs on the inbound device. –

Each session has one line of output.

Table 72: Summary of Key MPLS LSP Information Output Fields (continued)
Egress LSP Information about the LSPs on the outbound MPLS learns this information by querying RSVP,
device. Each session has one line of output. which holds all the transit and outbound session
information.
Transit LSP Number of LSPs on the transit routers and the MPLS learns this information by querying RSVP,
state of these paths. which holds all the transit and outbound session
information.
To Destination (outbound device) of the session. –
From Source (inbound device) of the session. –
State State of the path. It can be Up, Down, or AdminDn. AdminDn indicates that the LSP is being taken
down gracefully.
Rt Number of active routes (prefixes) installed in the For inbound RSVP sessions, the routing table is
routing table. the primary IPv4 table (inet.0). For transit and
outbound RSVP sessions, the routing table is the
primary MPLS table (mpls.0).
Active Path Name of the active path: Primary or Secondary. This field is used for inbound LSPs only.
P An asterisk (*) in this column indicates that the This field is used for inbound LSPs only.
LSP is a primary path.
LSPname Configured name of the LSP. –
Style RSVP reservation style. This field consists of two This field is used for outbound and transit LSPs
parts. The first is the number of active only.
reservations. The second is the reservation style,
which can be FF (fixed filter), SE (shared explicit),
or WF (wildcard filter).
Labelin Incoming label for this LSP. –
Labelout Outgoing label for this LSP. –
Total Total number of LSPs displayed for the particular –

type—ingress (inbound), egress (outbound), or
transit.
Monitoring MPLS LSP Statistics
Purpose Display statistics for LSP sessions currently active on the device, including the total
number of packets and bytes forwarded through an LSP.

Action Select Monitor>MPLS>LSP Statistics in the J-Web user interface, or enter the show mpls
lsp statistics command.
NOTE: Statistics are not available for LSPs on the outbound device, because
the penultimate device in the LSP sets the label to 0. Also, as the packet
arrives at the outbound device, the hardware removes its MPLS header and
the packet reverts to being an IPv4 packet. Therefore, it is counted as an IPv4
packet, not an MPLS packet.
Table 73 on page 424 summarizes key output fields in the MPLS LSP statistics display.
Table 73: Summary of Key MPLS LSP Statistics Output Fields

Ingress LSP Information about LSPs on the inbound device. –

Each session has one line of output.
Egress LSP Information about the LSPs on the outbound MPLS learns this information by querying RSVP,
device. Each session has one line of output. which holds all the transit and outbound session
information.
Transit LSP Number of LSPs on the transit routers and the MPLS learns this information by querying RSVP,
state of these paths. which holds all the transit and outbound session
information.
State State of the path: Up, Down, or AdminDn. AdminDn indicates that the LSP is being taken
down gracefully.
Packets Total number of packets received on the LSP from –

the upstream neighbor.
Bytes Total number of bytes received on the LSP from –

the upstream neighbor.
Total Total number of LSPs displayed for the particular –

type—ingress (inbound), egress (outbound), or
transit.
Monitoring RSVP Session Information

Purpose View information about RSVP-signaled LSP sessions currently active on the device,
including inbound (ingress) and outbound (egress) addresses, LSP state, and LSP name.
Action Select Monitor>MPLS>RSVP Sessions in the J-Web user interface, or enter the show rsvp
session command.
Table 74 on page 425 summarizes key output fields in the RSVP session information
display.
Table 74: Summary of Key RSVP Session Information Output Fields

Ingress LSP Information about inbound RSVP sessions. Each –

session has one line of output.
Egress LSP Information about outbound RSVP sessions. Each MPLS learns this information by querying RSVP,
session has one line of output. which holds all the transit and outbound session
information.
Transit LSP Information about transit RSVP sessions. MPLS learns this information by querying RSVP,
which holds all the transit and outbound session
information.
State State of the path: Up, Down, or AdminDn. AdminDn indicates that the LSP is being taken
down gracefully.
Rt Number of active routes (prefixes) installed in the For inbound RSVP sessions, the routing table is
routing table. the primary IPv4 table (inet.0). For transit and
outbound RSVP sessions, the routing table is the
primary MPLS table (mpls.0).
Style RSVP reservation style. This field consists of two This field is used for outbound and transit LSPs
parts. The first is the number of active only.
reservations. The second is the reservation style,
which can be FF (fixed filter), SE (shared explicit),
or WF (wildcard filter).
Labelin Incoming label for this RSVP session. –
Labelout Outgoing label for this RSVP session. –
Total Total number of RSVP sessions displayed for the –

particular type—ingress (inbound), egress
(outbound), or transit).

Monitoring MPLS RSVP Interfaces Information
Purpose View information about the interfaces on which RSVP is enabled, including the interface
name, total bandwidth through the interface, and total current reserved and reservable
(available) bandwidth on the interface.
Action Select Monitor>MPLS>RSVP Interfaces in the J-Web user interface, or enter the show
rsvp interface command.
Table 75 on page 426 summarizes key output fields in the RSVP interfaces information
display.
Table 75: Summary of Key RSVP Interfaces Information Output Fields

RSVP Interface Number of interfaces on which RSVP is active. –

Each interface has one line of output.
Interface Name of the interface. –
State State of the interface: –
• Disabled—No traffic engineering information is

displayed.
• Down—The interface is not operational.
• Enabled—Displays traffic engineering
information.
• Up—The interface is operational.
Active resv Number of reservations that are actively reserving –

bandwidth on the interface.
Subscription User-configured subscription factor. –
Static BW Total interface bandwidth, in bits per second –

(bps).
Available BW Amount of bandwidth that RSVP is allowed to –

reserve, in bits per second (bps). It is equal to
(static bandwidth X subscription factor).
Reserved BW Currently reserved bandwidth, in bits per second –

(bps).
Highwater mark Highest bandwidth that has ever been reserved –

on this interface, in bits per second (bps).

Related • Understanding Ping MPLS on page 543

Documentation
• MPLS Connection Checking Overview on page 541
• Monitoring Overview on page 7
Monitoring PPP
Supported Platforms SRX1500, SRX300, SRX320, SRX340
Purpose Display PPP monitoring information, including PPP address pool information, session
status for PPP interfaces, cumulative statistics for all PPP interfaces, and a summary of
PPP sessions.
NOTE: PPP monitoring information is available only in the CLI. The J-Web
user interface does not include pages for displaying PPP monitoring
information.
Action Enter the following CLI commands:
• show ppp address-pool pool-name
• show ppp interface interface-name
• show ppp statistics
• show ppp summary

Documentation
Monitoring PPPoE
Purpose Display the session status for PPPoE interfaces, cumulative statistics for all PPPoE
interfaces on the device, and the PPPoE version configured on the device.
Action Select Monitor>PPPoE in the J-Web user interface. To view interface-specific properties
in the J-Web interface, select the interface name on the PPPoE page.
Table 76 on page 428 summarizes key output fields in PPPoE displays.

Table 76: Summary of Key PPPoE Output Fields

PPPoE Interfaces
Interface Name of the PPPoE interface. Click the interface name to display PPPoE
information for the interface.
State State of the PPPoE session on the interface. –
Session ID Unique session identifier for the PPPoE session. To establish a PPPoE session, first the device acting
as a PPPoE client obtains the Ethernet address of
the PPPoE server or access concentrator, and then
the client and the server negotiate a unique session
ID. This process is referred to as PPPoE active
discovery and is made up of four steps: initiation,
offer, request, and session confirmation. The access
concentrator generates the session ID for session
confirmation and sends it to the PPPoE client in a
PPPoE Active Discovery Session-Confirmation
(PADS) packet.
Service Name Type of service required from the access Service Name identifies the type of service provided
concentrator. by the access concentrator, such as the name of the
Internet service provider (ISP), class, or quality of
service.
Configured AC Configured access concentrator name. –

Name
Session AC Names Name of the access concentrator. –
AC MAC Address Media access control (MAC) address of the access –

concentrator.
Session Uptime Number of seconds the current PPPoE session has –

been running.
Auto-Reconnect Number of seconds to wait before reconnecting –

Timeout after a PPPoE session is terminated.
Idle Timeout Number of seconds a PPPoE session can be idle –

without disconnecting.
Underlying Name of the underlying logical Ethernet or ATM –

Interface interface on which PPPoE is running—for example,
ge-0/0/0.1.
PPPoE Statistics
Active PPPoE Total number of active PPPoE sessions. –
Sessions

Table 76: Summary of Key PPPoE Output Fields (continued)

Packet Type Packets sent and received during the PPPoE –

session, categorized by packet type and packet
error:
• PADI—PPPoE Active Discovery Initiation

packets.
• PADO—PPPoE Active Discovery Offer packets.
• PADR—PPPoE Active Discovery Request
packets.
• PADS—PPPoE Active Discovery
Session-Confirmation packets.
• PADT—PPPoE Active Discovery Terminate
packets.
• Service Name Error—Packets for which the
Service-Name request could not be honored.
• AC System Error—Packets for which the access
concentrator experienced an error in processing
the host request. For example, the host had
insufficient resources to create a virtual circuit.
• Generic Error—Packets that indicate an
unrecoverable error occurred.
• Malformed Packet—Malformed or short packets
that caused the packet handler to disregard the
frame as unreadable.
• Unknown Packet—Unrecognized packets.
Sent Number of the specific type of packet sent from –

the PPPoE client.
Received Number of the specific type of packet received by –

the PPPoE client.
Timeout Information about the timeouts that occurred –

during the PPPoE session.
• PADI—Number of timeouts that occurred for

the PADI packet.
• PADO—Number of timeouts that occurred for
the PADO packet. (This value is always 0 and
is not supported.
• PADR—Number of timeouts that occurred for
the PADR packet.
Sent Number of the timeouts that occurred for PADI, –

PADO, and PADR packets.
PPPoE Version
Maximum Sessions Maximum number of active PPPoE sessions the –
device can support. The default is 256 sessions.

Table 76: Summary of Key PPPoE Output Fields (continued)

PADI Resend Initial time, (in seconds) the device waits to receive The PPPoE Active Discovery Initiation (PADI) packet
Timeout a PADO packet for the PADI packet sent—for is sent to the access concentrator to initiate a PPPoE
example, 2 seconds. This timeout doubles for each session. Typically, the access concentrator responds
successive PADI packet sent. to a PADI packet with a PPPoE Active Discovery Offer
(PADO) packet. If the access concentrator does not
send a PADO packet, the device sends the PADI
packet again after timeout period is elapsed. The
PADI Resend Timeout doubles for each successive
PADI packet sent. For example, if the PADI Resend
Timeout is 2 seconds, the second PADI packet is sent
after 2 seconds, the third after 4 seconds, the fourth
after 8 seconds, and so on.
PADR Resend Initial time (in seconds) the device waits to receive The PPPoE Active Discovery Request (PADR) packet
Timeout a PADS packet for the PADR packet sent. This is sent to the access concentrator in response to a
timeout doubles for each successive PADR packet PADO packet, and to obtain the PPPoE session ID.
sent. Typically, the access concentrator responds to a
PADR packet with a PPPoE Active Discovery
Session-Confirmation (PADS) packet, which contains
the session ID. If the access concentrator does not
send a PADS packet, the device sends the PADR
packet again after the PADR Resend Timeout period
is elapsed. The PADR Resend Timeout doubles for
each successive PADR packet sent.
Maximum Resend Maximum value (in seconds) that the PADI or –

Timeout PADR resend timer can accept—for example, 64
seconds. The maximum value is 64.
Maximum Time (in seconds), within which the configured –

Configured AC access concentrator must respond.
Timeout
Alternatively, enter the following CLI commands:
• show pppoe interfaces
• show pppoe statistics
• show pppoe version
You can also view status information about the PPPoE interface by entering the show
interfaces pp0 command in the CLI editor.

Documentation
• Monitoring DHCP Client Bindings on page 471

Monitoring Spanning Tree
Purpose Use the monitoring functionality to view the Spanning Tree page.
Action To monitor spanning tree, select Monitor>Switching>Spanning Tree in the J-Web user
interface.
Meaning Table 77 on page 431 summarizes key output fields in the spanning tree page.
Table 77: Spanning Tree Monitoring Page

Bridge parameters
Context ID An internally generated identifier. –
Enabled Protocol Spanning tree protocol type enabled. –
Root ID Bridge ID of the elected spanning tree root The bridge ID consists of a configurable
bridge. bridge priority and the MAC address of the
bridge.
Bridge ID Locally configured bridge ID. –
Inter instance ID An internally generated instance identifier. –
Extended system ID Extended system generated instance –

identifier.
Maximum age Maximum age of received bridge protocol –

data units (BPDUs).
Number of topology changes Total number of STP topology changes –

detected since the switch last booted.
Forward delay Spanning tree forward delay. –
Interface List
Interface Name Interface configured to participate in the STP –
instance.
Port ID Logical interface identifier configured to –

participate in the STP instance.
Designated Port ID Port ID of the designated port for the LAN –

segment to which the interface is attached.
Port Cost Configured cost for the interface. –

Table 77: Spanning Tree Monitoring Page (continued)

State STP port state. Forwarding (FWD), blocking –

(BLK), listening, learning, or disabled.
Role MSTP or RSTP port role. Designated (DESG), –

backup (BKUP), alternate (ALT), or root.
Related • Monitoring Ethernet Switching on page 418

Documentation
• Monitoring GVRP on page 419
Monitoring the WAN Acceleration Interface
Purpose View status information and traffic statistics for the WAN acceleration interface.
Action Select Monitor>WAN Acceleration in the J-Web user interface, or select Monitor>Interfaces
and select the interface name (wx-slot/0/0). Alternatively, enter the following CLI
command:
[edit]
user@host# show interfaces wx-slot/0/0 detail

Documentation

CHAPTER 25
Monitoring NAT
• Monitoring NAT on page 433
Monitoring NAT
• Monitoring Source NAT Information on page 433

• Monitoring Destination NAT Information on page 439
• Monitoring Static NAT Information on page 441
• Monitoring Incoming Table Information on page 442
• Monitoring Interface NAT Port Information on page 443
Monitoring Source NAT Information
Purpose Display configured information about source Network Address Translation (NAT) rules,
pools, persistent NAT, and paired addresses.
Action Select Monitor>NAT>Source NAT in the J-Web user interface, or enter the following CLI
commands:
• show security nat source summary
• show security nat source pool pool-name
• show security nat source persistent-nat-table
• show security nat source paired-address
Table 78 on page 433 describes the available options for monitoring source NAT.
Table 78: Source NAT Monitoring Page

Field Description Action
Rules

Table 78: Source NAT Monitoring Page (continued)

Rule-set Name of the rule set. Select all rule sets or a specific rule set to display from
Name the list.
Total rules Number of rules configured. –
ID Rule ID number. –
Name Name of the rule . –
From Name of the routing instance/zone/interface from –

which the packet flows.
To Name of the routing instance/zone/interface to which –

the packet flows.
Source Source IP address range in the source pool. –

address
range
Destination Destination IP address range in the source pool. –

address
range
Source Source port numbers. –

ports
Ip protocol IP protocol. –
Action Action taken for a packet that matches a rule. –
Persistent Persistent NAT type. –

NAT type
Inactivity Inactivity timeout interval for the persistent NAT binding. –

timeout
Alarm Utilization alarm threshold.

threshold
Max The maximum number of sessions. –

session
number

Chapter 25: Monitoring NAT

Sessions Successful, failed, and current sessions. –

(Succ/
Failed/ • Succ–Number of successful session installations
Current) after the NAT rule is matched.
• Failed–Number of unsuccessful session installations
after the NAT rule is matched.
• Current–Number of sessions that reference the
specified rule.
Translation Number of times a translation in the translation table –

Hits is used for a source NAT rule.
Pools
Pool Name The names of the pools. Select all pools or a specific pool to display from the
list.
Total Pools Total pools added. –
ID ID of the pool. –
Name Name of the source pool. –
Address IP address range in the source pool. –

range
Single/Twin Number of allocated single and twin ports. –

ports
Port Source port number in the pool. –
Address Displays the type of address assignment. –

assignment
Alarm Utilization alarm threshold. –

threshold
Port Port overloading capacity. –

overloading
factor
Routing Name of the routing instance. –

instance
Total Total IP address, IP address set, or address book entry. –

addresses
Host Host base address of the original source IP address –

address range.
base



hits is used for source NAT.
Top 10 Translation Hits

Graph Displays the graph of top 10 translation hits. –
Persistent NAT
Persistent NAT table statistics

binding Displays the total number of persistent NAT bindings –
total for the FPC.
binding in Number of persistent NAT bindings that are in use for –

use the FPC.
enode total Total number of persistent NAT enodes for the FPC. –
enode in Number of persistent NAT enodes that are in use for –

use the FPC.
Persistent NAT table

Source Name of the pool. Select all pools or a specific pool to display from the
NAT pool list.
Internal IP Internal IP address. Select all IP addresses or a specific IP address to display

from the list.
Internal Displays the internal ports configured in the system. Select the port to display from the list.
port
Internal Internal protocols . Select all protocols or a specific protocol to display

protocol from the list.
Internal IP Internal transport IP address of the outgoing session –

from internal to external.
Internal Internal transport port number of the outgoing session –

port from internal to external.
Internal Internal protocol of the outgoing session from internal –

protocol to external.
Reflective Translated IP address of the source IP address. –

IP
Reflective Displays the translated number of the port. –

port


Reflective Translated protocol. –

protocol
Source Name of the source NAT pool where persistent NAT is –

NAT pool used.
Type Persistent NAT type. –
Left Inactivity timeout period that remains and the –

time/Conf configured timeout value.
time
Current Number of current sessions associated with the –

session persistent NAT binding and the maximum number of
num/Max sessions.
session
num
Source Name of the source NAT rule to which this persistent –

NAT rule NAT binding applies.
External node table

Internal IP Internal transport IP address of the outgoing session –
from internal to external.
Internal Internal port number of the outgoing session from –

port internal to external.
External IP External IP address of the outgoing session from internal –

to external.
External External port of the outgoing session from internal to –

port external.
Zone External zone of the outgoing session from internal to –

external.
Paired Address
Pool name Name of the pool. Select all pools or a specific pool to display from the
list.
Specified IP address. Select all addresses, or select the internal or external

Address IP address to display, and enter the IP address.
Pool name Displays the selected pool or pools. –
Internal Displays the internal IP address. –

address


External Displays the external IP address. –

address
Resource Usage
Utilization for all source pools

Pool name Name of the pool. To view additional usage information for Port Address
Translation (PAT) pools, select a pool name. The
information displays under Detail Port Utilization for
Specified Pool.
Pool type Pool type: PAT or Non-PAT. –
Port Port overloading capacity for PAT pools. –

overloading
factor
Address Addresses in the pool. –
Used Number of used resources in the pool. –
For Non-PAT pools, the number of used IP addresses

is displayed.
For PAT pools, the number of used ports is displayed.
Available Number of available resources in the pool. –
For Non-PAT pools, the number of available IP

addresses is displayed.
For PAT pools, the number of available ports is

displayed.
Total Number of used and available resources in the pool. –
For Non-PAT pools, the total number of used and

available IP addresses is displayed.
For PAT pools, the total number of used and available

ports is displayed.
Usage Percent of resources used. –
For Non-PAT pools, the percent of IP addresses used

is displayed.
For PAT pools, the percent of ports, including single and

twin ports, is displayed.
Peak usage Percent of resources used during the peak date and –
time.


Detail Port Utilization for Specified Pool

Address IP addresses in the PAT pool. Select the IP address for which you want to display
Name detailed usage information.
Factor-Index Index number. –
Port-range Displays the number of ports allocated at a time. –
Used Displays the number of used ports. –
Available Displays the number of available ports. –
Total Displays the number of used and available ports. –
Usage Displays the percentage of ports used during the peak –

date and time.
Monitoring Destination NAT Information
Purpose View the destination Network Address Translation (NAT) summary table and the details
of the specified NAT destination address pool information.
Action Select Monitor>NAT> Destination NAT in the J-Web user interface, or enter the following
CLI commands:
• show security nat destination summary
• show security nat destination pool pool-name
Table 79 on page 439 summarizes key output fields in the destination NAT display.
Table 79: Summary of Key Destination NAT Output Fields

Field Values Action
Rules
Rule-set Name of the rule set. Select all rule sets or a specific rule set to display from
Name the list.
Name Name of the rule . –

Table 79: Summary of Key Destination NAT Output Fields (continued)

Field Values Action
Ruleset Name of the rule set. –

Name
From Name of the routing instance/zone/interface from –

which the packet flows.
Source Source IP address range in the source pool. –

address
range
Destination Destination IP address range in the source pool. –

address
range
Destination Destination port in the destination pool. –

port
IP protocol IP protocol. –
Action Action taken for a packet that matches a rule. –
Alarm Utilization alarm threshold. –

threshold

(Succ/
Failed/ • Succ–Number of successful session installations
Current) after the NAT rule is matched.
• Current–Number of sessions that reference the
specified rule.

hits is used for a destination NAT rule.
Pools
Pool Name The names of the pools. Select all pools or a specific pool to display from the
list.
Total Pools Total pools added. –
ID ID of the pool. –
Name Name of the destination pool. –
Address IP address range in the destination pool. –

range

Table 79: Summary of Key Destination NAT Output Fields (continued)

Field Values Action
Port Destination port number in the pool. –
Routing Name of the routing instance. –

instance
Total Total IP address, IP address set, or address book entry. –

addresses

hits is used for destination NAT.
Top 10 Translation Hits

Graph Displays the graph of top 10 translation hits. –
Monitoring Static NAT Information
Purpose View static NAT rule information.
Action Select Monitor>NAT>Static NAT in the J-Web user interface, or enter the following CLI
command:
show security nat static rule
Table 80 on page 441 summarizes key output fields in the static NAT display.
Table 80: Summary of Key Static NAT Output Fields

Field Values Action
Rule-set Name Name of the rule set. Select all rule sets or a specific rule set to
display from the list.
Position Position of the rule that indicates the order in which it –

applies to traffic.
Name Name of the rule. –
Ruleset Name Name of the rule set. –
From Name of the routing instance/interface/zone from which –

the packet comes

Table 80: Summary of Key Static NAT Output Fields (continued)

Field Values Action
Source Source IP addresses. –

addresses
Source ports Source port numbers. –
Destination Destination IP address and subnet mask. –

addresses
Destination Destination port numbers . –

ports
Host addresses Name of the host addresses. –
Host ports Host port numbers.
Netmask Subnet IP address. –
Host routing Name of the routing instance from which the packet comes. –
instance
Alarm threshold Utilization alarm threshold. –

(Succ/
Failed/ • Succ–Number of successful session installations after
Current) the NAT rule is matched.
• Current–Number of sessions that reference the specified
rule.
Translation hits Number of times a translation in the translation table is –

used for a static NAT rule.
Top 10 Displays the graph of top 10 translation hits. –

Translation Hits
Graph
Monitoring Incoming Table Information
Purpose View NAT table information.
Action Select Monitor>NAT>Incoming Table in the J-Web user interface, or enter the following
CLI command:
show security nat incoming-table

Table 81 on page 443 summarizes key output fields in the incoming table display.
Table 81: Summary of Key Incoming Table Output Fields

Field Values
Statistics
In use Number of entries in the NAT table.
Maximum Maximum number of entries possible in the NAT table.
Entry allocation failed Number of entries failed for allocation.
Incoming Table
Clear
Destination Destination IP address and port number.
Host Host IP address and port number that the destination IP address is mapped to.
References Number of sessions referencing the entry.
Timeout Timeout, in seconds, of the entry in the NAT table.
Source-pool Name of source pool where translation is allocated.
Monitoring Interface NAT Port Information
Purpose View port usage for an interface source pool information.
Action Select Monitor>Firewall/NAT>Interface NAT in the J-Web user interface, or enter the
following CLI command:
• show security nat interface-nat-ports
Table 82 on page 443 summarizes key output fields in the interface NAT display.
Table 82: Summary of Key Interface NAT Output Fields

Interface NAT Summary Table

Pool Index Port pool index. –
Total Ports Total number of ports in a port pool. –

Table 82: Summary of Key Interface NAT Output Fields (continued)

Single Number of ports allocated one at a time that are in use. –

Ports
Allocated
Single Number of ports allocated one at a time that are free –

Ports for use.
Available
Twin Ports Number of ports allocated two at a time that are in use. –
Allocated
Twin Ports Number of ports allocated two at a time that are free –
Available for use.

Documentation

CHAPTER 26
Monitoring Security Policies
• Monitoring Policy Statistics on page 445

• Monitoring Routing Information on page 446
• Monitoring Security Features on page 455
Monitoring Policy Statistics
Purpose Monitor and record traffic that Junos OS permits or denies based on previously configured
policies.
Action To monitor traffic, enable the count and log options.
Count—Configurable in an individual policy. If count is enabled, statistics are collected

for sessions that enter the device for a given policy, and for the number of packets and
bytes that pass through the device in both directions for a given policy. For counts (only
for packets and bytes), you can specify that alarms be generated whenever the traffic
exceeds specified thresholds. See count (Security Policies).
Log—Logging capability can be enabled with security policies during session initialization
(session-init) or session close (session-close) stage. See log (Security Policies).
• To view logs from denied connections, enable log on session-init.
• To log sessions after their conclusion/tear-down, enable log on session-close.
NOTE: Session log is enabled at real time in the flow code which impacts
the user performance. If both session-close and session-init are enabled,
performance is further degraded as compared to enabling session-init only.
For details about information collected for session logs, see Information Provided in
Session Log Entries for SRX Series Services Gateways.

Related • Security Policies Overview

Documentation
• Troubleshooting Security Policies on page 597
• Checking a Security Policy Commit Failure on page 597
• Verifying a Security Policy Commit on page 598
• Debugging Policy Lookup on page 598
Monitoring Routing Information
• Monitoring Route Information on page 446

• Monitoring RIP Routing Information on page 448
• Monitoring OSPF Routing Information on page 449
• Monitoring BGP Routing Information on page 451
Monitoring Route Information
Purpose View information about the routes in a routing table, including destination, protocol,
state, and parameter information.
Action Select Monitor>Routing>Route Information in the J-Web user interface, or enter the
• show route terse
• show route detail
NOTE: When you use an HTTPS connection in the Microsoft Internet Explorer
browser to save a report from this page in the J-Web interface, the error
message "Internet Explorer was not able to open the Internet site" is
displayed. This problem occurs because the Cache-Control: no cache HTTP
header is added on the server side and Internet Explorer does not allow you
to download the encrypted file with the Cache-Control: no cache HTTP header
set in the response from the server.
As a workaround, refer to Microsoft Knowledge Base article 323308, which

is available at this URL: http://support.microsoft.com/kb/323308. Also, you
can alternatively use HTTP in the Internet Explorer browser or use HTTPS in
the Mozilla Firefox browser to save a file from this page.

Chapter 26: Monitoring Security Policies
Table 83 on page 447 describes the different filters, their functions, and the associated
actions.
Table 84 on page 447 summarizes key output fields in the routing information display.
Table 83: Filtering Route Messages

Destination Address Specifies the destination address of the route. Enter the destination address.
Protocol Specifies the protocol from which the route was Enter the protocol name.
learned.
Next hop address Specifies the network layer address of the directly Enter the next hop address.
reachable neighboring system (if applicable) and the
interface used to reach it.
Receive protocol Specifies the dynamic routing protocol using which the Enter the routing protocol.
routing information was received through a particular
neighbor.
Best route Specifies only the best route available. Select the view details of the best route.
Inactive routes Specifies the inactive routes. Select the view details of inactive routes.
Exact route Specifies the exact route. Select the view details of the exact route.
Hidden routes Specifies the hidden routes. Select the view details of hidden routes.
Search Applies the specified filter and displays the matching To apply the filter and display messages,
messages. click Search.
Reset Resets selected options to default To reset the filter, click Reset.
Table 84: Summary of Key Routing Information Output Fields

Static The list of static route addresses. –

Route
Addresses
Protocol Protocol from which the route was learned: Static, –

Direct, Local, or the name of a particular protocol.
Preference The preference is the individual preference value for The route preference is used as one of the route
the route. selection criteria.

Table 84: Summary of Key Routing Information Output Fields (continued)

Next-Hop Network Layer address of the directly reachable If a next hop is listed as Discard, all traffic with that
neighboring system (if applicable) and the interface destination address is discarded rather than routed.
used to reach it. This value generally means that the route is a static
route for which the discard attribute has been set.
If a next hop is listed as Reject, all traffic with that

destination address is rejected. This value generally
means that the address is unreachable. For example,
if the address is a configured interface address and the
interface is unavailable, traffic bound for that address
is rejected.
If a next hop is listed as Local, the destination is an

address on the host (either the loopback address or
Ethernet management port 0 address, for example).
Age How long the route has been active. –
State Flags for this route. There are many possible flags.
AS Path AS path through which the route was learned. The –

letters of the AS path indicate the path origin:
• I—IGP.
• E—EGP.
• ?—Incomplete. Typically, the AS path was
aggregated.
Monitoring RIP Routing Information
Purpose View RIP routing information, including a summary of RIP neighbors and statistics.
Action Select Monitor>Routing>RIP Information in the J-Web user interface, or enter the following
CLI commands:
• show rip statistics
• show rip neighbors
Table 85 on page 448 summarizes key output fields in the RIP routing display in the J-Web
user interface.
Table 85: Summary of Key RIP Routing Output Fields

RIP Statistics
Protocol Name The RIP protocol name. –

Table 85: Summary of Key RIP Routing Output Fields (continued)

Port number The port on which RIP is enabled. –
Hold down time The interval during which routes are neither –
advertised nor updated.
Global routes Number of RIP routes learned on the logical –

learned interface.
Global routes held Number of RIP routes that are not advertised or –
down updated during the hold-down interval.
Global request Number of requests dropped. –

dropped
Global responses Number of responses dropped. –

dropped
RIP Neighbors
Details Tab used to view the details of the interface on –
which RIP is enabled.
Neighbor Name of the RIP neighbor. This value is the name of the interface on which
RIP is enabled. Click the name to see the details for
this neighbor.
State State of the RIP connection: Up or Dn (Down). –
Source Address Local source address. This value is the configured address of the interface
on which RIP is enabled.
Destination Address Destination address. This value is the configured address of the
immediate RIP adjacency.
Send Mode The mode of sending RIP messages. –
Receive Mode The mode in which messages are received. –
In Metric Value of the incoming metric configured for the RIP –

neighbor.
Monitoring OSPF Routing Information
Purpose View OSPF routing information, including a summary of OSPF neighbors, interfaces, and
statistics.

Action Select Monitor>Routing>OSPF Information in the J-Web user interface, or enter the
• show ospf neighbors
• show ospf interfaces
• show ospf statistics
Table 86 on page 450 summarizes key output fields in the OSPF routing display in the
J-Web user interface.
Table 86: Summary of Key OSPF Routing Output Fields

OSPF Interfaces
Details Tab used to view the details of the selected –
OSPF.
Interface Name of the interface running OSPF. –
State State of the interface: BDR, Down, DR, DRother, The Down state, indicating that the interface is
Loop, PtToPt, or Waiting. not functioning, and PtToPt state, indicating that
a point-to-point connection has been
established, are the most common states.
Area Number of the area that the interface is in. –
DR ID ID of the area's designated device. –
BDR ID ID of the area's backup designated device. –
Neighbors Number of neighbors on this interface. –
OSPF Statistics
Packets tab
Sent Displays the total number of packets sent. –
Received Displays the total number of packets received. –
Details tab
Flood Queue Depth Number of entries in the extended queue. –
Total Retransmits Number of retransmission entries enqueued. –
Total Database Total number of database description packets. –

Summaries
OSPF Neighbors
Address Address of the neighbor. –

Table 86: Summary of Key OSPF Routing Output Fields (continued)

Interface Interface through which the neighbor is –

reachable.
State State of the neighbor: Attempt, Down, Exchange, Generally, only the Down state, indicating a failed
ExStart, Full, Init, Loading, or 2way. OSPF adjacency, and the Full state, indicating
a functional adjacency, are maintained for more
than a few seconds. The other states are
transitional states that a neighbor is in only
briefly while an OSPF adjacency is being
established.
ID ID of the neighbor. –
Priority Priority of the neighbor to become the –

designated router.
Activity Time The activity time. –
Area Area that the neighbor is in. –
Options Option bits received in the hello packets from –

the neighbor.
DR Address Address of the designated router. –
BDR Address Address of the backup designated router. –
Uptime Length of time since the neighbor came up. –
Adjacency Length of time since the adjacency with the –

neighbor was established.
Monitoring BGP Routing Information
Purpose Monitor BGP routing information on the routing device, including a summary of BGP
routing and neighbor information.
Action Select Monitor>Routing>BGP Information in the J-Web user interface, or enter the following
CLI commands:
• show bgp summary
• show bgp neighbor
Table 87 on page 452 summarizes key output fields in the BGP routing display in the J-Web
user interface.

Table 87: Summary of Key BGP Routing Output Fields

BGP Peer Summary

Total Groups Number of BGP groups. –
Total Peers Number of BGP peers. –
Down Peers Number of unavailable BGP peers. –
Unconfigured Peers Address of each BGP peer. –
RIB Summary tab

RIB Name Name of the RIB group. –
Total Prefixes Total number of prefixes from the peer, both –

active and inactive, that are in the routing table.
Active Prefixes Number of prefixes received from the EBGP –

peers that are active in the routing table.
Suppressed Prefixes Number of routes received from EBGP peers –

currently inactive because of damping or other
reasons.
History Prefixes History of the routes received or suppressed. –
Dumped Prefixes Number of routes currently inactive because of –

damping or other reasons. These routes do not
appear in the forwarding table and are not
exported by routing protocols.
Pending Prefixes Number of pending routes. –
State Status of the graceful restart process for this –

routing table: BGP restart is complete, BGP
restart in progress, VPN restart in progress, or
VPN restart is complete.
BGP Neighbors
Details Click this button to view the selected BGP –
neighbor details.
Peer Address Address of the BGP neighbor. –
Autonomous System AS number of the peer. –

Table 87: Summary of Key BGP Routing Output Fields (continued)

Peer State Current state of the BGP session: Generally, the most common states are Active,
which indicates a problem establishing the BGP
• Active—BGP is initiating a TCP connection in connection, and Established, which indicates a
an attempt to connect to a peer. If the successful session setup. The other states are
connection is successful, BGP sends an open transition states, and BGP sessions normally do
message. not stay in those states for extended periods of
• Connect—BGP is waiting for the TCP time.
connection to become complete.
• Established—The BGP session has been
established, and the peers are exchanging
BGP update messages.
• Idle—This is the first stage of a connection.
BGP is waiting for a Start event.
• OpenConfirm—BGP has acknowledged receipt
of an open message from the peer and is
waiting to receive a keepalive or notification
message.
• OpenSent—BGP has sent an open message
and is waiting to receive an open message
from the peer.
Elapsed Time Elapsed time since the peering session was last –
reset.
Description Description of the BGP session. –

Documentation
Monitoring Security Events by Policy
Purpose Monitor security events by policy and display logged event details with the J-Web user
interface.
Action 1. Select Monitor>Events and Alarms>Security Events in the J-Web user interface. The
View Policy Log pane appears. Table 88 on page 453 describes the content of this
pane.
Table 88: View Policy Log Fields

Field Value
Log file name Name of the event log files to search.
Policy name Name of the policy of the events to be retrieved.

Table 88: View Policy Log Fields (continued)

Field Value
Source address Source address of the traffic that triggered the event.
Destination address Destination address of the traffic that triggered the event.
Event type Type of event that was triggered by the traffic.
Application Application of the traffic that triggered the event.
Source port Source port of the traffic that triggered the event.
Destination port Destination port of the traffic that triggered the event.
Source zone Source zone of the traffic that triggered the event.
Destination zone Destination zone of the traffic that triggered the event.
Source NAT rule Source NAT rule of the traffic that triggered the event.
Destination NAT rule Destination NAT rule of the traffic that triggered the event.
Is global policy Specifies that the policy is a global policy.
If your device is not configured to store session log files locally, the Create log
configuration button is displayed in the lower-right portion of the View Policy Log
pane.
• To store session log files locally, click Create log configuration.
If session logs are being sent to an external log collector (stream mode has been
configured for log files), a message appears indicating that event mode must be
configured to view policy logs.
NOTE: Reverting to event mode will discontinue event logging to the

external log collector.
• To reset the mode option to event, enter the set security log command.
2. Enter one or more search fields in the View Policy Log pane and click Search to display
events matching your criteria.
For example, enter the event type Session Close and the policy pol1 to display event
details from all Session Close logs that contain the specified policy. To reduce search
results further, add more criteria about the particular event or group of events that
you want displayed.

The Policy Events Detail pane displays information from each matching session log.
Table 89 on page 455 describes the contents of this pane.
Table 89: Policy Events Detail Fields

Field Value
Timestamp Time when the event occurred.
Policy name Policy that triggered the event.
Record type Type of event log providing the data.
Source IP/Port Source address (and port, if applicable) of the event traffic.
Destination IP/Port Destination address (and port, if applicable) of the event traffic.
Service name Service name of the event traffic.
NAT source IP/Port NAT source address (and port, if applicable) of the event traffic.
NAT destination IP/Port NAT destination address (and port, if applicable) of the event
traffic.

Documentation
Monitoring Security Features
• Monitoring Policies on page 456

• Checking Policies on page 458
• Monitoring Screen Counters on page 461
• Monitoring IDP Status on page 463
• Monitoring Flow Gate Information on page 464
• Monitoring Firewall Authentication Table on page 465
• Monitoring Firewall Authentication History on page 467
• Monitoring 802.1x on page 469

Monitoring Policies
Purpose Display, sort, and review policy activity for every activated policy configured on the device.
Policies are grouped by Zone Context (the from and to zones of the traffic) to control
the volume of data displayed at one time. From the policy list, select a policy to display
statistics and current network activity.
Action To review policy activity:
1. Select Monitor>Security>Policy>Activities in the J-Web user interface. The Security

Policies Monitoring page appears and lists the policies from the first Zone Context.
See Table 90 on page 456 for field descriptions.
2. Select the Zone Context of the policy you want to monitor, and click Filter. All policies
within the zone context appear in match sequence.
3. Select a policy, and click Clear Statistics to set all counters to zero for the selected
policy.
Table 90: Security Policies Monitoring Output Fields

Zone Context Displays a list of all from and to zone combinations To display policies for a different context, select a
(Total #) for the configured policies. The total number of zone context and click Filter. Both inactive and active
active policies for each context is specified in the policies appear for each context. However, the Total
Total # field. By default, the policies from the first # field for a context specifies the number of active
Zone Context are displayed. policies only.
Default Policy Specifies the action to take for traffic that does not –
action match any of the policies in the context:
• permit-all—Permit all traffic that does not match

a policy.
• deny-all—Deny all traffic that does not match a
policy.
From Zone Displays the source zone to be used as match –

criteria for the policy.
To Zone Displays the destination zone to be used as match –

criteria for the policy.
Name Displays the name of the policy. –
Source Address Displays the source addresses to be used as match –

criteria for the policy. Address sets are resolved to
their individual names. (In this case, only the names
are given, not the IP addresses).

Table 90: Security Policies Monitoring Output Fields (continued)

Destination Displays the destination addresses (or address –

Address sets) to be used as match criteria for the policy.
Addresses are entered as specified in the
destination zone’s address book.
Source Identity Displays the name of the source identities set for To display the value of the source identities, hover
the policy. the mouse on this field. Unknown source identities
are also displayed.
Application Displays the name of a predefined or custom –

application signature to be used as match criteria
for the policy.
Dynamic App Displays the dynamic application signatures to be The rule set appears in two lines. The first line
used as match criteria if an application firewall rule displays the configured dynamic application
set is configured for the policy. signatures in the rule set. The second line displays
the default dynamic application signature.
For a network firewall, a dynamic application is not
defined. If more than two dynamic application signatures are
specified for the rule set, hover over the output field
to display the full list in a tooltip.
Action Displays the action portion of the rule set if an The action portion of the rule set appears in two
application firewall rule set is configured for the lines. The first line identifies the action to be taken
policy. when the traffic matches a dynamic application
signature. The second line displays the default action
• permit—Permits access to the network services when traffic does not match a dynamic application
controlled by the policy. A green background signature.
signifies permission.
• deny—Denies access to the network services
controlled by the policy. A red background
signifies denial.
NW Services Displays the network services permitted or denied –

by the policy if an application firewall rule set is
configured. Network services include:
• gprs-gtp-profile—Specify a GPRS Tunneling

Protocol profile name.
• idp—Perform intrusion detection and prevention.
• redirect-wx—Set WX redirection.
• reverse-redirect-wx—Set WX reverse redirection.
• uac-policy—Enable unified access control
enforcement of the policy.
Policy Hit Counters Provides a representation of the value over time for To toggle a graph on and off, click the counter name
Graph a specified counter. The graph is blank if Policy below the graph.
Counters indicates no data. As a selected counter
accumulates data, the graph is updated at each
refresh interval.

Table 90: Security Policies Monitoring Output Fields (continued)

Policy Counters Lists statistical counters for the selected policy if To graph or to remove a counter from the Policy Hit
Count is enabled. The following counters are Counters Graph, toggle the counter name. The
available for each policy: names of enabled counters appear below the graph.
• input-bytes
• input-byte-rate
• output-bytes
• output-byte-rate
• input-packets
• input-packet-rate
• output-packets
• output-packet-rate
• session-creations
• session-creation-rate
• active-sessions
Checking Policies
Purpose Enter match criteria and conduct a policy search. The search results include all policies
that match the traffic criteria in the sequence in which they will be encountered.
Because policy matches are listed in the sequence in which they would be encountered,
you can determine whether a specific policy is being applied correctly or not. The first
policy in the list is applied to all matching traffic. Policies listed after this one remain in
the “shadow” of the first policy and are never encountered by this traffic.
By manipulating the traffic criteria and policy sequence, you can tune policy application
to suit your needs. During policy development, you can use this feature to establish the
appropriate sequence of policies for optimum traffic matches. When troubleshooting,
use this feature to determine if specific traffic is encountering the appropriate policy.
Action 1. Select Monitor>Security>Policy>Shadow Policies in the J-Web user interface. The

Check Policies page appears. Table 91 on page 459 explains the content of this page.
2. In the top pane, enter the From Zone and To Zone to supply the context for the search.
3. Enter match criteria for the traffic, including the source address and port, the
destination address and port, and the protocol of the traffic.
4. Enter the number of matching policies to display.
5. Click Search to find policies matching your criteria. The lower pane displays all policies
matching the criteria up to the number of policies you specified.
• The first policy will be applied to all traffic with this match criteria.

• Remaining policies will not be encountered by any traffic with this match criteria.
6. To manipulate the position and activation of a policy, select the policy and click the
appropriate button:
• Move—Moves the selected policy up or down to position it at a more appropriate

point in the search sequence.
• Move to—Moves the selected policy by allowing you to drag and drop it to a different
location on the same page.
Table 91: Check Policies Output

Field Function
Check Policies Search Input Pane

From Zone Name or ID of the source zone. If a From Zone is specified by name, the name is
translated to its ID internally.
To Zone Name or ID of the destination zone. If a To Zone is specified by name, the name is
translated to its ID internally.
Source Address Address of the source in IP notation.
Source Port Port number of the source.
Destination Address Address of the destination in IP notation.
Destination Port Port number of the destination.
Source Identity Name of the source identity.

Table 91: Check Policies Output (continued)

Field Function
Protocol Name or equivalent value of the protocol to be matched.
ah—51
egp—8
esp—50
gre—47
icmp—1
igmp—2
igp—9
ipip—94
ipv6—41
ospf—89
pgm—113
pim—103
rdp—27
rsvp—46
sctp—132
tcp—6
udp—17
vrrp—112
Result Count (Optional) Number of policies to display. Default value is 1. Maximum value is 16.
Check Policies List

From Zone Name of the source zone.
To Zone Name of the destination zone.
Total Policies Number of policies retrieved.
Default Policy action The action to be taken if no match occurs.
Name Policy name
Source Address Name of the source address (not the IP address) of a policy. Address sets are resolved
to their individual names.

Table 91: Check Policies Output (continued)

Field Function
Destination Address Name of the destination address or address set. A packet’s destination address must
match this value for the policy to apply to it.
Source Identity Name of the source identity for the policy.
Application Name of a preconfigured or custom application of the policy match.
Action Action taken when a match occurs as specified in the policy.
Hit Counts Number of matches for this policy. This value is the same as the Policy Lookups in a
policy statistics report.
Active Sessions Number of active sessions matching this policy.
Alternatively, to list matching policies using the CLI, enter the show security match-policies
command and include your match criteria and the number of matching policies to display.
Monitoring Screen Counters
Purpose View screen statistics for a specified security zone.
Action Select Monitor>Security>Screen Counters in the J-Web user interface, or enter the following
CLI command:
show security screen statistics zone zone-name
Table 92 on page 461 summarizes key output fields in the screen counters display.
Table 92: Summary of Key Screen Counters Output Fields

Zones
ICMP Flood Internet Control Message Protocol (ICMP) flood An ICMP flood typically occurs when ICMP echo
counter. requests use all resources in responding, such
that valid network traffic can no longer be
processed.
UDP Flood User Datagram Protocol (UDP) flood counter. UDP flooding occurs when an attacker sends IP
packets containing UDP datagrams with the
purpose of slowing down the resources, such
that valid connections can no longer be handled.
TCP Winnuke Number of Transport Control Protocol (TCP) WinNuke is a denial-of-service (DoS) attack
WinNuke attacks. targeting any computer on the Internet running
Windows.

Table 92: Summary of Key Screen Counters Output Fields (continued)

TCP Port Scan Number of TCP port scans. The purpose of this attack is to scan the available
services in the hopes that at least one port will
respond, thus identifying a service to target.
ICMP Address Sweep Number of ICMP address sweeps. An IP address sweep can occur with the intent
of triggering responses from active hosts.
IP Tear Drop Number of teardrop attacks. Teardrop attacks exploit the reassembly of
fragmented IP packets.
TCP SYN Attack Number of TCP SYN attacks. –
IP Spoofing Number of IP spoofs. IP spoofing occurs when an invalid source

address is inserted in the packet header to make
the packet appear to come from a trusted
source.
ICMP Ping of Death ICMP ping of death counter. Ping of death occurs when IP packets are sent
that exceed the maximum legal length (65,535
bytes).
IP Source Route Number of IP source route attacks. –
TCP Land Attack Number of land attacks. Land attacks occur when attacker sends spoofed
SYN packets containing the IP address of the
victim as both the destination and source IP
address.
TCP SYN Fragment Number of TCP SYN fragments. –
TCP No Flag Number of TCP headers without flags set. A normal TCP segment header has at least one
control flag set.
IP Unknown Protocol Number of unknown Internet protocols. –
IP Bad Options Number of invalid options. –
IP Record Route Option Number of packets with the IP record route This option records the IP addresses of the
option enabled. network devices along the path that the IP
packet travels.
IP Timestamp Option Number of IP timestamp option attacks. This option records the time (in Universal Time)
when each network device receives the packet
during its trip from the point of origin to its
destination.
IP Security Option Number of IP security option attacks. –

Table 92: Summary of Key Screen Counters Output Fields (continued)

IP Loose route Option Number of IP loose route option attacks. This option specifies a partial route list for a
packet to take on its journey from source to
destination.
IP Strict Source Route Number of IP strict source route option attacks. This option specifies the complete route list for
Option a packet to take on its journey from source to
destination.
IP Stream Option Number of stream option attacks. This option provides a way for the 16-bit SATNET
stream identifier to be carried through networks
that do not support streams.
ICMP Fragment Number of ICMP fragments. Because ICMP packets contain very short
messages, there is no legitimate reason for ICMP
packets to be fragmented. If an ICMP packet is
so large that it must be fragmented, something
is amiss.
ICMP Large Packet Number of large ICMP packets. –
TCP SYN FIN Packet Number of TCP SYN FIN packets. –
TCP FIN without ACK Number of TCP FIN flags without the –
acknowledge (ACK) flag.
TCP SYN-ACK-ACK Number of TCP flags enabled with To prevent flooding with SYN-ACK-ACK
Proxy SYN-ACK-ACK. sessions, you can enable the SYN-ACK-ACK
proxy protection screen option. After the number
of connections from the same IP address reaches
the SYN-ACK-ACK proxy threshold, Junos OS
rejects further connection requests from that IP
address.
IP Block Fragment Number of IP block fragments. –
Monitoring IDP Status
Purpose View detailed information about the IDP Status, Memory, Counters, Policy Rulebase
Statistics, and Attack table statistics.
Action To view Intrusion Detection and Prevention (IDP) table information, select
Monitor>Security>IDP>Status in the J-Web user interface, or enter the following CLI
commands:
• show security idp status
• show security idp memory

Table 93 on page 464 summarizes key output fields in the IDP display.
Table 93: Summary of IDP Status Output Fields

IDP Status
Status of IDP Displays the status of the current IDP policy. –
Up Since Displays the time from when the IDP policy first –
began running on the system.
Packets/Second Displays the number of packets received and –

returned per second.
Peak Displays the maximum number of packets –

received per second and the time when the
maximum was reached.
Kbits/Second Displays the aggregated throughput (kilobits per –

second) for the system.
Peak Kbits Displays the maximum kilobits per second and –

the time when the maximum was reached.
Latency (Microseconds) Displays the delay, in microseconds, for a packet –

to receive and return by a node .
Current Policy Displays the name of the current installed IDP –

policy.
IDP Memory Status

IDP Memory Statistics Displays the status of all IDP data plane memory. –
PIC Name Displays the name of the PIC. –
Total IDP Data Plane Displays the total memory space, in megabytes, –
Memory (MB) allocated for the IDP data plane.
Used (MB) Displays the used memory space, in megabytes, –

for the data plane.
Available (MB) Displays the available memory space, in –

megabytes, for the data plane.
Monitoring Flow Gate Information
Purpose View information about temporary openings known as pinholes or gates in the security
firewall.

Action Select Monitor>Security>Flow Gate in the J-Web user interface, or enter the show security
flow gate command.
Table 94 on page 465 summarizes key output fields in the flow gate display.
Table 94: Summary of Key Flow Gate Output Fields

Flow Gate Information

Hole Range of flows permitted by the pinhole. –
Translated Tuples used to create the session if it matches the –

pinhole:
• Source address and port

• Destination address and port
Protocol Application protocol, such as UDP or TCP. –
Application Name of the application. –
Age Idle timeout for the pinhole. –
Flags Internal debug flags for pinhole. –
Zone Incoming zone. –
Reference Number of resource manager references to the pinhole. –

count
Resource Resource manager information about the pinhole. –
Monitoring Firewall Authentication Table
Purpose View information about the authentication table, which divides firewall authentication
user information into multiple parts.
Action Select Monitor>Security>Firewall Authentication>Authentication Table in the J-Web user

interface. To view detailed information about the user with a particular identifier, select
the ID on the Authentication Table page. To view detailed information about the user at
a particular source IP address, select the Source IP on the Authentication Table page.
Alternatively, enter the following CLI show commands:
• show security firewall-authentication users
• show security firewall-authentication users address ip-address
• show security firewall-authentication users identifier identifier

Table 95 on page 466 summarizes key output fields in firewall authentication table display.
Table 95: Summary of Key Firewall Authentication Table Output Fields

Firewall authentication users

Total users in table Number of users in the authentication table. –
Authentication table
ID Authentication identification number. –
Source Ip IP address of the authentication source. –
Age Idle timeout for the user. –
Status Status of authentication (success or failure). –
user Name of the user. –
Detailed report per ID selected: ID

Source Zone Name of the source zone. –
Destination Zone Name of the destination zone. –
profile Name of the profile. Users information.
Authentication method Path chosen for authentication. –
Policy Id Policy Identifier. –
Interface name Name of the interface. –
Bytes sent by this user Number of packets in bytes sent by this user. –
Bytes received by this Number of packets in bytes received by this user. –

user
Client-groups Name of the client group. –
Detailed report per Source Ip selected

Entries from Source IP IP address of the authentication source. –
Source Zone Name of the source zone. –
profile Name of the profile. –
Age Idle timeout for the user. –

Table 95: Summary of Key Firewall Authentication Table Output Fields (continued)
user Name of the user. –
Policy Id Policy Identifier. –

user
Monitoring Firewall Authentication History
Purpose View information about the authentication history, which is divided into multiple parts.
Action Select Monitor>Security>Firewall Authentication>Authentication History in the J-Web

user interface. To view the detailed history of the authentication with this identifier, select
the ID on the Firewall Authentication History page. To view a detailed authentication
history of this source IP address, select the Source IP on the Firewall Authentication
History page.
Alternatively, enter the following CLI show commands:
• show security firewall-authentication history
• show security firewall-authentication history address ip-address
• show security firewall-authentication history identifier identifier
Table 96 on page 467 summarizes key output fields in firewall authentication history
display.
Table 96: Summary of Key Firewall Authentication History Output Fields

History of Firewall Authentication Data

Total authentications Number of authentication. –
History Table

Table 96: Summary of Key Firewall Authentication History Output Fields (continued)
ID Identification number. –
Source Ip IP address of the authentication source. –
Start Date Authentication date. –
Start Time Authentication time. –
Duration Authentication duration. –
User Name of the user. –
Detail history of selected Id: ID

Policy Id Security policy identifier. –
Source zone Name of the source zone. –

user
Detail history of selected Source Ip:Source Ip

User Name of the user. –
Start Date Authentication date. –
Start Time Authentication time. –
Duration Authentication duration. –
Profile Name of the profile. –

Table 96: Summary of Key Firewall Authentication History Output Fields (continued)
Policy Id Security policy identifier. –
Source zone Name of the source zone. –

user
Monitoring 802.1x
Purpose View information about 802.1X properties.
Action Select Monitor>Security>802.1x in the J-Web user interface, or enter the following CLI
commands:
• show dot1x interfaces interface-name
• show dot1x authentication-failed-users
Table 97 on page 469 summarizes the Dot1X output fields.
Table 97: Summary of Dot1X Output Fields

Select Port List of ports for selection. –
Number of connected Total number of hosts connected to the port. –

hosts
Number of Total number of authentication-bypassed hosts –

authentication with respect to the port.
bypassed hosts
Authenticated Users Summary

MAC Address MAC address of the connected host. –
User Name Name of the user. –

Table 97: Summary of Dot1X Output Fields (continued)

Status Information about the host connection status. –
Authentication Due Information about host authentication. –
Authentication Failed Users Summary

MAC Address MAC address of the authentication-failed host. –
User Name Name of the authentication-failed user. –

Documentation

CHAPTER 27
Monitoring Events, Services and System
• Monitoring DHCP Client Bindings on page 471

• Monitoring the System on page 474
Monitoring DHCP Client Bindings
Purpose View information about DHCP client bindings.
Action Select Monitor>Services>DHCP>Binding in the J-Web user interface, or enter the show
system services dhcp binding command.
Table 98 on page 471 summarizes the key output fields in the DHCP client binding displays.
Table 98: Summary of Key DHCP Client Binding Output Fields

IP Address List of IP addresses the DHCP server has assigned to –

clients.
Hardware Corresponding media access control (MAC) address –

Address of the client.
Type Type of binding assigned to the client: dynamic or static. –
Lease Date and time the lease expires, or never for leases that –
Expires at do not expire.
Related • Monitoring PPPoE on page 427

Documentation
• Understanding DHCP Client Operation
Monitoring Events

Purpose Use the monitoring functionality to view the events page.
Action To monitor events select Monitor>Events and Alarms>View Events in the J-Web user
interface.
NOTE: When you use an HTTPS connection in the Microsoft Internet Explorer
browser to save a report from this page in the J-Web interface, the error
message "Internet Explorer was not able to open the Internet site" is
displayed. This problem occurs because the Cache-Control: no cache HTTP
header is added on the server side and Internet Explorer does not allow you
to download the encrypted file with the Cache-Control: no cache HTTP header
set in the response from the server.
As a workaround, refer to Microsoft Knowledge Base article 323308, which

is available at this URL: http://support.microsoft.com/kb/323308. Also, you
can alternatively use HTTP in the Internet Explorer browser or use HTTPS in
the Mozilla Firefox browser to save a file from this page.
Meaning Table 99 on page 472 summarizes key output fields in the events page.
Table 99: Events Monitoring Page

Events Filter
System Log File Specifies the name of the system log file that -
records errors and events.
Process Specifies the system processes that -

generate the events to display.
Include archived files Specifies to enable the option to include Select to enable.
archived files.
Date From Specifies the beginning date range to -

monitor. Set the date using the calendar pick
tool.
To Specifies the end of the date range to -

monitor. Set the date using the calendar pick
tool.
Event ID Specifies the specific ID of the error or event -

to monitor.
Description Enter a description for the errors or events. -
Search Fetches the errors and events specified in -

the search criteria.

Chapter 27: Monitoring Events, Services and System
Table 99: Events Monitoring Page (continued)

Reset Clears the cache of errors and events that -

were previously selected.
Generate Report Creates an HTML report based on the -

specified parameters.
Events Detail
Process Displays the system process that generated –
the error or event.
Severity Displays the severity level that indicates how –

seriously the triggering event affects routing
platform functions. Only messages from the
facility that are rated at that level or higher
are logged. Possible severities and their
corresponding color code are:
• Debug/Info/Notice(Green)–Indicates
conditions that are not errors but are of
interest or might warrant special handling.
• Warning (Yellow) – Indicates conditions
that warrant monitoring.
• Error (Blue) – Indicates standard error
conditions that generally have less serious
consequences than errors in the
emergency, alert, and critical levels.
• Critical (Pink) – Indicates critical
conditions, such as hard drive errors.
• Alert (Orange) – Indicates conditions that
require immediate correction, such as a
corrupted system database.
• Emergency (Red) – Indicates system panic
or other conditions that cause the routing
platform to stop functioning.
Event ID Displays the unique ID of the error or event. -

The prefix on each code identifies the
generating software process. The rest of the
code indicates the specific event or error.
Event Description Displays a more detailed explanation of the -

message.
Time Time that the error or event occurred. -
Related • Monitoring Alarms on page 339

Documentation

Monitoring the System
The J-Web user interface lets you monitor a device’s physical characteristics, current
processing status and alarms, and ongoing resource utilization to quickly assess the
condition of a device at any time.
On SRX Series devices, the Dashboard lets you customize your view by selecting which
informational panes to include on the Dashboard.
• Monitoring System Properties for SRX Series Devices on page 474

• Monitoring Chassis Information on page 476
• System Health Management for SRX Series Devices on page 478
Monitoring System Properties for SRX Series Devices
Purpose View system properties and customize the Dashboard.
When you start the J-Web user interface on an SRX Series device, the interface opens
to the Dashboard. At the top and bottom of the page, the Dashboard displays an
interactive representation of your device and a current log messages pane. By default,
the center panes of the Dashboard display System Information, Resource Utilization,
Security Resources, and System Alarms. However, you can customize the Dashboard
panes to provide the best overview of your system.
Action To control the content and appearance of the Dashboard:
1. Click the Preferences icon at the top-right corner of the page. The Dashboard
Preference dialog box appears.
2. Select the types of information you want to display.
3. (Optional) Specify the Automatically Refresh Data option to specify how often you
want the data on the Dashboard to be refreshed.
4. Click OK to save the configuration or Cancel to clear it.
5. On the Dashboard, minimize, maximize, or drag the individual information panes to

customize the display as needed.
Chassis View—Displays an image of the device chassis, including line cards, link states,
errors, individual PICs, FPCs, fans, and power supplies.
You can use the Chassis View to link to corresponding configuration and monitoring
pages for the device. To link to interface configuration pages for a selected port from
the Chassis View, right-click the port in the device image and choose one of the
following options:

• Chassis Information—Links to the Chassis page.
• Configure Port: Port-name—Links to the interfaces configuration page for the

selected port.
• Monitor Port: Port-name—Links to the monitor interfaces page for the selected
port.
System Identification—Displays the device’s serial number, hostname, current software

version, the BIOS version, the amount of time since the device was last booted, and
the system’s time.
NOTE:
• To view the BIOS version under system identification, delete your
browser cookies.
• The hostname that appears in this pane is defined using the set system
hostname command.
On SRX Series devices, security logs were always timestamped using

the UTC time zone by running set system time-zone utc and set security
log utc-timestamp CLI commands. Now, time zone can be defined using
the local time zone by running the set system time-zone time-zone
command to specify the local time zone that the system should use
when timestamping the security logs.
Resource Utilization—Provides a graphic representation of resource use. Each bar

represents the percentage of CPU, memory, or storage utilization for the data plane
or the control plane.
Security Resources—Provides the maximum, configured, and active sessions; firewall and
VPN policies; and IPsec VPNs. Click Sessions,FW/VPN Policies, or IPsec VPNs for
detailed statistics about each category.
System Alarms—Indicates a missing rescue configuration or software license, where valid.

System alarms are preset and cannot be modified.
File Usage—Displays the usage statistics for log files, temporary files, crash (core) files,
and database files.
Login Sessions—Provides a list of all currently logged in sessions. The display includes
user credentials, login time, and idle time for each session.
Chassis Status—Provides a snapshot of the current physical condition of the device,

including temperature and fan status.
Storage Usage—Displays the storage usage report in detail.
Threat Activity—Provides information about the most current threats received on the
device.

Message Logs—Displays log messages and errors. You can clear old logs from the Message
Logs pane by clicking the Clear button.
To control the information that is displayed in the Chassis View, use the following options:
• To view an image of the front of the device, right-click the image and choose View
Front.
• To view an image of the back of the device, right-click the image and choose View Rear.
• To enlarge or shrink the device view, use the Zoom bar.
• To return the device image to its original position and size, click Reset.
NOTE: To use the Chassis View, a recent version of Adobe Flash that supports
ActionScript and AJAX (Version 9) must be installed. Also note that the
Chassis View appears by default on the Dashboard page. You can enable or
disable it using options in the Dashboard Preference dialog box. Clearing
cookies in Internet Explorer also causes the Chassis View appear on the
Dashboard page.
To return to the Dashboard at any time, select Dashboard in the J-Web user interface.
Alternatively, you can view system properties by entering the following show commands
in the CLI:
• show system uptime
• show system users
• show system storage
• show version
• show chassis hardware
Monitoring Chassis Information
Purpose View chassis properties, which include the status of hardware components on the device.
Action To view these chassis properties, select Monitor>System View>Chassis Information in

the J-Web user interface.
CAUTION: Do not install a combination of Physical Interface Modules (PIMs)

in a single chassis that exceeds the maximum power and heat capacity of
the chassis. If power management is enabled, PIMs that exceed the maximum
power and heat limits remain offline when the chassis is powered on. To

check PIM power and heat status, use the show chassis fpc and show chassis
power-ratings commands.
The Chassis Information page displays the following types of information:
• Routing Engine Details—This section of the page includes the following tabs:
• Master—Master tab displays information about the routing engine, including the
routing engine module, model number, version, part number, serial number, memory
utilization, temperature, and start time. Additionally, this tab displays the CPU load
averages for the last 1, 5, and 15 minutes.
• Backup—If a backup routing engine is available, the Backup tab displays the routing
engine module, model number, version, part number, serial number, memory
utilization, temperature, and start time. Additionally, this tab displays the CPU load
averages for the last 1, 5, and 15 minutes.
NOTE: If you need to contact customer support about the device chassis,
supply them with the version and serial number displayed in the Routing
Engine Details section of the page.
• Power and Fan Tray Details—This Details section of the page includes the following
tabs:
• Power—Power tab displays the names of the device’s power supply units and their
statuses.
• Fan—Fan tab displays the names of the device’s fans and their speeds (normal or
high). (The fan speeds are adjusted automatically according to the current
temperature.)
• Chassis Component Details—This section of the page includes the following tabs:
• General—General tab displays the version number, part number, serial number, and
description of the selected device component.
• Temperature—Temperature tab displays the temperature of the selected device

component (if applicable).
• Resource—Resource tab displays the state, total CPU DRAM, and start time of the
selected device component (if applicable).

NOTE: On some devices, you can have an FPC state as “offline.” You
might want to put an FPC offline because of an error or if the FPC is not
responding. You can put the FPC offline by using the CLI command
request chassis fpc slot number offline.
• Sub-Component—Sub-Component tab displays information about the device’s

sub-components (if applicable). Details include the sub-component’s version, part
number, serial number, and description.
To control which component details appear, select a hardware component from the
Select component list.
Alternatively, you can view chassis details by entering the following show commands in
the CLI configuration editor:
• show chassis hardware
• show chassis routing-engine
• show chassis environment
• show chassis redundant-power-supply
• show redundant-power-supply status
System Health Management for SRX Series Devices
Purpose Tracking the utilization of critical resources in the system ensures that all parameters
are within normal limits and the system remains functional.
In the event of a malfunction caused by abnormal resource usage, the system health
management feature provides the right diagnostic information to identify the source of
the problem.
When the system health management action is configured by the user, the system takes
appropriate monitoring, preventive, and recovery actions to ensure that the system is
accessible. The system configuration might be updated based on the information collected
by system health management feature to ensure that the system stays in the normal
operating environment. For example, when a system runs out of memory, then the
configuration associated with applications identified to be consuming memory resources
can be updated to bring down the memory resource consumption.
Action The system health management feature periodically monitors critical system resources
against configurable thresholds. The resources that can be monitored include CPU usage,
memory, storage, open-file-descriptor, process-count, and temperature. The system
health management feature collects usage information for each resource at the configured

interval and compares it against the three levels of thresholds: moderate, high, and
critical. Based on the configurations, appropriate action is taken.
The intervals, thresholds, and action are associated with system health management
and can be configured at both the resource level and the global level. Configurable and
default levels are as follows:
• Default configuration level— Default configuration is applied when system health

monitoring is enabled, and neither a global nor a resource-specific configuration is
present.
• Global configuration level—Configuration that is applied to resources when no

resource-specific configuration is available.
• Resource-specific configuration level—Configuration that, if available, overrides both

the global and the default configurations.
Per-resource configurations take precedence over the global configuration, and a global
configuration takes precedence over the defaults.
When resource usage exceeds the configured thresholds, the system collects information
that can be used to find the source of the increased usage and saves it in history for
analysis and action.
When resource utilization exceeds the high threshold, a minor system alarm is generated,
and the alarm LED lights yellow. When resource utilization exceeds the critical threshold,
a major alarm is generated, and the alarm LED lights red.
An SNMP trap is also sent to the remote monitoring server (NMS) for all events that
exceed the threshold.
To enable the system health monitor, use the set snmp health-monitor routing engine
command. You can view system properties by using CLI show commands.

Documentation


CHAPTER 28
Monitoring Unified Threat Management

Features
• Monitoring Antivirus Scan Engine Status on page 481

• Monitoring Antivirus Scan Results on page 482
• Monitoring Antivirus Session Status on page 484
• Monitoring Content Filtering Configurations on page 485
• Monitoring Reports on page 486
• Monitoring Web Filtering Configurations on page 492
Monitoring Antivirus Scan Engine Status
Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550M, vSRX
Purpose The Monitoring Antivirus Scan Engine Status is not supported from Junos OS Release
15.1X49-D10 onwards. For previous releases, using the CLI, you can view the following
scan engine status items:
Antivirus license key status
• View license expiration dates.
Scan engine status and settings
• View last action result.
• View default file extension list.
Antivirus pattern update server settings
• View update URL (HTTP or HTTPS-based).
• View update interval.
Antivirus pattern database status
• View auto update status.
• View last result of database loading.

• If the download completes, view database version timestamp virus record number.
• If the download fails, view failure reason.
Action In the CLI, enter the user@host> show security utm anti-virus status command.
Example status result:
AV Key Expire Date: 03/01/2010 00:00:00

Update Server: http://update.juniper-updates.net/AV/device-name
interval: 60 minutes
auto update status: next update in 12 minutes
last result: new database loaded
AV signature version: 12/21/2008 00:35 GMT, virus records: 154018
Scan Engine Info: last action result: No error(0x00000000)
15.1X49-D10 The Monitoring Antivirus Scan Engine Status is not supported from
Junos OS Release 15.1X49-D10 onwards.
Related • Full Antivirus Configuration Overview

Documentation
• Monitoring Antivirus Session Status on page 484
Monitoring Antivirus Scan Results
Purpose The Monitoring Antivirus Scan Results are not supported from Junos OS Release
15.1X49-D10 onwards. For previous releases, view statistics for antivirus requests, scan
results, and fallback counters.
Scan requests provide
• The total number of scan request forwarded to the engine.
• The number of scan request being pre-windowed.
• The number of scan requests using scan-all mode.
• The number of scan requests using scan-by-extension mode.
Scan code counters provide
• Number of clean files.
• Number of infected files.
• Number of password protected files.
• Number of decompress layers.

Chapter 28: Monitoring Unified Threat Management Features
• Number of corrupt files.
• When the engine is out of resources.
• When there is an internal error.
Fallback applied status provides either a log-and-permit or block result when the following
has occurred
• Scan engine not ready.
• Maximum content size reached.
• Too many requests.
• Password protected file found.
• Decompress layer too large.
• Corrupt file found.
• Timeout occurred.
• Out of resources.
• Other.
Action To view antivirus scan results using the CLI editor, enter the user@host> show security
utm anti-virus statistics status command.
To view antivirus scan results using J-Web:
1. Select Monitor>Security>UTM>Anti-Virus.
The following information becomes viewable in the right pane.
Antivirus license key status
• View license expiration dates.
Antivirus pattern update server settings
• View update URL (HTTP or HTTPS-based).
• View update interval.
Antivirus pattern database status
• View auto update status.
• View last result of database loading.
• If the download completes, view database version timestamp virus record number.
• If the download fails, view failure reason.
Antivirus statistics provide
• The number of scan request being pre-windowed.
• The total number of scan request forwarded to the engine.

• The number of scan requests using scan-all mode.
• The number of scan requests using scan-by-extension mode.
Scan code counters provide
• Number of clean files.
• Number of infected files.
• Number of password protected files.
• Number of decompress layers.
• Number of corrupt files.
• When the engine is out of resources.
• When there is an internal error.
Fallback applied status provides either a log-and-permit or block result when the
following has occurred
• Scan engine not ready.
• Password protected file found.
• Decompress layer too large.
• Corrupt file found.
• Out of resources.
• Timeout occurred.
• Maximum content size reached.
• Too many requests.
• Other.
2. You can click the Clear Anti-Virus Statistics button to clear all current viewable statistics
and begin collecting new statistics.
15.1X49-D10 The Monitoring Antivirus Scan Results are not supported from Junos
OS Release 15.1X49-D10 onwards.
Related • Monitoring Antivirus Session Status on page 484

Documentation
Monitoring Antivirus Session Status

Purpose The Monitoring Antivirus Session Status is not supported from Junos OS Release
15.1X49-D10 onwards. For previous releases, using the CLI, you can view the following
session status items:
Antivirus session status displays a snapshot of current antivirus sessions. It includes
• Maximum supported antivirus session numbers.
• Total allocated antivirus session numbers.
• Total freed antivirus session numbers.
• Current active antivirus session numbers.
Action In the CLI, enter the user@host> show security utm session status command.
15.1X49-D10 The Monitoring Antivirus Session Status is not supported from Junos
OS Release 15.1X49-D10 onwards.
Related • Full Antivirus Configuration Overview

Documentation
• Monitoring Antivirus Scan Engine Status on page 481
Monitoring Content Filtering Configurations
Purpose View content filtering statistics.
Action To view content filtering statistics in the CLI, enter the user@host > show security utm
content-filtering statistics command.
The content filtering show statistics command displays the following information:
Base on command list: # Blocked

Base on mime list: # Blocked
Base on extension list: # Blocked
ActiveX plugin: # Blocked
Java applet: # Blocked
EXE files: # Blocked
ZIP files: # Blocked
HTTP cookie: # Blocked
To view content filtering statistics using J-Web:
1. Select Clear Content filtering statisticsMonitor>Security>UTM>Content

FilteringMonitor>Security>UTM>Content Filtering.
The following statistics become viewable in the right pane.

Base on command list: # Passed # Blocked

Base on mime list: # Passed # Blocked
Base on extension list: # Passed # Blocked
ActiveX plugin: # Passed # Blocked
Java applet: # Passed # Blocked
EXE files: # Passed # Blocked
ZIP files: # Passed # Blocked
HTTP cookie: # Passed # Blocked
2. You can click Clear Content filtering statistics to clear all current viewable statistics
and begin collecting new statistics.
Related • Content Filtering Overview

Documentation
• Understanding Content Filtering Protocol Support
• Content Filtering Configuration Overview
• Example: Attaching Content Filtering UTM Policies to Security Policies
Monitoring Reports
On-box reporting offers a comprehensive reporting facility where your security

management team can spot a security event when it occurs, immediately access and
review pertinent details about the event, and quickly decide appropriate remedial action.
The J-Web reporting feature provides one- or two-page reports that are equivalent to a
compilation of numerous log entries.
• Threats Monitoring Report on page 486

• Traffic Monitoring Report on page 491
Threats Monitoring Report
Purpose Use the Threats Report to monitor general statistics and activity reports of current threats
to the network. You can analyze logging data for threat type, source and destination
details, and threat frequency information. The report calculates, displays, and refreshes
the statistics, providing graphic presentations of the current state of the network.
Action To view the Threats Report:
1. Click Threats Report in the bottom right of the Dashboard, or select

Monitor>Reports>Threats in the J-Web user interface. The Threats Report appears.
2. Select one of the following tabs:
• Statistics tab. See Table 100 on page 487 for a description of the page content.
• Activities tab. See Table 101 on page 489 for a description of the page content.

Table 100: Statistics Tab Output in the Threats Report

Field Description
General Statistics Pane

Threat Category One of the following categories of threats:
• Traffic
• IDP
• Content Security
• Antivirus
• Antispam
• Web Filter—Click the Web filter category to display counters for 39 subcategories.
• Content Filter
• Firewall Event
Severity Severity level of the threat:
• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug
Hits in past 24 hours Number of threats encountered per category in the past 24 hours.
Hits in current hour Number of threats encountered per category in the last hour.
Threat Counts in the Past 24 Hours

By Severity Graph representing the number of threats received each hour for the past 24 hours sorted
by severity level.
By Category Graph representing the number of threats received each hour for the past 24 hours sorted
by category.
X Axis Twenty-four hour span with the current hour occupying the right-most column of the display.
The graph shifts to the left every hour.
Y Axis Number of threats encountered. The axis automatically scales based on the number of
threats encountered.
Most Recent Threats

Threat Name Names of the most recent threats. Depending on the threat category, you can click the threat
name to go to a scan engine site for a threat description.

Table 100: Statistics Tab Output in the Threats Report (continued)

Field Description
Category Category of each threat:
• Traffic
• IDP
• Antivirus
• Antispam
• Web Filter
• Content Filter
• Firewall Event
Source IP/Port Source IP address (and port number, if applicable) of the threat.
Destination IP/Port Destination IP address (and port number, if applicable) of the threat.
Protocol Protocol name of the threat.
Description Threat identification based on the category type:
• Antivirus—URL
• Web filter—category
• Content filter—reason
• Antispam—sender e-mail
Action Action taken in response to the threat.
Hit Time Time the threat occurred.
Threat Trend in past 24 hours

Category Pie chart graphic representing comparative threat counts by category:
• Traffic
• IDP
• Antivirus
• Antispam
• Web Filter
• Content Filter
• Firewall Event
Web Filter Counters Summary
Category Web filter count broken down by up to 39 subcategories. Clicking on the Web filter listing in
the General Statistics pane opens the Web Filter Counters Summary pane.
Hits in past 24 hours Number of threats per subcategory in the last 24 hours.

Table 100: Statistics Tab Output in the Threats Report (continued)

Field Description
Hits in current hour Number of threats per subcategory in the last hour.
Table 101: Activities Tab Output in the Threats Report

Field Function
Most Recent Virus Hits

Threat Name Name of the virus threat. Viruses can be based on services, like Web, FTP, or e-mail, or based
on severity level.
Severity Severity level of each threat:
• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug
Source IP/Port IP address (and port number, if applicable) of the source of the threat.
Destination IP/Port IP address (and port number, if applicable) of the destination of the threat.
Description Threat identification based on the category type:
• Antivirus—URL
• Web filter—category
• Content filter—reason
• Antispam—sender e-mail
Last Hit Time Last time the threat occurred.
Most Recent Spam E-Mail Senders

From e-mail E-mail address that was the source of the spam.

Table 101: Activities Tab Output in the Threats Report (continued)

Field Function
Severity Severity level of the threat:
• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug
Source IP IP address of the source of the threat.
Last Send Time Last time that the spam e-mail was sent.
Recently Blocked URL Requests

URL URL request that was blocked.
Source IP/Port IP address (and port number, if applicable) of the source.
Destination IP/Port IP address (and port number, if applicable) of the destination.
Hits in current hour Number of threats encountered in the last hour.
Most Recent IDP Attacks

Attack
Severity Severity of each threat:
• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug
Source IP/Port IP address (and port number, if applicable) of the source.
Destination IP/Port IP address (and port number, if applicable) of the destination.

Table 101: Activities Tab Output in the Threats Report (continued)

Field Function
Last Send Time Last time the IDP threat was sent.
Traffic Monitoring Report
Purpose Monitor network traffic by reviewing reports of flow sessions over the past 24 hours. You
can analyze logging data for connection statistics and session usage by a transport
protocol.
Action To view network traffic in the past 24 hours, select Monitor>Reports>Traffic in the J-Web
user interface. See Table 102 on page 491 for a description of the report.
Table 102: Traffic Report Output

Field Description
Sessions in Past 24 Hours per Protocol

Protocol Name Name of the protocol. To see hourly activity by protocol, click the protocol name and review
the “Protocol activities chart” in the lower pane.
• TCP
• UDP
• ICMP
Total Session Total number of sessions for the protocol in the past 24 hours.
Bytes In (KB) Total number of incoming bytes in KB.
Bytes Out (KB) Total number of outgoing bytes in KB.
Packets In Total number of incoming packets.
Packets Out Total number of outgoing packets.
Most Recently Closed Sessions

Source IP/Port Source IP address (and port number, if applicable) of the closed session.
Destination IP/Port Destination IP address (and port number, if applicable) of the closed session.

Table 102: Traffic Report Output (continued)

Field Description
Protocol Protocol of the closed session.
• TCP
• UDP
• ICMP
Bytes In (KB) Total number of incoming bytes in KB.
Bytes Out (KB) Total number of outgoing bytes in KB.
Packets In Total number of incoming packets.
Packets Out Total number of outgoing packets.
Timestamp The time the session was closed.
Protocol Activities Chart

Bytes In/Out Graphic representation of traffic as incoming and outgoing bytes per hour. The byte count
is for the protocol selected in the Sessions in Past 24 Hours per Protocol pane. Changing
the selection causes this chart to refresh immediately.
Packets In/Out Graphic representation of traffic as incoming and outgoing packets per hour. The packet
count is for the protocol selected in the Sessions in Past 24 Hours per Protocol pane.
Changing the selection causes this chart to refresh immediately.
Sessions Graphic representation of traffic as the number of sessions per hour. The session count is
for the protocol selected in the Sessions in Past 24 Hours per Protocol pane. Changing the
selection causes this chart to refresh immediately.
X Axis One hour per column for 24 hours.
Y Axis Byte, packet, or session count.
Protocol Session Chart

Sessions by Protocol Graphic representation of the traffic as the current session count per protocol. The protocols
displayed are TCP, UDP, and ICMP.

Documentation
Monitoring Web Filtering Configurations
Purpose View Web-filtering statistics.

Action To view Web-filtering statistics using the CLI, enter the following commands:
user@host> show security utm web-filtering status

user@host> show security utm web-filtering statistics
To view Web-filtering statistics using J-Web:
1. Select Clear Web Filtering Statistics.
The following information is displayed in the right pane.
Total Requests: #
White List Hit: #
Black List Hit: #
Queries to Server: #
Server Reply Permit: #
Server Reply Block: #
Custom Category Permit: #
Custom Category Block: #
Cache Hit Permit: #
Cache Hit Block: #
Web Filtering Session Total: #
Web Ffiltering Session Inuse: #
Fall Back: Log-and-Permit Block
Default # #
Timeout # #
Server-Connectivity # #
Too-Many-Requests # #
2. You can click the Clear Web Filtering Statistics button to clear all current viewable
statistics and begin collecting new statistics.
Related • Web Filtering Overview

Documentation
• Example: Configuring Local Web Filtering


CHAPTER 29
Monitoring VPNs
• Monitoring VPNs on page 495
Monitoring VPNs
• Monitoring IKE Gateway Information on page 495

• Monitoring IPsec VPN—Phase I on page 499
• Monitoring IPsec VPN—Phase II on page 500
• Monitoring IPsec VPN Information on page 501
Monitoring IKE Gateway Information
Purpose View information about IKE security associations (SAs).
Action Select Monitor>IPSec VPN>IKE Gateway in the J-Web user interface. To view detailed
information for a particular SA, select the IKE SA index on the IKE gateway page.
• show security ike security-associations
• show security ike security-associations index index-id detail
Table 103 on page 495 summarizes key output fields in the IKE gateway display.
Table 103: Summary of Key IKE SA Information Output Fields

IKE Security Associations

IKE SA Index Index number of an SA. This number is an internally generated number
you can use to display information about a single
SA.

Table 103: Summary of Key IKE SA Information Output Fields (continued)

Remote Address IP address of the destination peer with which the –

local peer communicates.
State State of the IKE security associations: –
• DOWN—SA has not been negotiated with the

peer.
• UP—SA has been negotiated with the peer.
Initiator cookie Random number, called a cookie, which is sent –

to the remote node when the IKE negotiation is
triggered.
Responder cookie Random number generated by the remote node A cookie is aimed at protecting the computing
and sent back to the initiator as a verification resources from attack without spending
that the packets were received. excessive CPU resources to determine the
cookie’s authenticity.
Mode Negotiation method agreed on by the two IPsec –

endpoints, or peers, used to exchange
information between themselves. Each exchange
type determines the number of messages and
the payload types that are contained in each
message. The modes, or exchange types, are:
• Main—The exchange is done with six

messages. This mode, or exchange type,
encrypts the payload, protecting the identity
of the neighbor. The authentication method
used is displayed: preshared keys or certificate.
• Aggressive—The exchange is done with three
messages. This mode, or exchange type, does
not encrypt the payload, leaving the identity
of the neighbor unprotected.
IKE Security Association (SA) Index

IKE Peer IP address of the destination peer with which the –
local peer communicates.
IKE SA Index Index number of an SA. This number is an internally generated number
you can use to display information about a single
SA.
Role Part played in the IKE session. The device –

triggering the IKE negotiation is the initiator, and
the device accepting the first IKE exchange
packets is the responder.

Chapter 29: Monitoring VPNs

• DOWN—SA has not been negotiated with the

peer.
• UP—SA has been negotiated with the peer.
Initiator cookie Random number, called a cookie, which is sent –

to the remote node when the IKE negotiation is
triggered.
Responder cookie Random number generated by the remote node A cookie is aimed at protecting the computing
and sent back to the initiator as a verification resources from attack without spending
that the packets were received. excessive CPU resources to determine the
cookie’s authenticity.
Exchange Type Negotiation method agreed on by the two IPsec –

endpoints, or peers, used to exchange
information between themselves. Each exchange
type determines the number of messages and
the payload types that are contained in each
message. The modes, or exchange types, are:

messages. This mode, or exchange type,
encrypts the payload, protecting the identity
of the neighbor. The authentication method
used is displayed: preshared keys or certificate.
• Aggressive—The exchange is done with three
messages. This mode, or exchange type, does
not encrypt the payload, leaving the identity
of the neighbor unprotected.
Authentication Method Path chosen for authentication. –
Local Address of the local peer. –
Remote Address of the remote peer. –
Lifetime Number of seconds remaining until the IKE SA –

expires.


Algorithm IKE algorithms used to encrypt and secure –

exchanges between the peers during the IPsec
Phase 2 process:
• Authentication—Type of authentication
algorithm used.
• sha1—Secure Hash Algorithm 1 (SHA-1)
authentication.
• md5—MD5 authentication.
• Encryption—Type of encryption algorithm

used.
• aes-256-cbc—Advanced Encryption
Standard (AES) 256-bit encryption.
• 3des-cbc—3 Data Encryption Standard
(DES) encryption.
• des-cbc—Data Encryption Standard (DES)
encryption.
• Pseudo random function—Cryptographically
secure pseudorandom function family.
Traffic Statistics Traffic statistics include the following: –
• Input bytes—The number of bytes presented

for processing by the device.
• Output bytes—The number of bytes actually
processed by the device.
• Input packets—The number of packets
presented for processing by the device.
• Output packets—The number of packets
actually processed by the device.
IPsec security • number created—The number of SAs created. –

associations • number deleted—The number of SAs deleted.
Role Part played in the IKE session. The device –

triggering the IKE negotiation is the initiator, and
the device accepting the first IKE exchange
packets is the responder.
Message ID Message identifier. –
Local identity Specifies the identity of the local peer so that its –
partner destination gateway can communicate
with it. The value is specified as any of the
following: IPv4 address, fully qualified domain
name, e-mail address, or distinguished name.


Remote identity IPv4 address of the destination peer gateway. –
Monitoring IPsec VPN—Phase I
Purpose View IPsec VPN Phase I information.
Action Select Monitor>IPSec VPN>Phase I in the J-Web user interface.
Table 104 on page 499 describes the available options for monitoring IPsec VPN-Phase
I.
Table 104: IPsec VPN—Phase I Monitoring Page
IKE SA Tab Options
IKE Security Associations

SA Index Index number of an SA. –
Remote Address IP address of the destination peer with –

which the local peer communicates.
• DOWN—SA has not been negotiated

with the peer.
• UP—SA has been negotiated with the
peer.
Initiator Cookie Random number, called a cookie, which –

is sent to the remote node when the IKE
negotiation is triggered.
Responder Cookie Random number generated by the A cookie is aimed at protecting the
remote node and sent back to the computing resources from attack
initiator as a verification that the packets without spending excessive CPU
were received. resources to determine the cookie’s
authenticity.

Table 104: IPsec VPN—Phase I Monitoring Page (continued)

Mode Negotiation method agreed upon by the –
two IPsec endpoints, or peers, used to
exchange information. Each exchange
type determines the number of messages
and the payload types that are contained
in each message. The modes, or
exchange types, are:

messages. This mode, or exchange
type, encrypts the payload, protecting
the identity of the neighbor. The
authentication method used is
displayed: preshared keys or
certificate.
• Aggressive—The exchange is done
with three messages. This mode, or
exchange type, does not encrypt the
payload, leaving the identity of the
neighbor unprotected.
Monitoring IPsec VPN—Phase II
Purpose View IPsec VPN Phase II information.
Action Select Monitor>IPSec VPN>Phase II in the J-Web user interface.
Table 105 on page 500 describes the available options for monitoring IPsec VPN-Phase
II.
Table 105: IPsec VPN—Phase II Monitoring Page
Statistics Tab Details

By bytes Provides total number of bytes encrypted –
and decrypted by the local system across
the IPsec tunnel.
By packets Provides total number of packets –

encrypted and decrypted by the local
system across the IPsec tunnel.
IPsec Statistics Provides details of the IPsec statistics. –
IPsec SA Tab Details
IPsec Security Associations

ID Index number of the SA. –

Table 105: IPsec VPN—Phase II Monitoring Page (continued)

Gateway/Port IP address of the remote gateway/port. –
Algorithm Cryptography scheme used to secure –

exchanges between peers during the IKE
Phase II negotiations:
• An authentication algorithm used to

authenticate exchanges between the
peers. Options are hmac-md5-95 or
hmac-sha1-96.
SPI Security parameter index (SPI) identifier. –

An SA is uniquely identified by an SPI.
Each entry includes the name of the VPN,
the remote gateway address, the SPIs
for each direction, the encryption and
authentication algorithms, and keys. The
peer gateways each have two SAs, one
resulting from each of the two phases of
negotiation: Phase I and Phase II.
Life The lifetime of the SA, after which it –

expires, expressed either in seconds or
kilobytes.
Monitoring Specifies if VPN-Liveliness Monitoring –

has been enabled/disabled. Enabled - '
U ', Disabled- '—'
Vsys Specifies the root system. –
Monitoring IPsec VPN Information
Purpose View information about IPsec security (SAs).
Action Select Monitor>IPSec VPN>IPsec VPN in the J-Web user interface. To view the IPsec
statistics information for a particular SA, select the IPsec SA ID value on the IPsec VPN
page.
• show security ipsec security-associations
• show security ipsec statistics
Table 106 on page 502 summarizes key output fields in the IPsec VPN display.

Table 106: Summary of Key IPsec VPN Information Output Fields

IPsec Security Associations

Total configured SA Total number of IPsec security associations –
(SAs) configured on the device.
ID Index number of the SA. –
Gateway IP address of the remote gateway. –
Port If Network Address Translation (NAT-T) is used, –

this value is 4500. Otherwise, it is the standard
IKE port, 500.
Algorithm Cryptography used to secure exchanges between –

peers during the IKE Phase 2 negotiations:
• An authentication algorithm used to

authenticate exchanges between the peers.
Options are hmac-md5-95 or hmac-sha1-96.
• An encryption algorithm used to encrypt data
traffic. Options are 3des-cbc, aes-128-cbc,
aes-192-cbc, aes-256-cbc, or des-cbc.
SPI Security parameter index (SPI) identifier. An SA –

is uniquely identified by an SPI. Each entry
includes the name of the VPN, the remote
gateway address, the SPIs for each direction, the
encryption and authentication algorithms, and
keys. The peer gateways each have two SAs, one
negotiation: Phase 1 and Phase 2.
Life: sec/kb The lifetime of the SA, after which it expires, –

expressed either in seconds or kilobytes.
State State has two options, Installed and Not Installed. For transport mode, the value of State is always
Installed.
• Installed—The security association is installed
in the security association database.
• Not Installed—The security association is not
installed in the security association database.
Vsys The root system. –
IPsec Statistics Information

Table 106: Summary of Key IPsec VPN Information Output Fields (continued)
ESP Statistics Encapsulation Security Protocol (ESP) statistics –

include the following:
• Encrypted bytes—Total number of bytes

encrypted by the local system across the IPsec
tunnel.
• Decrypted bytes—Total number of bytes
decrypted by the local system across the IPsec
tunnel.
• Encrypted packets—Total number of packets
encrypted by the local system across the IPsec
tunnel.
• Decrypted packets—Total number of packets
decrypted by the local system across the IPsec
tunnel.
AH Statistics Authentication Header (AH) statistics include –

the following:
• Input bytes—The number of bytes presented

for processing by the device.
• Output bytes—The number of bytes actually
processed by the device.
• Input packets—The number of packets
presented for processing by the device.
• Output packets—The number of packets
actually processed by the device.
Errors Errors include the following –
• AH authentication failures—Total number of

authentication header (AH) failures. An AH
failure occurs when there is a mismatch of the
authentication header in a packet transmitted
across an IPsec tunnel.
• Replay errors—Total number of replay errors.
A replay error is generated when a duplicate
packet is received within the replay window.
• ESP authentication failures—Total number of
Encapsulation Security Payload (ESP) failures.
An ESP failure occurs when there is an
authentication mismatch in ESP packets.
• ESP decryption failures—Total number of ESP
decryption errors.
• Bad headers—Total number of invalid headers
detected.
• Bad trailers—Total number of invalid trailers
detected.
Details for IPsec SA Index: ID

Virtual System The root system. –

Local Gateway Gateway address of the local system. –
Remote Gateway Gateway address of the remote system. –
Local identity Specifies the identity of the local peer so that its –
partner destination gateway can communicate
with it. The value is specified as any of the
following: IPv4 address, fully qualified domain
name, e-mail address, or distinguished name.
Remote identity IPv4 address of the destination peer gateway. –
Df bit State of the don’t fragment bit—set or cleared. –
Policy name Name of the applicable policy. –
Direction Direction of the security association—inbound, –

or outbound.
SPI Security parameter index (SPI) identifier. An SA –

is uniquely identified by an SPI. Each entry
includes the name of the VPN, the remote
gateway address, the SPIs for each direction, the
encryption and authentication algorithms, and
keys. The peer gateways each have two SAs, one
negotiation: Phase 1 and Phase 2.
Mode Mode of the security association. Mode can be –

transport or tunnel.
• transport—Protects host-to-host connections.

• tunnel—Protects connections between
security gateways.
Type Type of the security association, either manual –

or dynamic.
• manual—Security parameters require no

negotiation. They are static and are configured
by the user.
• dynamic—Security parameters are negotiated
by the IKE protocol. Dynamic security
associations are not supported in transport
mode.

State State has two options, Installed, and Not For transport mode, the value of State is always
Installed. Installed.
• Installed—The security association is installed

in the security association database.
• Not Installed—The security association is not
installed in the security association database.
Protocol Protocol supported: –
• Transport mode supports Encapsulation

Security Protocol (ESP) and Authentication
Header (AH).
• Tunnel mode supports ESP and AH.
• Authentication—Type of authentication
used.
• Encryption—Type of encryption used.
Authentication/ • Authentication—Type of authentication –

Encryption algorithm used.
• sha1—Secure Hash Algorithm 1 (SHA-1)
authentication.
• md5—MD5 authentication.
• Encryption—Type of encryption algorithm

used.
• 3des-cbc—3 Data Encryption Standard
(DES) encryption.
• des-cbc—Data Encryption Standard (DES)
encryption.
Soft Lifetime The soft lifetime informs the IPsec key Each lifetime of a security association has two
management system that the SA is about to display options, hard and soft, one of which must
expire. be present for a dynamic security association.
This allows the key management system to
• Expires in seconds—Number of seconds left negotiate a new SA before the hard lifetime
until the SA expires. expires.
• Expires in kilobytes—Number of kilobytes left
until the SA expires.
Hard Lifetime The hard lifetime specifies the lifetime of the SA. –
• Expires in seconds—Number of seconds left

• Expires in kilobytes—Number of kilobytes left

Anti Replay Service State of the service that prevents packets from –
being replayed. It can be Enabled or Disabled.
Replay Window Size Configured size of the antireplay service window. The antireplay window size protects the receiver
It can be 32 or 64 packets. If the replay window against replay attacks by rejecting old or
size is 0, the antireplay service is disabled. duplicate packets.

Documentation

PART 8
Resource Monitoring of Memory Regions

and Types Using CLI and SNMP Queries
• Effective Troubleshooting of System Performance With Resource Monitoring
Methodology on page 509


CHAPTER 30
Effective Troubleshooting of System

Performance With Resource Monitoring
Methodology
• Resource Monitoring Usage Computation Overview on page 509

• Resource Monitoring Mechanism on MX Series Routers Overview on page 512
• Diagnosing and Debugging System Performance By Configuring Memory Resource
Usage Monitoring on MX Series Routers on page 515
• Troubleshooting the Mismatch of jnxNatObjects Values for MS-DPC and
MS-MIC on page 517
• Managed Objects for Ukernel Memory for a Packet Forwarding Engine in an FPC
Slot on page 518
• Managed Objects for Packet Forwarding Engine Memory Statistics Data on page 519
• Managed Objects for Next-Hop, Jtree, and Firewall Filter Memory for a Packet
Forwarding Engine in an FPC Slot on page 519
• jnxPfeMemoryErrorsTable on page 520
• pfeMemoryErrors on page 520
Resource Monitoring Usage Computation Overview
Supported Platforms MX104, MX2010, MX2020, MX240, MX480, MX80, MX960

You can configure the resource monitoring capability using both the configuration
statements in the CLI and SNMP MIB queries. You can employ this utility to provision
sufficient headroom (memory space limits that are set for the application or virtual
router) for monitoring the health and operating efficiency of DPCs and MPCs. To configure
the resource-monitoring capability on MX80, MX104, MX240, MX480, MX960, MX2010,
and MX2020 routers. You can also analyze and view the usage or consumption of memory
for the jtree memory type and for contiguous pages, double words, and free memory
pages. The jtree memory on all MX Series router Packet Forwarding Engines has two
segments: one segment primarily stores routing tables and related information, and the
other segment primarily stores firewall-filter-related information. As the allocation of
more memory for routing tables or firewall filters might disrupt the forwarding operations
of a Packet Forwarding Engine, the Junos OS CLI displays a warning to restart all affected
FPCs when you commit a configuration that includes the memory-enhanced route
statement.
The following sections describe the computation equations and the interpretation of the
different memory regions for I-chip-based and Trio-based line cards:
Resource Monitoring and Usage Computation For Trio-Based Line Cards

In Trio-based line cards, memory blocks for next-hop and firewall filters are allocated
separately. Also, an expansion memory is present, which is used when the allocated
memory for next-hop or firewall filter is fully consumed. Both next-hop and firewall filters
can allocate memory from the expansion memory. The encapsulation memory region is
specific to I-chip-based line cards and it is not applicable to Trio-based line cards.
Therefore, for Trio-based line cards, the percentage of free memory space can be
interpreted as follows:
% Free (NH) = (1- (Used NH memory + Used Expansion memory ) / (Total NH

memory+Total Expansion memory)) × 100
% Free (Firewall or Filter) = (1-(Used FW memory+Used Expansion memory ) / (Total

FW memory+Total Expansion memory)) × 100
Encapsulation memory is I-chip-specific and is not applicable for Trio-based line cards.
% Free (Encap memory) = Not applicable
Resource Monitoring and Usage Computation For I-Chip-Based Line Cards

I-chip-based line cards contain 32 MB of static RAM (SRAM) memory associated with
the route lookup block and 16 MB of SRAM memory associated with the output WAN
block.
The route-lookup memory is a single pool of 32 MB memory that is divided into two
segments of 16 MB each. In a standard configuration, segment 0 is used for NH and
prefixes, and segment 1 is used for firewall or filter. This allocation can be modified by
using the route-memory-enhanced option at the [edit chassis] hierarchy level. In a general
configuration, NH application can be allocated memory from any of the two segments.
Therefore, the percentage of free memory for NH is calculated on 32 MB memory.
Currently, firewall applications are allotted memory only from segment 1. As a result, the

Chapter 30: Effective Troubleshooting of System Performance With Resource Monitoring Methodology
percentage of free memory to be monitored for firewall starts from the available 16 MB
memory in segment 1 only.
For I-chip-based line cards, the percentage of free memory space can be interpreted as
follows:
% Free (NH) = (32-(Used NH memory+Used FW memory+Used Other application)) /

32×100
% Free (Firewall or Filter)=(16-(Used NH memory+Used FW memory+Used Other

application)) / 16×100
The memory size for Output WAN (Iwo) SRAM is 16 MB and stores the Layer 2 descriptors
that contain the encapsulation information. This entity is a critical resource and needs
to be monitored. This memory space is displayed in the output of the show command
as “Encap mem”. The percentage of free memory for the encapsulation region is calculated
as follows:
% Free (Encapsulation memory) = (16-(Iwo memory used ( L2 descriptors +other

applications))) / 16×100
The watermark level configured for next-hop memory is also effective for encapsulation
memory. Therefore, if the percentage of free memory for encapsulation region falls below
the configured watermark, logs are generated.
If the free memory percentage is lower than the free memory watermark of a specific
memory type, the following error message is recorded in the syslog:
“Resource Monitor: FPC <slot no> PFE <pfe inst> <“JNH memory” or “FW/ Filter memory”>
is below set watermark <configured watermark>”.
You can configure resource-monitoring tracing operations by using the traceoptions file
<filename> flag flag level level size bytes statement at the [edit system services
resource-monitor] hierarchy level. By default, messages are written to /var/log/rsmonlog.
The error logs associated with socket communication failure (between the Routing Engine
and the Packet Forwarding Engine) are useful in diagnosing the problems in the
communication between the Routing Engine and the Packet Forwarding Engine.
From the Ukern perspective, MPC5E contains only one Packet Forwarding Engine instance.
The show chassis fabric plane command output displays the state of fabric plane
connections to the Packet Forwarding Engine. Because two Packet Forwarding Engines
exist, you notice PFE-0 and PFE-1 in the output.
user@host# run show chassis fabric plane
Fabric management PLANE state
Plane 0
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
PFE 1 :Links ok

Because only one Packet Forwarding Engine instance for MPC5E exists, the output of
the show system resource-monitor fpc command displays only one row corresponding
to Packet Forwarding Engine instance 0.
user@host# run show system resource-monitor fpc
FPC Resource Usage Summary
Free Heap Mem Watermark : 20 %

Free NH Mem Watermark : 20 %
Free Filter Mem Watermark : 20 %
* - Watermark reached
Heap ENCAP mem NH mem FW

mem
Slot # % Free PFE # % Free % Free % Free
0 94 0 NA 83
99
The configured watermark is retained across GRES and unified ISSU procedures.
Related •
Documentation
Resource Monitoring Mechanism on MX Series Routers Overview

Junos OS supports a resource monitoring capability using both the configuration

statements in the CLI interface and SNMP MIB queries. You can employ this utility to
provision sufficient headroom (memory space limits that are set for the application or
virtual router) for ensuring system stability, especially the health and operating efficiency
of I-chip-based line cards and Trio-based FPCs on MX Series routers. When the memory
utilization, either the ukernel memory or ASIC memory reaches a certain threshold, the
system operations compromise on the health and traffic-handling stability of the line
card and such a trade-off on the system performance can be detrimental for supporting
live traffic and protocols. Besides the ability to configure a threshold to raise error logs
when a specific threshold value of resources is exceeded, you can also monitor the
threshold values and resource utilization using SNMP MIB queries. You can configure
watermark or checkpoint values for the line card resources, such as ukern memory (heap),
next-hop (NH) memory, and firewall or filter memory, to be uniform for both Trio-based
and I-chip-based line cards. The NH memory watermark is applicable only for
encapsulation memory (output WAN static RAM memory). Encapsulation memory is
specific to I-chips and not applicable for Trio-based chips. When the configured watermark
is exceeded, error logs are triggered. If the resource has been used above a certain
threshold, warning system log messages are generated to notify about the threshold
value having exceeded. Based on your network needs, you can then determine whether
you want to terminate any existing subscribers and services to prevent the system from
being overloaded and resulting in a breakdown. This feature gathers input from each of
the line cards and transfers this statistical detail to the Routing Engine process using a
well-known internal port. This information is scanned by the daemon on the Routine
Engine and using the shared memory space built into the session database, warning
messages are generated for exceeded threshold conditions.
The capability to configure resource monitoring is supported on the MX80, MX104 routers
and on the following line cards on MX240, MX480, MX960, MX2010, and MX2020 routers:
• MX-MPC1-3D
• MX-MPC1-3D-Q
• MX-MPC2-3D
• MX-MPC2-3D-Q
• MX-MPC2-3D-EQ
• MPC-3D-16XGE-SFPP
• MPC3E
• MPC4E-3D-2CGE-8XGE
• MPC4E-3D-32XGE
• MPC5EQ-40G10G
• MPC5EQ-100G10G
• MPC5E-100G10G
• MPC5E-40G10G
• MX2K-MPC6E

• DPCE
• MS-DPC
• MX Series Flexible PIC Concentrators (MX-FPCs)
You can configure the following parameters at the [edit system services] hierarchy level
to specify the high threshold value that is common for all the memory spaces or regions
and the watermark values for the different memory blocks on DPCs and MPCs:
• High threshold value, exceeding which warnings or error logs are generated, for all the
regions of memory, such as heap or ukernel, next-hop and encapsulation, and firewall
filter memory, by using the set resource-monitor high-threshold value statement.
• Percentage of free memory space used for next-hops to be monitored with a watermark
value by using the set resource-monitor free-nh-memory-watermark percentage
statement.
• Percentage of free memory space used for ukernel or heap memory to be monitored
with a watermark value by using the set resource-monitor free-heap-memory-watermark
percentage statement.
• Percentage of free memory space used for firewall and filter memory to be monitored
with a watermark value by using the set resource-monitor free-filter-memory-watermark
percentage statement. This feature is enabled by default and you cannot disable it
manually. The default value and the configured value of the watermark value for the
percentage of free next-hop memory also applies to encapsulation memory.
The default watermark values for the percentage of free ukernel or heap memory,
next-hop memory, and firewall filter memory are as follows:
• free-heap-memory-watermark—20
• free-nh-memory-watermark—20
• free-filter-memory-watermark—20
Examining the Utilization of Memory Resource Regions Using show Commands

You can use the show system resource-monitor fpc command to monitor the utilization
of memory resources on the Packet Forwarding Engines of an FPC. The filter memory
denotes the filter counter memory used for firewall filter counters. The asterisk (*)
displayed next to each of the memory regions denotes the ones for which the configured
threshold is being currently exceeded. Resource monitoring commands display the
configured values of watermark for memories for different line card applications to be
monitored. The displayed statistical metrics are based on the computation performed
of the current memory utilization of the individual line cards. The ukern memory is generic
across the different types of line cards and signifies the heap memory buffers. Because
a line card or an FPC in a particular slot can contain multiple Packet Forwarding Engine
complexes, the memory utilized on the application-specific integrated circuits (ASICs)
are specific to a particular PFE complex. Owing to different architecture models for
different variants of line cards supported, the ASIC-specific memory (next-hop and
firewall or filter memory) utilization percentage can be interpreted differently.

Related •
Documentation
Diagnosing and Debugging System Performance By Configuring Memory Resource

Usage Monitoring on MX Series Routers
Junos OS supports a resource monitoring capability using both the configuration

statements in the CLI interface and SNMP MIB queries. You can employ this utility to
provision sufficient headroom (memory space limits that are set for the application or
virtual router) for ensuring system stability, especially the health and operating efficiency
of I-chip-based line cards and Trio-based FPCs on MX Series routers. When the memory
utilization, either the ukernel memory or ASIC memory reaches a certain threshold, the
system operations compromise on the health and traffic-handling stability of the line
card and such a trade-off on the system performance can be detrimental for supporting
live traffic and protocols. You can configure the resource-monitoring capability on MX80,
MX104, MX240, MX480, MX960, MX2010, and MX2020 routers,
To configure the properties of the memory resource-utilization functionality:
1. Specify that you want to configure the monitoring mechanism for utilization of different
memory resource regions.
[edit]
user@host# edit system services resource-monitor
This feature is enabled by default and you cannot disable it manually.
2. Specify the high threshold value, exceeding which warnings or error logs are generated,
for all the regions of memory, such as heap or ukernel, next-hop and encapsulation,
and firewall filter memory.
[edit system services resource-monitor]

user@host# set high-threshold value
3. Specify the percentage of free memory space used for next-hops to be monitored
with a watermark value.

user@host# set free-nh-memory-watermark percentage
4. Specify the percentage of free memory space used for ukernel or heap memory to be
monitored with a watermark value.

user@host# set free-heap-memory- watermark percentage
5. Specify the percentage of free memory space used for firewall and filter memory to
be monitored with a watermark value.

user@host# set free-filter-memory-memory- watermark percentage

NOTE:
The default value and the configured value of the watermark value for the
percentage of free next-hop memory also applies to encapsulation
memory. The default watermark values for the percentage of free ukernel
or heap memory, next-hop memory, and firewall filter memory are 20
percent.
6. Disable the generation of error log messages when the utilization of memory resources
exceeds the threshold or checkpoint levels. By default, messages are written to
/var/log/rsmonlog.

user@host# set no-logging
7. Define the resource category that you want to monitor and analyze for ensuring system
stability, especially the health and operating efficiency of I-chip-based line cards and
Trio-based FPCs on MX Series routers. The resource category includes detailed CPU
utilization, session rate, and session count statistics. You use the resource category
statistics to understand the extent to which new attack objects or applications affect
performance.

user@host# edit resource-category jtree
NOTE: The jtree memory on all MX Series router Packet Forwarding

Engines has two segments: one segment primarily stores routing tables
and related information, and the other segment primarily stores
firewall-filter-related information. The Junos OS provides the
memory-enhanced statement to reallocate the jtree memory for routes,
firewall filters, and Layer 3 VPNs.
8. Configure the type of resource as contiguous pages for which you want to enable the
monitoring mechanism to provide sufficient headroom for ensuring effective system
performance and traffic-handling capacity. Specify the high and low threshold value,
exceeding which warnings or error logs are generated, for the specified type or region
of memory, which is contiguous page in this case.
[edit system services resource-monitor resource-category jtree]

user@host# set resource-type contiguous-pages high-threshold percentage
user@host# set resource-type contiguous-pages low-threshold percentage
9. Configure the type of resource as free double words (dwords) for which you want to
enable the monitoring mechanism to provide sufficient headroom for ensuring effective
system performance and traffic-handling capacity. Specify the high and low threshold
value, exceeding which warnings or error logs are generated, for the specified type or
region of memory, which is free dwords in this case.

user@host# set resource-type free-dwords high-threshold percentage
user@host# set resource-type free-dwords low-threshold percentage

10. Configure the type of resource as free memory pages for which you want to enable
the monitoring mechanism to provide sufficient headroom for ensuring effective
system performance and traffic-handling capacity. Specify the high and low threshold
value, exceeding which warnings or error logs are generated, for the specified type or
region of memory, which is free memory pages in this case.

user@host# set resource-type free-pages high-threshold percentage
user@host# set resource-type free-pages low-threshold percentage
11. View the utilization of memory resources on the Packet Forwarding Engines of an FPC
by using the show system resource-monitor fpc command. The filter memory denotes
the filter counter memory used for firewall filter counters. The asterisk (*) displayed
next to each of the memory regions denotes the ones for which the configured
threshold is being currently exceeded.
user@host# run show system resource-monitor fpc

Heap ENCAP mem NH mem

FW mem
Slot # % Free PFE # % Free % Free %
Free
0 94 0 NA 83
99
Related •
Documentation
Troubleshooting the Mismatch of jnxNatObjects Values for MS-DPC and MS-MIC
Supported Platforms MX Series
Problem Description: When both MS-DPC and MS-MIC are deployed in a network and the Network
Address Translation (NAT) type is configured as napt-44, the output of the snmp mib
walk command for jnxNatObjects displays different values for MS-DPC and MS-MIC.
Resolution Configure SNMP to Match jnxNatObjects Values for MS-DPC and MS-MIC
To configure SNMP to match jnxNatObjects values for MS-DPC and MS-MIC:
1. Run the set services service-set service-set-name nat-options snmp-value-match-msmic

configuration mode command. The following configuration example shows how to
configure SNMP to match the values for MS-MIC-specific objects in the jnxNatObjects
MIB table with the values for MS-DPC objects.
[edit]
user@host# set services service-set Mobile nat-options snmp-value-match-msmic

2. Issue the commit command to confirm the changes.
[edit]
user@host# commit
commit complete
3. (Optional) Run the show snmp mib walk jnxNatObjects command to verify that the
values for MS-MIC-specific objects in the jnxNatObjects MIB table match the values
for MS-DPC objects. For example, the following output shows that the values for
MS-MIC-specific objects and MS-DPC objects match.
[edit]
user@host# run show snmp mib walk jnxNatObjects
jnxNatSrcXlatedAddrType.6.77.111.98.105.108.101 = 1
jnxNatSrcPoolType.6.77.111.98.105.108.101 = 13
jnxNatSrcNumPortAvail.6.77.111.98.105.108.101 = 64512
jnxNatSrcNumPortInuse.6.77.111.98.105.108.101 = 0
jnxNatSrcNumAddressAvail.6.77.111.98.105.108.101 = 1
jnxNatSrcNumAddressInUse.6.77.111.98.105.108.101 = 0
jnxNatSrcNumSessions.6.77.111.98.105.108.101 = 0
jnxNatRuleType.9.77.111.98.105.108.101.58.116.49 = 13
jnxNatRuleTransHits.9.77.111.98.105.108.101.58.116.49 = 0
jnxNatPoolType.6.77.111.98.105.108.101 = 13
jnxNatPoolTransHits.6.77.111.98.105.108.101 = 0
NOTE: You can use the delete services service-set service-set-name

nat-options snmp-value-match-msmic configuration mode command to
disable this feature.
Related • Configuring Service Rules

Documentation
• snmp-value-match-msmic on page 720
Managed Objects for Ukernel Memory for a Packet Forwarding Engine in an FPC Slot
The jnxPfeMemoryUkernTable, whose object identifier is {jnxPfeMemory 1}, contains the

JnxPfeMemoryUkernEntry that retrieves the global ukernel or heap memory statistics for
the specified Packet Forwarding Engine slot. Each JnxPfeMemoryUkernEntry, whose
object identifier is {jnxPfeMemoryUkernTable 1}, contains the objects listed in the following
table. The jnxPfeMemoryUkernEntry denotes the memory utilization, such as the total
available memory and the percentage of memory used.
Table 107: jnxPfeMemoryUKernTable

Object Object ID Description
jnxPfeMemoryUkernFreePercent jnxPfeMemoryUkernEntry 3 Denotes the percentage of free Packet Forwarding

Engine memory within the ukern heap.

Managed Objects for Packet Forwarding Engine Memory Statistics Data
The jnxPfeMemory table, whose object identifier is {jnxPfeMib 2} contains the objects
listed in Table 108 on page 519
Table 108: jnxPfeMemory Table

jnxPfeMemoryUkernTable jnxPfeMemory 1 Provides global ukern memory statistics for the specified Packet
Forwarding Engine slot.
jnxPfeMemoryForwardingTable jnxPfeMemory 2 Provides global next-hop (for Trio-based line cards) or Jtree (for
I-chip-based line cards) memory utilization and firewall filter
memory utilization statistics for the specified Packet Forwarding
Engine slot.
Managed Objects for Next-Hop, Jtree, and Firewall Filter Memory for a Packet
Forwarding Engine in an FPC Slot
The jnxPfeMemoryForwardingTable, whose object identifier is {jnxPfeMemory 2}, contains

JnxPfeMemoryForwardingEntry that retrieves the next-hop memory for Trio- based line
cards, jtree memory for I-chip-based line cards, and firewall or filter memory statistics
for the specified Packet Forwarding Engine slot for both I- chip and Trio-based line cards.
Each jnxPfeMemoryForwardingEntry, whose object identifier is
{jnxPfeMemoryForwardingTable 1}, contains the objects listed in the following table.
The jnxPfeMemoryForwardingEntry represents the ASIC instance, ASIC memory used,

and ASIC free memory. The jtree memory on all MX Series router Packet Forwarding
Engines has two segments: one segment primarily stores routing tables and related
information, and the other segment primarily stores firewall-filter-related information.
As the allocation of more memory for routing tables or firewall filters might disrupt the
forwarding operations of a Packet Forwarding Engine, the Junos OS CLI displays a warning
to restart all affected FPCs when you commit a configuration that includes the
memory-enhanced route statement. The configuration does not become effective until
you restart the FPC or DPC (on MX Series routers).
Table 109: jnxPfeMemoryForwardingTable

jnxPfeMemoryForwardingChipSlot jnxPfeMemoryForwardingEntry 1 Indicates the ASIC instance number in the Packet

Forwarding Engine complex.
jnxPfeMemoryType jnxPfeMemoryForwardingEntry 2 Indicates the Packet Forwarding Engine memory

type, where nh = 1, fw = 2, encap = 3.

Table 109: jnxPfeMemoryForwardingTable (continued)

jnxPfeMemoryForwardingPercentFree jnxPfeMemoryForwardingEntry 3 Indicates the percentage of memory free for each

memory type.
jnxPfeMemoryErrorsTable
The Juniper Networks enterprise-specific Packet Forwarding Engine MIB, whose object
ID is {jnxPfeMibRoot 1}, supports a new MIB table, jnxPfeMemoryErrorsTable, to display
Packet Forwarding Engine memory error counters. The jnxPfeMemoryErrorsTable, whose
object identifier is jnxPfeNotification 3, contains the JnxPfeMemoryErrorsEntry. Each
JnxPfeMemoryErrorsEntry, whose object identifier is { jnxPfeMemoryErrorsTable 1 }, contains
the objects listed in the following table.
Table 110: jnxPfeMemoryErrorsTable

jnxPfeFpcSlot jnxPfeMemoryErrorsEntry 1 Signifies the FPC slot number for this set of PFE
notification
jnxPfeSlot jnxPfeMemoryErrorsEntry 2 Signifies the PFE slot number for this set of errors
jnxPfeParityErrors jnxPfeMemoryErrorsEntry 3 Signifies the parity error count
jnxPfeEccErrors jnxPfeMemoryErrorsEntry 4 Signifies the error-checking code (ECC) error count
pfeMemoryErrors
The pfeMemoryErrorsNotificationPrefix, whose object identifier is {jnxPfeNotification 0},

contains the pfeMemoryErrors attribute. The pfeMemoryErrors object, whose identifier
is {pfeMemoryErrorsNotificationPrefix 1} contains the jnxPfeParityErrors and
jnxPfeEccErrors objects.
Table 111: pfeMemoryErrors

pfeMemoryErrors pfeMemoryErrorsNotificationPrefix A pfeMemoryErrors notification is sent when the value of

1 jnxPfeParityErrors or jnxPfeEccErrors increases.

PART 9
Troubleshooting
• Configuring Data Path Debugging and Trace Options on page 523
• Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits on page 541
• Using Packet Capture to Analyze Network Traffic on page 559
• Troubleshooting Security Devices on page 585


CHAPTER 31
Configuring Data Path Debugging and

Trace Options
• Understanding Data Path Debugging for SRX Series Devices on page 523
• Debugging the Data Path (CLI Procedure) on page 524
• Example: Configuring End-to-End Debugging on SRX Series Device on page 525
• Understanding Security Debugging Using Trace Options on page 530
• Setting Security Trace Options (CLI Procedure) on page 530
• Displaying Log and Trace Files on page 531
• Displaying Output for Security Trace Options on page 532
• Displaying Multicast Trace Operations on page 533
• Using the J-Web Traceroute Tool on page 534
• J-Web Traceroute Results and Output Summary on page 535
• Understanding Flow Debugging Using Trace Options on page 536
• Setting Flow Debugging Trace Options (CLI Procedure) on page 537
• Displaying a List of Devices on page 537
Understanding Data Path Debugging for SRX Series Devices
Data path debugging, or end-to-end debugging, support provides tracing and debugging
at multiple processing units along the packet-processing path. The packet filter can be
executed with minimal impact to the production system.
On an SRX Series device, a packet goes through series of events involving different
components from ingress to egress processing.
With the data path debugging feature, you can trace and debug (capture packets) at
different data points along the processing path. The events available in the
packet-processing path are: NP ingress, load-balancing thread (LBT), jexec,
packet-ordering thread (POT), and NP egress. You can also enable flow module trace
if the security flow trace flag for a certain module is set.

At each event, you can specify any of the four actions (count, packet dump, packet
summary, and trace). Data path debugging provides filters to define what packets to
capture, and only the matched packets are traced. The packet filter can filter out packets
based on logical interface, protocol, source IP address prefix, source port, destination IP
address prefix, and destination port.
To enable end-to-end debugging, you must perform the following steps:
1. Define the capture file and specify the maximum capture size.
2. Define the packet filter to trace only a certain type of traffic based on the requirement.
3. Define the action profile specifying the location on the processing path from where
to capture the packets (for example, LBT or NP ingress).
4. Enable the data path debugging.
5. Capture traffic.
6. Disable data path debugging.
7. View or analyze the report.
NOTE:
The packet-filtering behavior for the port and interface options is as follows:
• The packet filter traces both IPv4 and IPv6 traffic if only port is specified.
• The packet filter traces IPv4, IPV6, and non-IP traffic if only interface is
specified.
Related • Understanding Security Debugging Using Trace Options on page 530

Documentation
• Example: Configuring End-to-End Debugging on SRX Series Device on page 525
Debugging the Data Path (CLI Procedure)
To configure the device for data path debugging:
1. Specify the following request command to set the data path debugging for the multiple
processing units along the packet-processing path:
[edit]
user@host# set security datapath-debug
2. Specify the trace options for data path-debug using the following command:
[edit]
user@host# set security datapath-debug traceoptions

Chapter 31: Configuring Data Path Debugging and Trace Options
3. Using the request security packet-filter command, you can set the packet filter to
specify the related packets to perform data path-debug action. A maximum of four
filters are supported at the same time. For example, the following command sets the
first packet-filter:
[edit]
user@host# set security datapath-debug packet-filter name
4. Using the request security action-profile command, you can set the action for the
packet match for a specified filter. Only the default action profile is supported, which
is the trace option for network processor ezchip ingress, ezchip egress, spu.lbt, and
spu.pot:
[edit]
user@host# set security datapath-debug packet-filter name action-profile
Related • Understanding Data Path Debugging for SRX Series Devices on page 523
Documentation
Example: Configuring End-to-End Debugging on SRX Series Device
Supported Platforms SRX5400, SRX5600, SRX5800
This example shows how to configure and enable end-to-end debugging on an SRX
Series device with an SRX5K-MPC.

• Enabling Data Path Debugging on page 528
Requirements
This example uses the following hardware and software components:
• SRX5600 device with an SRX5K-MPC installed with 100-Gigabit Ethernet CFP

transceiver
• Junos OS Release 12.1X47-D15 or later for SRX Series devices
Before you begin:
• See Understanding Data Path Debugging for SRX Series Devices.
No special configuration beyond device initialization is required before configuring this

feature.

Overview
Data path debugging enhances troubleshooting capabilities by providing tracing and
debugging at multiple processing units along the packet-processing path. With the data
path debugging feature, you can trace and debug (capture packets) at different data
points along the processing path. At each event, you can specify an action (count, packet
dump, packet summary, and trace) and you can set filters to define what packets to
capture.
In this example, you define a traffic filter, and then you apply an action profile. The action
profile specifies a variety of actions on the processing unit. The ingress and egress are
specified as locations on the processing path to capture the data for incoming and
outgoing traffic.
Next, you enable data path debugging in operational mode, and finally you view the data
capture report.
Configuration
set security datapath-debug traceoptions file e2e.trace size 10m

set security datapath-debug capture-file datapcap format pcap
set security datapath-debug maximum-capture-size 1500
set security datapath-debug action-profile profile-1 preserve-trace-order
set security datapath-debug action-profile profile-1 record-pic-history
set security datapath-debug action-profile profile-1 event np-ingress trace
set security datapath-debug action-profile profile-1 event np-ingress count
set security datapath-debug action-profile profile-1 event np-ingress packet-summary
set security datapath-debug action-profile profile-1 event np-ingress packet-count
set security datapath-debug action-profile profile-1 event np-egress trace
set security datapath-debug action-profile profile-1 event np-egress count
set security datapath-debug action-profile profile-1 event np-egress packet-summary
set security datapath-debug action-profile profile-1 event np-egress packet-count
set security datapath-debug packet-filter filter-1
set security datapath-debug packet-filter filter-1 action-profile profile-1
set security datapath-debug packet-filter filter-1 protocol tcp
set security datapath-debug packet-filter filter-1 source-prefix 203.0.113.1/24
set security datapath-debug packet-filter filter-1 destination-prefix 203.0.113.4/24
set security datapath-debug packet-filter filter-1 source-port 1000
set security datapath-debug packet-filter filter-1 destination-port 80
set security datapath-debug packet-filter filter-1 interface xe-2/2/0.0

To configure data path debugging:
1. Edit the security datapath debugging option for the multiple processing units along
the packet-processing path:
[edit]
user@host# edit security datapath-debug
2. Enable the capture file, file format, file size, and the number of files.
[edit security datapath-debug]

user@host# set traceoptions file e2e.trace size 10m
user@host# set capture-file datapcap format pcap;
user@host# set maximum-capture-size 1500
3. Configure action profile, event type, and actions for the action profile.

user@host# set action-profile profile-1 preserve-trace-order
user@host# set action-profile profile-1 record-pic-history
user@host# set action-profile profile-1 event np-ingress trace
user@host# set action-profile profile-1 event np-ingress count
user@host# set action-profile profile-1 event np-ingress packet-summary
user@host# set action-profile profile-1 event np-ingress packet-count
user@host# set action-profile profile-1 event np-egress trace
user@host# set action-profile profile-1 event np-egress count
user@host# set action-profile profile-1 event np-egress packet-summary
user@host# set action-profile profile-1 event np-egress packet-count
4. Configure packet filter, action, and filter options.

user@host# set packet-filter filter-1
user@host# set packet-filter filter-1 action-profile profile-1
user@host# set packet-filter filter-1 protocol tcp
user@host# set packet-filter filter-1 source-prefix 203.0.113.1/24
user@host# set packet-filter filter-1 destination-prefix 203.0.113.4/24
user@host# set packet-filter filter-1 source-port 1000
user@host# set packet-filter filter-1 destination-port 80
user@host# set packet-filter filter-1 interface xe-2/2/0.0
NOTE: You must configure multiple packet-filter statements to capture

the traffic, because one packet-filter captures only the traffic that is
specified in it, and the same packet filter does not capture the traffic in
the reverse direction. You must specify the source and destination
address for each packet filter, else the SRX Series device might log the
entire traffic and cause adverse impact to traffic.

Results From configuration mode, confirm your configuration by entering the show security
datapath-debug command. If the output does not display the intended configuration,
traceoptions {
file e2e.trace size 10m;
}
capture-file datapcap format pcap;
maximum-capture-size 1500;
action-profile {
profile-1 {
preserve-trace-order;
record-pic-history;
event np-ingress {
trace;
count;
packet-summary;
packet-dump;
}
event np-egress {
trace;
count;
packet-summary;
packet-dump;
}
}
}
packet-filter filter-1 {
action-profile profile-1;
protocol tcp;
source-prefix 203.0.113.1/24;
destination-prefix 203.0.113.4/24;
source-port 1000;
interface xe-2/2/0.0;
}
Enabling Data Path Debugging

Step-by-Step After configuring data path debugging, you must start the process on the device from
Procedure operational mode.
1. Enable data path debugging.
user@host> request security datapath-debug capture start
datapath-debug capture started on file datapcap
2. Before you verify the configuration and view the reports, you must disable data path
debugging.
user@host> request security datapath-debug capture stop
datapath-debug capture succesfully stopped, use show security datapath-debug

capture to view

NOTE: You must stop the debug process after you have finished
capturing the data. If you attempt to open the captured files without
stopping the debug process, the files obtained cannot be opened through
any third-party software (for example, tcpdump and wireshark).
Verification
Verifying Data Path Debug Packet Capture Details
Purpose Verify the data captured by enabling the data path debugging configuration.
Action From operational mode, enter the show security datapath-debug capture command.
Packet 8, len 152: (C2/F2/P0/SEQ:57935:np-ingress)

00 10 db ff 10 02 00 30 48 83 8d 4f 08 00 45 00
00 54 00 00 40 00 40 01 9f c7 c8 07 05 69 c8 08
05 69 08 00 91 1f 8f 03 2a a2 ae 66 85 53 8c 7d
02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
36 37
Packet 9, len 152: (C2/F2/P0/SEQ:57935:np-egress)
00 30 48 8d 1a bf 00 10 db ff 10 03 08 00 45 00
00 54 00 00 40 00 3f 01 a0 c7 c8 07 05 69 c8 08
05 69 08 00 91 1f 8f 03 2a a2 ae 66 85 53 8c 7d
02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
36 37....
For brevity, the show command output is truncated to display only a few samples.
Additional samples have been replaced with ellipses (...).
To view the results, from CLI operational mode, access the local UNIX shell and navigate
to the directory /var/log/<file-name>. The result can be read by using the tcpdump utility.
user@host>start shell
%tcptump -nr/var/log/e2e.pcap
21:50:04.288767 C0/F3 event:1(np-ingress) SEQ:1 IP 192.168.14.2 > 192.168.13.2:

ICMP echo request, id 57627, seq 0, length 64
21:50:04.292590 C0/F3 event:2(np-egress) SEQ:1 IP 192.168.14.2 > 192.168.13.2:
ICMP echo request, id 57627, seq 0, length 64
1:50:04.295164 C0/F3 event:1(np-ingress) SEQ:2 IP 192.168.13.2 > 192.168.14.2:
ICMP echo reply, id 57627, seq 0, length 64
21:50:04.295284 C0/F3 event:2(np-egress) SEQ:2 IP 192.168.13.2 > 192.168.14.2:
ICMP echo reply, id 57627, seq 0, length 64

NOTE: If you are finished with troubleshooting the data path debugging,
remove all traceoptions (not limited to flow traceoptions) and the complete
data path debug configuration, including the data path debug configuration
for packet capturing (packet-dump), which needs to be started/stopped
manually. If any part of the debugging configuration remains active, it will
continue to use the resources of the device (CPU/memory).
Documentation
Understanding Security Debugging Using Trace Options
The Junos OS trace function allows applications to write security debugging information
to a file. The information that appears in this file is based on criteria you set. You can use
this information to analyze security application issues.
The trace function operates in a distributed manner, with each thread writing to its own
trace buffer. These trace buffers are then collected at one point, sorted, and written to
trace files. Trace messages are delivered using the InterProcess Communications (IPC)
protocol. A trace message has a lower priority than that of control protocol packets such
as BGP, OSPF, and IKE, and therefore delivery is not considered to be as reliable.
Documentation
Setting Security Trace Options (CLI Procedure)
Use the following configuration statements to configure security trace options in the CLI
configuration editor.
• To disable remote tracing, enter the following statement:
[edit]
user@host# set security traceoptions no-remote-trace
• To write trace messages to a local file, enter the following statement. The system
saves the trace file in the /var/log/ directory.
[edit]
user@host# set security traceoptions use-local-files

• To specify a name for the trace file, enter the following statement. Valid values range
from 1 and 1024 characters. The name cannot include spaces, /, or % characters. The
default filename is security.
[edit]
user@host# set security traceoptions file filename
• To specify the maximum number of trace files that can accumulate, enter the following
statement. Valid values range from 2 to 1000. The default value is 3.
[edit]
user@host# set security traceoptions file files 3
• To specify the match criteria that you want the system to use when logging information
to the file, enter the following statement. Enter a regular expression. Wildcard (*)
characters are accepted.
[edit]
user@host# set security traceoptions file match *thread
• To allow any user to read the trace file, enter the world-readable statement. Otherwise,
enter the no-world-readable statement.
[edit]
user@host# set security traceoptions file world-readable
user@host# set security traceoptions file no-world-readable
• To specify the maximum size to which the trace file can grow, enter the following
statement. Once the file reaches the specified size, it is compressed and renamed
filename0.gz, the next file is named filename1.gz, and so on. Valid values range from
10240 to 1,073,741,824.
[edit]
user@host# set security traceoptions file size 10240
• To turn on trace options and to perform more than one tracing operation, set the
following flags.
[edit]
user@host# set security traceoptions flag all
user@host# set security traceoptions flag compilation
user@host# set security traceoptions flag configuration
user@host# set security traceoptions flag routing-socket
• To specify the groups that these trace option settings do or do not apply to, enter the
following statements:
[edit]
user@host# set security traceoptions apply-groups value
user@host# set security traceoptions apply-groups-except value

Documentation
Displaying Log and Trace Files

Enter the monitor start command to display real-time additions to system logs and trace
files:
user@host> monitor start filename
When the device adds a record to the file specified by filename, the record displays on
the screen. For example, if you have configured a system log file named system-log (by
including the syslog statement at the [edit system] hierarchy level), you can enter the
monitor start system-log command to display the records added to the system log.
To display a list of files that are being monitored, enter the monitor list command. To
stop the display of records for a specified file, enter the monitor stop filename command.
Related • Displaying a List of Devices on page 537

Documentation
• Displaying Real-Time Monitoring Information on page 383
Displaying Output for Security Trace Options
Purpose Display output for security trace options.
Action Use the show security traceoptions command to display the output of your trace files.
For example:
[edit]
user@host # show security traceoptions file usp_trace
user@host # show security traceoptions flag all
user@host # show security traceoptions rate-limit 888
The output for this example is as follows:
Apr 11 16:06:42 21:13:15.750395:CID-906489336:FPC-01:PIC-01:THREAD_ID-01:PFE:now

update 0x3607edf8df8in 0x3607e8d0
Apr 11 16:06:42 21:13:15.874058:CID-1529687608:FPC-01:PIC-01:THREAD_ID-01:CTRL:Enter
Function[util_ssam_handler]
Apr 11 16:06:42 21:13:15.874485:CID-00:FPC-01:PIC-01:THREAD_ID-01:CTRL:default1: Rate
limit changed to 888
Apr 11 16:06:42 21:13:15.874538:CID-00:FPC-01:PIC-01:THREAD_ID-01:CTRL:default1:
Destination ID set to 1

Documentation

Displaying Multicast Trace Operations
To monitor and display multicast trace operations, enter the mtrace monitor command:
user@host> mtrace monitor
Mtrace query at Apr 21 16:00:54 by 192.1.30.2, resp to 224.0.1.32, qid 2a83aa

packet from 192.1.30.2 to 224.0.0.2 from 192.1.30.2 to 192.1.4.1 via group
224.1.1.1 (mxhop=60) Mtrace query at Apr 21 16:00:57 by 192.1.30.2, resp to
224.0.1.32, qid 25dc17 packet from 192.1.30.2 to 224.0.0.2 from 192.1.30.2 to
192.1.4.1 via group 224.1.1.1 (mxhop=60) Mtrace query at Apr 21 16:01:00 by
192.1.30.2, resp to same, qid 20e046 packet from 192.1.30.2 to 224.0.0.2 from
192.1.30.2 to 192.1.4.1 via group 224.1.1.1 (mxhop=60) Mtrace query at Apr 21
16:01:10 by 192.1.30.2, resp to same, qid 1d25ad packet from 192.1.30.2 to
224.0.0.2 from 192.1.30.2 to 192.1.4.1 via group 224.1.1.1 (mxhop=60)
This example displays only mtrace queries. However, when the device captures an mtrace
response, the display is similar, but the complete mtrace response also appears (exactly
as it is appears in the mtrace from-source command output).
Table 112: CLI mtrace monitor Command Output Summary

Field Description
Mtrace operation-type at time-of-day • operation-type—Type of multicast trace operation: query or response.

• time-of-day—Date and time the multicast trace query or response was captured.
by IP address of the host issuing the query.
resp to address address—Response destination address.
qid qid qid—Query ID number.
packet from source to destination • source—IP address of the source of the query or response.
• destination—IP address of the destination of the query or response.
from source to destination • source—IP address of the multicast source.

• destination—IP address of the multicast destination.
via group address address—Group address being traced.
mxhop=number number—Maximum hop setting.
Related • Using the J-Web Traceroute Tool on page 534

Documentation

Using the J-Web Traceroute Tool
You can use the traceroute diagnostic tool to display a list of devices between the device
and a specified destination host. The output is useful for diagnosing a point of failure in
the path from the device to the destination host, and addressing network traffic latency
and throughput problems.
The device generates the list of devices by sending a series of ICMP traceroute packets
in which the time-to-live (TTL) value in the messages sent to each successive device is
incremented by 1. (The TTL value of the first traceroute packet is set to 1.) In this manner,
each device along the path to the destination host replies with a Time Exceeded packet
from which the source IP address can be obtained.
To use the traceroute tool:
1. Select Troubleshoot>Traceroute.
2. Next to Advanced options, click the expand icon.
3. Enter information into the Traceroute page (see Table 113 on page 534).
Table 113: Traceroute Field Summary

Remote Host Identifies the destination host of the traceroute. Type the hostname or IP address of the destination
host.
The Remote Host field is the only required field.
Advanced Options
Don't Resolve Determines whether hostnames of the hops along • Suppress the display of the hop hostnames by
Addresses the path are displayed, in addition to IP addresses. selecting the check box.
• Display the hop hostnames by clearing the check
box.
Gateway Specifies the IP address of the gateway to route Type the gateway IP address.
through.
Source Address Specifies the source address of the outgoing Type the source IP address.
traceroute packets.
Bypass Routing Determines whether traceroute packets are routed • Bypass the routing table and send the traceroute
by means of the routing table. packets to hosts on the specified interface only
by selecting the check box.
If the routing table is not used, traceroute packets
• Route the traceroute packets by means of the
are sent only to hosts on the interface specified in
routing table bu clearing the check box.
the Interface box. If the host is not on that interface,
traceroute responses are not sent.
Interface Specifies the interface on which the traceroute Select the interface on which traceroute packets are
packets are sent. sent from the list. If you select any, the traceroute
requests are sent on all interfaces.

Table 113: Traceroute Field Summary (continued)

Time-to-Live Specifies the maximum time-to-live (TTL) hop count Select the TTL from the list.
for the traceroute request packet.
Type-of-Service Specifies the type-of-service (TOS) value to include Select the decimal value of the TOS field from the
in the IP header of the traceroute request packet. list.
Resolve AS Determines whether the autonomous system (AS) • Display the AS numbers by selecting the check
Numbers number of each intermediate hop between the box.
device and the destination host is displayed. • Suppress the display of the AS numbers by
clearing the check box.
4. Click Start.
The results of the traceroute operation are displayed in the main pane. If no options
are specified, each line of the traceroute display is in the following format:
hop-number host (ip-address) [as-number]time1 time2 time3
The device sends a total of three traceroute packets to each router along the path
and the round-trip time for each traceroute operation appears. If the device times out
before receiving a Time Exceeded message, an asterisk (*) appears for that round-trip
time.
5. You can stop the traceroute operation before it is complete by clicking OK while the
results of the traceroute operation appear.
Related • Diagnostic Tools Overview on page 8

Documentation
• Using the J-Web Ping MPLS Tool on page 549
• Using the J-Web Packet Capture Tool on page 579
J-Web Traceroute Results and Output Summary
Table 114 on page 535 summarizes the output in the traceroute display.
Table 114: J-Web Traceroute Results and Output Summary

Field Description
hop-number Number of the hop (device) along the path.
host Hostname, if available, or IP address of the device. If the Don't Resolve Addresses check box is selected,
the hostname does not appear.

Table 114: J-Web Traceroute Results and Output Summary (continued)

Field Description
ip-address IP address of the device.
as-number AS number of the device.
time1 Round-trip time between the sending of the first traceroute packet and the receiving of the corresponding
Time Exceeded packet from that particular device.
time2 Round-trip time between the sending of the second traceroute packet and the receiving of the corresponding
time3 Round-trip time between the sending of the third traceroute packet and the receiving of the corresponding
If the device does not display the complete path to the destination host, one of the
following explanations might apply:
• The host is not operational.
• There are network connectivity problems between the device and the host.
• The host, or a router along the path, might be configured to ignore ICMP traceroute
messages.
• The host, or a device along the path, might be configured with a firewall filter that
blocks ICMP traceroute requests or ICMP time exceeded responses.
• The value you selected in the Time Exceeded box was less than the number of hops
in the path to the host. In this case, the host might reply with an ICMP error message.

Documentation
Understanding Flow Debugging Using Trace Options
For flow trace options, you can define a packet filter using combinations of
destination-port, destination-prefix, interface, protocol, source-port, and source-prefix. If
the security flow trace flag for a certain module is set, the packet matching the specific
packet filter triggers flow tracing and writes debugging information to the trace file.
Documentation

Setting Flow Debugging Trace Options (CLI Procedure)
The following examples display the options you can set by using security flow traceoptions.
• To match the imap destination port for the filter1 packet filter, use the following
statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 destination-port imap
• To set the 1.2.3.4 destination IPv4 prefix address for the filter1 packet filter, use the
following statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 destination-prefix 1.2.3.4
• To set the fxp0 logical interface for the filter1 packet filter, use the following statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 interface fxp0
• To match the TCP IP protocol for the filter1 packet filter, use the following statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 protocol tcp
• To match the HTTP source port for the filter1 packet filter, use the following statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 source-port http
• To set the 5.6.7.8 IPv4 prefix address for the filter1 packet filter, use the following
statement:
[edit]
user@host# set security flow traceoptions packet-filter filter1 source-prefix 5.6.7.8
Related • Understanding Flow Debugging Using Trace Options on page 536

Documentation
Displaying a List of Devices
To display a list of devices between the device and a specified destination host, enter
the traceroute command with the following syntax:
user@host> traceroute host <interface interface-name> <as-number-lookup>

<bypass-routing> <gateway address> <inet | inet6> <no-resolve>
<routing-instance routing-instance-name> <source source-address> <tos number>
<ttl number> <wait seconds>
Table 115 on page 538 describes the traceroute command options.

Table 115: CLI traceroute Command Options

Option Description
host Sends traceroute packets to the hostname or IP address you specify.
interface interface-name (Optional) Sends the traceroute packets on the interface you specify. If you do not include this
option, traceroute packets are sent on all interfaces.
as-number-lookup (Optional) Displays the autonomous system (AS) number of each intermediate hop between
the device and the destination host.
bypass-routing (Optional) Bypasses the routing tables and sends the traceroute packets only to hosts on directly
attached interfaces. If the host is not on a directly attached interface, an error message is returned.
Use this option to display a route to a local system through an interface that has no route through
it.
gateway address (Optional) Uses the gateway you specify to route through.
inet (Optional) Forces the traceroute packets to an IPv4 destination.
inet6 (Optional) Forces the traceroute packets to an IPv6 destination.
routing-instance (Optional) Uses the routing instance you specify for the traceroute.
source address (Optional) Uses the source address that you specify, in the traceroute packet.
tos number (Optional) Sets the type-of-service (TOS) value in the IP header of the traceroute packet. Specify
a value from 0 through 255.
ttl number (Optional) Sets the time-to-live (TTL) value for the traceroute packet. Specify a hop count from
0 through 128.
wait seconds (Optional) Sets the maximum time to wait for a response.
To quit the traceroute command, press Ctrl-C.
The following is sample output from a traceroute command:
user@host> traceroute host2
traceroute to 173.24.232.66 (172.24.230.41), 30 hops max, 40 byte packets 1

173.18.42.253 (173.18.42.253) 0.482 ms 0.346 ms 0.318 ms 2 host4.site1.net
(173.18.253.5) 0.401 ms 0.435 ms 0.359 ms 3 host5.site1.net (173.18.253.5)
0.401 ms 0.360 ms 0.357 ms 4 173.24.232.65 (173.24.232.65) 0.420 ms 0.456
ms 0.378 ms 5 173.24.232.66 (173.24.232.66) 0.830 ms 0.779 ms 0.834 ms
The fields in the display are the same as those displayed by the J-Web traceroute
diagnostic tool.

Related • Displaying Log and Trace Files on page 531

Documentation


CHAPTER 32
Using MPLS to Diagnose LSPs, VPNs, and

Layer 2 Circuits

• J-Web Ping Host Results and Output Summary on page 548
• J-Web Ping MPLS Results and Output Summary on page 552
• Pinging Layer 2 Circuits on page 553
• Pinging Layer 2 VPNs on page 554
• Pinging RSVP-Signaled LSPs and LDP-Signaled LSPs on page 557
MPLS Connection Checking Overview
Supported Platforms SRX1500, SRX1500, SRX300, SRX320, SRX340, vSRX
Use either the J-Web ping MPLS diagnostic tool or the CLI commands ping mpls, ping
mpls l2circuit, ping mpls l2vpn, and ping mpls l3vpn to diagnose the state of label-switched
paths (LSPs), Layer 2 and Layer 3 virtual private networks (VPNs), and Layer 2 circuits.
Based on how the LSP or VPN outbound (egress) node at the remote endpoint of the
connection replies to the probes, you can determine the connectivity of the LSP or VPN.
Each probe is an echo request sent to the LSP or VPN exit point as an MPLS packet with
a UDP payload. If the outbound node receives the echo request, it checks the contents
of the probe and returns a value in the UDP payload of the response packet. If the device
receives the response packet, it reports a successful ping response.
Responses that take longer than 2 seconds are identified as failed probes.
Table 116 on page 542 summarizes the options for using either the J-Web ping MPLS
diagnostic tool or the CLI ping mpls command to display information about MPLS
connections in VPNs and LSPs.

Table 116: Options for Checking MPLS Connections

J-Web Ping MPLS ping mpls
Tool Command Purpose Additional Information
Ping RSVP-signaled ping mpls rsvp Checks the operability of an LSP that When an RSVP-signaled LSP has
LSP has been set up by the Resource several paths, the device sends the
Reservation Protocol (RSVP). The ping requests on the path that is
device pings a particular LSP using currently active.
the configured LSP name.
Ping LDP-signaled LSP ping mpls ldp Checks the operability of an LSP that When an LDP-signaled LSP has
has been set up by the Label several gateways, the device sends
Distribution Protocol (LDP). The the ping requests through the first
device pings a particular LSP using gateway.
the forwarding equivalence class
(FEC) prefix and length. Ping requests sent to LDP-signaled
LSPs use only the master routing
instance.
Ping LSP to Layer 3 ping mpls l3vpn Checks the operability of the The device does not test the
VPN prefix connections related to a Layer 3 VPN. connection between a PE device and
The device tests whether a prefix is a customer edge (CE) router.
present in a provider edge (PE)
device’s VPN routing and forwarding
(VRF) table, by means of a Layer 3
VPN destination prefix.
Locate LSP using ping mpls l2vpn Checks the operability of the –
interface name interface connections related to a Layer 2 VPN.
The device directs outgoing request
probes out the specified interface.
Instance to which this ping mpls l2vpn Checks the operability of the –
connection belongs instance connections related to a Layer 2 VPN.
The device pings on a combination of
the Layer 2 VPN routing instance
name, the local site identifier, and the
remote site identifier, to test the
integrity of the Layer 2 VPN circuit
(specified by the identifiers) between
the inbound and outbound PE routers.
Locate LSP from ping mpls l2circuit Checks the operability of the Layer 2 –
interface name interface circuit connections. The device directs
outgoing request probes out the
specified interface.
Locate LSP from ping mpls l2circuit Checks the operability of the Layer 2 –
virtual circuit virtual-circuit circuit connections. The device pings
information on a combination of the IPv4 prefix
and the virtual circuit identifier on the
outbound PE router, testing the
integrity of the Layer 2 circuit between
the inbound and outbound PE routers.

Chapter 32: Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
Table 116: Options for Checking MPLS Connections (continued)

J-Web Ping MPLS ping mpls
Tool Command Purpose Additional Information
Ping end point of LSP ping mpls Checks the operability of an LSP –
lsp-end-point endpoint. The device pings an LSP
endpoint using either an LDP FEC
prefix or an RSVP LSP endpoint
address.

Documentation
Understanding Ping MPLS
Supported Platforms SRX100, SRX110, SRX210, SRX220, SRX240, SRX650
Before using the ping MPLS feature, make sure that the receiving interface on the VPN
or LSP remote endpoint has MPLS enabled, and that the loopback interface on the
outbound node is configured as 127.0.0.1. The source address for MPLS probes must be
a valid address on the J Series device.
• MPLS Enabled on page 543

• Loopback Address on page 543
• Source Address for Probes on page 544
MPLS Enabled
To process ping MPLS requests, the remote endpoint of the VPN or LSP must be
configured appropriately. You must enable MPLS on the receiving interface of the
outbound node for the VPN or LSP. If MPLS is not enabled, the remote endpoint drops
the incoming request packets and returns an “ICMP host unreachable” message to the
J Series device.
Loopback Address
The loopback address (lo0) on the outbound node must be configured as 127.0.0.1. If
this interface address is not configured correctly, the outbound node does not have this
forwarding entry. It drops the incoming request packets and returns a “host unreachable”
message to the J Series device.

Source Address for Probes

The source IP address you specify for a set of probes must be an address configured on
one of the J Series device interfaces. If it is not a valid J Series device address, the ping
request fails with the error message “Can't assign requested address.”

Documentation
• Junos OS Interfaces Configuration Guide for Security Devices
• Junos OS Feature Support Reference for SRX Series and J Series Devices
Using the ping Command
You can perform certain tasks only through the CLI. Use the CLI ping command to verify
that a host can be reached over the network. This command is useful for diagnosing host
and network connectivity problems. The device sends a series of ICMP echo (ping)
requests to a specified host and receives ICMP echo responses.
Enter the ping command with the following syntax:
user@host> ping host <interface source-interface> <bypass-routing> <count number>

<do-not-fragment> <inet | inet6> <interval seconds> <loose-source [hosts]>
<no-resolve> <pattern string> <rapid> <record-route>
<routing-instance routing-instance-name> <size bytes> <source source-address> <strict>
<strict-source [hosts]> <tos number> <ttl number> <wait seconds> <detail> <verbose>
Table 117 on page 544 describes the ping command options.
To quit the ping command, press Ctrl-C.
Table 117: CLI ping Command Options

Option Description
host Pings the hostname or IP address you specify.
interface source-interface (Optional) Sends the ping requests on the interface you specify. If you do not include this option,
ping requests are sent on all interfaces.
bypass-routing (Optional) Bypasses the routing tables and sends the ping requests only to hosts on directly
attached interfaces. If the host is not on a directly attached interface, an error message is returned.
Use this option to ping a local system through an interface that has no route through it.

Table 117: CLI ping Command Options (continued)

Option Description
countnumber (Optional) Limits the number of ping requests to send. Specify a count from 1 through
2,000,000,000. If you do not specify a count, ping requests are continuously sent until you press
Ctrl-C.
do-not-fragment (Optional) Sets the Don't Fragment (DF) bit in the IP header of the ping request packet.
inet (Optional) Forces the ping requests to an IPv4 destination.
inet6 (Optional) Forces the ping requests to an IPv6 destination.
interval seconds (Optional) Sets the interval between ping requests, in seconds. Specify an interval from 0.1 through
10,000. The default value is 1 second.
loose-source [hosts] (Optional) For IPv4, sets the loose source routing option in the IP header of the ping request
packet.
pattern string (Optional) Includes the hexadecimal string you specify, in the ping request packet.
rapid (Optional) Sends ping requests rapidly. The results are reported in a single message, not in
individual messages for each ping request. By default, five ping requests are sent before the results
are reported. To change the number of requests, include the count option.
record-route (Optional) For IPv4, sets the record route option in the IP header of the ping request packet. The
path of the ping request packet is recorded within the packet and displayed on the screen.
routing-instance (Optional) Uses the routing instance you specify for the ping request.
size bytes (Optional) Sets the size of the ping request packet. Specify a size from 0 through 65,468. The
default value is 56 bytes, which is effectively 64 bytes because 8 bytes of ICMP header data are
added to the packet.
source source-address (Optional) Uses the source address that you specify, in the ping request packet.
strict (Optional) For IPv4, sets the strict source routing option in the IP header of the ping request packet.
strict-source [hosts] (Optional) For IPv4, sets the strict source routing option in the IP header of the ping request packet,
and uses the list of hosts you specify for routing the packet.
tos number (Optional) Sets the type-of-service (TOS) value in the IP header of the ping request packet.
Specify a value from 0 through 255.
ttl number (Optional) Sets the time-to-live (TTL) value for the ping request packet. Specify a value from 0
through 255.

Table 117: CLI ping Command Options (continued)

Option Description
wait seconds (Optional) Sets the maximum time to wait after sending the last ping request packet. If you do
not specify this option, the default delay is 10 seconds. If you use this option without the count
option, the device uses a default count of 5 packets.
detail (Optional) Displays the interface on which the ping response was received.
verbose (Optional) Displays detailed output.
The following is sample output from a ping command:
user@host> ping host3 count 4
PING host3.site.net (176.26.232.111): 56 data bytes 64 bytes from 176.26.232.111:

icmp_seq=0 ttl=122 time=0.661 ms 64 bytes from 176.26.232.111: icmp_seq=1 ttl=122
time=0.619 ms 64 bytes from 176.26.232.111: icmp_seq=2 ttl=122 time=0.621 ms 64
bytes from 176.26.232.111: icmp_seq=3 ttl=122 time=0.634 ms --- host3.site.net
ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.619/0.634/0.661/0.017 ms
The fields in the display are the same as those displayed by the J-Web ping host diagnostic
tool.

Documentation
• Interfaces Feature Guide for Security Devices
Using the J-Web Ping Host Tool
You can ping a host to verify that the host can be reached over the network. The output
is useful for diagnosing host and network connectivity problems. The device sends a
series of ICMP echo (ping) requests to a specified host and receives ICMP echo responses.
Alternatively, you can use the CLI ping command. (See “Using the ping Command” on
page 544.)
To use the ping host tool:
1. Select Troubleshoot>Ping Host from the task bar.
2. Next to Advanced options, click the expand icon.

3. Enter information into the Ping Host page (see Table 118 on page 547).
Table 118: J-Web Ping Host Field Summary

Remote Host Identifies the host to ping. Type the hostname or IP address of the host to ping.
This is the only required field.
Advanced Options
Don't Resolve Determines whether to display hostnames of the • Suppress the display of the hop hostnames by
Addresses hops along the path. selecting the check box.
• Display the hop hostnames by clearing the check
box.
Interface Specifies the interface on which the ping requests Select the interface on which ping requests are sent
are sent. from the list. If you select any, the ping requests are
sent on all interfaces.
Count Specifies the number of ping requests to send. Select the number of ping requests to send from the
list.
Don't Fragment Specifies the Don't Fragment (DF) bit in the IP header • Set the DF bit by selecting the check box.
of the ping request packet. • Clear the DF bit by clearing the check box.
Record Route Sets the record route option in the IP header of the • Record and display the path of the packet by
ping request packet. The path of the ping request selecting the check box.
packet is recorded within the packet and displayed • Suppress the recording and display of the path of
in the main pane. the packet by clearing the check box.
Type-of-Service Specifies the type-of-service (TOS) value in the IP Select the decimal value of the TOS field from the
header of the ping request packet. list.
Routing Instance Names the routing instance for the ping attempt. Select the routing instance name from the list.
Interval Specifies the interval, in seconds, between the Select the interval from the list.
transmission of each ping request.
Packet Size Specifies the size of the ping request packet. Type the size, in bytes, of the packet. The size can
be from 0 through 65,468. The device adds 8 bytes
of ICMP header to the size.
Source Address Specifies the source address of the ping request Type the source IP address.
packet.
Time-to-Live Specifies the time-to-live (TTL) hop count for the Select the TTL from the list.
ping request packet.
Bypass Routing Determines whether ping requests are routed by • Bypass the routing table and send the ping
means of the routing table. requests to hosts on the specified interface only
by selecting the check box.
If the routing table is not used, ping requests are sent
• Route the ping requests using the routing table by
only to hosts on the interface specified in the
clearing the check box.
Interface box. If the host is not on that interface, ping
responses are not sent.

4. Click Start.
The results of the ping operation appear in the main pane. If no options are specified,
each ping response is in the following format:
bytes bytes from ip-address: icmp_seq=number ttl=number time=time
5. You can stop the ping operation before it is complete by clicking OK.

Documentation
• J-Web Ping Host Results and Output Summary on page 548
J-Web Ping Host Results and Output Summary
Table 119 on page 548 summarizes the output in the ping host display.
Table 119: Ping Host Results and Output

Ping Host Result Description
bytes bytes from ip-address • bytes —Size of ping response packet, which is equal to the value you entered in
the Packet Size box, plus 8.
• ip-address—IP address of destination host that sent the ping response packet.
icmp_seq=0 number—Sequence Number field of the ping response packet. You can use this value
to match the ping response to the corresponding ping request.
icmp_seq=number
ttl=number number—Time-to-live hop-count value of the ping response packet.
number packets transmitted number—Number of ping requests (probes) sent to host.
percentage packet loss percentage—Number of ping responses divided by the number of ping requests,
specified as a percentage.
round-trip min/avg/max/stddev = • min-time—Minimum round-trip time (see time=time field in this table).
min-time/avg-time/max-time/std-dev ms • avg-time—Average round-trip time.
• max-time—Maximum round-trip time.
• std-dev—Standard deviation of the round-trip times.
If the device does not receive ping responses from the destination host (the output shows
a packet loss of 100 percent), one of the following explanations might apply:

• The host might be configured to ignore ICMP echo requests.
• The host might be configured with a firewall filter that blocks ICMP echo requests or
ICMP echo responses.
• The size of the ICMP echo request packet exceeds the MTU of a host along the path.
• The value you selected in the Time-to-Live box was less than the number of hops in
the path to the host, in which case the host might reply with an ICMP error message.

Documentation
Using the J-Web Ping MPLS Tool
Before using the ping MPLS feature, make sure that the receiving interface on the VPN
or LSP remote endpoint has MPLS enabled, and that the loopback interface on the
outbound node is configured as 127.0.0.1. The source address for MPLS probes must be
a valid address on the device.
To use the ping MPLS tool:
1. Select Troubleshoot>Ping MPLS from the task bar.
2. Next to the ping MPLS option you want to use, click the expand icon.
3. Enter information into the Ping MPLS page (see Table 120 on page 549).
Table 120: J-Web Ping MPLS Field Summary

Ping RSVP-signaled LSP

LSP Name Identifies the LSP to ping. Type the name of the LSP to ping.
Source Address Specifies the source address of the ping request Type the source IP address—a valid address
packet. configured on a device interface.
list. The default is 5 requests.
Detailed Output Requests the display of extensive rather than brief Select the check box to display detailed output.
ping output.
Ping LDP-signaled LSP

Table 120: J-Web Ping MPLS Field Summary (continued)

FEC Prefix Identifies the LSP to ping. Type the forwarding equivalence class (FEC) prefix
and length of the LSP to ping.
ping output.
Ping LSP to Layer 3 VPN prefix

Layer 3 VPN Identifies the Layer 3 VPN to ping. Type the name of the VPN to ping.
Name
ping output.
VPN Prefix Identifies the IP address prefix and length of the Type the IP address prefix and length of the VPN to
Layer 3 VPN to ping. ping.
Locate LSP using interface name

Interface Specifies the interface on which the ping requests Select the device interface on which ping requests
are sent. are sent from the list. If you select any, the ping
ping output.
Instance to which this connection belongs

Layer 2VPN Identifies the Layer 2 VPN to ping. Type the name of the VPN to ping.
Name
Remote Site Specifies the remote site identifier of the Layer 2 VPN Type the remote site identifier for the VPN.
Identifier to ping.


Local Site Specifies the local site identifier of the Layer 2 VPN Type the local site identifier for the VPN.
Identifier to ping.
ping output.
Locate LSP from interface name

Interface Specifies the interface on which the ping requests Select the device interface on which ping requests
are sent. are sent from the list. If you select any, the ping
ping output.
Locate LSP from virtual circuit information

Remote Identifies the remote neighbor (PE device) within Type the IP address of the remote neighbor within
Neighbor the virtual circuit to ping. the virtual circuit.
Circuit Identifier Specifies the virtual circuit identifier for the Layer 2 Type the virtual circuit identifier for the Layer 2 circuit.
circuit to ping.
list.
ping output.
Ping end point of LSP

VPN Prefix Identifies the LSP endpoint to ping. Type either the LDP FEC prefix and length or the
RSVP LSP endpoint address for the LSP to ping.


list.
ping output.
4. Click Start.
5. You can stop the ping operation before it is complete by clicking OK.

Documentation
• J-Web Ping MPLS Results and Output Summary on page 552
J-Web Ping MPLS Results and Output Summary
Table 121 on page 552 summarizes the output in the ping MPLS display.
Table 121: J-Web Ping MPLS Results and Output Summary

Field Description
Exclamation point (!) Echo reply was received.
Period (.) Echo reply was not received within the timeout period.
x Echo reply was received with an error code. Errored packets are not counted in the
received packets count and are accounted for separately.
number packets transmitted number—Number of ping requests (probes) sent to a host.
number packets received number—Number of ping responses received from a host.
percentage packet loss percentage—Number of ping responses divided by the number of ping requests, specified
as a percentage.
time For Layer 2 circuits only, the number of milliseconds required for the ping packet to
reach the destination. This value is approximate, because the packet has to reach the
Routing Engine.

If the device does not receive ping responses from the destination host (the output shows
a packet loss of 100 percent), one of the following explanations might apply:
• The host might be configured to ignore echo requests.
• The host might be configured with a firewall filter that blocks echo requests or echo
responses.
• The size of the echo request packet exceeds the MTU of a host along the path.
• The outbound node at the remote endpoint is not configured to handle MPLS packets.
• The remote endpoint's loopback address is not configured to 127.0.0.1.

Documentation
Pinging Layer 2 Circuits
Enter the ping mpls l2circuit command with the following syntax:
user@host> ping mpls l2circuit (interface interface-name | virtual-circuit neighbor

prefix-name virtual-circuit-id) <exp forwarding-class> <count number>
<source source-address> <detail>
Table 122 on page 553 describes the ping mpls l2circuit command options.
Table 122: CLI ping mpls l2circuit Command Options

Option Description
l2circuit interface Sends ping requests out the specified interface configured for the Layer 2 circuit on the outbound
interface-name PE device.
l2circuit virtual-circuit Pings on a combination of the IPv4 prefix and the virtual circuit identifier on the outbound PE
neighbor prefix-name device, testing the integrity of the Layer 2 circuit between the inbound and outbound PE devices.
virtual-circuit-id
exp forwarding-class (Optional) Specifies the value of the forwarding class to be used in the MPLS ping packets.
countnumber (Optional) Limits the number of ping requests to send. Specify a count from 0 through 1,000,000.
The default value is 5. If you do not specify a count, ping requests are continuously sent until you
press Ctrl-C.

Table 122: CLI ping mpls l2circuit Command Options (continued)

Option Description
detail (Optional) Displays detailed output about the echo requests sent and received. Detailed output
includes the MPLS labels used for each request and the return codes for each request.
To quit the ping mpls l2circuit command, press Ctrl-C.
The following is sample output from a ping mpls l2circuit command:
user@host> ping mpls l2circuit interface fe-1/0/0.0
Request for seq 1, to interface 69, labels <100000, 100208>

Reply for seq 1, return code: Egress-ok, time: 0.439 ms
The fields in the display are the same as those displayed by the J-Web ping MPLS
diagnostic tool.
Related • Using the ping Command on page 544

Documentation
Pinging Layer 2 VPNs
Enter the ping mpls l2vpn command with the following syntax:
user@host> ping mpls l2vpn interface interface-name | instance l2vpn-instance-name

local-site-id local-site-id-number remote-site-id remote-site-id-number
<bottom-label-ttl> <exp forwarding-class> <count number> <source source-address>
<detail>
Table 123 on page 554 describes the ping mpls l2vpn command options.
Table 123: CLI ping mpls l2vpn Command Options

Option Description
l2vpn interface Sends ping requests out the specified interface configured for the Layer 2 VPN on the outbound
interface-name (egress) PE device.
l2vpn instance Pings on a combination of the Layer 2 VPN routing instance name, the local site identifier, and
l2vpn-instance-name the remote site identifier, testing the integrity of the Layer 2 VPN circuit (specified by the identifiers)
local-site-id between the inbound (ingress) and outbound PE devices.
local-site-id-number
remote-site-id
remote-site-id-number

Table 123: CLI ping mpls l2vpn Command Options (continued)

Option Description
bottom-label-ttl (Optional) Displays the time-to-live (TTL) value for the bottom label in the MPLS label stack.
press Ctrl-C.
To quit the ping mpls l2vpn command, press Ctrl-C.
The following is sample output from a ping mpls l2vpn command:
user@host> ping mpls l2vpn instance vpn1 remote-site-id 1 local-site-id 2 detail

Reply for seq 1, return code: Egress-ok
--- lsping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
diagnostic tool.

Documentation
Pinging Layer 3 VPNs

Enter the ping mpls l3vpn command with the following syntax:
user@host> ping mpls l3vpn prefix prefix-name <l3vpn-name> <bottom-label-ttl>

<exp forwarding-class> <count number> <source source-address> <detail>
Table 124 on page 556 describes the ping mpls l3vpn command options.
Table 124: CLI ping mpls l3vpn Command Options

Option Description
l3vpn prefix prefix-name Pings the remote host specified by the prefix to verify that the prefix is present in the PE device's
VPN routing and forwarding (VRF) table. This option does not test the connectivity between a
PE device and a CE device.
l3vpn-name (Optional) Layer 3 VPN name.
bottom-label-ttl (Optional) Displays the time-to-live (TTL) value for the bottom label in the MPLS label stack.
press Ctrl-C.
To quit the ping mpls l3vpn command, press Ctrl-C.
The following is sample output from a ping mpls l3vpn command:
user@host> ping mpls l3vpn vpn1 prefix 10.255.245.122/32
!!!!!
diagnostic tool.

Documentation

Pinging RSVP-Signaled LSPs and LDP-Signaled LSPs
Enter the ping mpls command with the following syntax:
user@host> ping mpls (ldp fec | lsp-end-point prefix-name | rsvp lsp-name)

<exp forwarding-class> <count number> <source source-address> <detail>
Table 125 on page 557 describes the ping mpls command options.
Table 125: CLI ping mpls ldp and ping mpls lsp-end-point Command Options
Option Description
ldp fec Pings an LDP-signaled LSP identified by the forwarding equivalence class (FEC) prefix and length.
lsp-end-point prefix-name Pings an LSP endpoint using either an LDP FEC or a RSVP LSP endpoint address.
rsvp lsp-name Pings an RSVP-signaled LSP identified by the specified LSP name.
press Ctrl-C.
To quit the ping mpls command, press Ctrl-C.
The following is sample output from a ping mpls command:
user@host> ping mpls rsvp count 5
!!xxx
3 packets received with error status, not counted as received.
diagnostic tool.

Documentation


CHAPTER 33
Using Packet Capture to Analyze Network

Traffic
• Packet Capture Overview on page 559

• Example: Enabling Packet Capture on a Device on page 562
• Example: Configuring Packet Capture on an Interface on page 565
• Example: Configuring a Firewall Filter for Packet Capture on page 567
• Example: Configuring Packet Capture for Datapath Debugging on page 569
• Disabling Packet Capture on page 572
• Deleting Packet Capture Files on page 573
• Changing Encapsulation on Interfaces with Packet Capture Configured on page 574
• Displaying Packet Headers on page 575
• J-Web Packet Capture Results and Output Summary on page 582
Packet Capture Overview
Packet capture is a tool that helps you to analyze network traffic and troubleshoot
network problems. The packet capture tool captures real-time data packets traveling
over the network for monitoring and logging.
NOTE: Packet capture is supported on physical interfaces, reth interfaces,

and tunnel interfaces, such as gr, ip, st0, and lsq-/ls.
Packets are captured as binary data, without modification. You can read the packet
information offline with a packet analyzer such as Ethereal or tcpdump. If you need to
quickly capture packets destined for, or originating from, the Routing Engine and analyze
them online, you can use the J-Web packet capture diagnostic tool.

NOTE: The packet capture tool does not support IPv6 packet capture.
You can use either the J-Web configuration editor or CLI configuration editor
to configure packet capture.
Network administrators and security engineers use packet capture to perform the
following tasks:
• Monitor network traffic and analyze traffic patterns.
• Identify and troubleshoot network problems.
• Detect security breaches in the network, such as unauthorized intrusions, spyware

activity, or ping scans.
Packet capture operates like traffic sampling on the device, except that it captures entire
packets including the Layer 2 header and saves the contents to a file in libpcap format.
Packet capture also captures IP fragments. You cannot enable packet capture and traffic
sampling on the device at the same time. Unlike traffic sampling, there are no tracing
operations for packet capture.
NOTE: You can enable packet capture and port mirroring simultaneously on
a device.
• Packet Capture on Device Interfaces on page 560

• Firewall Filters for Packet Capture on page 561
• Packet Capture Files on page 561
• Analysis of Packet Capture Files on page 561
Packet Capture on Device Interfaces

Packet capture is supported on the T1, T3, E1, E3, serial, Fast Ethernet, ADSL, G.SHDSL,
PPPoE, and ISDN interfaces.
To capture packets on an ISDN interface, configure packet capture on the dialer interface.
To capture packets on a PPPoE interface, configure packet capture on the PPPoE logical
interface.
Packet capture supports PPP, Cisco HDLC, Frame Relay, and other ATM encapsulations.
Packet capture also supports Multilink PPP (MLPPP), Multilink Frame Relay end-to-end
(MLFR), and Multilink Frame Relay UNI/NNI (MFR) encapsulations.
You can capture all IPv4 packets flowing on an interface in the inbound or outbound
direction. However, on traffic that bypasses the flow software module (protocol packets
such as ARP, OSPF, and PIM), packets generated by the Routing Engine are not captured
unless you have configured and applied a firewall filter on the interface in the outbound
direction.

Chapter 33: Using Packet Capture to Analyze Network Traffic
Tunnel interfaces can support packet capture in the outbound direction only.
Use the J-Web configuration editor or CLI configuration editor to specify the maximum
packet size, the filename to be used for storing the captured packets, the maximum file
size, the maximum number of packet capture files, and the file permissions.
NOTE: For packets captured on T1, T3, E1, E3, serial, and ISDN interfaces in
the outbound (egress) direction, the size of the packet captured might be
1 byte less than the maximum packet size configured because of the packet
loss priority (PLP) bit.
To modify encapsulation on an interface that has packet capture configured, you must
first disable packet capture.
Firewall Filters for Packet Capture

When you enable packet capture on a device, all packets flowing in the direction specified
in packet capture configuration (inbound, outbound, or both) are captured and stored.
Configuring an interface to capture all packets might degrade the performance of the
device. You can control the number of packets captured on an interface with firewall
filters and specify various criteria to capture packets for specific traffic flows.
You must also configure and apply appropriate firewall filters on the interface if you need
to capture packets generated by the host device, because interface sampling does not
capture packets originating from the host device.
Packet Capture Files

When packet capture is enabled on an interface, the entire packet including the Layer 2
header is captured and stored in a file. You can specify the maximum size of the packet
to be captured, up to 1500 bytes. Packet capture creates one file for each physical
interface. You can specify the target filename, the maximum size of the file, and the
maximum number of files.
File creation and storage take place in the following way. Suppose you name the packet
capture file pcap-file. Packet capture creates multiple files (one per physical interface),
suffixing each file with the name of the physical interface; for example, pcap-file.fe-0.0.1
for the Fast Ethernet interface fe-0.0.1. When the file named pcap-file.fe-0.0.1 reaches
the maximum size, the file is renamed pcap-file.fe-0.0.1.0. When the file named
pcap-file.fe-0.0.1 reaches the maximum size again, the file named pcap-file.fe-0.0.1.0 is
renamed pcap-file.fe-0.0.1.1 and pcap-file.fe-0.0.1 is renamed pcap-file.fe-0.0.1.0. This
process continues until the maximum number of files is exceeded and the oldest file is
overwritten. The pcap-file.fe-0.0.1 file is always the latest file.
Packet capture files are not removed even after you disable packet capture on an interface.
Analysis of Packet Capture Files

Packet capture files are stored in libpcap format in the /var/tmp directory. You can specify
user or administrator privileges for the files.

Packet capture files can be opened and analyzed offline with tcpdump or any packet
analyzer that recognizes the libpcap format. You can also use FTP or the Session Control
Protocol (SCP) to transfer the packet capture files to an external device.
NOTE: Disable packet capture before opening the file for analysis or
transferring the file to an external device with FTP or SCP. Disabling packet
capture ensures that the internal file buffer is flushed and all the captured
packets are written to the file.
Related • Example: Enabling Packet Capture on a Device on page 562

Documentation
Example: Enabling Packet Capture on a Device
This example shows how to enable packet capture on a device, allowing you to analyze
network traffic and troubleshoot network problems

Requirements
Before you begin:
Overview
In this example, you set the maximum packet capture size in each file as 500 bytes. The
range is from 68 through 1500, and the default is 68 bytes. You specify the target filename
for the packet capture file as pcap-file. You then specify the maximum number of files
to capture as 100. The range is from 2 through 10,000, and the default is 10 files. You set
the maximum size of each file to 1024 bytes. The range is from 1,024 through 104,857,600,
and the default is 512,000 bytes. Finally, you specify that all users have permission to
read the packet capture files.

Configuration
set forwarding-options packet-capture maximum-capture-size 500

set forwarding-options packet-capture file filename pcap-file files 100 size 1024
world-readable
Mode.
To enable packet capture on a device:
1. Set the maximum packet capture size.
[edit]
user@host# edit forwarding-options
user@host# set packet-capture maximum-capture-size 500
2. Specify the target filename.
[edit forwarding-options]
user@host# set packet-capture file filename pcap-file
3. Specify the maximum number of files to capture.
user@host# set packet-capture file files 100
4. Specify the maximum size of each file.
user@host# set packet-capture file size 1024
5. Specify that all users have permission to read the file.
user@host# set packet-capture file world-readable
Results From configuration mode, confirm your configuration by entering the show
forwarding-options command. If the output does not display the intended configuration,
[edit]
user@host# show forwarding-options
packet-capture {
file filename pcap-file files 100 size 1k world-readable;
}

Verification
• Verifying the Packet Capture Configuration on page 564

• Verifying Captured Packets on page 564
Verifying the Packet Capture Configuration
Purpose Verify that the packet capture is configured on the device.
Action From configuration mode, enter the show forwarding-options command. Verify that the
output shows the intended file configuration for capturing packets.
Verifying Captured Packets
Purpose Verify that the packet capture file is stored under the /var/tmp directory and the packets
can be analyzed offline.
Action 1. Disable packet capture.
Using FTP, transfer a packet capture file (for example, 126b.fe-0.0.1), to a server where
you have installed packet analyzer tools (for example, tools-server).
a. From configuration mode, connect to tools-server using FTP.
[edit]
user@host# run ftp tools-server
Connected to tools-server.mydomain.net
220 tools-server.mydomain.net FTP server (Version 6.00LS) ready
Name (tools-server:user):remoteuser
331 Password required for remoteuser.
Password:
230 User remoteuser logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
b. Navigate to the directory where packet capture files are stored on the device.
ftp> lcd /var/tmp

Local directory now /cf/var/tmp
c. Copy the packet capture file that you want to analyze to the server, for example
126b.fe-0.0.1.
ftp> put 126b.fe-0.0.1

local: 126b.fe-0.0.1 remote: 126b.fe-0.0.1
200 PORT command successful.
150 Opening BINARY mode data connection for '126b.fe-0.0.1'.
100% 1476 00:00 ETA
226 Transfer complete.
1476 bytes sent in 0.01 seconds (142.42 KB/s)

d. Return to configuration mode.
ftp> bye
221 Goodbye.
[edit]
user@host#
2. Open the packet capture file on the server with tcpdump or any packet analyzer that
supports libpcap format and review the output.
root@server% tcpdump -r 126b.fe-0.0.1 -xevvvv
01:12:36.279769 Out 0:5:85:c4:e3:d1 > 0:5:85:c8:f6:d1, ethertype IPv4 (0x0800),

length 98: (tos 0x0, ttl 64, id 33133, offset 0, flags [none], proto: ICMP (1),
length: 84) 14.1.1.1 > 15.1.1.1: ICMP echo request seq 0, length 64
0005 85c8 f6d1 0005 85c4 e3d1 0800 4500
0054 816d 0000 4001 da38 0e01 0101 0f01
0101 0800 3c5a 981e 0000 8b5d 4543 51e6
0100 aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000
01:12:36.279793 Out 0:5:85:c8:f6:d1 > 0:5:85:c4:e3:d1, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 63, id 41227, offset 0, flags [none], proto: ICMP (1),
length: 84) 15.1.1.1 > 14.1.1.1: ICMP echo reply seq 0, length 64
0005 85c4 e3d1 0005 85c8 f6d1 0800 4500
0054 a10b 0000 3f01 bb9a 0f01 0101 0e01
0101 0000 445a 981e 0000 8b5d 4543 51e6
0100 aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000
root@server%
Related • Packet Capture Overview on page 559

Documentation
Example: Configuring Packet Capture on an Interface
This example shows how to configure packet capture on an interface to analyze traffic.


Requirements
Before you begin:
Overview
In this example, you create an interface called fe-0/0/1. You then configure the direction
of the traffic for which you are enabling packet capture on the logical interface as inbound
and outbound.
NOTE: On traffic that bypasses the flow software module (protocol packets
such as ARP, OSPF, and PIM), packets generated by the Routing Engine are
not captured unless you have configured and applied a firewall filter on the
interface in the output direction.
Configuration
edit interfaces fe-0/0/1

set unit 0 family inet sampling input output
Mode.
To configure packet capture on an interface:
1. Create an interface.
[edit]
user@host# edit interfaces fe-0/0/1
2. Configure the direction of the traffic.

user@host# set unit 0 family inet sampling input output
3. If you are done configuring the device, commit the configuration.
[edit]
user@host# commit

Verification
Verifying the Packet Capture Configuration
Verify that packet capture is configured on the interface.
Action From configuration mode, enter the show interfaces fe-0/0/1 command.

Documentation
Example: Configuring a Firewall Filter for Packet Capture
This example shows how to configure a firewall filter for packet capture and apply it to
a logical interface.

Requirements
Before you begin:
Overview
In this example, you set a firewall filter called dest-all and a term name called dest-term
to capture packets from a specific destination address, which is 192.168.1.1/32. You define
the match condition to accept the sampled packets. Finally, you apply the dest-all filter
to all of the outgoing packets on interface fe-0/0/1.

NOTE: If you apply a firewall filter on the loopback interface, it affects all
traffic to and from the Routing Engine. If the firewall filter has a sample action,
packets to and from the Routing Engine are sampled. If packet capture is
enabled, then packets to and from the Routing Engine are captured in the
files created for the input and output interfaces.
Configuration
set firewall filter dest-all term dest-term from destination-address 192.168.1.1/32

set firewall filter dest-all term dest-term then sample accept
edit interfaces
set interfaces fe-0/0/1 unit 0 family inet filter output dest-all
To configure a firewall filter for packet capture and apply it to a logical interface:
1. Specify the firewall filter and its destination address.
[edit]
user@host# edit firewall
user@host# set filter dest-all term dest-term from destination-address 192.168.1.1/32
2. Define the match condition and its action.
[edit firewall]
user@host# set filter dest-all term dest-term then sample accept
3. Apply the filter to all the outgoing packets.
[edit interfaces]
user@host# set interfaces fe-0/0/1 unit 0 family inet filter output dest-all
Results From configuration mode, confirm your configuration by entering the show firewall filter
dest-all command. If the output does not display the intended configuration, repeat the
[edit]
user@host# show firewall filter dest-all
term dest-term {
from {
destination-address 192.168.1.1/32;
}
then {
sample;
accept;

}
}
Verification
Verifying the Firewall Filter for Packet Capture Configuration
Verify that the firewall filter for packet capture is configured.
Action From configuration mode, enter the show firewall filter dest-all command. Verify that the
output shows the intended configuration of the firewall filter for capturing packets sent
to the destination address.

Documentation
Example: Configuring Packet Capture for Datapath Debugging
This example shows how to configure packet capture to monitor traffic that passes
through the device. Packet capture then dumps the packets into a PCAP file format that
can be later examined by the tcpdump utility.

Requirements
Before you begin, see “Debugging the Data Path (CLI Procedure)” on page 524.
Overview
A filter is defined to filter traffic; then an action profile is applied to the filtered traffic.
The action profile specifies a variety of actions on the processing unit. One of the
supported actions is packet dump, which sends the packet to the Routing Engine and
stores it in proprietary form to be read using the show security datapath-debug capture
command.

Configuration
set security datapath-debug capture-file my-capture

set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 1m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 400
set security datapath-debug action-profile do-capture event np-ingress packet-dump
set security datapath-debug packet-filter my-filter action-profile do-capture
set security datapath-debug packet-filter my-filter source-prefix 1.2.3.4/32
Modein the CLI User Guide.
To configure packet capture:
1. Edit the security datapath-debug option for the multiple processing units along the
packet-processing path:
[edit]
user@host# edit security datapath-debug
2. Enable the capture file, the file format, the file size, and the number of files. Size
number limits the size of the capture file. After the limit size is reached, if the file
number is specified, then the capture file will be rotated to filename x, where x is
auto-incremented until it reaches the specified index and then returns to zero. If no
files index is specified, the packets will be discarded after the size limit is reached.
The default size is 512 kilobytes.

user@host# set capture-file my-capture format pcap size 1m files 5
user@host# set maximum-capture-size 400
3. Enable action profile and set the event. Set the action profile as do-capture and
the event type as np-ingress:

user@host# edit action-profile do-capture
[edit security datapath-debug action-profile do-capture]
user@host# edit event np-ingress
4. Enable packet dump for the action profile:
[edit security datapath-debug action-profile do-capture event np-ingress]

user@host# set packet-dump
5. Enable packet filter, action, and filter options. The packet filter is set to my-filter,
the action profile is set to do-capture, and filter option is set to source-prefix
1.2.3.4/32.


user@host# set security datapath-debug packet-filter my-filter action-profile
do-capture

user@host# set security datapath-debug packet-filter my-filter source-prefix
1.2.3.4/32
Results From configuration mode, confirm your configuration by entering the show security
datapath-debug command. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it. The following isshow
security datapath-debug output from the show security datapath-debug command:
security {
datapath-debug {
capture-file {
my-capture
format pcap
size 1m
files 5;
}
}
action-profile do-capture {
event np-ingress {
packet-dump
}
}
packet-filter my-filter {
source-prefix 1.2.3.4/32
action-profile do-capture
}
}
Verification
• Verifying Packet Capture on page 571

• Verifying Data Path Debugging Capture on page 572
• Verifying Data Path Debugging Counter on page 572
Verifying Packet Capture
Purpose Verify if the packet capture is working.
Action From operational mode, enter the request security datapath-debug capture start command
to start packet capture and enter the request security datapath-debug capture stop
command to stop packet capture.

To view the results, from CLI operational mode, access the local UNIX shell and navigate
to the directory /var/log/my-capture. The result can be read by using the tcpdump utility.
Verifying Data Path Debugging Capture
Purpose Verify the details of data path debugging capture file.
Action From operational mode, enter the show security datapath-debug capture command.
user@host>show security datapath-debug capture
WARNING: When you are done troubleshooting, make sure to remove or

deactivate all the traceoptions configurations (not limited to flow
traceoptions) and the complete security datapath-debug configuration
stanza. If any debugging configurations remain active, they will continue to
use the device's CPU and memory resources.
Verifying Data Path Debugging Counter
Purpose Verify the details of the data path debugging counter.
Action From operational mode, enter the show security datapath-debug counter command.

Documentation
• Understanding Data Path Debugging for SRX Series Devices on page 523
Disabling Packet Capture
You must disable packet capture before opening the packet capture file for analysis or
transferring the file to an external device. Disabling packet capture ensures that the
internal file buffer is flushed and all the captured packets are written to the file.
To disable packet capture, enter from configuration mode:
user@host# set packet-capture disable

Documentation

Deleting Packet Capture Files
Deleting packet capture files from the /var/tmp directory only temporarily removes the
packet capture files. Packet capture files for the interface are automatically created
again the next time a packet capture configuration change is committed or as part of a
packet capture file rotation.
To delete a packet capture file:
1. Disable packet capture (see “Disabling Packet Capture” on page 572).
2. Delete the packet capture file for the interface.
a. From operational mode, access the local UNIX shell.
user@host> start shell

%
b. Navigate to the directory where packet capture files are stored.
% cd /var/tmp
%
c. Delete the packet capture file for the interface; for example pcap-file.fe.0.0.0.
% rm pcap-file.fe.0.0.0
%
d. Return to operational mode.
% exit
user@host>
3. Reenable packet capture (see “Example: Enabling Packet Capture on a Device” on

page 562).

Documentation

Changing Encapsulation on Interfaces with Packet Capture Configured
Before modifying the encapsulation on a device interface that is configured for packet
capture, you must disable packet capture and rename the latest packet capture file.
Otherwise, packet capture saves the packets with different encapsulations in the same
packet capture file. Packet files containing packets with different encapsulations are not
useful, because packet analyzer tools like tcpdump cannot analyze such files.
After modifying the encapsulation, you can safely reenable packet capture on the device.
To change the encapsulation on interfaces with packet capture configured:
1. Disable packet capture (see “Disabling Packet Capture” on page 572).
2. Enter commit from configuration mode.
3. Rename the latest packet capture file on which you are changing the encapsulation
with the .chdsl extension.
a. From operational mode, access the local UNIX shell.
user@host> start shell

%
b. Navigate to the directory where packet capture files are stored.
% cd /var/tmp
%
c. Rename the latest packet capture file for the interface on which you are changing
the encapsulation; for example fe.0.0.0.
% mv pcap-file.fe.0.0.0 pcap-file.fe.0.0.0.chdsl
%
d. Return to operational mode.
% exit
user@host>
4. Change the encapsulation on the interface using the J-Web user interface or CLI
configuration editor.
6. Reenable packet capture (see “Example: Enabling Packet Capture on a Device” on

page 562).

Documentation

Displaying Packet Headers
Enter the monitor traffic command to display packet headers transmitted through network
interfaces with the following syntax:
NOTE: Using the monitor traffic command can degrade system performance.
We recommend that you use filtering options—such as count and matching—to
minimize the impact to packet throughput on the system.
user@host> monitor traffic <absolute-sequence> <count number>

<interface interface-name> <layer2-headers> <matching "expression">
<no-domain-names> <no-promiscuous> <no-resolve> <no-timestamp> <print-ascii>
<print-hex> <size bytes> <brief | detail | extensive>
Table 126 on page 575 describes the monitor traffic command options.
Table 126: CLI monitor traffic Command Options

Option Description
absolute-sequence (Optional) Displays the absolute TCP sequence numbers.
count number (Optional) Displays the specified number of packet headers. Specify
a value from 0 through 100,000. The command quits and exits to
the command prompt after this number is reached.
interface interface-name (Optional) Displays packet headers for traffic on the specified
interface. If an interface is not specified, the lowest numbered
interface is monitored.
layer2-headers (Optional) Displays the link-layer packet header on each line.
matching "expression" (Optional) Displays packet headers that match an expression

enclosed in quotation marks (" "). Table 127 on page 577 through
Table 129 on page 578 list match conditions, logical operators, and
arithmetic, binary, and relational operators you can use in the
expression.
no-domain-names (Optional) Suppresses the display of the domain name portion of

the hostname.
no-promiscuous (Optional) Specifies not to place the monitored interface in

promiscuous mode.
In promiscuous mode, the interface reads every packet that reaches

it. In nonpromiscuous mode, the interface reads only the packets
addressed to it.

Table 126: CLI monitor traffic Command Options (continued)

Option Description
no-resolve (Optional) Suppresses the display of hostnames.
no-timestamp (Optional) Suppresses the display of packet header timestamps.
print-ascii (Optional) Displays each packet header in ASCII format.
print-hex (Optional) Displays each packet header, except link-layer headers,

in hexadecimal format.
size bytes (Optional) Displays the number of bytes for each packet that you
specify. If a packet header exceeds this size, the displayed packet
header is truncated. The default value is 96.
brief (Optional) Displays minimum packet header information. This is

the default.
detail (Optional) Displays packet header information in moderate detail.

For some protocols, you must also use the size option to see detailed
information.
extensive (Optional) Displays the most extensive level of packet header

information. For some protocols, you must also use the size option
to see extensive information.
To quit the monitor traffic command and return to the command prompt, press Ctrl-C.
To limit the packet header information displayed by the monitor traffic command, include
the matching "expression" option. An expression consists of one or more match conditions
listed in Table 127 on page 577, enclosed in quotation marks (" "). You can combine match
conditions by using the logical operators listed in Table 128 on page 578 (shown in order
of highest to lowest precedence).
For example, to display TCP or UDP packet headers, enter:
user@host> monitor traffic matching “tcp || udp”
To compare the following types of expressions, use the relational operators listed in
Table 129 on page 578 (listed from highest to lowest precedence):
• Arithmetic—Expressions that use the arithmetic operators listed in Table 129 on page 578.
• Binary—Expressions that use the binary operators listed in Table 129 on page 578.
• Packet data accessor—Expressions that use the following syntax:
protocol [byte-offset <size>]
Replace protocol with any protocol in Table 127 on page 577. Replace byte-offset with
the byte offset, from the beginning of the packet header, to use for the comparison.
The optional size parameter represents the number of bytes examined in the packet
header—1, 2, or 4 bytes.

For example, the following command displays all multicast traffic:
user@host> monitor traffic matching “ether[0] & 1 !=0”
Table 127: CLI monitor traffic Match Conditions

Match Condition Description
Entity Type
host [address | hostname] Matches packet headers that contain the specified address or hostname. You can
preprend any of the following protocol match conditions, followed by a space, to host:
arp, ip, rarp, or any of the Directional match conditions.
network address Matches packet headers with source or destination addresses containing the specified
network address.
network address mask mask Matches packet headers containing the specified network address and subnet mask.
port [port-number | port-name] Matches packet headers containing the specified source or destination TCP or UDP
port number or port name.
Directional
destination Matches packet headers containing the specified destination. Directional match
conditions can be prepended to any Entity Type match conditions, followed by a space.
source Matches packet headers containing the specified source.
source and destination Matches packet headers containing the specified source and destination.
source or destination Matches packet headers containing the specified source or destination.
Packet Length
less bytes Matches packets with lengths less than or equal to the specified value, in bytes.
greater bytes Matches packets with lengths greater than or equal to the specified value, in bytes.
Protocol
arp Matches all ARP packets.
ether Matches all Ethernet frames.
ether [broadcast | multicast] Matches broadcast or multicast Ethernet frames. This match condition can be prepended
with source or destination.
ether protocol [address | (\arp | \ip | Matches Ethernet frames with the specified address or protocol type. The arguments
\rarp) arp, ip, and rarp are also independent match conditions, so they must be preceded with
a backslash (\) when used in the ether protocol match condition.
icmp Matches all ICMP packets.
ip Matches all IP packets.

Table 127: CLI monitor traffic Match Conditions (continued)

Match Condition Description
ip [broadcast | multicast] Matches broadcast or multicast IP packets.
ip protocol [address | (\icmp | igrp | Matches IP packets with the specified address or protocol type. The arguments icmp,
\tcp | \udp)] tcp, and udp are also independent match conditions, so they must be preceded with a
backslash (\) when used in the ip protocol match condition.
isis Matches all IS-IS routing messages.
rarp Matches all RARP packets.
tcp Matches all TCP packets.
udp Matches all UDP packets.
Table 128: CLI monitor traffic Logical Operators

Logical
Operator Description
! Logical NOT. If the first condition does not match, the next condition is
evaluated.
&& Logical AND. If the first condition matches, the next condition is evaluated. If
the first condition does not match, the next condition is skipped.
|| Logical OR. If the first condition matches, the next condition is skipped. If the
first condition does not match, the next condition is evaluated.
() Group operators to override default precedence order. Parentheses are special

characters, each of which must be preceded by a backslash (\).
Table 129: CLI monitor traffic Arithmetic, Binary, and Relational Operators
Arithmetic Operator
+ Addition operator.
– Subtraction operator.
/ Division operator.
Binary Operator
& Bitwise AND.
* Bitwise exclusive OR.

Table 129: CLI monitor traffic Arithmetic, Binary, and Relational

Operators (continued)
| Bitwise inclusive OR.
Relational Operator
<= A match occurs if the first expression is less than or equal to the second.
>= A match occurs if the first expression is greater than or equal to the second.
< A match occurs if the first expression is less than the second.
> A match occurs if the first expression is greater than the second.
= A match occurs if the first expression is equal to the second.
!= A match occurs if the first expression is not equal to the second.
The following is sample output from the monitor traffic command:
user@host> monitor traffic count 4 matching “arp” detail
Listening on fe-0/0/0, capture size 96 bytes 15:04:16.276780 In arp who-has

193.1.1.1 tell host1.site2.net 15:04:16.376848 In arp who-has host2.site2.net
tell host1.site2.net 15:04:16.376887 In arp who-has 193.1.1.2 tell host1.site2.net
15:04:16.601923 In arp who-has 193.1.1.3 tell host1.site2.net

Documentation
Using the J-Web Packet Capture Tool
You can use the J-Web packet capture diagnostic tool when you need to quickly capture
and analyze router control traffic on a device. Packet capture on the J-Web user interface
allows you to capture traffic destined for, or originating from, the Routing Engine. You
can use the J-Web packet capture tool to compose expressions with various matching
criteria to specify the packets that you want to capture. You can either choose to decode
and view the captured packets in the J-Web user interface as they are captured, or save
the captured packets to a file and analyze them offline using packet analyzers such as
Ethereal. The J-Web packet capture tool does not capture transient traffic.
To capture transient traffic and entire IPv4 data packets for offline analysis, you must
configure packet capture with the J-Web user interface or CLI configuration editor.

To use J-Web packet capture:
1. Select Troubleshoot>Packet Capture.
2. Enter information into the Packet Capture page (see Table 130 on page 580). The
sample configuration captures the next 10 TCP packets originating from the IP address
10.1.40.48 on port 23 and passing through the Gigabit Ethernet interface ge-0/0/0.
3. Save the captured packets to a file, or specify other advanced options by clicking the
expand icon next to Advanced options.
4. Click Start.
The captured packet headers are decoded and appear in the Packet Capture display.
5. Do one of the following:
• To stop capturing the packets and stay on the same page while the decoded packet
headers are being displayed, click Stop Capturing.
• To stop capturing packets and return to the Packet Capture page, click OK.
Table 130: Packet Capture Field Summary

Interface Specifies the interface on which the packets are Select an interface from the list—for example,
captured. ge-0/0/0.
If you select default, packets on the Ethernet

management port 0 are captured.
Detail level Specifies the extent of details to be displayed for the Select Detail from the list.
packet headers.
• Brief—Displays the minimum packet header

information. This is the default.
• Detail—Displays packet header information in
moderate detail.
• Extensive—Displays the maximum packet header
information.
Packets Specifies the number of packets to be captured. Select the number of packets to be captured from
Values range from 1 to 1000. Default is 10. Packet the list—for example, 10.
capture stops capturing packets after this number
is reached.
Addresses Specifies the addresses to be matched for capturing Select address-matching criteria. For example:
the packets using a combination of the following
parameters: 1. From the Direction list, select source.
2. From the Type list, select host.

• Direction—Matches the packet headers for IP
address, hostname, or network address of the 3. In the Address box, type 10.1.40.48.
source, destination or both.
4. Click Add.
• Type—Specifies if packet headers are matched
for host address or network address.
You can add multiple entries to refine the match

criteria for addresses.

Table 130: Packet Capture Field Summary (continued)

Protocols Matches the protocol for which packets are captured. Select a protocol from the list—for example, tcp.
You can choose to capture TCP, UDP, or ICMP
packets or a combination of TCP, UDP, and ICMP
packets.
Ports Matches packet headers containing the specified Select a direction and a port. For example:
source or destination TCP or UDP port number or
port name. 1. From the Type list, select src.
2. In the Port box, type 23.
Advanced Options
Absolute TCP Specifies that absolute TCP sequence numbers are • Display absolute TCP sequence numbers in the
Sequence to be displayed for the packet headers. packet headers by selecting this check box.
• Stop displaying absolute TCP sequence numbers
in the packet headers by clearing this check box.
Layer 2 Headers Specifies that link-layer packet headers to display. • Include link-layer packet headers while capturing
packets, by selecting this check box.
• Exclude link-layer packet headers while capturing
packets by clearing this check box.
Non-Promiscuous Specifies not to place the interface in promiscuous • Read all packets that reach the interface by
mode, so that the interface reads only packets selecting this check box.
addressed to it. • Read only packets addressed to the interface by
clearing this check box.
In promiscuous mode, the interface reads every
packet that reaches it.
Display Hex Specifies that packet headers, except link-layer • Display the packet headers in hexadecimal format
headers, are to be displayed in hexadecimal format. by selecting this check box.
• Stop displaying the packet headers in hexadecimal
format by clearing this check box.
Display ASCII Specifies that packet headers are to be displayed in • Display the packet headers in ASCII and
and Hex hexadecimal and ASCII format. hexadecimal formats by selecting this check box.
• Stop displaying the packet headers in ASCII and
hexadecimal formats by clearing this check box.
Header Specifies the match condition for the packets to Enter match conditions in expression format or
Expression capture. modify the expression composed from the match
conditions you specified for Addresses, Protocols,
The match conditions you specify for Addresses, and Ports. If you change the match conditions
Protocols, and Ports appear in expression format in specified for Addresses, Protocols, and Ports again,
this field. packet capture overwrites your changes with the
new match conditions.
Packet Size Specifies the number of bytes to be displayed for Type the number of bytes you want to capture for
each packet. If a packet header exceeds this size, each packet header—for example, 256.
the display is truncated for the packet header. The
default value is 96 bytes.

Table 130: Packet Capture Field Summary (continued)

Don't Resolve Specifies that IP addresses are not to be resolved • Prevent packet capture from resolving IP
Addresses into hostnames in the packet headers displayed. addresses to hostnames by selecting this check
box.
• Resolve IP addresses into hostnames by clearing
this check box.
No Timestamp Suppresses the display of packet header • Stop displaying timestamps in the captured
timestamps. packet headers by selecting this check box.
• Display the timestamp in the captured packet
headers by clearing this check box.
Write Packet Writes the captured packets to a file in PCAP format • Save the captured packet headers to a file by
Capture File in /var/tmp. The files are named with the prefix selecting this check box.
jweb-pcap and the extension .pcap. • Decode and display the packet headers on the
J-Web page by clearing this check box.
If you select this option, the decoded packet headers
do not appear on the packet capture page.

Documentation
• J-Web Packet Capture Results and Output Summary on page 582
J-Web Packet Capture Results and Output Summary
Table 131 on page 582 summarizes the output in the packet capture display.
Table 131: J-Web Packet Capture Results and Output Summary

Field Description
timestamp Time when the packet was captured. The timestamp 00:45:40.823971 means 00 hours (12.00 a.m.), 45
minutes, and 40.823971 seconds.
NOTE: The time displayed is local time.
direction Direction of the packet. Specifies whether the packet originated from the Routing Engine (Out), or was
destined for the Routing Engine (In).
protocol Protocol for the packet.
In the sample output, IP indicates the Layer 3 protocol.

Table 131: J-Web Packet Capture Results and Output Summary (continued)
Field Description
source address Hostname, if available, or IP address and the port number of the packet's origin. If the Don't Resolve
Addresses check box is selected, only the IP address of the source displays.
NOTE: When a string is defined for the port, the packet capture output displays the string instead of the
port number.
destination address Hostname, if available, or IP address of the packet's destination with the port number. If the Don't Resolve
Addresses check box is selected, only the IP address of the destination and the port appear.
NOTE: When a string is defined for the port, the packet capture output displays the string instead of the
port number.
protocol Protocol for the packet.
In the sample output, TCP indicates the Layer 4 protocol.
data size Size of the packet (in bytes).

Documentation


CHAPTER 34
Troubleshooting Security Devices
• Recovering the Root Password for SRX Series Devices on page 585
• Troubleshooting DNS Name Resolution in Logical System Security Policies (Master
Administrators Only) on page 587
• Troubleshooting the Link Services Interface on page 587
• Troubleshooting Security Policies on page 597
• Understanding Log Error Messages for Troubleshooting ISSU-Related
Problems on page 599
Recovering the Root Password for SRX Series Devices
If you forget the root password for an SRX Series device, you can use the password
recovery procedure to reset the root password. This procedure also involves disabling
the watchdog functionality to allow the system to properly boot into single-user mode
(KB article 17565).
NOTE: You need console access to recover the root password
To recover the root password for an SRX Series device:
1. Power on the device by pressing the power button on the front panel. Verify that the
POWER LED on the front panel turns green.
The device’s boot sequence on your management device appears on the terminal
emulation screen.
2. When the autoboot completes, press the Spacebar a few times to access the bootstrap
loader prompt.
3. In operational mode, disable the watchdog functionality and enter boot -s to start up
the system in single-user mode.
loader>boot -s

NOTE: For SRX1500 Series device, the following prompt appears instead
of loader prompt.
OK boot -s.
The SRX Series device will start up in single-user mode.
4. Enter recovery to start the root password recovery procedure.
System watchdog timer disabled.

Enter full pathname of shell or 'recovery' for root password recovery or RETURN for
/bin/sh: recovery
5. Enter configuration mode in the CLI.
6. Set the root password.
[edit]
user@host# set system root-authentication plain-text-password
7. Enter the new root password.
New password: juniper1

Retype new password:
8. At the second prompt, reenter the new root password.
9. If you are finished configuring the network, commit the configuration.
root@host# commit
commit complete
10. Exit from configuration mode.
11. Exit from operational mode.
12. Enter y to reboot the device.
Reboot the system? [y/n] y
The start up messages display on the screen.
13. Once again, press the Spacebar a few times to access the bootstrap loader prompt.
14. In operational mode, enable the watchdog functionality and enter boot to start up
the system.
loader>watchdog enable
loader>boot
15. The SRX Series device starts up again and prompts you to enter a user name and
password. Enter the newly configured password:
Wed Jul 12 14:20:21 UTC 2011

Deviceabc (ttyu0)
login: root
Password: juniper1
Related • System Log Messages

Documentation

Chapter 34: Troubleshooting Security Devices
Troubleshooting DNS Name Resolution in Logical System Security Policies (Master

Administrators Only)
Problem Description: The address of a hostname in an address book entry that is used in a security
policy might fail to resolve correctly.
Cause Normally, address book entries that contain dynamic hostnames refresh automatically
for SRX Series devices. The TTL field associated with a DNS entry indicates the time after
which the entry should be refreshed in the policy cache. Once the TTL value expires, the
SRX Series device automatically refreshes the DNS entry for an address book entry.
However, if the SRX Series device is unable to obtain a response from the DNS server
(for example, the DNS request or response packet is lost in the network or the DNS server
cannot send a response), the address of a hostname in an address book entry might fail
to resolve correctly. This can cause traffic to drop as no security policy or session match
is found.
Solution The master administrator can use the show security dns-cache command to display DNS
cache information on the SRX Series device. If the DNS cache information needs to be
refreshed, the master administrator can use the clear security dns-cache command.
NOTE: These commands are only available to the master administrator on

devices that are configured for logical systems. This command is not available
in user logical systems or on devices that are not configured for logical
systems.
Related • Understanding Logical System Security Policies

Documentation
Troubleshooting the Link Services Interface
NOTE: Starting with Junos OS Release 15.1X49-D10, link services interfaces

are no longer supported on SRX300, SRX320, SRX340, and SRX1500 devices.
To solve configuration problems on a link services interface:
• Determine Which CoS Components Are Applied to the Constituent Links on page 588
• Determine What Causes Jitter and Latency on the Multilink Bundle on page 589

• Determine If LFI and Load Balancing Are Working Correctly on page 590
• Determine Why Packets Are Dropped on a PVC Between a Juniper Networks Device
and a Third-Party Device on page 596
Determine Which CoS Components Are Applied to the Constituent Links
Problem Description: You are configuring a multilink bundle, but you also have traffic without
MLPPP encapsulation passing through constituent links of the multilink bundle. Do you
apply all CoS components to the constituent links, or is applying them to the multilink
bundle enough?
Solution You can apply a scheduler map to the multilink bundle and its constituent links. Although
you can apply several CoS components with the scheduler map, configure only the ones
that are required. We recommend that you keep the configuration on the constituent
links simple to avoid unnecessary delay in transmission.
Table 132 on page 588 shows the CoS components to be applied on a multilink bundle
and its constituent links.
Table 132: CoS Components Applied on Multilink Bundles and Constituent Links
Multilink Constituent
Cos Component Bundle Links Explanation
Classifier Yes No CoS classification takes place on the incoming side of

the interface, not on the transmitting side, so no
classifiers are needed on constituent links.
Forwarding class Yes No Forwarding class is associated with a queue, and the
queue is applied to the interface by a scheduler map. The
queue assignment is predetermined on the constituent
links. All packets from Q2 of the multilink bundle are
assigned to Q2 of the constituent link, and packets from
all the other queues are queued to Q0 of the constituent
link.

Table 132: CoS Components Applied on Multilink Bundles and Constituent Links (continued)
Multilink Constituent
Cos Component Bundle Links Explanation
Scheduler map Yes Yes Apply scheduler maps on the multilink bundle and the
constituent link as follows:
• Transmit rate—Make sure that the relative order of the

transmit rate configured on Q0 and Q2 is the same on
the constituent links as on the multilink bundle.
• Scheduler priority—Make sure that the relative order
of the scheduler priority configured on Q0 and Q2 is
the same on the constituent links as on the multilink
bundle.
• Buffer size—Because all non-LFI packets from the
multilink bundle transit on Q0 of the constituent links,
make sure that the buffer size on Q0 of the constituent
links is large enough.
• RED drop profile—Configure a RED drop profile on the
multilink bundle only. Configuring the RED drop profile
on the constituent links applies a back pressure
mechanism that changes the buffer size and
introduces variation. Because this behavior might
cause fragment drops on the constituent links, make
sure to leave the RED drop profile at the default
settings on the constituent links.
Shaping rate for a per-unit No Yes Because per-unit scheduling is applied only at the end
scheduler or an point, apply this shaping rate to the constituent links only.
interface-level scheduler Any configuration applied earlier is overwritten by the
constituent link configuration.
Transmit-rate exact or Yes No The interface-level shaping applied on the constituent

queue-level shaping links overrides any shaping on the queue. Thus apply
transmit-rate exact shaping on the multilink bundle only.
Rewrite rules Yes No Rewrite bits are copied from the packet into the
fragments automatically during fragmentation. Thus
what you configure on the multilink bundle is carried on
the fragments to the constituent links.
Virtual channel group Yes No Virtual channel groups are identified through firewall
filter rules that are applied on packets only before the
multilink bundle. Thus you do not need to apply the
virtual channel group configuration to the constituent
links.
Determine What Causes Jitter and Latency on the Multilink Bundle
Problem Description: To test jitter and latency, you send three streams of IP packets. All packets
have the same IP precedence settings. After configuring LFI and CRTP, the latency
increased even over a noncongested link. How can you reduce jitter and latency?

Solution To reduce jitter and latency, do the following:
1. Make sure that you have configured a shaping rate on each constituent link.
2. Make sure that you have not configured a shaping rate on the link services interface.
3. Make sure that the configured shaping rate value is equal to the physical interface
bandwidth.
4. If shaping rates are configured correctly, and jitter still persists, contact the Juniper
Networks Technical Assistance Center (JTAC).
Determine If LFI and Load Balancing Are Working Correctly
Problem Description: In this case, you have a single network that supports multiple services. The
network transmits data and delay-sensitive voice traffic. After configuring MLPPP and
LFI, make sure that voice packets are transmitted across the network with very little delay
and jitter. How can you find out if voice packets are being treated as LFI packets and load
balancing is performed correctly?
Solution When LFI is enabled, data (non-LFI) packets are encapsulated with an MLPPP header
and fragmented to packets of a specified size. The delay-sensitive, voice (LFI) packets
are PPP-encapsulated and interleaved between data packet fragments. Queuing and
load balancing are performed differently for LFI and non-LFI packets.
To verify that LFI is performed correctly, determine that packets are fragmented and
encapsulated as configured. After you know whether a packet is treated as an LFI packet
or a non-LFI packet, you can confirm whether the load balancing is performed correctly.
Solution Scenario—Suppose two Juniper Networks devices, R0 and R1, are connected by
a multilink bundle lsq-0/0/0.0 that aggregates two serial links, se-1/0/0 and se-1/0/1.
On R0 and R1, MLPPP and LFI are enabled on the link services interface and the
fragmentation threshold is set to 128 bytes.
In this example, we used a packet generator to generate voice and data streams. You
can use the packet capture feature to capture and analyze the packets on the incoming
interface.
The following two data streams were sent on the multilink bundle:
• 100 data packets of 200 bytes (larger than the fragmentation threshold)
• 500 data packets of 60 bytes (smaller than the fragmentation threshold)
The following two voice streams were sent on the multilink bundle:
• 100 voice packets of 200 bytes from source port 100
• 300 voice packets of 200 bytes from source port 200

To confirm that LFI and load balancing are performed correctly:
NOTE: Only the significant portions of command output are displayed and
described in this example.
1. Verify packet fragmentation. From operational mode, enter the show interfaces
lsq-0/0/0 command to check that large packets are fragmented correctly.
user@R0#> show interfaces lsq-0/0/0

Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Interface index: 136, SNMP ifIndex: 29
Link-level type: LinkService, MTU: 1504
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42)

Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP
Bandwidth: 16mbps
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 0 0 0 0
Output: 1100 0 118800 0
Packets:
Input : 0 0 0 0
Output: 1000 0 112000 0
...
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 9.9.9/24, Local: 9.9.9.10
Meaning—The output shows a summary of packets transiting the device on the

multilink bundle. Verify the following information on the multilink bundle:
• The total number of transiting packets = 1000
• The total number of transiting fragments=1100
• The number of data packets that were fragmented =100
The total number of packets sent (600 + 400) on the multilink bundle match the
number of transiting packets (1000), indicating that no packets were dropped.
The number of transiting fragments exceeds the number of transiting packets by 100,
indicating that 100 large data packets were correctly fragmented.
Corrective Action—If the packets are not fragmented correctly, check your
fragmentation threshold configuration. Packets smaller than the specified
fragmentation threshold are not fragmented.
2. Verify packet encapsulation. To find out whether a packet is treated as an LFI or

non-LFI packet, determine its encapsulation type. LFI packets are PPP encapsulated,

and non-LFI packets are encapsulated with both PPP and MLPPP. PPP and MLPPP
encapsulations have different overheads resulting in different-sized packets. You can
compare packet sizes to determine the encapsulation type.
A small unfragmented data packet contains a PPP header and a single MLPPP header.
In a large fragmented data packet, the first fragment contains a PPP header and an
MLPPP header, but the consecutive fragments contain only an MLPPP header.
PPP and MLPPP encapsulations add the following number of bytes to a packet:
• PPP encapsulation adds 7 bytes:
4 bytes of header+2 bytes of frame check sequence (FCS)+1 byte that is idle or
contains a flag
• MLPPP encapsulation adds between 6 and 8 bytes:
4 bytes of PPP header+2 to 4 bytes of multilink header
Figure 10 on page 592 shows the overhead added to PPP and MLPPP headers.
Figure 10: PPP and MLPPP Headers
For CRTP packets, the encapsulation overhead and packet size are even smaller than
for an LFI packet. For more information, see Example: Configuring the Compressed
Real-Time Transport Protocol.
Table 133 on page 592 shows the encapsulation overhead for a data packet and a voice
packet of 70 bytes each. After encapsulation, the size of the data packet is larger than
the size of the voice packet.
Table 133: PPP and MLPPP Encapsulation Overhead

Packet Size
Initial after
Packet Type Encapsulation Packet Size Encapsulation Overhead Encapsulation
Voice packet (LFI) PPP 70 bytes 4 + 2 + 1 = 7 bytes 77 bytes
Data fragment (non-LFI) MLPPP 70 bytes 4 + 2 + 1 + 4 + 2 = 13 bytes 83 bytes

with short sequence

Table 133: PPP and MLPPP Encapsulation Overhead (continued)

Packet Size
Initial after
Packet Type Encapsulation Packet Size Encapsulation Overhead Encapsulation
Data fragment (non-LFI) MLPPP 70 bytes 4 + 2 + 1 + 4 + 4 = 15 bytes 85 bytes

with long sequence
From operational mode, enter the show interfaces queue command to display the size
of transmitted packet on each queue. Divide the number of bytes transmitted by the
number of packets to obtain the size of the packets and determine the encapsulation
type.
3. Verify load balancing. From operational mode, enter the show interfaces queue
command on the multilink bundle and its constituent links to confirm whether load
balancing is performed accordingly on the packets.
user@R0> show interfaces queue lsq-0/0/0

Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Forwarding classes: 8 supported, 8 in use
Egress queues: 8 supported, 8 in use
Queue: 0, Forwarding classes: DATA
Queued:
Packets : 600 0 pps
Bytes : 44800 0 bps
Transmitted:
Packets : 600 0 pps
Bytes : 44800 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
…
Queue: 1, Forwarding classes: expedited-forwarding
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
…
Queue: 2, Forwarding classes: VOICE
Queued:
Packets : 400 0 pps
Bytes : 61344 0 bps
Transmitted:
Packets : 400 0 pps
Bytes : 61344 0 bps
…
Queue: 3, Forwarding classes: NC
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
…
user@R0> show interfaces queue se-1/0/0

Physical interface: se-1/0/0, Enabled, Physical link is Up
Queued:

Packets : 350 0 pps

Bytes : 24350 0 bps
Transmitted:
Packets : 350 0 pps
Bytes : 24350 0 bps
...
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
…
Queued:
Packets : 100 0 pps
Bytes : 15272 0 bps
Transmitted:
Packets : 100 0 pps
Bytes : 15272 0 bps
…
Queued:
Packets : 19 0 pps
Bytes : 247 0 bps
Transmitted:
Packets : 19 0 pps
Bytes : 247 0 bps
…
user@R0> show interfaces queue se-1/0/1

Physical interface: se-1/0/1, Enabled, Physical link is Up
Queued:
Packets : 350 0 pps
Bytes : 24350 0 bps
Transmitted:
Packets : 350 0 pps
Bytes : 24350 0 bps
…
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
…
Queued:
Packets : 300 0 pps
Bytes : 45672 0 bps
Transmitted:
Packets : 300 0 pps
Bytes : 45672 0 bps
…
Queued:
Packets : 18 0 pps
Bytes : 234 0 bps
Transmitted:
Packets : 18 0 pps
Bytes : 234 0 bps

Meaning—The output from these commands shows the packets transmitted and
queued on each queue of the link services interface and its constituent links.
Table 134 on page 595 shows a summary of these values. (Because the number of
transmitted packets equaled the number of queued packets on all the links, this table
shows only the queued packets.)
Table 134: Number of Packets Transmitted on a Queue

Bundle Constituent Link Constituent Link
Packets Queued lsq-0/0/0.0 se-1/0/0 se-1/0/1 Explanation
Packets on Q0 600 350 350 The total number of packets transiting

the constituent links (350+350 = 700)
exceeded the number of packets
queued (600) on the multilink bundle.
Packets on Q2 400 100 300 The total number of packets transiting

the constituent links equaled the
number of packets on the bundle.
Packets on Q3 0 19 18 The packets transiting Q3 of the

constituent links are for keepalive
messages exchanged between
constituent links. Thus no packets
were counted on Q3 of the bundle.
On the multilink bundle, verify the following:
• The number of packets queued matches the number transmitted. If the numbers
match, no packets were dropped. If more packets were queued than were
transmitted, packets were dropped because the buffer was too small. The buffer
size on the constituent links controls congestion at the output stage. To correct this
problem, increase the buffer size on the constituent links.
• The number of packets transiting Q0 (600) matches the number of large and small
data packets received (100+500) on the multilink bundle. If the numbers match,
all data packets correctly transited Q0.
• The number of packets transiting Q2 on the multilink bundle (400) matches the
number of voice packets received on the multilink bundle. If the numbers match,
all voice LFI packets correctly transited Q2.
On the constituent links, verify the following:
• The total number of packets transiting Q0 (350+350) matches the number of data
packets and data fragments (500+200). If the numbers match, all the data packets
after fragmentation correctly transited Q0 of the constituent links.
Packets transited both constituent links, indicating that load balancing was correctly
performed on non-LFI packets.
• The total number of packets transiting Q2 (300+100) on constituent links matches

the number of voice packets received (400) on the multilink bundle. If the numbers
match, all voice LFI packets correctly transited Q2.

LFI packets from source port 100 transited se-1/0/0, and LFI packets from source
port 200 transited se-1/0/1. Thus all LFI (Q2) packets were hashed based on the
source port and correctly transited both constituent links.
Corrective Action—If the packets transited only one link, take the following steps to
resolve the problem:
a. Determine whether the physical link is up (operational) or down (unavailable). An

unavailable link indicates a problem with the PIM, interface port, or physical
connection (link-layer errors). If the link is operational, move to the next step.
b. Verify that the classifiers are correctly defined for non-LFI packets. Make sure that
non-LFI packets are not configured to be queued to Q2. All packets queued to Q2
are treated as LFI packets.
c. Verify that at least one of the following values is different in the LFI packets: source
address, destination address, IP protocol, source port, or destination port. If the
same values are configured for all LFI packets, the packets are all hashed to the
same flow and transit the same link.
4. Use the results to verify load balancing.
Determine Why Packets Are Dropped on a PVC Between a Juniper Networks Device and a
Third-Party Device
Problem Description: You are configuring a permanent virtual circuit (PVC) between T1, E1, T3, or
E3 interfaces on a Juniper Networks device and a third-party device, and packets are
being dropped and ping fails.
Solution If the third-party device does not have the same FRF.12 support as the Juniper Networks
device or supports FRF.12 in a different way, the Juniper Networks device interface on the
PVC might discard a fragmented packet containing FRF.12 headers and count it as a
"Policed Discard."
As a workaround, configure multilink bundles on both peers, and configure fragmentation

thresholds on the multilink bundles.

15.1X49-D10 Starting with Junos OS Release 15.1X49-D10, link services interfaces

are no longer supported on SRX300, SRX320, SRX340, and SRX1500
devices.
Troubleshooting Security Policies
• Synchronizing Policies Between Routing Engine and Packet Forwarding

Engine on page 597
Synchronizing Policies Between Routing Engine and Packet Forwarding Engine
Supported Platforms LN Series, SRX Series, vSRX
Problem Description: Security policies are stored in both the Routing Engine and the Packet
Forwarding Engine. After you modify a policy, you commit the configuration on the Routing
Engine, and it is synchronized to the Packet Forwarding Engine.
Environment: The policies in the Routing Engine and Packet Forwarding Engine must be
in sync for the configuration to be committed. However, under certain circumstances,
policies in the Routing Engine and the Packet Forwarding Engine might be out of sync,
which causes the commit to fail.
Symptoms: The following error message appears if you attempt to commit a configuration
when the policies in the Routing Engine and Packet Forwarding Engine are out of sync:
Policy is out of sync between RE and PFE <SPU-name(s)> Please resync before commit.
Solution Synchronize the policies as follows:
• Reboot the device (standalone)
• Reboot the devices (chassis cluster)
Checking a Security Policy Commit Failure
Problem Description: Most policy configuration failures occur during a commit or runtime.
Commit failures are reported directly on the CLI when you execute the CLI command
commit-check in configuration mode. These errors are configuration errors, and you
cannot commit the configuration without fixing these errors.

Solution To fix these errors, do the following:
1. Review your configuration data.
2. Open the file /var/log/nsd_chk_only. This file is overwritten each time you perform a
commit check and contains detailed failure information.
Verifying a Security Policy Commit
Problem Description: Upon performing a policy configuration commit, if you notice that the system
behavior is incorrect, use the following steps to troubleshoot this problem:
Solution 1. Operational show Commands—Execute the operational commands for security policies
and verify that the information shown in the output is consistent with what you
expected. If not, the configuration needs to be changed appropriately.
2. Traceoptions—Set the traceoptions command in your policy configuration. The flags

under this hierarchy can be selected as per user analysis of the show command output.
If you cannot determine what flag to use, the flag option all can be used to capture
all trace logs.
user@host# set security policies traceoptions <flag all>
You can also configure an optional filename to capture the logs.
user@host# set security policies traceoptions <filename>
If you specified a filename in the trace options, you can look in the /var/log/<filename>
for the log file to ascertain if any errors were reported in the file. (If you did not specify a
filename, the default filename is eventd.) The error messages indicate the place of failure
and the appropriate reason.
After configuring the trace options, you must recommit the configuration change that
caused the incorrect system behavior.
Debugging Policy Lookup
Problem Description: When you have the correct configuration, but some traffic was incorrectly
dropped or permitted, you can enable the lookup flag in the security policies traceoptions.
The lookup flag logs the lookup related traces in the trace file.
Solution user@host# set security policies traceoptions <flag lookup>
Related • Synchronizing Policies Between Routing Engine and Packet Forwarding Engine on
Documentation page 597
• Security Policies Overview

• Monitoring Policy Statistics on page 445
Understanding Log Error Messages for Troubleshooting ISSU-Related Problems
Supported Platforms SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800, vSRX
The following problems might occur during an ISSU upgrade. You can identify the errors
by using the details in the logs. You can also see the details of the error messages in the
System Log Explorer.
• Chassisd Process Errors on page 599

• Kernel State Synchronization on page 599
• Installation-Related Errors on page 599
• ISSU Support-Related Errors on page 600
• Redundancy Group Failover Errors on page 600
• Initial Validation Checks Fail on page 600
• Understanding Common Error Handling for ISSU on page 601
Chassisd Process Errors

Problem Description: Errors related to chassisd.
Solution Use the error messages to understand the issues related to chassisd.
When ISSU starts, a request is sent to chassisd to check whether there are any problems
related to the ISSU from a chassis perspective. If there is a problem, a log message is
created.
Kernel State Synchronization

Problem Description: Errors related to ksyncd.
Solution Use the following error messages to understand the issues related to ksyncd:
Failed to get kernel-replication error information from Standby Routing Engine.
mgd_slave_peer_has_errors() returns error at line 4414 in mgd_package_issu.
ISSU checks whether there are any ksyncd errors on the secondary node (node 1) and
displays the error message if there are any problems and aborts the upgrade.
Installation-Related Errors
Problem Description: The install image file does not exist or the remote site is inaccessible.

Solution Use the following error messages to understand the installation-related problems:
error: File does not exist: /var/tmp/junos-srx5000-11.4X3.2-domest

error: Couldn't retrieve package /var/tmp/junos-srx5000-11.4X3.2-domest
ISSU downloads the install image as specified in the ISSU command as an argument.
The image file can be a local file or located at a remote site. If the file does not exist or
the remote site is inaccessible, an error is reported.
ISSU Support-Related Errors

Problem Description: Installation failure occurs because of unsupported software and unsupported
feature configuration.
Solution Use the following error messages to understand the compatibility-related problems:
WARNING: Current configuration not compatible with
/var/tmp/junos-srx5000-11.4X3.2-domestic.tgz
Exiting in-service-upgrade window
Redundancy Group Failover Errors

Problem Description: Problem with automatic redundancy group (RG) failure.
Solution Use the following error messages to understand the problem:
failover all RG 1+ groups to node 0

error: Command failed. None of the redundancy-groups has been failed over.
Some redundancy-groups on node1 are already in manual failover mode.
Please execute 'failover reset all' first..
Initial Validation Checks Fail

Problem Description: The initial validation checks fail.
Solution The validation checks fail if the image is not present or if the image file is corrupt. The
following error messages are displayed when initial validation checks fail when the image
is not present and the ISSU is aborted:
When Image Is Not Present

user@host> ...0120914_srx_12q1_major2.2-539764-domestic.tgz reboot
Chassis ISSU Started
ISSU: Validating Image
Initiating in-service-upgrade
Fetching package...
error: File does not exist:
/var/tmp/junos-srx1k3k-12.1I20120914_srx_12q1_major2.2-539764-domestic.tgz
error: Couldn't retrieve package
/var/tmp/junos-srx1k3k-12.1I20120914_srx_12q1_major2.2-539764-domestic.tgz


Chassis ISSU Aborted
ISSU: IDLE
ISSU aborted; exiting ISSU window.
When Image File Is Corrupted
If the image file is corrupted, the following output displays:
user@host> ...junos-srx1k3k-11.4X9-domestic.tgz_1 reboot

node1:
--------------------------------------------------------------------------
ISSU: Validating Image
node1:
--------------------------------------------------------------------------
ERROR: Cannot use /var/tmp/junos-srx1k3k-11.4X9-domestic.tgz_1:
gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
ERROR: It may have been corrupted during download.
ERROR: Please try again, making sure to use a binary transfer.
node1:
--------------------------------------------------------------------------
node1:
--------------------------------------------------------------------------
ISSU: IDLE
ISSU aborted; exiting ISSU window.
{primary:node0}
The primary node validates the device configuration to ensure that it can be committed
using the new software version. If anything goes wrong, the ISSU aborts and error
messages are displayed.
Understanding Common Error Handling for ISSU

Problem Description: You might encounter some problems in the course of an ISSU. This section
provides details on how to handle them.
Solution Any errors encountered during an ISSU result in the creation of log messages, and ISSU
continues to function without impact to traffic. If reverting to previous versions is required,
the event is either logged or the ISSU is halted, so as not to create any mismatched

versions on both nodes of the chassis cluster. Table 135 on page 602 provides some of the
common error conditions and the workarounds for them. The sample messages used in
the Table 135 on page 602 are from the SRX1500 device and are also applicable to all
supported SRX Series devices.
Table 135: ISSU-Related Errors and Solutions

Error Conditions Solutions
Attempt to initiate The following message is displayed:

an ISSU when
previous instance warning: ISSU in progress
of an ISSU is
already in progress You can abort the current ISSU process, and initiate the ISSU again using
the request chassis cluster in-service-upgrade abort command.
Reboot failure on No service downtime occurs, because the primary node continues to provide
the secondary required services. Detailed console messages are displayed requesting that
node you manually clear existing ISSU states and restore the chassis cluster.
error: [Oct 6 12:30:16]: Reboot secondary node failed

(error-code: 4.1)
error: [Oct 6 12:30:16]: ISSU Aborted! Backup node

maybe in inconsistent state, Please restore backup node
[Oct 6 12:30:16]: ISSU aborted. But, both nodes are
in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback
command
Note: use the 'node' option in the rollback command
otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all

RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node

Table 135: ISSU-Related Errors and Solutions (continued)

Secondary node The primary node times out if the secondary node fails to complete the cold
failed to complete synchronization. Detailed console messages are displayed that you manually
the cold clear existing ISSU states and restore the chassis cluster. No service
synchronization downtime occurs in this scenario.
[Oct 3 14:00:46]: timeout waiting for secondary node node1

to sync(error-code: 6.1)
Chassis control process started, pid 36707
error: [Oct 3 14:00:46]: ISSU Aborted! Backup node

has been upgraded, Please restore backup node
[Oct 3 14:00:46]: ISSU aborted. But, both nodes are
in ISSU window.
command
3. Ensure the node with older image is primary for all

RGs
Failover of newly No service downtime occurs, because the primary node continues to provide
upgraded required services. Detailed console messages are displayed requesting that
secondary failed you manually clear existing ISSU states and restore the chassis cluster.
[Aug 27 15:28:17]: Secondary node0 ready for failover.

[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed
(error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU
window.
command
3. Ensure the node with older image is primary for all RGs
{primary:node1}
Upgrade failure on No service downtime occurs, because the secondary node fails over as
primary primary and continues to provide required services.

Table 135: ISSU-Related Errors and Solutions (continued)

Reboot failure on Before the reboot of the primary node, devices being out of the ISSU setup,
primary node no ISSU-related error messages are displayed. The following reboot error
message is displayed if any other failure is detected:
Reboot failure on Before the reboot of primary node,

devices will be out of ISSU setup and no primary node error
messages will be displayed.
Primary node
Related • Troubleshooting Chassis Cluster ISSU-Related Problems

Documentation
• Upgrading Both Devices in a Chassis Cluster Using an ISSU
• ISSU System Requirements
• Understanding the ISSU Process on Devices in a Chassis Cluster

PART 10
Configuration Statements and

Operational Commands
• Configuration Statements: Accounting Options, Source Class Usage and Destination
Class Usage Options on page 607
• Configuration Statements: Chassis Cluster on page 647
• Configuration Statements: Datapath Debug on page 655
• Configuration Statements: Health Monitoring on page 665
• Configuration Statements: Remote Monitoring (RMON) on page 671
• Configuration Statements: Resource Monitoring for Memory Regions on page 687
• Configuration Statements: Security Alarms on page 695
• Configuration Statements: SNMP on page 697
• Configuration Statements: SNMPv3 on page 729
• Operational Commands on page 777


CHAPTER 35
Configuration Statements: Accounting

Options, Source Class Usage and
Destination Class Usage Options
• accounting-options on page 608

• archive-sites on page 609
• backup-on-failure (Accounting Options) on page 610
• class-usage-profile on page 611
• cleanup-interval (Accounting Options) on page 612
• compress (Accounting Options) on page 612
• counters on page 613
• destination-classes on page 613
• egress-stats (Flat-File Accounting Options) on page 614
• fields (Flat-File Accounting Options) on page 616
• fields (for Interface Profiles) on page 618
• fields (for Routing Engine Profiles) on page 619
• file (Associating with a Profile) on page 620
• file (Configuring a Log File) on page 621
• file (Flat-File Accounting Options) on page 622
• files on page 622
• filter-profile on page 623
• flat-file-profile (Accounting Options) on page 624
• format (Flat-File Accounting Options) on page 626
• general-param (Flat-File Accounting Options) on page 627
• ingress-stats (Flat-File Accounting Options) on page 629
• interface-profile on page 630
• interval on page 631
• interval (Flat-File Accounting Options) on page 632
• l2-stats (Flat-File Accounting Options) on page 633

• mib-profile on page 634

• mpls (Security Forwarding Options) on page 635
• nonpersistent on page 636
• object-names on page 636
• operation on page 637
• overall-packet (Flat-File Accounting Options) on page 638
• push-backup-to-master (Accounting Options) on page 639
• routing-engine-profile on page 640
• schema-version (Flat-File Accounting Options) on page 641
• size on page 642
• source-classes on page 643
• start-time on page 643
• traceoptions (System Accounting) on page 644
• transfer-interval on page 645
accounting-options
Syntax accounting-options {...}

}
Hierarchy Level [edit]
Release Information Statement introduced before Junos OS Release 7.4.
Description Configure options for accounting statistics collection.
Required Privilege snmp—To view this statement in the configuration.

Level snmp-control—To add this statement to the configuration.
Related • Configuration Statements at the [edit accounting-options] Hierarchy Level on page 295
Documentation

Chapter 35: Configuration Statements: Accounting Options, Source Class Usage and Destination Class Usage Options
archive-sites
Supported Platforms EX Series, M Series, MX Series, PTX Series, SRX Series, T Series, vSRX
Syntax archive-sites {
site-name;
}
Hierarchy Level [edit accounting-options file filename]

Statement introduced in Junos OS Release 9.0 for EX Series switches.
Description Configure an archive site. If more than one site name is configured, an ordered list of
archive sites for the accounting-data log files is created. When a file is archived, the router
or switch attempts to transfer the file to the first URL in the list, moving to the next site
only if the transfer does not succeed. The log file is stored at the archive site with a
filename of the format router-name_log-filename_timestamp.
Options site-name—Any valid FTP/SCP URL to a destination.

Related • Configuring Archive Sites for the Files on page 306

Documentation

backup-on-failure (Accounting Options)
Syntax backup-on-failure (master-and-slave | master-only);
Release Information Statement introduced in Junos OS Release 16.1.
Description Configure the router to save a copy of the accounting file locally, to the
/var/log/pfedBackup directory of the relevant Routing Engine, in the event that file transfer
to the remote archive sites cannot be completed.
Options master-and-slave—Back up accounting files from both the master Routing Engine and
the backup Routing Engine.
master-only—Back up accounting files from only the master Routing Engine.
Required Privilege system—To view this statement in the configuration.

Level system-control—To add this statement to the configuration.
Related • Configuring Accounting-Data Log Files on page 304

Documentation
• Configuring Flat-File Accounting for Layer 2 Wholesale
• Configuring Flat-File Accounting for Extensible Subscriber Services Management
• Flat-File Accounting Overview

class-usage-profile
Syntax class-usage-profile profile-name {

file filename;
interval minutes;
source-classes {
source-class-name;
}
}
}
Hierarchy Level [edit accounting-options]

Description Create a class usage profile, which is used to log class usage statistics to a file in the
/var/log directory. The class usage profile logs class usage statistics for the configured
source classes on every interface that has destination-class-usage configured.
For information about configuring source classes, see the Junos Routing Protocols
Configuration Guide. For information about configuring source class usage, see the Junos
Network Management Configuration Guide.
Options profile-name—Name of the destination class profile.
The remaining statements are explained separately.
Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.
Related • Configuring Class Usage Profiles on page 319

Documentation

cleanup-interval (Accounting Options)
Syntax cleanup-interval days;
Description Configure the interval to delete files from the local backup directory.
Options days—Number of days after which accounting-options files are to be deleted from the
backup directory.
Range: 1 through 31 days
Default: 1 day


Documentation
compress (Accounting Options)
Syntax compress;
Description Compress the accounting file during file transfer to the backup site.


Documentation

counters
Syntax counters {
counter-name;
}
Hierarchy Level [edit accounting-options filter-profile profile-name]

Description Names of counters for which filter profile statistics are collected. The packet and byte
counts for the counters are logged to a file in the /var/log directory.
Options counter-name—Name of the counter.

Related • Configuring the Counters on page 312

Documentation
destination-classes
Syntax destination-classes {
}
Hierarchy Level [edit accounting-options class-usage-profile profile-name]

Statement introduced in Junos OS Release 15.1F6 for PTX Series routers with
third-generation FPCs installed.
Description Specify the destination classes for which statistics are collected.
Options destination-class-name—Name of the destination class to include in the source class

usage profile.

Related • Configuring a Class Usage Profile on page 320

Documentation

egress-stats (Flat-File Accounting Options)
Syntax egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
Hierarchy Level [edit accounting-options flat-file-profile profile-name fields]
Description Specify egress queue statistics to be collected for the interface.
Options all-fields—Collect all egress queue statistics available for the interface context, logical
or physical.
input-bytes—Collect the number of octets queued including traffic dropped because of

congestion.
input-packets—Collect the number of packets queued including traffic dropped because

of congestion.
output-bytes—Collect the number of octets transmitted by the egress queue.
output-packets—Collect the number of packets transmitted by the egress queue.
queue-id—Collect the logical identifier for the egress queue; identifies the traffic class.
red-drop-bytes—Collect the number of octets dropped on the egress queue because of

random early detection.
red-drop-packets—Collect the number of packets dropped on the egress queue because

of random early detection.
tail-drop-packets—Collect the number of packets dropped in the egress queue because

of tail drop.

Related • Configuring Flat-File Accounting for Layer 2 Wholesale

Documentation


fields (Flat-File Accounting Options)
Syntax fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
user-name;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
}
overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;
output-errors;
output-packets;

outputv6-bytes;
outputv6-packets;
}
service-accounting;
}
Hierarchy Level [edit accounting-options flat-file-profile profile-name]
Description Specify the accounting statistics and the nonstatistical information to be collected for
an interface and recorded in the accounting flat file created by the profile.
Options all-fields—Include all available statistical fields in the accounting file. Many fields are
available for both logical interfaces and physical interfaces, but some fields are
available only for one or the other interface type.
service-accounting—Include the filter counts in bytes for the inet input filter, inet output
filter, inet6 input filter, and inet6 output filter in the service accounting flat file.
Statistics reported are the running total values.


Documentation
• Configuring Service Accounting in Local Flat Files

fields (for Interface Profiles)
Syntax fields {
field-name;
}
Hierarchy Level [edit accounting-options interface-profile profile-name]

Description Statistics to collect in an accounting-data log file for an interface.
Options field-name—Name of the field:
• input-bytes—Input bytes
• input-errors—Generic input error packets
• input-multicast—Input packets arriving by multicast
• input-packets—Input packets
• input-unicast—Input unicast packets
• output-bytes—Output bytes
• output-errors—Generic output error packets
• output-multicast—Output packets sent by multicast
• output-packets—Output packets
• output-unicast—Output unicast packets

Related • Configuring the Interface Profile on page 309

Documentation

fields (for Routing Engine Profiles)
Syntax fields {
field-name;
}
Hierarchy Level [edit accounting-options routing-engine-profile profile-name]
Description Statistics to collect in an accounting-data log file for a Routing Engine.
Options field-name—Name of the field:
• cpu-load-1—Average system load over the last 1 minute
• cpu-load-5—Average system load over the last 5 minutes
• cpu-load-15—Average system load over the last 15 minutes
• date—Date, in YYYYMMDD format
• host-name—Hostname for the router
• time-of-day—Time of day, in HHMMSS format
• uptime—Time since last reboot, in seconds

Related • Configuring the Routing Engine Profile on page 324

Documentation

file (Associating with a Profile)
Syntax file filename;
Hierarchy Level [edit accounting-options class-usage-profile profile-name],

[edit accounting-options filter-profile profile-name],
[edit accounting-options interface-profile profile-name],
[edit accounting-options mib-profile profile-name],

The [edit accounting-options mib-profile profile-name] hierarchy added in Junos OS
Release 8.2.
Statement introduced in Junos OS Release 9.0 for EX Series Switches.
Description Specify the accounting log file associated with the profile.
Options filename—Name of the log file. You must specify a filename already configured in the file
statement at the [edit accounting-options] hierarchy level.


Documentation

file (Configuring a Log File)
Syntax file filename {

archive-sites {
site-name;
}
backup-on-failure (master-and-slave | master-only);
compress;
files number;
nonpersistent;
push-backup-to-master;
size bytes;
start-time time;
}

Description Specify a log file to be used for accounting data.
Options filename—Name of the file in which to write accounting data.


Documentation

file (Flat-File Accounting Options)
Syntax file filename;
Description Specify the name of the accounting file created by a flat-file profile. By default, the
filename becomes the name of the local directory where the accounting file is backed
up: /var/log/pfedBackup/filename.
Options filename—Name of the accounting file. The complete output filename is in the format
filename.hostname.file-number_timestamp.gz.


Documentation
files
Syntax files number;

Description Specify the maximum number of log files to be used for accounting data.
Options number—The maximum number of files. When a log file (for example, profilelog) reaches
its maximum size, it is renamed profilelog.0, then profilelog.1, and so on, until the
maximum number of log files is reached. Then the oldest log file is overwritten. The
minimum value for number is 3 and the default value is 10.


Documentation

filter-profile
Syntax filter-profile profile-name {

counters {
counter-name;
}
file filename;
interval minutes;
}

Description Create a profile to filter and collect packet and byte count statistics and write them to
a file in the /var/log directory. To apply the profile to a firewall filter, you include the
accounting-profile statement at the [edit firewall filter filter-name] hierarchy level. For
more information about firewall filters, see Firewall Filters Overview.
Options profile-name—Name of the filter profile.

Related • Firewall Filters Overview

Documentation

flat-file-profile (Accounting Options)
Syntax flat-file-profile profile-name{

fields {
all-fields;
egress-stats {
all-fields;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
red-drop-bytes;
red-drop-packets;
tail-drop-packets;
}
general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
user-name;
vlan-id;
}
ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
l2-stats {
all-fields;
input-mcast-bytes;
}
overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;
output-errors;

output-packets;
outputv6-bytes;
outputv6-packets;
}
service-accounting;
}
file filename;
format (csv | ipdr)
interval minutes;
}

service-accounting option added in Junos OS Release 17.1.
Description Configure a flat-file accounting profile that defines the contents of a flat file that records
accounting statistics collected from the Packet Forwarding Engine for an interface at
regular intervals. To be used, the profile is associated with a subscriber interface. The
accounting flat file is archived by the accounting-options archiving mechanism.
Options profile-name—Name of the flat-file profile.


Documentation
• show extensible-subscriber-services accounting

format (Flat-File Accounting Options)
Syntax format (csv | ipdr);
Description Specify the format for logging the flat-file accounting statistics.
Options csv—Comma-separated values (CSV) format.
ipdr—IP Detail Record (IPDR) format.

Default: ipdr


Documentation

general-param (Flat-File Accounting Options)
Syntax general-param {
all-fields;
accounting-type;
descr;
line-id;
logical-interface;
nas-port-id;
physical-interface;
routing-instance;
timestamp;
user-name;
vlan-id;
}

user-name option added in Junos OS Release 17.1.
Description Specify general, nonstatistical interface parameters that are displayed as part of the
header for the accounting file.
Options all-fields—Display all available nonstatistical fields. Many fields are available for both
logical interfaces and physical interfaces, but some fields are available for only one
interface type.
accounting-type—(Logical interfaces only ) Display the accounting status type.
descr—Display the description of the interface as configured.
line-id—(Logical interfaces only ) Display the access line identifier.
logical-interface—(Logical interfaces only ) Display the name of the logical interface.
nas-port-id—(Logical interfaces only ) Display the NAS port ID.
physical-interface—(Physical interfaces only ) Display the name of the physical interface.
routing-instance—Display the name of the routing instance to which the interface belongs.
timestamp—Display the timestamp of the accounting record.
user-name—Display the name of the subscriber.
vlan-id—(Logical interfaces only ) Display the VLAN identifier.



Documentation

ingress-stats (Flat-File Accounting Options)
Syntax ingress-stats {
all-fields;
drop-packets;
input-bytes;
input-packets;
output-bytes;
output-packets;
queue-id;
}
Description Specify ingress queue statistics to be collected for the interface.
Options all-fields—Collect all ingress queue statistics available for the interface context, logical
or physical.
drop-packets—Collect the number of received packets dropped on the Ingress queue.
input-bytes—Collect the number of octets received on the queue for the traffic class
indicated by the queue identifier.
input-packets—Collect the number of packets received on the queue for the traffic class
indicated by the queue identifier.
output-bytes—Collect the number of octets forwarded for the traffic class indicated by
the queue identifier. Same value as input-bytes unless oversubscription is present
at the ingress.
output-packets—Collect the number of packets forwarded for the traffic class indicated
by the queue identifier. Same value as input-packets unless oversubscription is
present at the ingress.
queue-id—Collect the logical identifier for the ingress queue; identifies the traffic class.


Documentation

interface-profile
Syntax interface-profile profile-name {

fields {
field-name;
}
file filename;
interval minutes;
}

Description Create a profile to filter and collect error and packet statistics and write them to a file in
the /var/log directory. You can specify an interface profile for either a physical or a logical
interface.
Options profile-name—Name of the interface profile.


Documentation

interval
Syntax interval minutes;
Hierarchy Level [edit accounting-options class-usage-profile profile-name],

[edit accounting-options filter-profile profile-name],
[edit accounting-options interface-profile profile-name],
[edit accounting-options mib-profile profile-name],

The [edit accounting-options mib-profile profile-name] hierarchy level added in Junos OS
Release 8.2.
Description Specify how often statistics are collected for the accounting profile.
Options minutes—Length of time between each collection of statistics.

Range: 1 through 2880 minutes
Default: 30 minutes


Documentation

interval (Flat-File Accounting Options)
Syntax interval minutes;
Description Specify the interval in minutes at which the Packet Forwarding Engine associated with
the interface is polled to collect the statistics specified in the flat-file accounting profile.
These interim accounting results are recorded in the flat file.
NOTE: The value configured with this statement is superseded by the value
configured with the update-interval statement at the [edit access profile
profile-name service accounting] hierarchy level. That access profile interval
value is in turn superseded by an update interval value configured in the
RADIUS attribute, Service-Interim-Acct-Interval (VSA 26–140).
Options minutes—Polling interval.

Default: 15 minutes


Documentation

l2-stats (Flat-File Accounting Options)
Syntax l2-stats {
all-fields;
input-mcast-bytes;
}
Description Specify the statistics to collect for the named flat-file-profile field.
Options all-fields—Collect all Layer 2 statistics for the named flat-file profile.
input-mcast-bytes—Collect multicast bytes from the input side for the named flat-file
profile.
input-mcast-packets—Collect multicast packets from the input side for the named flat-file
profile.


Documentation

mib-profile
Supported Platforms EX Series, M Series, MX Series, SRX Series, T Series, vSRX
Syntax mib-profile profile-name {

file filename;
interval minutes;
object-names {
mib-object-name;
}
}

Description Create a MIB profile to collect selected MIB statistics and write them to a file in the
/var/log directory.
NOTE: Do not configure MIB objects related to interface octets or packets

for a MIB profile, because it can cause the SNMP walk or a CLI show command
to time out.
Options profile-name—Name of the MIB statistics profile.

Related • Configuring the MIB Profile on page 322

Documentation

mpls (Security Forwarding Options)
Syntax mpls {
mode packet-based;
}
Hierarchy Level [edit security forwarding-options family]
Description Enable the forwarding of MPLS traffic. By default, the device drops MPLS traffic.
CAUTION: Because MPLS operates in packet mode, security services are not
available.
NOTE: Packet-based processing is not supported on the following SRX Series

devices: SRX1500, SRX5600, and SRX5800.
Required Privilege security—To view this statement in the configuration.

Level security-control—To add this statement to the configuration.
Related • MPLS Overview

Documentation

nonpersistent
Syntax nonpersistent;
Description Store log files used for accounting data in the mfs/var/log directory (located on DRAM)
instead of the cf/var/log directory (located on the compact flash drive). This feature is
useful for minimizing read/write traffic on the router’s compact flash drive.
NOTE: If log files for accounting data are stored on DRAM, these files are lost
when you reboot the router. Therefore, you should back up these files
periodically.

Related • Configuring the Storage Location of the File on page 307

Documentation
object-names
Syntax object-names {
mib-object-name;
}
Hierarchy Level [edit accounting-options mib-profile profile-name]

Description Specify the name of each MIB object for which MIB statistics are collected for an
accounting-data log file.
Options mib-object-name—Name of a MIB object. You can specify more than one MIB object
name.


Documentation

operation
Syntax operation operation-name;
Hierarchy Level [edit accounting-options mib-profile profile-name]

Description Specify the name of the operation used to collect MIB statistics for an accounting-data
log file.
Options operation-name—Name of the operation to use. You can specify a get, get-next, or walk
operation.
Default: walk


Documentation

overall-packet (Flat-File Accounting Options)
Syntax overall-packet {
all-fields;
input-bytes;
input-discards;
input-errors;
input-packets;
inputv6-bytes;
inputv6-packets;
output-bytes;
output-errors;
output-packets;
outputv6-bytes;
outputv6-packets;
}
Description Specify overall packet statistics to be collected for the interface.
Options all-fields—Collect all overall packet statistics available for the interface context, logical
or physical.
input-bytes—Collect the number of octets received on the interface.
input-discards—(Physical interfaces only ) Collect the number of received packets that

were discarded on the interface.
input-errors—(Physical interfaces only ) Collect the number of frames with errors received
on the interface.
input-packets—Collect the number of packets received on the interface.
input-v6-bytes—Collect the number of IPv6 octets received on the interface.
input-v6-packets—Collect the number of IPv6 packets received on the interface.
output-bytes—Collect the number of octets transmitted on the interface.
output-errors—(Physical interfaces only ) Collect the number of frames that could not
be transmitted on the interface because of errors.
output-packets—Collect the number of packets transmitted on the interface.
output-v6-bytes—Collect the number of IPv6 octets transmitted on the interface.
output-v6-packets—Collect the number of IPv6 packets transmitted on the interface.



Documentation
push-backup-to-master (Accounting Options)
Syntax push-backup-to-master;
Description Configure the router to save the accounting files from the new backup Routing Engine
to the new master Routing Engine when a change in mastership occurs. The files are
saved to the /var/log/pfedBackup directory on the router. The master Routing Engine
includes these accounting files with its own current accounting files when it transfers
the files from the backup directory to the archive site at the next transfer interval. Use
this statement when the new backup Routing Engine is not able to connect to the archive
site; for example, when site is not connected by means of an out-of-band interface or
the path to the site is routed through a line card.
NOTE: The backup Routing Engine’s files on the master Routing Engine are
sent at each interval even though the files remain the same. If this is more
activity than you want, consider using the backup-on-failure master-and-slave
statement instead.


Documentation

routing-engine-profile
Syntax routing-engine-profile profile-name {

fields {
field-name;
}
file filename;
interval minutes;
}

Description Create a Routing Engine profile to collect selected Routing Engine statistics and write
them to a file in the /var/log directory.
Options profile-name—Name of the Routing Engine statistics profile.

Related • Configuring the Routing Engine Profile on page 324

Documentation

schema-version (Flat-File Accounting Options)
Syntax schema-version schema-name;
Description Specify the name of the XML schema that defines the contents and format of the
accounting file, and appears in the accounting record header.
Options schema-name—Name of the schema.


Documentation

size
Syntax size bytes;

Description Specify attributes of an accounting-data log file.
Options bytes—Maximum size of each log file, in bytes, kilobytes (KB), megabytes (MB), or
gigabytes (GB). When a log file (for example, profilelog) reaches its maximum size,
it is renamed profilelog.0, then profilelog.1, and so on, until the maximum number of
log files is reached. Then the oldest log file is overwritten. If you do not specify a size,
the file is closed, archived, and renamed when the time specified for the transfer
interval is exceeded.
Syntax: x to specify bytes, xk to specify KB, xm to specify MB, xg to specify GB
Range: 256 KB through 1 GB

Related • Configuring the Maximum Size of the File on page 305

Documentation

source-classes
Syntax source-classes {
source-class-name;
}
Hierarchy Level [edit accounting-options class-usage-profile profile-name]

Statement introduced in Junos OS Release 15.1F6 for PTX Series routers with
third-generation FPCs installed.
Description Specify the source classes for which statistics are collected.
Options source-class-name—Name of the source class to include in the class usage profile.

Related • Configuring a Class Usage Profile on page 320

Documentation
start-time
Syntax start-time time;

Description Specify the start time for transfer of an accounting-data log file.
Options time—Start time for file transfer.

Syntax: YYYY-MM-DD.hh:mm

Related • Configuring the Start Time for File Transfer on page 308
Documentation

traceoptions (System Accounting)
Supported Platforms EX Series, MX Series
Syntax traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag (all| config | events | radius | tacplus);
no-remote-trace
}
Hierarchy Level [edit system accounting]]

tacplus option introduced in Junos OS Release 15.1.
Description Define tracing operations for System Accounting.
Default Trace options are not enabled by default.
Options file filename—Name of the file in which Junos OS stores the accounting logs. By default,
this is created under the /var/log directory.
files number—(Optional) Maximum number of trace files. When a trace file reaches the
size specified by the size option, the filename is appended with 0 and compressed.
For example, when trace file named trace-file-log reaches size <size>, it is renamed
and compressed to trace-file-log.0.gz. When trace-file-log reaches size <size> or
the second time, the trace-file-log.0.gz is renamed to trace-file-log.1.gz and
trace-file-log is renamed and compressed to trace-file-log.0.gz. This renaming
shceme ensures that the older logs to have a greater index number. When number
of trace files reach <number> then the oldest file is deleted.
If you specify a maximum number of files, you also must specify a maximum file size with
the size option and a filename.
Range: 2 through 1000 files
Default: 10
flag flag—Tracing operation to perform. You can include one or more of the following
flags:
• all—Trace all operations.
• config—Trace configuration processing.
• events—Trace accounting events and their processing.
• radius—Trace RADIUS processing.
• tacplus—Trace TACPLUS processing.
no-remote-trace—(Optional) Disable tracing and logging operations that track normal

operations, error conditions, and packets that are generated by or passed through
the Juniper Networks device.

no-world-readable—Restrict access to the trace files to the owner.

Default: no-world-readable
size size—(Optional) Maximum size of each trace file in bytes, kilobytes (KB), megabytes
(MB), or gigabytes (GB). If you do not specify a unit, the default is bytes. If you specify
a maximum file size, you also must specify a maximum number of trace files by using
the files option and a filename by using the file option.
If you specify a maximum file size, you also must specify a maximum number of trace
files with the files option.
Syntax: size to specify bytes, sizek to specify KB, sizem to specify MB, or sizeg to specify
GB.
Range: 10 KB through 1 MB
Default: 128 KB
world-readable—Enable any user to access the trace files.
Required Privilege admin—To view this statement in the configuration.

Level admin-control—To add this statement to the configuration.
transfer-interval
Syntax transfer-interval minutes;

Description Specify the length of time the file remains open and receives new statistics before it is
closed and transferred to an archive site.
Options minutes—Time the file remains open and receives new statistics before it is closed and
transferred to an archive site.
Default: 30 minutes

Related • Configuring the Transfer Interval of the File on page 308

Documentation


CHAPTER 36
Configuration Statements: Chassis Cluster
• cluster (Chassis) on page 648

• global-threshold on page 649
• global-weight on page 650
• ip-monitoring on page 651
• ip-monitoring (Services) on page 653
• next-hop on page 654

cluster (Chassis)
Syntax cluster {
configuration-synchronize {
no-secondary-bootup-auto;
}
control-link-recovery;
heartbeat-interval milliseconds;
heartbeat-threshold number;
network-management {
cluster-master;
}
redundancy-group group-number {
gratuitous-arp-count number;
hold-down-interval number;
interface-monitor interface-name {
weight number;
}
ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;
retry-count number;
retry-interval seconds;
}
node (0 | 1 ) {
priority number;
}
preempt;
}
reth-count number;
traceoptions {
file {
filename;
files number;
match regular-expression;
(world-readable | no-world-readable);
size maximum-file-size;
}
flag flag;
level {
(alert | all | critical | debug | emergency | error | info | notice | warning);
}

Chapter 36: Configuration Statements: Chassis Cluster
no-remote-trace;
}
}
Hierarchy Level [edit chassis]
Description Configure a chassis cluster.
Options The remaining statements are explained separately. See CLI Explorer.

Related • ip-monitoring on page 651

Documentation
global-threshold
Syntax global-threshold number;
Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring ]
Description Specify the failover value for all IP addresses monitored by the redundancy group. When
IP addresses with a configured total weight in excess of the threshold have become
unreachable, the weight of IP monitoring is deducted from the redundancy group
threshold.
Options number —Value at which the IP monitoring weight is applied against the redundancy
group failover threshold.
Range: 0 through 255
Default: 0


Documentation

global-weight
Syntax global-weight number;
Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring]
Description Specify the relative importance of all IP address monitored objects to the operation of
the redundancy group. Every monitored IP address is assigned a weight. If the monitored
address becomes unreachable, the weight of the object is deducted from the
global-threshold of IP monitoring objects in its redundancy group. When the
global-threshold reaches 0, the global-weight is deducted from the redundancy group.
Every redundancy group has a default threshold of 255. If the threshold reaches 0, a
failover is triggered. Failover is triggered even if the redundancy group is in manual failover
mode and preemption is not enabled.
Options number —Combined weight assigned to all monitored IP addresses. A higher weight value
indicates a greater importance.
Default: 255


Documentation

ip-monitoring
Syntax ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;
retry-count number;
retry-interval seconds;
}
Hierarchy Level [edit chassis cluster redundancy-group group-number ]
Release Information Statement updated in Junos OS Release 10.1.
Description Specify a global IP address monitoring threshold and weight, and the interval between
pings (retry-interval) and the number of consecutive ping failures (retry-count) permitted
before an IP address is considered unreachable for all IP addresses monitored by the
redundancy group. Also specify IP addresses, a monitoring weight, a redundant Ethernet
interface number, and a secondary IP monitoring ping source for each IP address, for the
redundancy group to monitor.
Options IPv4 address—The address to be continually monitored for reachability.
NOTE: All monitored object failures, including IP monitoring, are deducted

from the redundancy group threshold priority. Other monitored objects include
interface monitor, SPU monitor, cold-sync monitor, and NPC monitor (on
supported platforms).
The remaining statements are explained separately. See CLI Explorer.

Related • interface (Chassis Cluster)

Documentation
• global-threshold on page 649
• global-weight on page 650

• weight
• Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring on

page 377

ip-monitoring (Services)
Syntax ip-monitoring {
policy policy-name {
match {
rpm-probe [probe-name];
}
no-preempt ;
then {
interface interface-name (disable | enable);
preferred-route {
route destination-address {
discard
next hop next-hop;
preferred-metric metric;
}
routing-instances name;
}
}
}
traceoptions {
file {
filename;
files number;
}
flag flag;
no-remote-trace;
}
}
Hierarchy Level [edit services]

Support added for the dicard option starting from Junos OS Release 15.1X49-D60.
Description Configure IP monitoring.
Required Privilege services—To view this statement in the configuration.

Level services-control—To add this statement to the configuration.
Related • icmp on page 662

Documentation

next-hop
Syntax next-hop next-hop;
Hierarchy Level [edit services rpm probe owner test test-name]
Description Specify the next-hop address to which the probe should be sent.
Required Privilege services—To view this statement in the configuration.

Level services-control—To add this statement to the configuration.
Related • probe
Documentation

CHAPTER 37
Configuration Statements: Datapath

Debug
• action-profile on page 656

• capture-file (Security) on page 657
• datapath-debug on page 658
• flow (Security Flow) on page 660
• icmp on page 662
• maximum-capture-size (Datapath Debug) on page 662
• traceoptions (Security Datapath Debug) on page 663

action-profile
Syntax action-profile profile-name {

event (jexec | lbt | lt-enter | lt-leave | mac-egress | mac-ingress | np-egress | np-ingress |
pot) {
count;
packet-dump;
packet-summary;
trace;
}
module {
flow {
flag {
all;
}
}
}
record-pic-history;
}
Hierarchy Level [edit security datapath-debug]
Release Information Command introduced in Junos OS Release 10.0.
Description Configure the action profile options for data path debugging.
Options • action-profile name — Name of the action profile.
• event—Enable the events to trace the packet when the packet hit the events (jexec,
lbt, lt-enter, lt-leave, mac-egress, mac-ingress, np-egress, np-ingress, pot)
• count—Number of times a packet hits the specified event.
• packet-dump—Capture the packet that hits the specified event.
• packet-summary—Print the source/destination IP address details with protocol

number and IP length details along with trace message for the specified event.
• trace—Print the standard trace message when the packet hits the specified event.
• module—Turn on the flow session related trace messages.
• flow—Trace flow session related messages.
• flag—Specify which flow message needs to be traced.
• all—Trace all possible flow trace messages.
• trace—Print the standard trace message when the packet hits the specified event.
• preserve-trace-order—Preserve trace order.
• record-pic-history—Record the PICs in which the packet has been processed.

Chapter 37: Configuration Statements: Datapath Debug

Related • Example: Configuring Packet Capture for Datapath Debugging on page 569
Documentation
capture-file (Security)
Syntax capture-file {
filename;
files number;
format pacp-format;
}
Description Sets packet capture for performing the datapath-debug action.
Options • filename—Name of the file to receive the output of the packet capturing operation.
• files—Maximum number of capture files.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
• format—Describes the format of the capture file. The default format file is pcap. You
can also set it as private (binary) format.
• size—Describes the size limit of the capture file.
files with the files option and a filename.
Range: 10 KB through 100 MB
• world-readable | no-world-readable—By default, log files can be accessed only by the

user who configures the tracing operation. The world-readable option enables any user
to read the file. To explicitly set the default behavior, use the no-world-readable option.


Documentation

datapath-debug
Syntax datapath-debug {
action-profile profile-name {
event (jexec | lbt | lt-enter | lt-leave | mac-egress | mac-ingress | np-egress | np-ingress
| pot) {
count;
packet-dump;
packet-summary;
trace;
}
module {
flow {
flag {
all;
}
}
}
record-pic-history;
}
capture-file {
filename;
files number;
format pacp-format;
}
maximum-capture-size value;
packet-filter packet-filter-name {
action-profile (profile-name | default);
destination-port (port-range | protocol-name);
destination-prefix destination-prefix;
interface logical-interface-name;
protocol (protocol-number | protocol-name;
source-port (port-range | protocol- name);
source-prefix source-prefix;
}
traceoptions {
file {
filename;
files number;
}
no-remote-trace;
}
}
Hierarchy Level [edit security]

Description Configure the data path debugging options.

Related • Understanding Data Path Debugging for Logical Systems

Documentation

flow (Security Flow)
Syntax flow {
aging {
early-ageout seconds;
high-watermark percent;
low-watermark percent;
}
allow-dns-reply;
ethernet-switching {
block-non-ip-all;
bpdu-vlan-flooding;
bypass-non-ip-unicast;
no-packet-flooding {
no-trace-route;
}
}
force-ip-reassembly;
ipsec-performance-acceleration;
load distribution {
session-affinity ipsec;
}
pending-sess-queue-length (high | moderate | normal);
route-change-timeout seconds;
syn-flood-protection-mode (syn-cookie | syn-proxy);
tcp-mss {
all-tcp mss value;
gre-in {
mss value;
}
gre-out {
mss value;
}
ipsec-vpn {
mss value;
}
}
tcp-session {
fin-invalidate-session;
no-sequence-check;
no-syn-check;
no-syn-check-in-tunnel;
rst-invalidate-session;
rst-sequence-check;
strict-syn-check;
tcp-initial-timeout seconds;
time-wait-state {
(session-ageout | session-timeout seconds);
}
}
traceoptions {
file {
filename;

files number;
}
flag flag;
no-remote-trace;
packet-filter filter-name {
destination-port port-identifier;
destination-prefix address;
interface interface-name;
protocol protocol-identifier;
source-port port-identifier;
source-prefix address;
}
rate-limit messages-per-second;
}
}
Hierarchy Level [edit security]
Release Information Statement modified in Junos OS Release 9.5.
Description Determine how the device manages packet flow. The device can regulate packet flow
in the following ways:
• Enable or disable DNS replies when there is no matching DNS request.
• Set the initial session-timeout values.

Related • Juniper Networks Devices Processing Overview

Documentation
• Understanding Session Characteristics for SRX Series Services Gateways
• Understanding Flow in Logical Systems for SRX Series Devices

icmp
Syntax icmp{
destination-interface interface-name;
}
Hierarchy Level [edit services rpm probe-server]
Description Specify the port information for the ICMP server.
The remaining statements are explained separately. See CLI Explorer.

Related • Understanding ICMP Fragment Protection

Documentation
maximum-capture-size (Datapath Debug)
Syntax maximum-capture-size maximum-capture-size;
Description Specifies maximum packet capture length.
Options • maximum-capture-size maximum-capture-size—Specify the maximum packet capture

length.
Range: 68 through 10,000 bytes


Documentation

traceoptions (Security Datapath Debug)
file {
filename;
files number;
}
no-remote-trace;
}
Description Sets the trace options for datapath-debug.
Options • file—Configure the trace file options.
• filename—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log. By
default, the name of the file is the name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file
reaches its maximum size, it is renamed to trace-file.0, then trace-file.1, and so on,
until the maximum number of trace files is reached. The oldest archived file is
overwritten.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular
expression.
• size maximum-file-size—Maximum size of each trace file, in kilobytes (KB), megabytes

(MB), or gigabytes (GB). When a trace file named trace-file reaches this size, it is
renamed trace-file.0. When the trace-file again reaches its maximum size, trace-file.0
is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme
continues until the maximum number of trace files is reached. Then the oldest trace
file is overwritten.
files with the files option and a filename.
Syntax: x K to specify KB, x m to specify MB, or x g to specify GB

Default: 128 KB
• world-readable | no-world-readable—By default, log files can be accessed only by

the user who configures the tracing operation. The world-readable option enables
any user to read the file. To explicitly set the default behavior, use the
no-world-readable option
• no-remote-trace—Set remote tracing as disabled.
Required Privilege trace—To view this statement in the configuration.

Level trace-control—To add this statement to the configuration.

CHAPTER 38
Configuration Statements: Health

Monitoring
• falling-threshold on page 666

• health-monitor on page 667
• idp (SNMP) on page 667
• rising-threshold on page 669

falling-threshold
Supported Platforms EX Series, M Series, MX Series, PTX Series, SRX Series, T Series
Syntax falling-threshold percentage;
Hierarchy Level [edit snmp health-monitor],

[edit snmp health-monitor idp]

Statement introduced in Junos OS Release 9.3 for the [edit snmp health-monitor idp]
hierarchy level.
Description The lower threshold is expressed as a percentage of the maximum possible value for the
sampled variable. When the current sampled value is less than or equal to this threshold,
and the value at the last sampling interval is greater than this threshold, a single event
is generated. A single event is also generated if the first sample after this entry becomes
valid is less than or equal to this threshold. After a falling event is generated, another
falling event cannot be generated until the sampled value rises above this threshold and
reaches the rising-threshold.
Options percentage—The lower threshold for the alarm entry.

Default: 70 percent of the maximum possible value

Related • Configuring the Falling Threshold or Rising Threshold on page 287

Documentation

Chapter 38: Configuration Statements: Health Monitoring
health-monitor
Syntax health-monitor {
interval seconds;
idp {
interval seconds;
}
}
Hierarchy Level [edit snmp]

Option idp introduced in Junos OS Release 9.3 for all supported platforms.
Description Configure health monitoring.


Documentation
idp (SNMP)
Syntax idp {
interval seconds;
}
Hierarchy Level [edit snmp health-monitor]
Description Configure health monitoring for Intrusion Detection and Prevention (IDP).


Documentation

interval
Syntax interval seconds;


hierarchy level.
Description Interval between samples.
Options seconds—Time between samples, in seconds.

Range: 1 through 2147483647 seconds
Default: 300 seconds

Related • Configuring the Interval on page 288

Documentation

Chapter 38: Configuration Statements: Health Monitoring
rising-threshold
Syntax rising-threshold percentage;


hierarchy level.
Description The upper threshold is expressed as a percentage of the maximum possible value for
the sampled variable. When the current sampled value is greater than or equal to this
threshold, and the value at the last sampling interval is less than this threshold, a single
event is generated. A single event is also generated if the first sample after this entry
becomes valid is greater than or equal to this threshold. After a rising event is generated,
another rising event cannot be generated until the sampled value falls below this threshold
and reaches the falling-threshold.
Options percentage—The lower threshold for the alarm entry.

Default: 80 percent of the maximum possible value

Related • falling-threshold on page 666

Documentation


CHAPTER 39
Configuration Statements: Remote

Monitoring (RMON)
• alarm (SNMP RMON) on page 672

• community on page 673
• description on page 673
• event on page 674
• falling-event-index on page 675
• falling-threshold-interval on page 677
• request-type on page 678
• rising-event-index on page 679
• rmon on page 680
• sample-type on page 681
• startup-alarm on page 682
• syslog-subtag on page 683
• type on page 684
• variable on page 685

alarm (SNMP RMON)
Supported Platforms ACX Series, EX Series, M Series, MX Series, OCX1100, PTX Series, QFX Series, SRX320, T
Series
Syntax alarm index {

interval seconds;
startup-alarm (falling-alarm | rising-alarm | rising-or-falling alarm);
}
Hierarchy Level [edit snmp rmon]

Statement introduced in Junos OS Release 11.1 for the QFX Series.
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series.
Description Configure RMON alarm entries.
Options index—Identifies this alarm entry as an integer.

Related • Configuring an RMON Alarm Entry and Its Attributes on page 244
Documentation
• event on page 674
• RMON MIB Event, Alarm, Log, and History Control Tables
• Monitoring RMON MIB Tables
• Understanding RMON

Chapter 39: Configuration Statements: Remote Monitoring (RMON)
community
Supported Platforms EX Series, M Series, MX Series, SRX Series, T Series
Syntax community community-name;
Hierarchy Level [edit snmp rmon event index]

Description The trap group that is used when generating a trap (if eventType is configured to send
traps). If that trap group has the rmon-alarm trap category configured, a trap is sent to
all the targets configured for that trap group. The community string in the trap matches
the name of the trap group (and hence, the value of eventCommunity). If nothing is
configured, traps are sent to each group with the rmon-alarm category set.
Options community-name—Identifies the trap group that is used when generating a trap if the
event is configured to send traps.

Related • Configuring an RMON Event Entry and Its Attributes on page 248
Documentation
description
Syntax description description;
Hierarchy Level [edit snmp rmon alarm index],

[edit snmp rmon event index]

Description Text description of alarm or event.
Options description—Text description of an alarm or event entry. If the description includes spaces,

Related • Configuring the Description on page 245

Documentation

event
Syntax event index {

type type;
}
Hierarchy Level [edit snmp rmon]

Description Configure RMON event entries.
Options index—Identifier for a specific event entry.

Documentation
• alarm (SNMP RMON) on page 672

falling-event-index
Syntax falling-event-index index;
Hierarchy Level [edit snmp rmon alarm index]

Description The index of the event entry that is used when a falling threshold is crossed. If this value
is zero, no event is triggered.
Options index—Index of the event entry that is used when a falling threshold is crossed.
Range: 0 through 65,535
Default: 0

Related • Configuring the Falling Event Index or Rising Event Index on page 245
Documentation
• rising-event-index on page 679

falling-threshold
Syntax falling-threshold integer;

Description The lower threshold for the sampled variable. When the current sampled value is less
than or equal to this threshold, and the value at the last sampling interval is greater than
this threshold, a single event is generated. A single event is also generated if the first
sample after this entry becomes valid is less than or equal to this threshold, and the
associated startup-alarm value is equal to falling-alarm value or rising-or-falling-alarm
value. After a falling event is generated, another falling event cannot be generated until
the sampled value rises above this threshold and reaches the rising-threshold.
Options integer—The lower threshold for the alarm entry.

Range: -2,147,483,648 through 2,147,483,647
Default: 20 percent less than rising-threshold


Documentation

falling-threshold-interval
Syntax falling-threshold-interval seconds;

Description Interval between samples when the rising threshold is crossed. Once the alarm crosses
the falling threshold, the regular sampling interval is used.

Range: 1 through 2,147,483,647 seconds
Default: 60 seconds

Related • Configuring the Falling Threshold Interval on page 246

Documentation
interval
Syntax interval seconds;

Description Interval between samples.

Range: 1 through 2,147,483,647 seconds
Default: 60 seconds

Related • Configuring the Interval on page 246

Documentation

request-type
Syntax request-type (get-next-request | get-request | walk-request);

Description Extend monitoring to a specific SNMP object instance (get-request), or extend monitoring
to all object instances belonging to a MIB branch (walk-request), or extend monitoring
to the next object instance after the instance specified in the configuration
(get-next-request).
Options get-next-request—Performs an SNMP get next request.
get-request—Performs an SNMP get request.
walk-request—Performs an SNMP walk request.

Default: walk-request

Related • Configuring the Request Type on page 247

Documentation
• variable on page 685

rising-event-index
Syntax rising-event-index index;

Description Index of the event entry that is used when a rising threshold is crossed. If this value is
zero, no event is triggered.
Options index—Index of the event entry that is used when a rising threshold is crossed.
Range: 0 through 65,535
Default: 0

Related • Configuring the Falling Event Index or Rising Event Index on page 245
Documentation
• falling-event-index on page 675

rising-threshold
Syntax rising-threshold integer;

Description Upper threshold for the sampled variable. When the current sampled value is greater
than or equal to this threshold, and the value at the last sampling interval is less than
this threshold, a single event is generated. A single event is also generated if the first
sample after this entry becomes valid is greater than or equal to this threshold, and the
associated startup alarm value is equal to the falling alarm or rising or falling alarm value.
After a rising event is generated, another rising event cannot be generated until the
sampled value falls below this threshold and reaches the falling threshold.
Options integer—The lower threshold for the alarm entry.

Range: –2,147,483,648 through 2,147,483,647


Documentation
rmon
Syntax rmon { ... }

Description Configure Remote Monitoring.

Related • Configuring an RMON Alarm Entry and Its Attributes on page 244
Documentation

sample-type
Syntax sample-type (absolute-value | delta-value);

Description Method of sampling the selected variable.
Options absolute-value—Actual value of the selected variable is used when comparing against
the thresholds.
delta-value—Difference between samples of the selected variable is used when comparing

against the thresholds.

Related • Configuring the Sample Type on page 247

Documentation

startup-alarm
Syntax startup-alarm (falling-alarm | rising-alarm | rising-or-falling-alarm);

Description The alarm that can be sent upon entry startup.
Options falling-alarm—Generated if the first sample after the alarm entry becomes active is less
than or equal to the falling threshold.
rising-alarm—Generated if the first sample after the alarm entry becomes active is greater
than or equal to the rising threshold.
rising-or-falling-alarm—Generated if the first sample after the alarm entry becomes active
satisfies either of the corresponding thresholds.
Default: rising-or-falling-alarm

Related • Configuring the Startup Alarm on page 247

Documentation

syslog-subtag
Syntax syslog-subtag syslog-subtag;

Description Add a tag to the system log message.
Options syslog-subtag syslog-subtag—Tag of not more than 80 uppercase characters to be added

to syslog messages.
Default: None

Related • Configuring the System Log Tag on page 248

Documentation

type
Syntax type type;
Hierarchy Level [edit snmp rmon event index]

Description Type of notification generated when a threshold is crossed.
Options type—Type of notification:
• log—Add an entry to logTable.
• log-and-trap—Send an SNMP trap and make a log entry.
• none—No notifications are sent.
• snmptrap—Send an SNMP trap.
Default: log-and-trap

Documentation

variable
Syntax variable oid-variable;

Description Object identifier (OID) of MIB variable to be monitored.
Options oid-variable—OID of the MIB variable that is being monitored. The OID can be a dotted
decimal (for example, 1.3.6.1.2.1.2.1.2.2.1.10.1). Alternatively, use the MIB object name
(for example, ifInOctets.1).

Related • Configuring the Variable on page 248

Documentation


CHAPTER 40
Configuration Statements: Resource

Monitoring for Memory Regions
• free-fw-memory-watermark (Resource Monitor) on page 687

• free-heap-memory-watermark (Resource Monitor) on page 688
• free-nh-memory-watermark (Resource Monitor) on page 689
• high-threshold (Resource Monitor) on page 690
• no-logging (Resource Monitor) on page 690
• resource-category jtree (Resource Monitor) on page 691
• resource-monitor on page 692
• traceoptions (Resource Monitor) on page 693
free-fw-memory-watermark (Resource Monitor)
Syntax free-fw-memory-watermark number;
Hierarchy Level [edit system services resource-monitor]
Release Information Statement introduced in Junos OS Release 15.1 for MX80, MX104, MX240, MX480, MX960,
MX2010, and MX2020 routers.
Description Configure the percentage of free memory space used for firewall or filters to be monitored
with a watermark value. You can configure the resource-monitoring capability on MX80,
MX104, MX240, MX480, MX960, MX2010, and MX2020 routers with I-chip-based DPCs
and Trio-based FPCs.
Options number—Percentage of free memory space used for firewall and filters to be monitored
with a watermark value. When the configured watermark is exceeded, error logs are
triggered. The default watermark values for the percentage of free ukernel or heap
memory, next-hop memory, and firewall filter memory are 20.


free-heap-memory-watermark (Resource Monitor)
Syntax free-heap-memory-watermark number;
Description Configure the percentage of free memory space used for ukernel or heap (ASIC) memory
to be monitored with a watermark value. You can configure the resource-monitoring
capability on MX80, MX104, MX240, MX480, MX960, MX2010, and MX2020 routers with
I-chip-based DPCs and Trio-based FPCs.
Options number—Percentage of free memory space used for ukernel or heap to be monitored
with a watermark value. When the configured watermark is exceeded, error logs are
triggered. The default watermark values for the percentage of free ukernel or heap
memory, next-hop memory, and firewall filter memory are 20.


Chapter 40: Configuration Statements: Resource Monitoring for Memory Regions
free-nh-memory-watermark (Resource Monitor)
Syntax free-nh-memory-watermark number;
Description Configure the percentage of free memory space used for next-hops to be monitored with
a watermark value. The default value and the configured value of the watermark value
for the percentage of free next-hop memory also applies to encapsulation memory. You
can configure the resource-monitoring capability on MX80, MX104, MX240, MX480,
MX960, MX2010, and MX2020 routers with I-chip-based DPCs and Trio-based FPCs.
Options number—Percentage of free memory space used for next-hops to be monitored with a
watermark value. The NH memory watermark is applicable only for encapsulation
memory (output WAN static RAM memory). When the configured watermark is
exceeded, error logs are triggered. The default watermark values for the percentage
of free ukernel or heap memory, next-hop memory, and firewall filter memory are
20.


high-threshold (Resource Monitor)
Syntax high-threshold number;
Description Configure the high threshold value, exceeding which warnings or error logs are generated,
for all the regions of memory, such as heap or ukernel, next-hop and encapsulation, and
firewall filter memory. You can configure the resource-monitoring capability on MX80,
MX104, MX240, MX480, MX960, MX2010, and MX2020 routers with I-chip-based DPCs
and Trio-based FPCs.
Options number—High threshold percentage for memory resource utilization


no-logging (Resource Monitor)
Syntax no-logging;
Description Disable the generation of error log messages when the utilization of memory resources
exceeds the threshold or checkpoint levels. By default, messages are written to
/var/log/rsmonlog.
Options no-logging—Disable the generation of error log messages when the utilization of memory
resources exceeds the configured level. By default, error logs are recorded when the
resource level utilization is exceeded.


resource-category jtree (Resource Monitor)
Supported Platforms MX2010, MX2020, MX240, MX480, MX960
Syntax resource-category jtree {

resource-type contiguous-pages (continguous-pages | free-dwords | free-pages) {
low-watermark number;
high-watermark number;
}
}
Release Information Statement introduced in Junos OS Release 15.1 for MX240, MX480, MX960, MX2010,
and MX2020 routers.
Description Define the resource category that you want to monitor and analyze for ensuring system
stability, especially the health and operating efficiency of I-chip-based line cards and
Trio-based FPCs on MX Series routers. The resource category includes detailed CPU
utilization, session rate, and session count statistics. You use the resource category
statistics to understand the extent to which new attack objects or applications affect
performance. The jtree memory on all MX Series router Packet Forwarding Engines has
two segments: one segment primarily stores routing tables and related information, and
the other segment primarily stores firewall-filter-related information. The Junos OS
provides the memory-enhanced statement to reallocate the jtree memory for routes,
firewall filters, and Layer 3 VPNs.
Options jtree—Specify the Jtree resource category for which you want to monitor the health
(working condition), operating efficiency, traffic-handling capacity, and performance
status.


resource-monitor
Supported Platforms MX2010, MX2020, MX240, MX480, MX960
Syntax resource-monitor {
free-fw-memory-watermark number;
free-heap-memory-watermark number;
free-nh-memory-watermark number;
high-threshold number;
no-logging;
no-throttle;
resource-category jtree {
resource-type contiguous-pages (continguous-pages | free-dwords | free-pages) {
low-watermark number;
high-watermark number;
}
}
traceoptions {
file filename <files number> <match regular-expression> <size maximum-file-size>
<world-readable | no-world-readable>;
flag flag;
no-remote-trace;
}
}
Hierarchy Level [edit system services]
Release Information Statement introduced in Junos OS Release 15.1 for MX240, MX480, MX960, MX2010,
and MX2020 routers.
Description Enable the resource monitoring capability to provision sufficient headroom (memory
space limits that are set for the application or virtual router) for monitoring the health
and operating efficiency of DPCs and MPCs. This feature also enables the memory
resource monitoring mechanism to avoid the system operations from compromising on
the health and traffic-handling stability of the line cards by generating error logs when
a specified watermark value for memory regions and threshold value for the jtree memory
region are exceeded. A trade-off on the system performance can be detrimental for
supporting live traffic and protocols.
You can configure the resource-monitoring capability on MX240, MX480, MX960, MX2010,
and MX2020 routers with I-chip-based DPCs and Trio-based FPCs.

Related • Diagnosing and Debugging System Performance By Configuring Memory Resource

Documentation Usage Monitoring on MX Series Routers on page 515
• Resource Monitoring Mechanism on MX Series Routers Overview on page 512
• Resource Monitoring Usage Computation Overview on page 509

traceoptions (Resource Monitor)
file filename <files number> <match regular-expression > <size maximum-file-size>
<world-readable | no-world-readable>;
flag flag;
}
Description Define tracing operations for the memory resource utilization processes.
Options file filename—Name of the file to receive the output of the tracing operation. All files are
placed in the directory /var/log.
Default: rmopd
files number—(Optional) Maximum number of trace files to create before overwriting the
oldest one. If you specify a maximum number of files, you also must specify a
maximum file size with the size option.
Default: 3 files
match regular-expression—(Optional) Refine the output to include lines that contain the
regular expression.
size maximum-file-size—(Optional) Maximum size of each trace file. By default, the number
entered is treated as bytes. Alternatively, you can include a suffix to the number to
indicate kilobytes (KB), megabytes (MB), or gigabytes (GB). If you specify a maximum
file size, you also must specify a maximum number of trace files with the files option.
Default: 128 KB
world-readable—(Optional) Enable unrestricted file access.
no-world-readable—(Default) Disable unrestricted file access. This means the log file
can be accessed only by the user who configured the tracing operation.
flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements. You can include the following flags:
• all—Trace all operations.
Required Privilege trace—To view this statement in the configuration.

Level trace-control—To add this statement to the configuration.


CHAPTER 41
Configuration Statements: Security

Alarms
• decryption-failures on page 695

• idp (Security Alarms) on page 696
decryption-failures
Syntax decryption-failures {
threshold value;
}
Hierarchy Level [edit security alarms potential-violation]
Description Raise a security alarm after exceeding a specified number of decryption failures. This
statement is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, and
SRX1500 devices and vSRX instances.
Default Multiple decryption failures do not cause an alarm to be raised.
Options failures—Number of decryption failures up to which an alarm is not raised. When the
configured number is exceeded, an alarm is raised.
Range: 0 through 1 through 1,000,000,000.
Default: 1000

Related • IPsec VPN Overview

Documentation

idp (Security Alarms)
Syntax idp;
Hierarchy Level [edit security alarms potential-violation]
Description Configure alarms for IDP attack.


CHAPTER 42
Configuration Statements: SNMP
• access-list on page 698

• agent-address on page 699
• alarm-id on page 700
• alarm-list-name on page 701
• alarm-management on page 702
• alarm-state on page 703
• authorization on page 704
• categories on page 705
• client-list on page 706
• client-list-name on page 706
• clients on page 707
• commit-delay on page 708
• community (SNMP) on page 709
• contact (SNMP) on page 710
• description on page 710
• destination-port on page 711
• enterprise-oid on page 711
• filter-duplicates on page 712
• filter-interfaces on page 712
• interface (SNMP) on page 713
• location (SNMP) on page 713
• logical-system on page 714
• logical-system-trap-filter on page 715
• name on page 715
• nonvolatile on page 716
• oid on page 716
• proxy (snmp) on page 717
• routing-instance on page 718

• routing-instance-access on page 719

• snmp on page 719
• snmp-value-match-msmic (Services NAT Options) on page 720
• source-address on page 720
• targets on page 721
• traceoptions (SNMP) on page 722
• trap-group on page 724
• trap-options on page 725
• version (SNMP) on page 726
• view (Associating a MIB View with a Community) on page 726
access-list
Syntax [edit snmp]

access-list {
routing-instance;
routing-instance restrict;
}
}
Hierarchy Level [edit snmp routing-instance-access]
Description Create access lists to control SNMP agents in routing instances from accessing SNMP
information. To enable the SNMP agent on a routing instance to access SNMP information,
specify the routing instance name. To disable the SNMP agent on a routing instance from
accessing SNMP information, include the routing-instance name followed by the restrict
keyword.

Related • routing-instance-access on page 719

Documentation

Chapter 42: Configuration Statements: SNMP
agent-address
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, SRX Series, T Series
Syntax agent-address outgoing-interface;
Hierarchy Level [edit snmp trap-options]

Description Set the agent address of all SNMPv1 traps generated by this router or switch. Currently,
the only option is outgoing-interface, which sets the agent address of each SNMPv1 trap
to the address of the outgoing interface of that trap.
Options outgoing-interface—Value of the agent address of all SNMPv1 traps generated by this
router or switch. The outgoing-interface option sets the agent address of each SNMPv1
trap to the address of the outgoing interface of that trap.
Default: disabled (the agent address is not specified in SNMPv1 traps).

Related • Configuring the Agent Address for SNMP Traps on page 111
Documentation

alarm-id
Syntax alarm-id id {
alarm-state state {
}
}
Hierarchy Level [edit snmp alarm-management alarm-list-name]
Description Specify the identifier of the alarm that you need to configure.
The remaining statement is explained separately.

Related • alarm-list-name on page 701

Documentation
• jnxAlarmMib

alarm-list-name
Syntax alarm-list-name list-name {

alarm-id id {
alarm-state state {
}
}
}
Hierarchy Level [edit snmp alarm-management]
Description Specify the name of the alarm list that you need to configure.

Related • alarm-id on page 700

Documentation
• jnxAlarmMib

alarm-management
Syntax alarm-management {
alarm-list-name list-name {
alarm-id id {
alarm-state state {
}
}
}
}
Description Configure the alarm management system to monitor and report active alarms as well
as the history of alarms through the SNMP MIB tables supported by the Alarm MIB.
NOTE: You cannot configure alarms without notifications. It is mandatory

to include the notification identifier in the configuration.


Documentation
• jnxAlarmMib

alarm-state
Syntax alarm-state state {

}
Hierarchy Level [edit snmp alarm-management alarm-list-name]
Description Specify the state of the alarm and the other parameters that you need to monitor.
Options description alarm-description—Include a brief description of the alarm.
notification-id notification-id-of-alarm—Specify the identifier of the notification associated

with the alarm.
resource-prefix alarm-resource-prefix—Specify the resource prefix of the alarm.
varbind-index varbind-index-in-alarm-varbind-list—Specify the varbind index in the alarm

varbind list.
varbind-subtree alarm-varbind-subtree—Specify the subtree of the varbind.
varbind-value alarm-varbind-value—Specify the varbind value of the alarm.



Documentation
• jnxAlarmMib

authorization
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, SRX
Series, T Series
Syntax authorization authorization;
Hierarchy Level [edit snmp community community-name]

Description Set the access authorization for SNMP Get, GetBulk, GetNext, and Set requests.
Options authorization—Access authorization level:
• read-only—Enable Get, GetNext, and GetBulk requests.
• read-write—Enable all requests, including Set requests. You must configure a view to
enable Set requests.
Default: read-only


Documentation

categories
Series, T Series
Syntax categories {
category;
}
Hierarchy Level [edit snmp trap-group group-name]

Description Define the types of traps that are sent to the targets of the named trap group.
Default If you omit the categories statement, all trap types are included in trap notifications.
Options category—Name of a trap type: authentication, chassis, configuration, link,

remote-operations, rmon-alarm, routing, services, sonet-alarms, startup, or vrrp-events.


Documentation

client-list
Syntax client-list client-list-name {

ip-addresses;
}

Statement introduced in Junos OS Release 11.1 for QFX Series switches.
Description Define a list of SNMP clients.
Options client-list-name—Name of the client list.
ip-addresses—IP addresses of the SNMP clients to be added to the client list,


Documentation
client-list-name
Syntax client-list-name client-list-name;

Description Add a client list or prefix list to an SNMP community.
Options client-list-name—Name of the client list or prefix list.


Documentation

clients
Syntax clients {
address <restrict>;
}

Description Specify the IPv4 or IPv6 addresses of the SNMP client hosts that are authorized to use
this community.
Default If you omit the clients statement, all SNMP clients using this community string are
authorized to access the router.
Options address—Address of an SNMP client that is authorized to access this router. You must
specify an address, not a hostname. To specify more than one client, include multiple
address options.
restrict—(Optional) Do not allow the specified SNMP client to access the router.


Documentation

commit-delay
Series, T Series
Syntax commit-delay seconds;
Hierarchy Level [edit snmp nonvolatile]

Description Configure the timer for the SNMP Set reply and start of the commit.
Options seconds—Delay between an affirmative SNMP Set reply and start of the commit.
Default: 5 seconds

Related • Configuring the Commit Delay Timer on page 98

Documentation

community (SNMP)
Syntax community community-name {

clients {
address restrict;
}
view view-name;
}

Description Define an SNMP community. An SNMP community authorizes SNMP clients based on
the source IP address of incoming SNMP request packets. A community also defines
which MIB objects are available and the operations (read-only or read-write) allowed
on those objects.
The SNMP client application specifies an SNMP community name in Get, GetBulk, GetNext,
and Set SNMP requests.
Default If you omit the community statement, all SNMP requests are denied.
Options community-name—Community string. If the name includes spaces, enclose it in quotation

marks (" ").


Documentation

contact (SNMP)
Syntax contact contact;

Description Define the value of the MIB II sysContact object, which is the contact person for the
managed system.
Options contact—Name of the contact person. If the name includes spaces, enclose it in quotation
marks (" ").

Related • Configuring the System Contact on a Device Running Junos OS on page 94

Documentation
description
Supported Platforms EX Series, M Series, MX Series, QFX Series, SRX Series, T Series, vSRX
Syntax description description;

Description Define the value of the MIB II sysDescription object, which is the description of the system
being managed.
Options description—System description. If the name includes spaces, enclose it in quotation

marks (" ").

Related • Configuring the System Description on a Device Running Junos OS on page 95

Documentation

destination-port
Syntax destination-port port-number;
Hierarchy Level [edit snmp trap-group]

Description Assign a trap port number other than the default.
Default If you omit this statement, the default port is 162.
Options port-number—SNMP trap port number.


Documentation
enterprise-oid
Syntax enterprise-oid;
Release Information Statement introduced in Junos OS Release 10.0
Description Add the snmpTrapEnterprise object, which shows the association between an
enterprise-specific trap and the organization that defined the trap, to standard SNMP
traps. By default, the snmpTrapEnterprise object is added only to the enterprise-specific
traps. When the enterprise-oid statement is included in the configuration,
snmpTrapEnterprise is added to all the traps generated from the device.


Documentation

filter-duplicates
Syntax filter-duplicates;

Description Filter duplicate Get, GetNext, or GetBulk SNMP requests.

Related • Filtering Duplicate SNMP Requests on page 98

Documentation
filter-interfaces
Syntax filter-interfaces {
interfaces {
all-internal-interfaces;
interface 1;
interface 2;
}
}
Release Information Statement introduced in Junos OS Release 9.4 for EX Series Switches.
Description Filter out information related to specific interfaces from the output of SNMP Get and
GetNext requests performed on interface-related MIBs.
Options all-internal-interfaces—Filters out information from SNMP Get and GetNext requests for
the specified interfaces.
interfaces—Specifies the interfaces to filter out from the output of SNMP Get and GetNext
requests.

Related • Filtering Interface Information Out of SNMP Get and GetNext Output on page 115
Documentation

interface (SNMP)
Supported Platforms ACX Series, EX Series, M120, MX240, OCX1100, PTX Series, QFabric System, QFX Series,
SRX Series, T1600, T640
Syntax interface [ interface-names ];

Description Configure the interfaces on which SNMP requests can be accepted.
Default If you omit this statement, SNMP requests entering the router or switch through any
interface are accepted.
Options interface-names—Names of one or more logical interfaces.

Documentation
location (SNMP)
Syntax location location;

Description Define the value of the MIB II sysLocation object, which is the physical location of the
managed system.
Options location—Location of the local system. You must enclose the name within quotation
marks (" ").

Related • Configuring the System Location for a Device Running Junos OS on page 95
Documentation

logical-system
Supported Platforms EX Series, M120, MX240, PTX Series, SRX Series, SRX320, T1600
Syntax logical-system logical-system-name {

routing-instance routing-instance-name;
}
Hierarchy Level [edit snmp community community-name],

[edit snmp trap-group],
[edit snmp v3target-address target-address-name]
Release Information Statement introduced in Junos OS Release 9.3

NOTE: The logical-system statement replaces the logical-router statement,

and is backward-compatible with Junos OS Release 8.3 and later.
Description Specify a logical system name for SNMP v1 and v2c clients.
Include at the [edit snmp trap-options] hierarchy level to specify a logical-system address
as the source address of an SNMP trap.
Include at the [edit snmp v3 target-address] hierarchy level to specify a logical-system

name as the destination address for an SNMPv3 trap or inform.
Options logical-system-name–Name of the logical system.
routing-instance routing-instance-name–Statement to specify a routing instance associated

with the logical system.

Related • Specifying a Routing Instance in an SNMPv1 or SNMPv2c Community on page 173

Documentation

logical-system-trap-filter
Syntax logical-system-trap-filter;
Description Restrict the routing instances from receiving traps that are not related to the logical
system networks to which they belong.

Related • SNMP Traps Supported for Routing Instances on page 171

Documentation
name
Syntax name name;

Description Set the system name from the command-line interface.
Options name—System name override.

Related • Configuring a Different System Name on page 97

Documentation

nonvolatile
Syntax nonvolatile {
}

The commit-delay statement introduced in Junos OS Release 9.0 for EX Series switches.
Description Configure options for SNMP Set requests.
The statement is explained separately.

Related • Configuring the Commit Delay Timer on page 98

Documentation
• commit-delay on page 708
oid
Syntax oid object-identifier (exclude | include);
Hierarchy Level [edit snmp view view-name]

Description Specify an object identifier (OID) used to represent a subtree of MIB objects.
Options exclude—Exclude the subtree of MIB objects represented by the specified OID.
include—Include the subtree of MIB objects represented by the specified OID.
object-identifier—OID used to represent a subtree of MIB objects. All MIB objects

represented by this statement have the specified OID as a prefix. You can specify
the OID using either a sequence of dotted integers or a subtree name.

Related • Configuring MIB Views on page 116

Documentation

proxy (snmp)
Syntax proxy proxy-name{

device-name device-name;
logical-system logical-system {
}
(version-v1 | version-v2c) {
snmp-community community-name;
no-default-comm-to-v3-config;
}
version-v3 {
}
}
Description Configure a device to act as a proxy SNMP agent, and specify a name for the proxy.
Options context context-name—Specify the SNMPv3 context name as configured on the device
specified at edit snmp proxy proxy-name device-name device-name.
For more information about this statement, see context.
device-name device-name—Specify the name of the device to be managed through the

proxy SNMP agent.
no-default-comm-to-v3-config—(Optional) Specify whether you have to manually

configure the statements at the [edit snmp v3 snmp-community community-name]
and [edit snmp v3 vacm] hierarchy levels.
If this statement is not included in the configuration, the [edit snmp v3
snmp-community community-name] and [edit snmp v3 vacm] hierarchy level
configurations are automatically initialized.
proxy-name—Specify the name of the proxy.
security-name security-name—Specify the SNMPv3 security name as configured on the

device specified at edit snmp proxy proxy-name device-name device-name.
For more information about this statement, see security-name.
snmp-community community-name—Specify the name of the SNMP community. The

community name you configure should match the snmp-community configuration
on the device specified at edit snmp proxy proxy-name device-name device-name. For
more information about this statement, see snmp-community.
(version-v1 | version-v2c)—Specify the SNMP version, and add the relevant configuration.

version-v3—Add the SNMPv3 configuration.

Related • Configuring a Proxy SNMP Agent on page 104

Documentation
routing-instance
Syntax routing-instance routing-instance-name;
Hierarchy Level [edit snmp community community-name],

[edit snmp community community-name logical-system logical-system-name],
[edit snmp trap-group group]

Added to the [edit snmp community community-name] hierarchy level in Junos OS
Release 8.4.
Added to the [edit snmp community community-name logical-system logical-system-name]
hierarchy level in Junos OS Release 9.1.
Description Specify a routing instance for SNMPv1 and SNMPv2 trap targets. All targets configured
in the trap group use this routing instance.
If the routing instance is defined within a logical system, include the logical-system
logical-system-name statement at the [edit snmp community community-name] hierarchy
level and specify the routing-instance statement under the [edit snmp community
community-name logical-system logical system-name] hierarchy level.
Options routing-instance-name—Name of the routing instance.


Documentation
• Configuring the Source Address for SNMP Traps on page 109

routing-instance-access
Syntax [edit snmp]

access-list {
routing-instance;
routing-instance restrict;
}
}
Description Enable SNMP managers in routing instances other than the default routing instance to
access SNMP information. For information about the access-list option, see access-list.

Related • Enabling SNMP Access over Routing Instances on page 173

Documentation
snmp
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, T Series
Syntax snmp { ... }
Hierarchy Level [edit]

Description Configure SNMP.
SNMP modules cannot have the slash (/) character or the @ character in the name.


Documentation

snmp-value-match-msmic (Services NAT Options)
Syntax snmp-value-match-msmic;
Hierarchy Level [edit services service-set service-set-name nat-options]
Release Information Statement introduced with Junos OS Release 13.3R7
Description Match the values for MS-MIC-specific objects in the jnxNatObjects MIB table with the
values for MS-DPC objects. Use the deactivate services service-set service-set-name
nat-options snmp-value-match-msmic configuration mode command to disable this
feature. By default, this feature is disabled.
Required Privilege control—To add this statement to the configuration.

Level
Related • Configuring Service Rules

Documentation
• Troubleshooting the Mismatch of jnxNatObjects Values for MS-DPC and MS-MIC on
page 517
source-address
Syntax source-address address;

Description Set the source address of every SNMP trap packet sent by this router to a single address
regardless of the outgoing interface. If the source address is not specified, the default is
to use the address of the outgoing interface as the source address.
Options address—Source address of SNMP traps. You can configure the source address of trap
packets two ways: lo0 or a valid IPv4 address configured on one of the router
interfaces. The value lo0 indicates that the source address of all SNMP trap packets
is set to the lowest loopback address configured at interface lo0.
Default: Disabled. (The source address is the address of the outgoing interface.)

Related • Configuring the Source Address for SNMP Traps on page 109
Documentation

targets
Syntax targets {
address;
}

Description Configure one or more systems to receive SNMP traps.
Options address—IPv4 or IPv6 address of the system to receive traps. You must specify an address,
not a hostname.


Documentation

traceoptions (SNMP)
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, SRX320, T Series, vSRX
file filename <files number> <match regular-expression> <size size> <world-readable |
no-world-readable>;
flag flag;
no-remote-trace;
}

file filename option added in Junos OS Release 8.1.
world-readable | no-world-readable option added in Junos OS Release 8.1.
match regular-expression option added in Junos OS Release 8.1.
Description The output of the tracing operations is placed into log files in the /var/log directory. Each
log file is named after the SNMP agent that generates it. Currently, the following logs are
created in the /var/log directory when the traceoptions statement is used:
• chassisd
• craftd
• ilmid
• mib2d
• rmopd
• serviced
• snmpd
Options file filename—By default, the name of the log file that records trace output is the name
of the process being traced (for example, mib2d or snmpd). Use this option to specify
another name.
files number—(Optional) Maximum number of trace files per SNMP subagent. When a
trace file (for example, snmpd) reaches its maximum size, it is archived by being
renamed to snmpd.0. The previous snmpd.1 is renamed to snmpd.2, and so on. The
oldest archived file is deleted.
Default: 10 files
flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements:
• all—Log all SNMP events.

• general—Log general events.
• interface-stats—Log physical and logical interface statistics.
• nonvolatile-sets—Log nonvolatile SNMP set request handling.
• pdu—Log SNMP request and response packets.
• protocol-timeouts—Log SNMP response timeouts.
• routing-socket—Log routing socket calls.
• subagent—Log subagent restarts.
• timer—Log internally generated events.
• varbind-error—Log variable binding errors.
match regular-expression—(Optional) Refine the output to include lines that contain the
regular expression.
size size—(Optional) Maximum size, in kilobytes (KB), of each trace file before it is closed
and archived.
Default: 1000 KB
world-readable | no-world-readable—(Optional) By default, log files can be accessed

only by the user who configures the tracing operation. The world-readable option
enables any user to read the file. To explicitly set the default behavior, use the
no-world-readable option.

Related • Tracing SNMP Activity on a Device Running Junos OS on page 203

Documentation

trap-group
Supported Platforms ACX Series, EX Series, M Series, MX Series, OCX1100, PTX Series, QFabric System, QFX Series,
SRX Series, T Series, vSRX
Syntax trap-group group-name {

categories {
category;
}
targets {
address;
}
}

Statement introduced in Junos OS Release 14.1X53-D20 for OCX Series switches.
Description Create a named group of hosts to receive the specified trap notifications. The name of
the trap group is embedded in SNMP trap notification packets as one variable binding
(varbind) known as the community name. At least one trap group must be configured
for SNMP traps to be sent.
Options group-name—Name of the trap group. If the name includes spaces, enclose it in quotation
marks (" ").


Documentation

trap-options
Syntax trap-options {
}

Description Using SNMP trap options, you can set the source address of every SNMP trap packet
sent by the router or switch to a single address, regardless of the outgoing interface. In
addition, you can set the agent address of each SNMPv1 trap. For more information about
the contents of SNMPv1 traps, see RFC 1157.
Default Disabled


Documentation

version (SNMP)
Syntax version (all | v1 | v2);

Description Specify the version number of SNMP traps.
Default all—Send an SNMPv1 and SNMPv2 trap for every trap condition.
Options all—Send an SNMPv1 and SNMPv2 trap for every trap condition.
v1—Send SNMPv1 traps only.
v2—Send SNMPv2 traps only.


Documentation
view (Associating a MIB View with a Community)
Syntax view view-name;

Description Associate a view with a community. A view represents a group of MIB objects.
Options view-name—Name of the view. You must use a view name already configured in the view
statement at the [edit snmp] hierarchy level.


Documentation

view (Configuring a MIB View)
Syntax view view-name {

}

Description Define a MIB view. A MIB view identifies a group of MIB objects. Each MIB object in a view
has a common OID prefix. Each object identifier represents a subtree of the MIB object
hierarchy. The view statement uses a view to specify a group of MIB objects on which to
define access. To enable a view, you must associate the view with a community by
including the view statement at the [edit snmp community community-name] hierarchy
level.
NOTE: To remove an OID completely, use the delete view all oid oid-number
command but omit the include parameter.
Options view-name—Name of the view.


Documentation
• Associating MIB Views with an SNMP User Group on page 134
• community on page 709


CHAPTER 43
Configuration Statements: SNMPv3
• address on page 731

• address-mask on page 731
• authentication-md5 on page 732
• authentication-none on page 733
• authentication-password on page 734
• authentication-sha on page 735
• community-name on page 736
• context (SNMPv3) on page 737
• engine-id on page 738
• group (Configuring Group Name) on page 739
• group (Defining Access Privileges for an SNMPv3 Group) on page 740
• retry-count on page 740
• timeout on page 741
• local-engine on page 742
• message-processing-model on page 743
• notify on page 744
• notify-filter (Applying to the Management Target) on page 745
• notify-filter (Configuring the Profile Name) on page 745
• notify-view on page 746
• oid on page 747
• parameters on page 748
• port on page 748
• privacy-3des on page 749
• privacy-aes128 on page 750
• privacy-des on page 751
• privacy-none on page 752
• privacy-password on page 753
• read-view on page 754

• remote-engine on page 755

• routing-instance on page 756
• security-level (Defining Access Privileges) on page 757
• security-level (Generating SNMP Notifications) on page 758
• security-model (Access Privileges) on page 759
• security-model (Group) on page 760
• security-model (SNMP Notifications) on page 761
• security-name (Community String) on page 762
• security-name (Security Group) on page 763
• security-name (SNMP Notifications) on page 764
• security-to-group on page 765
• snmp-community on page 766
• tag on page 766
• tag-list on page 767
• target-address on page 768
• target-parameters on page 769
• type on page 770
• user on page 770
• usm on page 771
• v3 on page 773
• vacm on page 775
• write-view on page 776

Chapter 43: Configuration Statements: SNMPv3
address
Syntax address address;
Hierarchy Level [edit snmp v3 target-address target-address-name]

Description Specify the SNMP target address.
Options address—IPv4 address of the system to receive traps or informs. You must specify an
address, not a hostname.

Related • Configuring the Address on page 143

Documentation
address-mask
Syntax address-mask address-mask;

Statement introduced in Junos OS Release 11.1 on the QFX Series.
Description Verify the source addresses for a group of target addresses.
Options address-mask combined with the address defines a range of addresses.

Related • Configuring the Address Mask on page 143

Documentation

authentication-md5
Syntax authentication-md5 {
}
Hierarchy Level [edit snmp v3 usm local-engine user username],

[edit snmp v3 usm remote-engine engine-id user username]

Description Configure MD5 as the authentication type for the SNMPv3 user.
NOTE: You can only configure one authentication type for each SNMPv3
user.

Related • Configuring MD5 Authentication on page 129

Documentation

authentication-none
Supported Platforms ACX Series, EX4600, M Series, MX Series, OCX1100, PTX Series, QFX Series, SRX Series, T
Series
Syntax authentication-none;


Description Configure that there should be no authentication for the SNMPv3 user.
NOTE: You can configure only one authentication type for each SNMPv3
user.

Related • Configuring No Authentication on page 129

Documentation

authentication-password
Syntax authentication-password authentication-password;
Hierarchy Level [edit snmp v3 usm local-engine user username authentication-md5],

[edit snmp v3 usm local-engine user username authentication-sha],
[edit snmp v3 usm remote-engine engine-id user username authentication-md5],
[edit snmp v3 usm remote-engine engine-id user username authentication-sha]

Description Configure the password for user authentication.
Options authentication-password—Password that a user enters. The password is then converted

into a key that is used for authentication.
switch:

Related • Configuring MD5 Authentication on page 129

Documentation
• Configuring SHA Authentication on page 129

authentication-sha
Syntax authentication-sha {
}


Description Configure the secure hash algorithm (SHA) as the authentication type for the SNMPv3
user.
NOTE: You can configure only one authentication type for each SNMPv3
user.

Related • Configuring SHA Authentication on page 129

Documentation

community-name
Syntax community-name community-name;
Hierarchy Level [edit snmp v3 snmp-community community-index]

Description The community name defines an SNMP community. The SNMP community authorizes
SNMPv1 or SNMPv2 clients. The access privileges associated with the configured security
name define which MIB objects are available and the operations (notify, read, or write)
allowed on those objects.
Options community-name—Community string for an SNMPv1 or SNMPv2c community. If

unconfigured, it is the same as the community index. If the name includes spaces,
NOTE: Community names must be unique. You cannot configure the same
community name at the [edit snmp community] and [edit snmp v3
snmp-community community-index] hierarchy levels.
The community name at the [edit snmp v3 snmp-community community-index]

hierarchy level is encrypted and not displayed in the command-line interface
(CLI).


Documentation

context (SNMPv3)
Syntax context context-name;
Description Specify the SNMPv3 context for access control. A context identifies a collection of
information accessible for an SNMP entity.


Documentation

engine-id
Syntax engine-id {
(local engine-id-suffix | use-default-ip-address | use-mac-address);
}

Description The local engine ID is defined as the administratively unique identifier of an SNMPv3
engine, and is used for identification, not for addressing. There are two parts of an engine
ID: prefix and suffix. The prefix is formatted according to the specifications defined in
RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks. You can configure the suffix here.
NOTE: SNMPv3 authentication and encryption keys are generated based on

the associated passwords and the engine ID. If you configure or change the
engine ID, you must commit the new engine ID before you configure SNMPv3
users. Otherwise the keys generated from the configured passwords are
based on the previous engine ID.
For the engine ID, we recommend using the MAC address of the management
port.
Options local engine-id-suffix—Explicit setting for the engine ID suffix.
use-default-ip-address—The engine ID suffix is generated from the default IP address.
use-mac-address—The SNMP engine identifier is generated from the MAC address of

the management interface on the router.
Default: use-default-ip-address

Related • Configuring the Local Engine ID on page 126

Documentation

group (Configuring Group Name)
SRX Series, T Series
Syntax group group-name {

(default-context-prefix | context-prefix context-prefiix){
}
}
}
}
Hierarchy Level [edit snmp v3 vacm access]

Description Assign the security name to a group, and specify the SNMPv3 context applicable to the
group. The default-context-prefix statement, when included, adds all the contexts
configured on the device to the group, whereas the context-prefix context-prefix statement
enables you to specify a context and to add that particular context to the group.
(Not applicable to the QFX Series and OCX Series.) When the context prefix is specified
as default (for example, context-prefix default), the context associated with the master
routing instance is added to the group. To specify a routing instance that is part of a
logical system, specify it as logical system/routing instance. For example, to specify routing
instance ri1 in logical system ls1, include context-prefix ls1/ri1.
The remaining statements under this hierarchy are explained separately.
Options group-name—SNMPv3 group name created for the SNMPv3 group.

Related • Configuring the Group on page 133

Documentation

group (Defining Access Privileges for an SNMPv3 Group)
Syntax group group-name;
Hierarchy Level [edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c)

security-name security-name]

Description Define access privileges granted to a group.
Options group-name—Identifies a collection of SNMP security names that belong to the same
access policy SNMP.

Related • Configuring the Group on page 138

Documentation
retry-count
Syntax retry-count number;
Description Configure the retry count for SNMP informs.
Options number—Maximum number of times the inform is transmitted if no acknowledgment is

received. If no acknowledgment is received after the inform is transmitted the
maximum number of times, the inform message is discarded.
Default: 3 times

Related • Configuring SNMP Informs on page 149

Documentation
• timeout on page 741

timeout
Syntax timeout seconds;
Description Configure the timeout period (in seconds) for SNMP informs.
Options seconds—Number of seconds to wait for an inform acknowledgment. If no

acknowledgment is received within the timeout period, the inform is retransmitted.
Default: 15


Documentation
• retry-count on page 740

local-engine
Syntax local-engine {
user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none {
}
}
}
Hierarchy Level [edit snmp v3 usm]

Description Configure local engine information for the user-based security model (USM).


Documentation

message-processing-model
Supported Platforms EX Series, M Series, MX Series, QFX Series, SRX Series, T Series
Syntax message-processing-model (v1 | v2c | v3);
Hierarchy Level [edit snmp v3 target-parameters target-parameter-name parameters]

Description Configure the message processing model to be used when generating SNMP notifications.
Options v1—SNMPv1 message process model.
v2c—SNMPv2c message process model.
v3—SNMPv3 message process model.

Related • Configuring the Message Processing Model on page 147

Documentation

notify
Supported Platforms ACX Series, EX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series
Syntax notify name {

tag tag-name;
}
Hierarchy Level [edit snmp v3]

type inform option added in Junos OS Release 7.4.
Description Select management targets for SNMPv3 notifications as well as the type of notifications.
Notifications can be either traps or informs.
Options name—Name assigned to the notification.
tag-name—Notifications are sent to all targets configured with this tag.
type—Notification type is trap or inform. Traps are unconfirmed notifications. Informs are
confirmed notifications.

Related • Configuring the Inform Notification Type and Target Address on page 154
Documentation

notify-filter (Applying to the Management Target)
Syntax notify-filter profile-name;
Hierarchy Level [edit snmp v3 target-parameters target-parameters-name]

Description Specify the notify filter to be used by a specific set of target parameters.
Options profile-name—Name of the notify filter to apply to notifications.

Related • Applying the Trap Notification Filter on page 147

Documentation
notify-filter (Configuring the Profile Name)
Supported Platforms EX Series, M Series, MX Series, PTX Series, QFX Series, SRX Series, T Series
Syntax notify-filter profile-name {

}

Description Specify a group of MIB objects for which you define access. The notify filter limits the
type of traps or informs sent to the network management system.
Options profile-name—Name assigned to the notify filter.

Related • Configuring the Trap Notification Filter on page 141

Documentation
• oid on page 747

notify-view
Syntax notify-view view-name;
Hierarchy Level [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix
privacy)]

Description Associate the notify view with a community (for SNMPv1 or SNMPv2c clients) or a group
name (for SNMPv3 clients).
Options view-name—Name of the view to which the SNMP user group has access.


Documentation
• Configuring the Notify View on page 135

oid
Syntax oid oid (include | exclude);
Hierarchy Level [edit snmp v3 notify-filter profile-name]

Description Specify an object identifier (OID) used to represent a subtree of MIB objects. This OID is
a prefix that the represented MIB objects have in common.
Options exclude—Exclude the subtree of MIB objects represented by the specified OID.
include—Include the subtree of MIB objects represented by the specified OID.
oid—Object identifier used to represent a subtree of MIB objects. All MIB objects
represented by this statement have the specified OID as a prefix. You can specify
the OID using either a sequence of dotted integers or a subtree name.

Related • Configuring the Trap Notification Filter on page 141

Documentation

parameters
Syntax parameters {
security-level (none | authentication | privacy);
}
Hierarchy Level [edit snmp v3 target-parameters target-parameters-name]

Description Configure a set of target parameters for message processing and security.

Related • Defining and Configuring the Trap Target Parameters on page 146
Documentation
port
Syntax port port-number;

Description Configure a UDP port number for an SNMP target.
Default If you omit this statement, the default port is 162.
Options port-number—Port number for the SNMP target.

Related • Configuring the Port on page 144

Documentation

privacy-3des
Supported Platforms M Series, MX Series, QFX Series, SRX Series, T Series
Syntax privacy-3des {
}


Description Configure the triple Data Encryption Standard (3DES) as the privacy type for the SNMPv3
user.
Options privacy-password privacy-password—Password that a user enters. The password is then

converted into a key that is used for encryption.
switch:


Documentation

privacy-aes128
Syntax privacy-aes128 {
}


Description Configure the Advanced Encryption Standard encryption algorithm (CFB128-AES-128

Privacy Protocol) for the SNMPv3 user.

switch:


Documentation

privacy-des
Syntax privacy-des {
}


Description Configure the Data Encryption Standard (DES) as the privacy type for the SNMPv3 user.

switch:


Documentation

privacy-none
Syntax privacy-none;


Description Configure that no encryption be used for the SNMPv3 user.


Documentation

privacy-password
Syntax privacy-password privacy-password;
Hierarchy Level [edit snmp v3 usm local-engine user username privacy-3des],

[edit snmp v3 usm local-engine user username privacy-aes128],
[edit snmp v3 usm local-engine user username privacy-des],
[edit snmp v3 usm remote-engine engine-id user username privacy-3des],
[edit snmp v3 usm remote-engine engine-id user username privacy-aes128],
[edit snmp v3 usm remote-engine engine-id user username privacy-des]

Description Configure a privacy password for the SNMPv3 user.
Options privacy-password—Password that a user enters. The password is then converted into a
key that is used for encryption.
switch:


Documentation

read-view
Syntax read-view view-name;
privacy)]

Description Associate the read-only view with a community (for SNMPv1 or SNMPv2c clients) or a
group name (for SNMPv3 clients).
Options view-name—The name of the view to which the SNMP user group has access.

Related • Configuring the Read View on page 135

Documentation

remote-engine
Supported Platforms EX4600, M Series, MX Series, OCX1100, PTX Series, QFX Series, SRX Series, T Series
Syntax remote-engine engine-id {

user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none {
}
}
}
Hierarchy Level [edit snmp v3 usm]

Description Configure the remote engine information for the user-based security model (USM). To
send inform messages to an SNMPv3 user on a remote device, you must configure the
engine identifier for the SNMP agent on the remote device where the user resides.
Options engine-id—Specify engine identifier in hexadecimal format. Used to compute the security
digest for authenticating and encrypting packets sent to a user on the remote host.

Related • Configuring the Remote Engine and Remote User on page 150
Documentation

routing-instance
Syntax routing-instance routing-instance-name;

Description Specify a routing instance for an SNMPv3 trap target.
Options routing-instance-name—Name of the routing instance.
To configure a routing instance within a logical system, specify the logical system name
followed by the routing instance name. Use a slash ( / ) to separate the two names
(for example, test-ls/test-ri). To configure the default routing instance on a logical
system, specify the logical system name followed by default (for example,
test-ls/default).

Related • Configuring the Trap Target Address on page 142

Documentation

security-level (Defining Access Privileges)
Syntax security-level (authentication | none | privacy) {

}
context-prefix) security-model (any | usm | v1 | v2c)]

Description Define the security level used for access privileges.
Default none
Options authentication—Provide authentication but no encryption.
none—No authentication and no encryption.
privacy—Provide authentication and encryption.

Related • Configuring the Security Level on page 134

Documentation

security-level (Generating SNMP Notifications)
Syntax security-level (authentication | none | privacy);
Hierarchy Level [edit snmp v3 target-parameters target-parameters-name parameters]

Description Configure the security level to use when generating SNMP notifications.
Default none
Options authentication—Provide authentication but no encryption.
none—No authentication and no encryption.
privacy—Provide authentication and encryption.

Related • Configuring the Security Level on page 148

Documentation

security-model (Access Privileges)
Syntax security-model (usm | v1 | v2c);
context-prefix)]

Description Configure the security model for an SNMPv3 group. The security model is used to
determine access privileges for the group.
Options usm—SNMPv3 security model.
v1—SNMPv1 security model.
v2c—SNMPv2c security model.

Related • Configuring the Security Model on page 133

Documentation

security-model (Group)
Syntax security-model (usm | v1 | v2c) {

group group-name;
}
}
Hierarchy Level [edit snmp v3 vacm security-to-group]

Description Define a security model for a group.


Documentation

security-model (SNMP Notifications)
Syntax security-model (usm | v1 | v2c);

Description Configure the security model for an SNMPv3 group. The security model is used for SNMP
notifications.


Documentation

security-name (Community String)
Supported Platforms ACX Series, EX Series, M Series, MX Series, QFX Series, SRX Series, T Series
Syntax security-name security-name;

Description Associate a community string with the security name of a user. The community string,
which is used for SNMPv1 and SNMPv2c clients in an SNMPv3 system, is configured at
the [edit snmp v3 snmp-community community-index] hierarchy level.
Options security-name—Name that is used for messaging security and user access control.
NOTE: The security name must match the configured security name at the
[edit snmp v3 target-parameters target-parameters-name parameters] hierarchy
level when you configure traps or informs.

Related • Configuring the Security Names on page 157

Documentation

security-name (Security Group)
Syntax security-name security-name {

group group-name;
}
Hierarchy Level [edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c)]

Description Associate a group or a community string with a configured security group.
Options security-name—Username configured at the [edit snmp v3 usm local-engine user username]
hierarchy level. For SNMPv1 and SNMPv2c, the security name is the community string
configured at the [edit snmp v3 snmp-community community-index] hierarchy level.

Related • Assigning Security Names to Groups on page 138

Documentation

security-name (SNMP Notifications)
Syntax security-name security-name;

Description Configure the security name used when generating SNMP notifications.
Options security-name—If the SNMPv3 USM security model is used, identify the user when
generating the SNMP notification. If the v1 or v2c security models are used, identify
the SNMP community used when generating the notification.
NOTE: The access privileges for the group associated with this security name
must allow this notification to be sent.
If you are using the v1 or v2 security models, the security name at the [edit
snmp v3 vacm security-to-group] hierarchy level must match the security
name at the [edit snmp v3 snmp-community community-index] hierarchy level.

Related • Configuring the Security Name on page 148

Documentation

security-to-group
Syntax security-to-group {
group group-name;
}
}
Hierarchy Level [edit snmp v3 vacm]

Description Configure the group to which a specific SNMPv3 security name belongs. The security
name is used for messaging security.

Related • Assigning Security Model and Security Name to a Group on page 137
Documentation

snmp-community
Syntax snmp-community community-index {

tag tag-name;
}

Description Configure the SNMP community.
Options community-index—(Optional) String that identifies an SNMP community.


Documentation
tag
Syntax tag tag-name;
Hierarchy Level [edit snmp v3 notify name],


Description Configure a set of targets to receive traps or informs (for IPv4 packets only).
Options tag-name—Identifies the address of managers that are allowed to use a community
string.

Related • Configuring the Tag on page 158

Documentation

tag-list
Syntax tag-list tag-list;

Description Configure an SNMP tag list used to select target addresses.
Options tag-list—Define sets of target addresses (tags). To specify more than one tag, specify
the tag names as a space-separated list enclosed within double quotes.


Documentation

target-address
Syntax target-address target-address-name {

address address;
port port-number;
retry-count number;
tag-list tag-list;
timeout seconds;
}

Description Configure the address of an SNMP management application and the parameters to be
used in sending notifications.
Options target-address-name—String that identifies the target address.


Documentation

target-parameters
Syntax At the [edit snmp v3] hierarchy level:
profile-name;
parameters {
}
}
At the [edit snmp v3 target-address target-address-name] hierarchy level:


Description Configure the message processing and security parameters for sending notifications to
a particular management target. The target parameters are configured at the [edit snmp
v3] hierarchy level. The remaining statements at this level are explained separately.
Then apply the target parameters configured at the [edit snmp v3 target-parameters
target-parameters-name] hierarchy level to the target address configuration at the [edit
snmp v3] hierarchy level.

Related • Defining and Configuring the Trap Target Parameters on page 146
Documentation
• Applying Target Parameters on page 145

type
Syntax type (inform | trap);
Hierarchy Level [edit snmp v3 notify name]

inform option added in Junos OS Release 7.4.
Description Configure the type of SNMP notification.
Options inform—Defines the type of notification as an inform. SNMP informs are confirmed
notifications.
trap—Defines the type of notification as a trap. SNMP traps are unconfirmed notifications.


Documentation
user
Syntax user username;
Hierarchy Level [edit snmp v3 usm local-engine],

[edit snmp v3 usm remote-engine engine-id]

Description Specify a user associated with an SNMPv3 group on a local or remote SNMP engine.
Options username—SNMPv3 user-based security model (USM) username.


Documentation

usm
Syntax usm {
local-engine {
user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none {
}
}
user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none {
}
}
}
}
}


Description Configure user-based security model (USM) information.


Documentation

v3
Syntax v3 {
notify name {
tag tag-name;
type trap;
}
}
tag tag-name;
}
address address;
port port-number;
retry-count number;
tag-list tag-list;
timeout seconds;
}
parameters {
}
}
usm {
local-engine {
user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-des {

}
privacy-none;
}
}
user username {
}
}
privacy-aes128 {
}
privacy-des {
}
privacy-3des {
}
privacy-none {
}
}
}
}
vacm {
access {
group group-name {
}
}
}
}
}
security-to-group {
group group-name;
}
}
}
}
}


Description Configure SNMPv3.


Documentation
vacm
Syntax vacm {
access {
group group-name {
}
}
}
}
}
security-to-group {
group group-name;
}
}
}

Description Configure view-based access control model (VACM) information.

Related • Defining Access Privileges for an SNMP Group on page 132

Documentation

write-view
Syntax write-view view-name;
privacy)]

Statement introduced in Junos OS Release 11.1 for the QFX Series switches.
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series.
Description Associate the write view with a community (for SNMPv1 or SNMPv2c clients) or a group
name (for SNMPv3 clients).
Options view-name—Name of the view for which the SNMP user group has write permission.


Documentation
• Configuring the Write View on page 136

CHAPTER 44
Operational Commands
• clear chassis cluster ip-monitoring failure-count

• clear chassis cluster ip-monitoring failure-count ip-address
• clear ilmi statistics
• clear snmp history
• clear snmp statistics
• request pppoe connect
• request pppoe disconnect
• request services ip-monitoring preempt-restore policy
• request snmp spoof-trap
• show chassis cluster ip-monitoring status redundancy-group
• show interfaces (SRX Series)
• show interfaces snmp-index
• show interfaces summary
• show ilmi statistics
• show security alarms
• show security datapath-debug capture
• show security datapath-debug counter
• show security monitoring
• show security monitoring fpc fpc-number
• show security monitoring performance session
• show security monitoring performance spu
• show services ip-monitoring status
• show snmp health-monitor
• show snmp inform-statistics
• show snmp mib
• show snmp rmon
• show snmp statistics

• show snmp stats-response-statistics

• show snmp v3
• show system resource-monitor fpc

Chapter 44: Operational Commands
clear chassis cluster ip-monitoring failure-count
Syntax clear chassis cluster ip-monitoring failure-count
Description Clear the failure count for all IP addresses.
Required Privilege clear

Level
Related • clear chassis cluster ip-monitoring failure-count

Documentation
• clear chassis cluster ip-monitoring failure-count ip-address on page 780
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
user@host> clear chassis cluster ip-monitoring failure-count
node0:
--------------------------------------------------------------------------
Cleared failure count for all IPs
node1:
--------------------------------------------------------------------------
Cleared failure count for all IPs

clear chassis cluster ip-monitoring failure-count ip-address
Syntax clear chassis cluster ip-monitoring failure-count ip-address 1.1.1.1
Description Clear the failure count for a specified IP address.
NOTE: Entering an IP address at the end of this command is optional. If you

do not specify an IP address, the failure count for all monitored IP addresses
is cleared.

Level
Related • clear chassis cluster failover-count

Documentation
• clear chassis cluster ip-monitoring failure-count on page 779
Sample Output
user@host> clear chassis cluster ip-monitoring failure-count ip-address 1.1.1.1
node0:
--------------------------------------------------------------------------
Cleared failure count for IP: 1.1.1.1
node1:
--------------------------------------------------------------------------
Cleared failure count for IP: 1.1.1.1

clear ilmi statistics
Supported Platforms EX Series, M Series, MX Series, PTX Series, T Series
Syntax clear ilmi statistics
Release Information Command introduced before Junos OS Release 7.4.
Description Set Integrated Local Management Interface (ILMI) statistics to zero.
Options This command has no options.

Level
Related • show ilmi statistics on page 833

Documentation
List of Sample Output clear ilmi statistics on page 781
Sample Output
clear ilmi statistics
user@host> clear ilmi statistics

clear snmp history
Supported Platforms EX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, T Series
Syntax clear snmp history (index | all)

Command introduced in Junos OS Release 9.0 for EX Series switches.
Command introduced in Junos OS Release 11.1 for the QFX Series.
Description Delete the history record of Simple Network Management Protocol (SNMP) samples of
Ethernet statistics collected.
Options all—Clear all the entries in the history index.
index—Clear the contents of the specified entry in the history index.

Level
Related • clear snmp statistics on page 783

Documentation

clear snmp statistics
Supported Platforms EX Series, M Series, MX Series, OCX1100, PTX Series, QFX Series, T Series
Syntax clear snmp statistics

Description Clear Simple Network Management Protocol (SNMP) statistics.

Level
Related • show snmp statistics on page 870

Documentation
List of Sample Output clear snmp statistics on page 783
Output Fields See show snmp statistics for an explanation of output fields.
Sample Output
clear snmp statistics
In the following example, SNMP statistics are displayed before and after the clear snmp
statistics command is issued:
user@host> show snmp statistics

SNMP statistics:
Input:
Silent drops: 0, Proxy drops 0
Output:
user@host> clear snmp statistics

SNMP statistics:
Input:


Output:

request pppoe connect
Syntax request pppoe connect
Release Information Statement supported on SRX300, SRX320, SRX340, and SRX345 is introduced in Junos
OS Release 15.1X49-D60.
Statement supported on SRX1500 and vSRX instances is introduced in Junos OS Release
15.1X49-D70.
Description Connect all sessions that are down.
Options pppoe interface name— (Optional) Connect to a specified session.
Required Privilege maintenance

Level
List of Sample Output request pppoe connect on page 785
Output Fields When you enter this command, this command returns no output.
Sample Output
request pppoe connect
user@host> request pppoe connect

request pppoe disconnect
Syntax request pppoe disconnect
Release Information Statement supported on SRX300, SRX320, SRX340, and SRX345 is introduced in Junos
Statement supported on SRX1500 and vSRX instances is introduced in Junos OS Release
15.1X49-D70.
Description Disconnect all active sessions.
Options session id — (Optional) Disconnect the session for which the session ID is specified.
pppoe interface name— (Optional) Disconnect the session for a specific pppoe interface
name.

Level
List of Sample Output request pppoe disconnect on page 786
Output Fields When you enter this command, this command returns no output.
Sample Output
request pppoe disconnect
user@host> request pppoe disconnect

request services ip-monitoring preempt-restore policy
Syntax request services ip-monitoring preempt-restore policy

<policy-name>
Description If the no–preempt option is specified, the policy will not perform preemptive failback
when it is in a failover state, and when the RPM probe test recovers from failure. To
manually revert to the failback state, run the request services ip-monitoring preempt-restore
policy command.
NOTE: The request services ip-monitoring preempt-restore policy command

takes effect only when the RPM probe is in the pass state, and when the
policy is in a failover state.
Options policy name—Name of the policy.

Level
Related • show services ip-monitoring status on page 850

Documentation
List of Sample Output run request services ip-monitoring preempt-restore policy <policy name> on page 787
Output Fields When you run this command, the policy is restored to the failback state.
Sample Output
run request services ip-monitoring preempt-restore policy <policy name>
user@host> run request services ip-monitoring preempt-restore policy policy1
Restore request succeeded: Policy policy1

request snmp spoof-trap
Supported Platforms EX Series, M Series, MX Series, OCX1100, PTX Series, QFabric System, QFX Series, T Series
Syntax request snmp spoof-trap

<trap> variable-bindings <object> <instance> <value>

Description Spoof (mimic) the behavior of a Simple Network Management Protocol (SNMP) trap.
Options <trap>—Name of the trap to spoof.
variable-bindings <object> <instance> <value>—(Optional) List of variables and values

to include in the trap. Each variable binding is specified as an object name, the object
instance, and the value (for example, ifIndex[14] = 14). Enclose the list of variable
bindings in quotation marks (“ “) and use a comma to separate each object name,
instance, and value definition (for example, variable-bindings “ifIndex[14] = 14,
ifAdminStatus[14] = 1, ifOperStatus[14] = 2”). Objects included in the trap definition
that do not have instances and values specified as part of the command are included
in the trap and spoofed with automatically generated instances and values.
<dummy name>—A dummy trap name to display the list of available traps.
Question mark (?)—Question mark? to display possible completions.
Required Privilege request

Level
List of Sample Output request snmp spoof-trap (with Variable Bindings) on page 788
request snmp spoof-trap (Illegal Trap Name) on page 788
request snmp spoof-trap (Question Mark ?) on page 792
Sample Output
request snmp spoof-trap (with Variable Bindings)
user@host> request snmp spoof-trap linkUp variable-bindings “ifIndex[14] = 14, ifAdminStatus[14]
= 1, ifOperStatus[14] = 2”
Spoof trap request result: trap sent successfully
request snmp spoof-trap (Illegal Trap Name)

user@host> request snmp spoof-trap xx
Spoof trap request result: trap not found
Allowed Traps:
adslAtucInitFailureTrap
adslAtucPerfESsThreshTrap
adslAtucPerfLofsThreshTrap
adslAtucPerfLolsThreshTrap
adslAtucPerfLossThreshTrap

adslAtucPerfLprsThreshTrap
adslAtucRateChangeTrap
adslAturPerfESsThreshTrap
adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap
adslAturRateChangeTrap
apsEventChannelMismatch
apsEventFEPLF
apsEventModeMismatch
apsEventPSBF
apsEventSwitchover
authenticationFailure
bfdSessDown
bfdSessUp
bgpBackwardTransition
bgpEstablished
coldStart
dlswTrapCircuitDown
dlswTrapCircuitUp
dlswTrapTConnDown
dlswTrapTConnPartnerReject
dlswTrapTConnProtViolation
dlswTrapTConnUp
dsx1LineStatusChange
dsx3LineStatusChange
entConfigChange
fallingAlarm
frDLCIStatusChange
ggsnTrapChanged
ggsnTrapCleared
ggsnTrapNew
gmplsTunnelDown
ifMauJabberTrap
ipv6IfStateChange
isisAreaMismatch
isisAttemptToExceedMaxSequence
isisAuthenticationFailure
isisAuthenticationTypeFailure
isisCorruptedLSPDetected
isisDatabaseOverload
isisIDLenMismatch
isisLSPTooLargeToPropagate
isisManualAddressDrops
isisMaxAreaAddressesMismatch
isisOriginatingLSPBufferSizeMismatch
isisOwnLSPPurge
isisProtocolsSupportedMismatch
isisRejectedAdjacency
isisSequenceNumberSkip
isisVersionSkew
jnxAccessAuthServerDisabled
jnxAccessAuthServerEnabled
jnxAccessAuthServiceDown
jnxAccessAuthServiceUp
jnxBfdSessDetectionTimeHigh
jnxBfdSessTxIntervalHigh
jnxBgpM2BackwardTransition
jnxBgpM2Established
jnxCmCfgChange
jnxCmRescueChange

jnxCollFlowOverload
jnxCollFlowOverloadCleared
jnxCollFtpSwitchover
jnxCollMemoryAvailable
jnxCollMemoryUnavailable
jnxCollUnavailableDest
jnxCollUnavailableDestCleared
jnxCollUnsuccessfulTransfer
jnxDfcHardMemThresholdExceeded
jnxDfcHardMemUnderThreshold
jnxDfcHardPpsThresholdExceeded
jnxDfcHardPpsUnderThreshold
jnxDfcSoftMemThresholdExceeded
jnxDfcSoftMemUnderThreshold
jnxDfcSoftPpsThresholdExceeded
jnxDfcSoftPpsUnderThreshold
jnxEventTrap
jnxExampleStartup
jnxFEBSwitchover
jnxFanFailure
jnxFanOK
jnxFruCheck
jnxFruFailed
jnxFruInsertion
jnxFruOK
jnxFruOffline
jnxFruOnline
jnxFruPowerOff
jnxFruPowerOn
jnxFruRemoval
jnxHardDiskFailed
jnxHardDiskMissing
jnxJsAvPatternUpdateTrap
jnxJsChassisClusterSwitchover
jnxJsFwAuthCapacityExceeded
jnxJsFwAuthFailure
jnxJsFwAuthServiceDown
jnxJsFwAuthServiceUp
jnxJsNatAddrPoolThresholdStatus
jnxJsScreenAttack
jnxJsScreenCfgChange
jnxLdpLspDown
jnxLdpLspUp
jnxLdpSesDown
jnxLdpSesUp
jnxMIMstCistPortLoopProtectStateChangeTrap
jnxMIMstCistPortRootProtectStateChangeTrap
jnxMIMstErrTrap
jnxMIMstGenTrap
jnxMIMstInvalidBpduRxdTrap
jnxMIMstMstiPortLoopProtectStateChangeTrap
jnxMIMstMstiPortRootProtectStateChangeTrap
jnxMIMstNewRootTrap
jnxMIMstProtocolMigrationTrap
jnxMIMstRegionConfigChangeTrap
jnxMIMstTopologyChgTrap
jnxMacChangedNotification
jnxMplsLdpInitSesThresholdExceeded
jnxMplsLdpPathVectorLimitMismatch
jnxMplsLdpSessionDown
jnxMplsLdpSessionUp

jnxOspfv3IfConfigError
jnxOspfv3IfRxBadPacket
jnxOspfv3IfStateChange
jnxOspfv3LsdbApproachingOverflow
jnxOspfv3LsdbOverflow
jnxOspfv3NbrRestartHelperStatusChange
jnxOspfv3NbrStateChange
jnxOspfv3NssaTranslatorStatusChange
jnxOspfv3RestartStatusChange
jnxOspfv3VirtIfConfigError
jnxOspfv3VirtIfRxBadPacket
jnxOspfv3VirtIfStateChange
jnxOspfv3VirtNbrRestartHelperStatusChange
jnxOspfv3VirtNbrStateChange
jnxOtnAlarmCleared
jnxOtnAlarmSet
jnxOverTemperature
jnxPMonOverloadCleared
jnxPMonOverloadSet
jnxPingEgressJitterThresholdExceeded
jnxPingEgressStdDevThresholdExceeded
jnxPingEgressThresholdExceeded
jnxPingIngressJitterThresholdExceeded
jnxPingIngressStddevThresholdExceeded
jnxPingIngressThresholdExceeded
jnxPingRttJitterThresholdExceeded
jnxPingRttStdDevThresholdExceeded
jnxPingRttThresholdExceeded
jnxPortBpduErrorStatusChangeTrap
jnxPortLoopProtectStateChangeTrap
jnxPortRootProtectStateChangeTrap
jnxPowerSupplyFailure
jnxPowerSupplyOK
jnxRedundancySwitchover
jnxRmonAlarmGetFailure
jnxRmonGetOk
jnxSecAccessIfMacLimitExceeded
jnxSecAccessdsRateLimitCrossed
jnxSonetAlarmCleared
jnxSonetAlarmSet
jnxSpSvcSetCpuExceeded
jnxSpSvcSetCpuOk
jnxSpSvcSetZoneEntered
jnxSpSvcSetZoneExited
jnxStormEventNotification
jnxSyslogTrap
jnxTemperatureOK
jnxVccpPortDown
jnxVccpPortUp
jnxVpnIfDown
jnxVpnIfUp
jnxVpnPwDown
jnxVpnPwUp
jnxl2aldGlobalMacLimit
jnxl2aldInterfaceMacLimit
jnxl2aldRoutingInstMacLimit
linkDown
linkUp
lldpRemTablesChange
mfrMibTrapBundleLinkMismatch
mplsLspChange

mplsLspDown
mplsLspInfoChange
mplsLspInfoDown
mplsLspInfoPathDown
mplsLspInfoPathUp
mplsLspInfoUp
mplsLspPathDown
mplsLspPathUp
mplsLspUp
mplsNumVrfRouteMaxThreshExceeded
mplsNumVrfRouteMidThreshExceeded
mplsNumVrfSecIllglLblThrshExcd
mplsTunnelDown
mplsTunnelReoptimized
mplsTunnelRerouted
mplsTunnelUp
mplsVrfIfDown
mplsVrfIfUp
mplsXCDown
mplsXCUp
msdpBackwardTransition
msdpEstablished
newRoot
ospfIfAuthFailure
ospfIfConfigError
ospfIfRxBadPacket
ospfIfStateChange
ospfLsdbApproachingOverflow
ospfLsdbOverflow
ospfMaxAgeLsa
ospfNbrStateChange
ospfOriginateLsa
ospfTxRetransmit
ospfVirtIfAuthFailure
ospfVirtIfConfigError
ospfVirtIfRxBadPacket
ospfVirtIfStateChange
ospfVirtIfTxRetransmit
ospfVirtNbrStateChange
pethMainPowerUsageOffNotification
pethMainPowerUsageOnNotification
pethPsePortOnOffNotification
pingProbeFailed
pingTestCompleted
pingTestFailed
ptopoConfigChange
risingAlarm
rpMauJabberTrap
sdlcLSStatusChange
sdlcPortStatusChange
topologyChange
traceRoutePathChange
traceRouteTestCompleted
traceRouteTestFailed
vrrpTrapAuthFailure
vrrpTrapNewMaster
warmStart
request snmp spoof-trap (Question Mark ?)

user@host> request snmp spoof-trap ?

Possible completions:
<trap> The name of the trap to spoof
adslAtucInitFailureTrap
adslAtucPerfESsThreshTrap
adslAtucPerfLofsThreshTrap
adslAtucPerfLolsThreshTrap
adslAtucPerfLossThreshTrap
adslAtucPerfLprsThreshTrap
adslAtucRateChangeTrap
adslAturPerfESsThreshTrap
adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap
adslAturRateChangeTrap
apsEventChannelMismatch
apsEventFEPLF
apsEventModeMismatch
apsEventPSBF
apsEventSwitchover
authenticationFailure
bfdSessDown
bfdSessUp
bgpBackwardTransition
bgpEstablished
coldStart
dlswTrapCircuitDown
dlswTrapCircuitUp
---(more 10%)---

show chassis alarms
Syntax show chassis alarms
Release Information Command introduced in Junos OS Release 11.1 for SRX Series devices.
Description Display information about the conditions that have been configured to trigger alarms.
Additional Information You cannot clear the alarms for chassis components. Instead, you must remedy the
cause of the alarm. When a chassis alarm is lit, it indicates that you are running the device
in a manner that we do not recommend.
On routers, you can manually silence external devices connected to the alarm relay
contacts by pressing the alarm cutoff button, located on the craft interface. Silencing
the device does not remove the alarm messages from the display (if present on the
router) or extinguish the alarm LEDs. In addition, new alarms that occur after you silence
an external device reactivate the external device.
In Junos OS Release 11.1 and later, alarms for fans also show the slot number of the fans
in the CLI output.
Required Privilege view

Level
Related • show system alarms on page 883

Documentation
List of Sample Output show chassis alarms on page 795
Output Fields Table 136 on page 794 lists the output fields for the show chassis alarms command. Output
fields are listed in the approximate order in which they appear.
Table 136: show chassis alarms Output Fields

Field
Name Field Description
Alarm Date and time the alarm was first recorded.

time
Class Severity class for this alarm: Minor or Major.
Description Information about the alarm.

Sample Output
show chassis alarms
user@host> show chassis alarms
4 alarms currently active
Alarm time Class Description
2012-05-29 16:47:18 UTC Major /var partition usage crossed critical threshold
2012-05-29 16:47:18 UTC Minor /var partition usage crossed high threshold
2012-05-29 16:47:18 UTC Major /root partition usage crossed critical threshold
2012-05-29 16:47:18 UTC Minor /root partition usage crossed high threshold

show chassis cluster ip-monitoring status redundancy-group
Syntax show chassis cluster ip-monitoring status

<redundancy-group group-number>
Release Information Command introduced in Junos OS Release 9.6. Support for global threshold, current
threshold, and weight of each monitored IP address added in Junos OS Release
12.1X47-D10.
Description Display the status of all monitored IP addresses for a redundancy group.
Options • none— Display the status of monitored IP addresses for all redundancy groups on the
node.
• redundancy-group group-number— Display the status of monitored IP addresses under

the specified redundancy group.

Level
Related • clear chassis cluster failover-count

Documentation
List of Sample Output show chassis cluster ip-monitoring status on page 797
show chassis cluster ip-monitoring status redundancy-group on page 798
Output Fields Table 137 on page 796 lists the output fields for the show chassis cluster ip-monitoring
status command.
Table 137: show chassis cluster ip-monitoring status Output Fields

Field Name Field Description
Redundancy-group ID number (0 - 255) of a redundancy group in the cluster.
Global threshold Failover value for all IP addresses monitored by the redundancy group.
Current threshold Value equal to the global threshold minus the total weight of the unreachable IP address.
IP Address Monitored IP address in the redundancy group.
Status Current reachability state of the monitored IP address.
Values for this field are: reachable, unreachable, and unknown. The status is “unknown”
if Packet Forwarding Engines (PFEs) are not yet up and running.
Failure count Number of attempts to reach an IP address.
Reason Explanation for the reported status. See Table 138 on page 797.

Table 137: show chassis cluster ip-monitoring status Output Fields (continued)
Weight Combined weight (0 - 255) assigned to all monitored IP addresses. A higher weight value
indicates greater importance.
Expanded reason output fields for unreachable IP addresses added in Junos OS Release
10.1. You might see any of the following reasons displayed.
Table 138: show chassis cluster ip-monitoring status redundancy group Reason Fields
Reason Reason Description
No route to host The router could not resolve the ARP, which is needed to send the ICMP packet to the
host with the monitored IP address.
No auxiliary IP found The redundant Ethernet interface does not have an auxiliary IP address configured.
Reth child not up A child interface of a redundant Ethernet interface is down.
redundancy-group state unknown Unable to obtain the state (primary, secondary, secondary-hold, disable) of a
redundancy-group.
No reth child MAC address Could not extract the MAC address of the redundant Ethernet child interface.
Secondary link not monitored The secondary link might be down (the secondary child interface of a redundant Ethernet
interface is either down or non-functional).
Unknown The IP address has just been configured and the router still does not know the status of
this IP.
or
Do not know the exact reason for the failure.
Sample Output
show chassis cluster ip-monitoring status
user@host> show chassis cluster ip-monitoring status
node0:
--------------------------------------------------------------------------
Redundancy group: 1

10.254.5.44 reachable 0 n/a 220
2.2.2.1 reachable 0 n/a 100
node1:
--------------------------------------------------------------------------

Redundancy group: 1

10.254.5.44 reachable 0 n/a 220
2.2.2.1 reachable 0 n/a 100
Sample Output
show chassis cluster ip-monitoring status redundancy-group
user@host> show chassis cluster ip-monitoring status redundancy-group 1
node0:
--------------------------------------------------------------------------
Redundancy group: 1

node1:
--------------------------------------------------------------------------
Redundancy group: 1


show interfaces (SRX Series)
Syntax show interfaces {

<brief | detail | extensive | terse>
controller interface-name
descriptions interface-name
destination-class (all | destination-class-name logical-interface-name)
diagnostics optics interface-name
far-end-interval interface-fpc/pic/port
filters interface-name
flow-statistics interface-name
interval interface-name
load-balancing (detail | interface-name)
mac-database mac-address mac-address
mc-ae id identifier unit number revertive-info
media interface-name
policers interface-name
queue both-ingress-egress egress forwarding-class forwarding-class ingress l2-statistics
redundancy (detail | interface-name)
routing brief detail summary interface-name
routing-instance (all | instance-name)
snmp-index snmp-index
source-class (all | destination-class-name logical-interface-name)
statistics interface-name
switch-port switch-port number
transport pm (all | optics | otn) (all | current | currentday | interval | previousday) (all |
interface-name)
zone interface-name
}
Release Information Command modified in Junos OS Release 9.5.
Description Display status information and statistics about interfaces on SRX Series appliance running
Junos OS.
On SRX Series appliance, on configuring identical IPs on a single interface, you will not
see a warning message; instead, you will see a syslog message.
Options • interface-name—(Optional) Display standard information about the specified interface.

Following is a list of typical interface names. Replace pim with the PIM slot and port
with the port number.
• at- pim/0/port—ATM-over-ADSL or ATM-over-SHDSL interface.
• ce1-pim/0/ port—Channelized E1 interface.
• cl-0/0/8—3G wireless modem interface for SRX320 devices.
• ct1-pim/0/port—Channelized T1 interface.
• dl0—Dialer Interface for initiating ISDN and USB modem connections.
• e1-pim/0/port—E1 interface.

• e3-pim/0/port—E3 interface.
• fe-pim/0/port—Fast Ethernet interface.
• ge-pim/0/port—Gigabit Ethernet interface.
• se-pim/0/port—Serial interface.
• t1-pim/0/port—T1 (also called DS1) interface.
• t3-pim/0/port—T3 (also called DS3) interface.
• wx-slot/0/0—WAN acceleration interface, for the WXC Integrated Services Module

(ISM 200).
• brief | detail | extensive | terse—(Optional) Display the specified level of output.
• controller—(Optional) Show controller information.
• descriptions—(Optional) Display interface description strings.
• destination-class—(Optional) Show statistics for destination class.
• diagnostics—(Optional) Show interface diagnostics information.
• far-end-interval—(Optional) Show far end interval statistics.
• filters—(Optional) Show interface filters information.
• flow-statistics—(Optional) Show security flow counters and errors.
• interval—(Optional) Show interval statistics.
• load-balancing—(Optional) Show load-balancing status.
• mac-database—(Optional) Show media access control database information.
• mc-ae—(Optional) Show MC-AE configured interface information.
• media—(Optional) Display media information.
• policers—(Optional) Show interface policers information.
• queue—(Optional) Show queue statistics for this interface.
• redundancy—(Optional) Show redundancy status.
• routing—(Optional) Show routing status.
• routing-instance—(Optional) Name of routing instance.
• snmp-index—(Optional) SNMP index of interface.
• source-class—(Optional) Show statistics for source class.
• statistics—(Optional) Display statistics and detailed output.
• switch-port—(Optional) Front end port number (0..15).
• transport—(Optional) Show interface transport information.
• zone—(Optional) Interface's zone.


Level
Related • Understanding Layer 2 Interfaces

Documentation
List of Sample Output show interfaces Gigabit Ethernet on page 808

show interfaces brief (Gigabit Ethernet) on page 809
show interfaces detail (Gigabit Ethernet) on page 809
show interfaces extensive (Gigabit Ethernet) on page 811
show interfaces terse on page 814
show interfaces controller (Channelized E1 IQ with Logical E1) on page 814
show interfaces controller (Channelized E1 IQ with Logical DS0) on page 814
show interfaces descriptions on page 815
show interfaces destination-class all on page 815
show interfaces diagnostics optics on page 815
show interfaces far-end-interval coc12-5/2/0 on page 816
show interfaces far-end-interval coc1-5/2/1:1 on page 816
show interfaces filters on page 817
show interfaces flow-statistics (Gigabit Ethernet) on page 817
show interfaces interval (Channelized OC12) on page 818
show interfaces interval (E3) on page 818
show interfaces interval (SONET/SDH) on page 819
show interfaces load-balancing on page 819
show interfaces load-balancing detail on page 819
show interfaces mac-database (All MAC Addresses on a Port) on page 820
show interfaces mac-database (All MAC Addresses on a Service) on page 820
show interfaces mac-database mac-address on page 821
show interfaces mc-ae on page 821
show interfaces media (SONET/SDH) on page 821
show interfaces policers on page 822
show interfaces policers interface-name on page 822
show interfaces queue on page 822
show interfaces redundancy on page 823
show interfaces redundancy (Aggregated Ethernet) on page 823
show interfaces redundancy detail on page 824
show interfaces routing brief on page 824
show interfaces routing detail on page 824
show interfaces routing-instance all on page 825
show interfaces snmp-index on page 825
show interfaces source-class all on page 825
show interfaces statistics (Fast Ethernet) on page 826
show interfaces switch-port on page 826
show interfaces transport pm on page 827
show security zones on page 828
Output Fields Table 139 on page 802 lists the output fields for the show interfaces command. Output

Table 139: show interfaces Output Fields

Field Name Field Description Level of Output
Physical Interface
Physical interface Name of the physical interface. All levels
Enabled State of the interface. All levels
Interface index Index number of the physical interface, which reflects its initialization sequence. detail extensive none
SNMP ifIndex SNMP index number for the physical interface. detail extensive none
Link-level type Encapsulation being used on the physical interface. All levels
Generation Unique number for use by Juniper Networks technical support only. detail extensive
MTU Maximum transmission unit size on the physical interface. All levels
Link mode Link mode: Full-duplex or Half-duplex.
Speed Speed at which the interface is running. All levels
BPDU error Bridge protocol data unit (BPDU) error: Detected or None
Loopback Loopback status: Enabled or Disabled. If loopback is enabled, type of loopback: All levels
Local or Remote.
Source filtering Source filtering status: Enabled or Disabled. All levels
Flow control Flow control status: Enabled or Disabled. All levels
Auto-negotiation (Gigabit Ethernet interfaces) Autonegotiation status: Enabled or Disabled. All levels
Remote-fault (Gigabit Ethernet interfaces) Remote fault status: All levels
• Online—Autonegotiation is manually configured as online.

• Offline—Autonegotiation is manually configured as offline.
Device flags Information about the physical device. All levels
Interface flags Information about the interface. All levels
Link flags Information about the physical link. All levels
CoS queues Number of CoS queues configured. detail extensive none
Current address Configured MAC address. detail extensive none

Table 139: show interfaces Output Fields (continued)

Last flapped Date, time, and how long ago the interface went from down to up. The format detail extensive none
is Last flapped: year-month-day hour:minute:second:timezone (hour:minute:second
ago). For example, Last flapped: 2002-04-26 10:52:40 PDT (04:33:20 ago).
Input Rate Input rate in bits per second (bps) and packets per second (pps). None
Output Rate Output rate in bps and pps. None
Active alarms and Ethernet-specific defects that can prevent the interface from passing packets. detail extensive none
Active defects When a defect persists for a certain amount of time, it is promoted to an alarm.
These fields can contain the value None or Link.
• None—There are no active defects or alarms.

• Link—Interface has lost its link state, which usually means that the cable is
unplugged, the far-end system has been turned off, or the PIC is
malfunctioning.
Statistics last cleared Time when the statistics for the interface were last set to zero. detail extensive
Traffic statistics Number and rate of bytes and packets received and transmitted on the physical detail extensive
interface.
• Input bytes—Number of bytes received on the interface.

• Output bytes—Number of bytes transmitted on the interface.
• Input packets—Number of packets received on the interface.
• Output packets—Number of packets transmitted on the interface.


Input errors Input errors on the interface. extensive
• Errors—Sum of the incoming frame aborts and FCS errors.

• Drops—Number of packets dropped by the input queue of the I/O Manager
ASIC. If the interface is saturated, this number increments once for every
packet that is dropped by the ASIC's RED mechanism.
• Framing errors—Number of packets received with an invalid frame checksum
(FCS).
• Runts—Number of frames received that are smaller than the runt threshold.
• Policed discards—Number of frames that the incoming packet match code
discarded because they were not recognized or not of interest. Usually, this
field reports protocols that Junos OS does not handle.
• L3 incompletes—Number of incoming packets discarded because they failed
Layer 3 (usually IPv4) sanity checks of the header. For example, a frame with
less than 20 bytes of available IP header is discarded. L3 incomplete errors
can be ignored by configuring the ignore-l3-incompletes .
• L2 channel errors—Number of times the software did not find a valid logical
interface for an incoming frame.
• L2 mismatch timeouts—Number of malformed or short packets that caused
the incoming packet handler to discard the frame as unreadable.
• FIFO errors—Number of FIFO errors in the receive direction that are reported
by the ASIC on the PIC. If this value is ever nonzero, the PIC is probably
malfunctioning.
• Resource errors—Sum of transmit drops.
Output errors Output errors on the interface. extensive
• Carrier transitions—Number of times the interface has gone from down to up.
This number does not normally increment quickly, increasing only when the
cable is unplugged, the far-end system is powered down and then up, or
another problem occurs. If the number of carrier transitions increments quickly
(perhaps once every 10 seconds), the cable, the far-end system, or the PIC
or PIM is malfunctioning.
• Errors—Sum of the outgoing frame aborts and FCS errors.
• Drops—Number of packets dropped by the output queue of the I/O Manager
ASIC. If the interface is saturated, this number increments once for every
packet that is dropped by the ASIC's RED mechanism.
• Collisions—Number of Ethernet collisions. The Gigabit Ethernet PIC supports
only full-duplex operation; therefore, for Gigabit Ethernet PICs, this number
must always remain 0. If it is nonzero, there is a software bug.
• Aged packets—Number of packets that remained in shared packet SDRAM
so long that the system automatically purged them. The value in this field
must never increment. If it does, it is most likely a software bug or possibly
malfunctioning hardware.
• FIFO errors—Number of FIFO errors in the send direction as reported by the
ASIC on the PIC. If this value is ever nonzero, the PIC is probably
malfunctioning.
• HS link CRC errors—Number of errors on the high-speed links between the
ASICs responsible for handling the interfaces.
• MTU errors—Number of packets whose size exceeded the MTU of the interface.
• Resource errors—Sum of transmit drops.


Ingress queues Total number of ingress queues supported on the specified interface. extensive
Queue counters and CoS queue number and its associated user-configured forwarding class name. detail extensive
queue number
• Queued packets—Number of queued packets.
• Transmitted packets—Number of transmitted packets.
• Dropped packets—Number of packets dropped by the ASIC's RED mechanism.
MAC statistics Receive and Transmit statistics reported by the PIC's MAC subsystem, including extensive
the following:
• Total octets and total packets—Total number of octets and packets.

• Unicast packets, Broadcast packets, and Multicast packets—Number of unicast,
broadcast, and multicast packets.
• CRC/Align errors—Total number of packets received that had a length
(excluding framing bits, but including FCS octets) of between 64 and 1518
octets, inclusive, and had either a bad FCS with an integral number of octets
(FCS Error) or a bad FCS with a nonintegral number of octets (Alignment
Error).
• FIFO error—Number of FIFO errors that are reported by the ASIC on the PIC.
If this value is ever nonzero, the PIC or a cable is probably malfunctioning.
• MAC control frames—Number of MAC control frames.
• MAC pause frames—Number of MAC control frames with pause operational
code.
• Oversized frames—There are two possible conditions regarding the number
of oversized frames:
• Packet length exceeds 1518 octets, or

• Packet length exceeds MRU
• Jabber frames—Number of frames that were longer than 1518 octets (excluding
framing bits, but including FCS octets), and had either an FCS error or an
alignment error. This definition of jabber is different from the definition in
IEEE-802.3 section 8.2.1.5 (10BASE5) and section 10.3.1.4 (10BASE2). These
documents define jabber as the condition in which any packet exceeds 20
ms. The allowed range to detect jabber is from 20 ms to 150 ms.
• Fragment frames—Total number of packets that were less than 64 octets in
length (excluding framing bits, but including FCS octets) and had either an
FCS error or an alignment error. Fragment frames normally increment because
both runts (which are normal occurrences caused by collisions) and noise
hits are counted.
• VLAN tagged frames—Number of frames that are VLAN tagged. The system
uses the TPID of 0x8100 in the frame to determine whether a frame is tagged
or not.
• Code violations—Number of times an event caused the PHY to indicate “Data
reception error” or “invalid data symbol error.”


Filter statistics Receive and Transmit statistics reported by the PIC's MAC address filter extensive
subsystem. The filtering is done by the content-addressable memory (CAM)
on the PIC. The filter examines a packet's source and destination MAC addresses
to determine whether the packet should enter the system or be rejected.
• Input packet count—Number of packets received from the MAC hardware

that the filter processed.
• Input packet rejects—Number of packets that the filter rejected because of
either the source MAC address or the destination MAC address.
• Input DA rejects—Number of packets that the filter rejected because the
destination MAC address of the packet is not on the accept list. It is normal
for this value to increment. When it increments very quickly and no traffic is
entering the device from the far-end system, either there is a bad ARP entry
on the far-end system, or multicast routing is not on and the far-end system
is sending many multicast packets to the local device (which the router is
rejecting).
• Input SA rejects—Number of packets that the filter rejected because the
source MAC address of the packet is not on the accept list. The value in this
field should increment only if source MAC address filtering has been enabled.
If filtering is enabled, if the value increments quickly, and if the system is not
receiving traffic that it should from the far-end system, it means that the
user-configured source MAC addresses for this interface are incorrect.
• Output packet count—Number of packets that the filter has given to the MAC
hardware.
• Output packet pad count—Number of packets the filter padded to the
minimum Ethernet size (60 bytes) before giving the packet to the MAC
hardware. Usually, padding is done only on small ARP packets, but some very
small IP packets can also require padding. If this value increments rapidly,
either the system is trying to find an ARP entry for a far-end system that does
not exist or it is misconfigured.
• Output packet error count—Number of packets with an indicated error that
the filter was given to transmit. These packets are usually aged packets or
are the result of a bandwidth problem on the FPC hardware. On a normal
system, the value of this field should not increment.
• CAM destination filters, CAM source filters—Number of entries in the CAM
dedicated to destination and source MAC address filters. There can only be
up to 64 source entries. If source filtering is disabled, which is the default, the
values for these fields must be 0.
Autonegotiation Information about link autonegotiation. extensive

information
• Negotiation status:
• Incomplete—Ethernet interface has the speed or link mode configured.
• No autonegotiation—Remote Ethernet interface has the speed or link mode
configured, or does not perform autonegotiation.
• Complete—Ethernet interface is connected to a device that performs
autonegotiation and the autonegotiation process is successful.
Packet Forwarding Information about the configuration of the Packet Forwarding Engine: extensive
Engine configuration
• Destination slot—FPC slot number.


CoS information Information about the CoS queue for the physical interface. extensive
• CoS transmit queue—Queue number and its associated user-configured

forwarding class name.
• Bandwidth %—Percentage of bandwidth allocated to the queue.
• Bandwidth bps—Bandwidth allocated to the queue (in bps).
• Buffer %—Percentage of buffer space allocated to the queue.
• Buffer usec—Amount of buffer space allocated to the queue, in microseconds.

This value is nonzero only if the buffer size is configured in terms of time.
• Priority—Queue priority: low or high.
• Limit—Displayed if rate limiting is configured for the queue. Possible values

are none and exact. If exact is configured, the queue transmits only up to the
configured bandwidth, even if excess bandwidth is available. If none is
configured, the queue transmits beyond the configured bandwidth if
bandwidth is available.
Interface transmit Status of the interface-transmit-statistics configuration: Enabled or Disabled. detail extensive
statistics
Queue counters CoS queue number and its associated user-configured forwarding class name. detail extensive
(Egress)
• Queued packets—Number of queued packets.
• Transmitted packets—Number of transmitted packets.
• Dropped packets—Number of packets dropped by the ASIC's RED mechanism.
Logical Interface
Logical interface Name of the logical interface. All levels
Index Index number of the logical interface, which reflects its initialization sequence. detail extensive none
SNMP ifIndex SNMP interface index number for the logical interface. detail extensive none
Flags Information about the logical interface. All levels
Encapsulation Encapsulation on the logical interface. All levels
Traffic statistics Number and rate of bytes and packets received and transmitted on the specified detail extensive
interface set.
• Input bytes, Output bytes—Number of bytes received and transmitted on the

interface set. The value in this field also includes the Layer 2 overhead bytes
for ingress or egress traffic on Ethernet interfaces if you enable accounting
of Layer 2 overhead at the PIC level or the logical interface level.
• Input packets, Output packets—Number of packets received and transmitted
on the interface set.


Local statistics Number and rate of bytes and packets destined to the device. extensive
Transit statistics Number and rate of bytes and packets transiting the switch. extensive
NOTE: For Gigabit Ethernet intelligent queuing 2 (IQ2) interfaces, the logical
interface egress statistics might not accurately reflect the traffic on the wire
when output shaping is applied. Traffic management output shaping might
drop packets after they are tallied by the Output bytes and Output packets
interface counters. However, correct values display for both of these egress
statistics when per-unit scheduling is enabled for the Gigabit Ethernet IQ2
physical interface, or when a single logical interface is actively using a shared
scheduler.
Security Security zones that interface belongs to. extensive
Flow Input statistics Statistics on packets received by flow module. extensive
Flow Output statistics Statistics on packets sent by flow module. extensive
Flow error statistics Statistics on errors in the flow module. extensive

(Packets dropped due
to)
Protocol Protocol family. detail extensive none
MTU Maximum transmission unit size on the logical interface. detail extensive none
Route Table Route table in which the logical interface address is located. For example, 0 detail extensive none
refers to the routing table inet.0.
Flags Information about protocol family flags. . detail extensive
Addresses, Flags Information about the address flags.. detail extensive none
Destination IP address of the remote side of the connection. detail extensive none
Local IP address of the logical interface. detail extensive none
Broadcast Broadcast address of the logical interface. detail extensive none
Sample Output
show interfaces Gigabit Ethernet
user@host> show interfaces ge-0/0/1

Physical interface: ge-0/0/1, Enabled, Physical link is Down

Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,

Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running Down
Interface flags: Hardware-Down SNMP-Traps Internal: 0x0
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Current address: 00:1f:12:e4:b1:01, Hardware address: 00:1f:12:e4:b1:01
Last flapped : 2015-05-12 08:36:59 UTC (1w1d 22:42 ago)
Active alarms : LINK
Active defects : LINK
Interface transmit statistics: Disabled
Logical interface ge-0/0/1.0 (Index 71) (SNMP ifIndex 514)

Flags: Device-Down SNMP-Traps 0x0 Encapsulation: ENET2
Input packets : 0
Output packets: 0
Security: Zone: public
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 1.1.1/24, Local: 1.1.1.1, Broadcast: 1.1.1.255
Sample Output
show interfaces brief (Gigabit Ethernet)
user@host> show interfaces ge-3/0/2 brief
Physical interface: ge-3/0/2, Enabled, Physical link is Up
Link-level type: 52, MTU: 1522, Speed: 1000mbps, Loopback: Disabled,
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
Logical interface ge-3/0/2.0

Flags: SNMP-Traps 0x4000
VLAN-Tag [ 0x8100.512 0x8100.513 ] In(pop-swap 0x8100.530) Out(swap-push
0x8100.512 0x8100.513)
Encapsulation: VLAN-CCC
ccc
Logical interface ge-3/0/2.32767

Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x0000.0 ] Encapsulation: ENET2
Sample Output
show interfaces detail (Gigabit Ethernet)
user@host> show interfaces ge-0/0/1 detail
Interface index: 135, SNMP ifIndex: 510, Generation: 138
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:

Disabled,
Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
Link flags : None
Hold-times : Up 0 ms, Down 0 ms
Statistics last cleared: Never
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes

0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
Logical interface ge-0/0/1.0 (Index 71) (SNMP ifIndex 514) (Generation 136)
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Flow Statistics :
Flow Input statistics :
Self packets : 0
ICMP packets : 0
VPN packets : 0
Multicast packets : 0
Bytes permitted by policy : 0
Connections established : 0

Flow Output statistics:

Flow error statistics (Packets dropped due to):
Address spoofing: 0
Authentication failed: 0
Incoming NAT errors: 0
Invalid zone received packet: 0
Multiple user authentications: 0
Multiple incoming NAT: 0
No parent for a gate: 0
No one interested in self packets: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No SA for incoming SPI: 0
No tunnel found: 0
No session for a gate: 0
No zone or NULL zone binding 0
Policy denied: 0
Security association not active: 0
TCP sequence number out of window: 0
Syn-attack protection: 0
User authentication errors: 0
Protocol inet, MTU: 1500, Generation: 150, Route table: 0
Destination: 1.1.1/24, Local: 1.1.1.1, Broadcast: 1.1.1.255, Generation:
150
Sample Output
show interfaces extensive (Gigabit Ethernet)
user@host> show interfaces ge-0/0/1.0 extensive
Interface index: 135, SNMP ifIndex: 510, Generation: 138
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,

Link flags : None
Hold-times : Up 0 ms, Down 0 ms
Traffic statistics:
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:

Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0

Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes

0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
MAC statistics: Receive Transmit
Total octets 0 0
Total packets 0 0
Unicast packets 0 0
Broadcast packets 0 0
Multicast packets 0 0
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 0
Output packet pad count 0
Output packet error count 0
CAM destination filters: 2, CAM source filters: 0
Autonegotiation information:
Negotiation status: Incomplete
Packet Forwarding Engine configuration:
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue Bandwidth Buffer Priority
Limit
% bps % usec
0 best-effort 95 950000000 95 0 low
none
3 network-control 5 50000000 5 0 low
none
Logical interface ge-0/0/1.0 (Index 71) (SNMP ifIndex 514) (Generation 136)


Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Flow Statistics :
Self packets : 0
ICMP packets : 0
VPN packets : 0
Address spoofing: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No tunnel found: 0
Policy denied: 0
Protocol inet, MTU: 1500, Generation: 150, Route table: 0
Destination: 1.1.1/24, Local: 1.1.1.1, Broadcast: 1.1.1.255,
Generation: 150

Sample Output
show interfaces terse
user@host> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.209.4.61/18
gr-0/0/0 up up
ip-0/0/0 up up
st0 up up
st0.1 up ready inet
ls-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
pd-0/0/0 up up
pe-0/0/0 up up
e3-1/0/0 up up
t3-2/0/0 up up
e1-3/0/0 up up
se-4/0/0 up down
t1-5/0/0 up up
br-6/0/0 up up
dc-6/0/0 up up
dc-6/0/0.32767 up up
bc-6/0/0:1 down up
bc-6/0/0:1.0 up down
dl0 up up
dl0.0 up up inet
dsc up up
gre up up
ipip up up
lo0 up up
lo0.16385 up up inet 10.0.0.1 --> 0/0
10.0.0.16 --> 0/0
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
Sample Output
show interfaces controller (Channelized E1 IQ with Logical E1)
user@host> show interfaces controller ce1-1/2/6
Controller Admin Link

ce1-1/2/6 up up
e1-1/2/6 up up
show interfaces controller (Channelized E1 IQ with Logical DS0)

user@host> show interfaces controller ce1-1/2/3
Controller Admin Link

ce1-1/2/3 up up
ds-1/2/3:1 up up
ds-1/2/3:2 up up

Sample Output
show interfaces descriptions
user@host> show interfaces descriptions
Interface Admin Link Description
so-1/0/0 up up M20-3#1
so-2/0/0 up up GSR-12#1
ge-3/0/0 up up SMB-OSPF_Area300
so-3/3/0 up up GSR-13#1
so-3/3/1 up up GSR-13#2
ge-4/0/0 up up T320-7#1
ge-5/0/0 up up T320-7#2
so-7/1/0 up up M160-6#1
ge-8/0/0 up up T320-7#3
ge-9/0/0 up up T320-7#4
so-10/0/0 up up M160-6#2
so-13/0/0 up up M20-3#2
so-14/0/0 up up GSR-12#2
ge-15/0/0 up up SMB-OSPF_Area100
ge-15/0/1 up up GSR-13#3
Sample Output
show interfaces destination-class all
user@host> show interfaces destination-class all
Logical interface so-4/0/0.0
Packets Bytes
Destination class (packet-per-second) (bits-per-second)
gold 0 0
( 0) ( 0)
silver 0 0
( 0) ( 0)
Packets Bytes
gold 0 0
( 0) ( 0)
silver 0 0
( 0) ( 0)
Sample Output
show interfaces diagnostics optics
user@host> show interfaces diagnostics optics ge-2/0/0
Physical interface: ge-2/0/0
Laser bias current : 7.408 mA
Laser output power : 0.3500 mW / -4.56 dBm
Module temperature : 23 degrees C / 73 degrees F
Module voltage : 3.3450 V
Receiver signal average optical power : 0.0002 mW / -36.99 dBm
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off

Module temperature high alarm : Off

Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : On
Laser rx power high warning : Off
Laser rx power low warning : On
Laser bias current high alarm threshold : 17.000 mA
Laser bias current low alarm threshold : 1.000 mA
Laser bias current high warning threshold : 14.000 mA
Laser bias current low warning threshold : 2.000 mA
Laser output power high alarm threshold : 0.6310 mW / -2.00 dBm
Laser output power low alarm threshold : 0.0670 mW / -11.74 dBm
Laser output power high warning threshold : 0.6310 mW / -2.00 dBm
Laser output power low warning threshold : 0.0790 mW / -11.02 dBm
Module temperature high alarm threshold : 95 degrees C / 203 degrees F
Module temperature low alarm threshold : -25 degrees C / -13 degrees F
Module temperature high warning threshold : 90 degrees C / 194 degrees F
Module temperature low warning threshold : -20 degrees C / -4 degrees F
Module voltage high alarm threshold : 3.900 V
Module voltage low alarm threshold : 2.700 V
Module voltage high warning threshold : 3.700 V
Module voltage low warning threshold : 2.900 V
Laser rx power high alarm threshold : 1.2590 mW / 1.00 dBm
Laser rx power low alarm threshold : 0.0100 mW / -20.00 dBm
Laser rx power high warning threshold : 0.7940 mW / -1.00 dBm
Laser rx power low warning threshold : 0.0158 mW / -18.01 dBm
Sample Output
show interfaces far-end-interval coc12-5/2/0
user@host> show interfaces far-end-interval coc12-5/2/0
Physical interface: coc12-5/2/0, SNMP ifIndex: 121
05:30-current:
ES-L: 1, SES-L: 1, UAS-L: 0
05:15-05:30:
05:00-05:15:
04:45-05:00:
04:30-04:45:
04:15-04:30:
04:00-04:15:
...
show interfaces far-end-interval coc1-5/2/1:1

user@host> run show interfaces far-end-interval coc1-5/2/1:1
Physical interface: coc1-5/2/1:1, SNMP ifIndex: 342
05:30-current:
ES-L: 1, SES-L: 1, UAS-L: 0, ES-P: 0, SES-P: 0, UAS-P: 0

05:15-05:30:
05:00-05:15:
04:45-05:00:
04:30-04:45:
04:15-04:30:
04:00-04:15:
Sample Output
show interfaces filters
user@host> show interfaces filters
Interface Admin Link Proto Input Filter Output Filter
ge-0/0/0 up up
ge-0/0/0.0 up up inet
iso
ge-5/0/0 up up
ge-5/0/0.0 up up any f-any
inet f-inet
multiservice
gr-0/3/0 up up
ip-0/3/0 up up
mt-0/3/0 up up
pd-0/3/0 up up
pe-0/3/0 up up
vt-0/3/0 up up
at-1/0/0 up up
at-1/0/0.0 up up inet
iso
at-1/1/0 up down
at-1/1/0.0 up down inet
iso
....
Sample Output
show interfaces flow-statistics (Gigabit Ethernet)
user@host> show interfaces flow-statistics ge-0/0/1.0
Logical interface ge-0/0/1.0 (Index 70) (SNMP ifIndex 49)
Flags: SNMP-Traps Encapsulation: ENET2
Input packets : 5161
Output packets: 83
Security: Zone: zone2
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp ldp msdp nhrp ospf
pgm
pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http
https ike
netconf ping rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text
xnm-ssl
lsping
Flow Statistics :
Self packets : 0
ICMP packets : 0
VPN packets : 2564


Address spoofing: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No tunnel found: 0
Policy denied: 0
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 203.0.113.1/24, Local: 203.0.113.2, Broadcast: 2.2.2.255
Sample Output
show interfaces interval (Channelized OC12)
user@host> show interfaces interval t3-0/3/0:0
Physical interface: t3-0/3/0:0, SNMP ifIndex: 23
17:43-current:
LCV: 0, PCV: 0, CCV: 0, LES: 0, PES: 0, PSES: 0, CES: 0, CSES: 0,
SEFS: 0, UAS: 0
17:28-17:43:
SEFS: 0, UAS: 0
17:13-17:28:
SEFS: 0, UAS: 0
16:58-17:13:
SEFS: 0, UAS: 0
16:43-16:58:
...
Interval Total:
LCV: 230, PCV: 1145859, CCV: 455470, LES: 0, PES: 230, PSES: 230,
CES: 230, CSES: 230, SEFS: 230, UAS: 238
show interfaces interval (E3)

user@host> show interfaces interval e3-0/3/0

Physical interface: e3-0/3/0, SNMP ifIndex: 23

17:43-current:
SEFS: 0, UAS: 0
17:28-17:43:
SEFS: 0, UAS: 0
17:13-17:28:
SEFS: 0, UAS: 0
16:58-17:13:
SEFS: 0, UAS: 0
16:43-16:58:
....
Interval Total:
LCV: 230, PCV: 1145859, CCV: 455470, LES: 0, PES: 230, PSES: 230,
CES: 230, CSES: 230, SEFS: 230, UAS: 238
show interfaces interval (SONET/SDH)

user@host> show interfaces interval so-0/1/0
Physical interface: so-0/1/0, SNMP ifIndex: 19
20:02-current:
ES-S: 0, SES-S: 0, SEFS-S: 0, ES-L: 0, SES-L: 0, UAS-L: 0, ES-P: 0,
SES-P: 0, UAS-P: 0
19:47-20:02:
ES-S: 267, SES-S: 267, SEFS-S: 267, ES-L: 267, SES-L: 267, UAS-L: 267,
ES-P: 267, SES-P: 267, UAS-P: 267
19:32-19:47:
SES-P: 56, UAS-P: 46
19:17-19:32:
SES-P: 0, UAS-P: 0
19:02-19:17:
.....
Sample Output
show interfaces load-balancing
user@host> show interfaces load-balancing
Interface State Last change Member count
ams0 Up 1d 00:50 2
ams1 Up 00:00:59 2
show interfaces load-balancing detail

user@host>show interfaces load-balancing detail
Load-balancing interfaces detail
Interface : ams0
State : Up
Last change : 1d 00:51
Member count : 2
Members :
Interface Weight State
mams-2/0/0 10 Active
mams-2/1/0 10 Active

Sample Output
show interfaces mac-database (All MAC Addresses on a Port)
user@host> show interfaces mac-database xe-0/3/3
Physical interface: xe-0/3/3, Enabled, Physical link is Up
Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, Loopback:
None, Source filtering: Disabled, Flow control: Enabled
Link flags : None
Logical interface xe-0/3/3.0 (Index 364) (SNMP ifIndex 829)

Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2
MAC address Input frames Input bytes Output frames Output bytes
00:00:00:00:00:00 1 56 0 0
00:00:c0:01:01:02 7023810 323095260 0 0
00:00:c0:01:01:03 7023810 323095260 0 0
00:00:c0:01:01:04 7023810 323095260 0 0
00:00:c0:01:01:05 7023810 323095260 0 0
00:00:c0:01:01:06 7023810 323095260 0 0
00:00:c0:01:01:07 7023810 323095260 0 0
00:00:c0:01:01:08 7023809 323095214 0 0
00:00:c0:01:01:09 7023809 323095214 0 0
00:00:c0:01:01:0a 7023809 323095214 0 0
00:00:c0:01:01:0b 7023809 323095214 0 0
00:00:c8:01:01:02 30424784 1399540064 37448598 1722635508
00:00:c8:01:01:03 30424784 1399540064 37448598 1722635508
00:00:c8:01:01:04 30424716 1399536936 37448523 1722632058
00:00:c8:01:01:05 30424789 1399540294 37448598 1722635508
00:00:c8:01:01:06 30424788 1399540248 37448597 1722635462
00:00:c8:01:01:07 30424783 1399540018 37448597 1722635462
00:00:c8:01:01:08 30424783 1399540018 37448596 1722635416
00:00:c8:01:01:09 8836796 406492616 8836795 406492570
00:00:c8:01:01:0a 30424712 1399536752 37448521 1722631966
00:00:c8:01:01:0b 30424715 1399536890 37448523 1722632058
Number of MAC addresses : 21
show interfaces mac-database (All MAC Addresses on a Service)

user@host> show interfaces mac-database xe-0/3/3
MAC address Input frames Input bytes Output frames Output bytes
00:00:00:00:00:00 1 56 0 0
00:00:c0:01:01:02 7023810 323095260 0 0
00:00:c0:01:01:03 7023810 323095260 0 0
00:00:c0:01:01:04 7023810 323095260 0 0
00:00:c0:01:01:05 7023810 323095260 0 0
00:00:c0:01:01:06 7023810 323095260 0 0
00:00:c0:01:01:07 7023810 323095260 0 0
00:00:c0:01:01:08 7023809 323095214 0 0
00:00:c0:01:01:09 7023809 323095214 0 0
00:00:c0:01:01:0a 7023809 323095214 0 0
00:00:c0:01:01:0b 7023809 323095214 0 0
00:00:c8:01:01:02 31016568 1426762128 38040381 1749857526

00:00:c8:01:01:03 31016568 1426762128 38040382 1749857572

00:00:c8:01:01:04 31016499 1426758954 38040306 1749854076
00:00:c8:01:01:05 31016573 1426762358 38040381 1749857526
00:00:c8:01:01:06 31016573 1426762358 38040381 1749857526
00:00:c8:01:01:07 31016567 1426762082 38040380 1749857480
00:00:c8:01:01:08 31016567 1426762082 38040379 1749857434
00:00:c8:01:01:09 9428580 433714680 9428580 433714680
00:00:c8:01:01:0a 31016496 1426758816 38040304 1749853984
00:00:c8:01:01:0b 31016498 1426758908 38040307 1749854122
show interfaces mac-database mac-address

user@host> show interfaces mac-database xe-0/3/3 mac-address 00:00:c8:01:01:09
Physical interface: xe-0/3/3, Enabled, Physical link is Up
Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, Loopback:
None, Source filtering: Disabled, Flow control: Enabled
Link flags : None

MAC address: 00:00:c8:01:01:09, Type: Configured,
Input bytes : 202324652
Output bytes : 202324560
Input frames : 4398362
Output frames : 4398360
Policer statistics:
Policer type Discarded frames Discarded bytes
Output aggregate 3992386 183649756
Sample Output
show interfaces mc-ae
user@host> show interfaces mc-ae ae0 unit 512
Member Links : ae0
Local Status : active
Peer Status : active
Logical Interface : ae0.512
Core Facing Interface : Label Ethernet Interface
ICL-PL : Label Ethernet Interface
show interfaces media (SONET/SDH)
The following example displays the output fields unique to the show interfaces media
command for a SONET interface (with no level of output specified):
user@host> show interfaces media so-4/1/2

Physical interface: so-4/1/2, Enabled, Physical link is Up
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC48,
Loopback: None, FCS: 16, Payload scrambler: Enabled
Interface flags: Point-To-Point SNMP-Traps 16384
Link flags : Keepalives
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 1783 (00:00:00 ago), Output: 1786 (00:00:08 ago)
LCP state: Opened

NCP state: inet: Not-configured, inet6: Not-configured, iso: Not-configured,

mpls: Not-configured
CHAP state: Not-configured
CoS queues : 8 supported
Last flapped : 2005-06-15 12:14:59 PDT (04:31:29 ago)
SONET alarms : None
SONET defects : None
SONET errors:
BIP-B1: 121, BIP-B2: 916, REI-L: 0, BIP-B3: 137, REI-P: 16747, BIP-BIP2: 0
Received path trace: routerb so-1/1/2
Transmitted path trace: routera so-4/1/2
Sample Output
show interfaces policers
user@host> show interfaces policers
Interface Admin Link Proto Input Policer Output Policer
ge-0/0/0 up up
ge-0/0/0.0 up up inet
iso
gr-0/3/0 up up
ip-0/3/0 up up
mt-0/3/0 up up
pd-0/3/0 up up
pe-0/3/0 up up
...
so-2/0/0 up up
so-2/0/0.0 up up inet so-2/0/0.0-in-policer so-2/0/0.0-out-policer
iso
so-2/1/0 up down
...
show interfaces policers interface-name

user@host> show interfaces policers so-2/1/0
Interface Admin Link Proto Input Policer Output Policer
so-2/1/0 up down
so-2/1/0.0 up down inet so-2/1/0.0-in-policer so-2/1/0.0-out-policer
iso
inet6
Sample Output
show interfaces queue
The following truncated example shows the CoS queue sizes for queues 0, 1, and 3. Queue
1 has a queue buffer size (guaranteed allocated memory) of 9192 bytes.
user@host> show interfaces queue

Physical interface: ge-0/0/0, Enabled, Physical link is Up
Queue: 0, Forwarding classes: class0
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps

Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RL-dropped packets : 0 0 pps
RL-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue Buffer Usage:
Reserved buffer : 118750000 bytes
Queue-depth bytes :
Current : 0
..
..
..
..
Queue Buffer Usage:
Queue-depth bytes :
Current : 0
..
..
Queued:
..
..
Queue Buffer Usage:
Queue-depth bytes :
Current : 0
..
..
Sample Output
show interfaces redundancy
user@host> show interfaces redundancy
Interface State Last change Primary Secondary Current status
rsp0 Not present sp-1/0/0 sp-0/2/0 both down
rsp1 On secondary 1d 23:56 sp-1/2/0 sp-0/3/0 primary down
rsp2 On primary 10:10:27 sp-1/3/0 sp-0/2/0 secondary down
rlsq0 On primary 00:06:24 lsq-0/3/0 lsq-1/0/0 both up
show interfaces redundancy (Aggregated Ethernet)

user@host> show interfaces redundancy
Interface State Last change Primary Secondary Current status
rlsq0 On secondary 00:56:12 lsq-4/0/0 lsq-3/0/0 both up
ae0
ae1

ae2
ae3
ae4
show interfaces redundancy detail

user@host> show interfaces redundancy detail
Interface : rlsq0
State : On primary
Last change : 00:45:47
Primary : lsq-0/2/0
Secondary : lsq-1/2/0
Current status : both up
Mode : hot-standby
Interface : rlsq0:0
State : On primary
Last change : 00:45:46
Primary : lsq-0/2/0:0
Secondary : lsq-1/2/0:0
Current status : both up
Mode : warm-standby
Sample Output
show interfaces routing brief
user@host> show interfaces routing brief
Interface State Addresses
so-5/0/3.0 Down ISO enabled
so-5/0/2.0 Up MPLS enabled
ISO enabled
INET 192.168.2.120
INET enabled
so-5/0/1.0 Up MPLS enabled
ISO enabled
INET 192.168.2.130
INET enabled
at-1/0/0.3 Up CCC enabled
at-1/0/0.2 Up CCC enabled
at-1/0/0.0 Up ISO enabled
INET 192.168.90.10
INET enabled
lo0.0 Up ISO 47.0005.80ff.f800.0000.0108.0001.1921.6800.5061.00
ISO enabled
INET 127.0.0.1
fxp1.0 Up
fxp0.0 Up INET 192.168.6.90
show interfaces routing detail

user@host> show interfaces routing detail
so-5/0/3.0
Index: 15, Refcount: 2, State: Up <Broadcast PointToPoint Multicast> Change:<>
Metric: 0, Up/down transitions: 0, Full-duplex

Link layer: HDLC serial line Encapsulation: PPP Bandwidth: 155Mbps
ISO address (null)
State: <Broadcast PointToPoint Multicast> Change: <>
Preference: 0 (120 down), Metric: 0, MTU: 4470 bytes
so-5/0/2.0

Index: 14, Refcount: 7, State: <Up Broadcast PointToPoint Multicast> Change:<>
Metric: 0, Up/down transitions: 0, Full-duplex

Link layer: HDLC serial line Encapsulation: PPP Bandwidth: 155Mbps
MPLS address (null)
State: <Up Broadcast PointToPoint Multicast> Change: <>
ISO address (null)
INET address 192.168.2.120
State: <Up Broadcast PointToPoint Multicast Localup> Change: <>
Local address: 192.168.2.120
Destination: 192.168.2.110/32
INET address (null)
...
Sample Output
show interfaces routing-instance all
user@host> show interfaces terse routing-instance all
Interface Admin Link Proto Local Remote Instance
at-0/0/1 up up inet 10.0.0.1/24
ge-0/0/0.0 up up inet 192.168.4.28/24 sample-a
at-0/1/0.0 up up inet6 fe80::a:0:0:4/64 sample-b
so-0/0/0.0 up up inet 10.0.0.1/32
Sample Output
show interfaces snmp-index
user@host> show interfaces snmp-index 33
Physical interface: so-2/1/1, Enabled, Physical link is Down
Interface flags: Hardware-Down Point-To-Point SNMP-Traps 16384
SONET alarms : LOL, PLL, LOS
SONET defects : LOL, PLL, LOF, LOS, SEF, AIS-L, AIS-P
Sample Output
show interfaces source-class all
user@host> show interfaces source-class all
Packets Bytes
Source class (packet-per-second) (bits-per-second)
gold 1928095 161959980
( 889) ( 597762)
bronze 0 0

( 0) ( 0)
silver 0 0
( 0) ( 0)
Packets Bytes
Source class (packet-per-second) (bits-per-second)
gold 0 0
( 0) ( 0)
bronze 0 0
( 0) ( 0)
silver 116113 9753492
( 939) ( 631616)
Sample Output
show interfaces statistics (Fast Ethernet)
user@host> show interfaces fe-1/3/1 statistics
Physical interface: fe-1/3/1, Enabled, Physical link is Up
Description: ford fe-1/3/1
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled
Current address: 00:90:69:93:04:dc, Hardware address: 00:90:69:93:04:dc
Input errors: 0, Output errors: 0
Active alarms : None
Active defects : None
Logical interface fe-1/3/1.0 (Index 69) (SNMP ifIndex 50)
Flags: SNMP-Traps Encapsulation: ENET2
Flags: Is-Primary, DCU, SCU-in
Packets Bytes
silver1 0 0
( 0) ( 0)
silver2 0 0
( 0) ( 0)
silver3 0 0
( 0) ( 0)
Addresses, Flags: Is-Default Is-Preferred Is-Primary
Destination: 10.27.245/24, Local: 10.27.245.2,
Broadcast: 10.27.245.255
Protocol iso, MTU: 1497
Flags: Is-Primary
Sample Output
show interfaces switch-port
user@host# show interfaces ge-slot/0/0 switch-port port-number
Port 0, Physical link is Up
Speed: 100mbps, Auto-negotiation: Enabled
Statistics: Receive Transmit
Total bytes 28437086 21792250

Total packets 409145 88008

Unicast packets 9987 83817
Multicast packets 145002 0
Broadcast packets 254156 4191
Multiple collisions 23 10
FIFO/CRC/Align errors 0 0
MAC pause frames 0 0
Oversized frames 0
Runt frames 0
Jabber frames 0
Fragment frames 0
Discarded frames 0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: None, Remote fault: OK, Link
partner Speed: 100 Mbps
Local resolution:
Flow control: None, Remote fault: Link OK
Sample Output
show interfaces transport pm
user@host> show interfaces transport pm all current et-0/1/0
Physical interface: et-0/1/0, SNMP ifIndex 515
14:45-current Elapse time:900 Seconds
Near End Suspect Flag:False Reason:None
PM COUNT THRESHOLD TCA-ENABLED TCA-RAISED
OTU-BBE 0 800 No No
OTU-ES 0 135 No No
OTU-SES 0 90 No No
OTU-UAS 427 90 No No
Far End Suspect Flag:True Reason:Unknown
OTU-BBE 0 800 No No
OTU-ES 0 135 No No
OTU-SES 0 90 No No
OTU-UAS 0 90 No No
Near End Suspect Flag:False Reason:None
ODU-BBE 0 800 No No
ODU-ES 0 135 No No
ODU-SES 0 90 No No
ODU-UAS 427 90 No No
Far End Suspect Flag:True Reason:Unknown
ODU-BBE 0 800 No No
ODU-ES 0 135 No No
ODU-SES 0 90 No No
ODU-UAS 0 90 No No
FEC Suspect Flag:False Reason:None
FEC-CorrectedErr 2008544300 0 NA NA
FEC-UncorrectedWords 0 0 NA NA
BER Suspect Flag:False Reason:None

PM MIN MAX AVG THRESHOLD TCA-ENABLED

TCA-RAISED
BER 3.6e-5 5.8e-5 3.6e-5 10.0e-3 No
Yes
Physical interface: et-0/1/0, SNMP ifIndex 515
14:45-current
Suspect Flag:True Reason:Object Disabled
PM CURRENT MIN MAX AVG THRESHOLD
TCA-ENABLED TCA-RAISED
(MIN)
(MAX) (MIN) (MAX) (MIN) (MAX)
Lane chromatic dispersion 0 0 0 0 0
0 NA NA NA NA
Lane differential group delay 0 0 0 0 0
0 NA NA NA NA
q Value 120 120 120 120 0
0 NA NA NA NA
SNR 28 28 29 28 0
0 NA NA NA NA
Tx output power(0.01dBm) -5000 -5000 -5000 -5000 -300
-100 No No No No
Rx input power(0.01dBm) -3642 -3665 -3626 -3637 -1800
-500 No No No No
Module temperature(Celsius) 46 46 46 46 -5
75 No No No No
Tx laser bias current(0.1mA) 0 0 0 0 0
0 NA NA NA NA
Rx laser bias current(0.1mA) 1270 1270 1270 1270 0
0 NA NA NA NA
Carrier frequency offset(MHz) -186 -186 -186 -186 -5000
5000 No No No No
Sample Output
show security zones
user@host> show security zones
Functional zone: management
Description: This is the management zone.
Policy configurable: No
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: Host
Description: This is the host zone.
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
fxp0.0
Security zone: abc
Description: This is the abc zone.
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
Security zone: def
Description: This is the def zone.

Interfaces bound: 1
Interfaces:
ge-0/0/2.0

Syntax show interfaces snmp-index snmp-index
Description Display information for the interface with the specified SNMP index.
Additional Information Output from both the show interfaces interface-name detail and the show interfaces
interface-name extensive command includes all the information displayed in the output
from the show interfaces snmp-index command.

Level
List of Sample Output show interfaces snmp-index on page 830
Output Fields The output fields from the show interfaces snmp-index snmp-index command are identical
to those produced by the show interfaces interface-name command. For a description of
output fields, see the other chapters in this manual.
Sample Output
user@host> show interfaces snmp-index 33
Physical interface: so-2/1/1, Enabled, Physical link is Down
Interface flags: Hardware-Down Point-To-Point SNMP-Traps 16384
SONET alarms : LOL, PLL, LOS
SONET defects : LOL, PLL, LOF, LOS, SEF, AIS-L, AIS-P

show interfaces summary
Syntax show interfaces summary
Release Information Command introduced in Junos OS Release 14.1R2.
Description Display the status and statistics on logical interfaces configured on the device at the
Flexible PIC Concentrator (FPC) level.

Level
List of Sample Output show interfaces summary on page 831
Output Fields Table 140 on page 831 describes the output fields for the show interfaces summary
command. Output fields are listed in the approximate order in which they appear.
Table 140: show interfaces summary Output Fields

System's maximum logical interfaces Total number of logical interfaces in the device.
Logical interfaces allocated Number of allocated logical interfaces.
Logical interfaces available Number of available logical interfaces.
Logical interface type The type of logical interfaces.
• LSI—Number of label-switched logical interfaces and their status.

• Ethernet Untagged—Number of untagged logical interfaces and their status.
• Ethernet VLAN—Number of tagged logical interfaces and their status.
• Others—Number of dynamic and other logical interfaces, and their status.
System Statistics on the global logical interfaces in the system.
FPC x Statistics on the logical interfaces in a specific FPC.
Sample Output
show interfaces summary
user@host> show interfaces summary
Logical interfaces:
System's maximum logical interfaces : 262144
Logical interfaces allocated : 31
Logical interfaces available : 262113
System:
Logical interface type Count UP DOWN
Total 28 28 0

LSI 0 0 0
Ethernet Untagged 15 15 0
Ethernet VLAN 0 0 0
Others 13 13 0
FPC1:
Total 3 3 0
LSI 0 0 0
Ethernet VLAN 0 0 0
Others 0 0 0
FPC2:
Total 0 0 0
LSI 0 0 0
Ethernet VLAN 0 0 0
Others 0 0 0

show ilmi statistics
Syntax show ilmi statistics
Description Display input and output Integrated Local Management Interface (ILMI) statistics.

Level
Related • clear ilmi statistics on page 781

Documentation
List of Sample Output show ilmi statistics on page 835
Output Fields Table 141 on page 834 lists the output fields for the show ilmi statistics command. Output

Table 141: show ilmi statistics Output Fields

Field
Name Field Description
Input Information about received ILMI packets:
• Packets—Total number of messages delivered to the ILMI entity from the transport service.
• Bad versions—Total number of messages delivered to the ILMI entity that were for an unsupported ILMI version.
• Bad community names—Total number of messages delivered to the ILMI entity that did not use an ILMI community
name.
• Bad community uses—Total number of messages delivered to the ILMI entity that represented an ILMI operation
that was not allowed by the ILMI community named in the message.
• ASN parse errors—Total number of ASN.1 or BER errors encountered by the ILMI entity when decoding received ILMI
messages.
• Too bigs—Total number of ILMI packets delivered to the ILMI entity with an error status field of tooBig.
• No such names—Total number of ILMI packets delivered to the ILMI entity with an error status field of noSuchName.
• Bad values—Total number of ILMI packets delivered to the ILMI entity with an error status field of badValue.
• Read onlys—Total number of valid ILMI packets delivered to the ILMI entity with an error status field of readOnly.
Only incorrect implementations of ILMI generate this error.
• General errors—Total number of ILMI packets delivered to the ILMI entity with an error status field of genErr.
• Total request varbinds—Total number of objects retrieved successfully by the ILMI entity as a result of receiving
valid ILMI GetRequest and GetNext packets.
• Total set varbinds—Total number of objects modified successfully by the ILMI entity as a result of receiving valid
ILMI SetRequest packets.
• Get requests—Total number of ILMI GetRequest packets that have been accepted and processed by the ILMI entity.
• Get nexts—Total number of ILMI GetNext packets that have been accepted and processed by the ILMI entity.
• Set requests—Total number of ILMI SetRequest packets that have been accepted and processed by the ILMI entity.
• Get responses—Total number of ILMI GetResponse packets that have been accepted and processed by the ILMI
entity.
• Traps—Total number of ILMI traps received by the ILMI entity.
• Silent drops—Total number of GetRequest, GetNextRequest, GetBulkRequest, SetRequest, and InformRequest
packets delivered to the ILMI entity that were silently dropped because the size of a reply containing an alternate
response packet with an empty variable-bindings field was greater than either a local constraint or the maximum
message size associated with the originator of the requests.
• Proxy drops—Total number of GetRequest, GetNextRequest, GetBulkRequest, SetRequest, and InformRequest
packets delivered to the ILMI entity that were silently dropped because the transmission of the (possibly translated)
message to a proxy target failed in such a way (other than a timeout) that no response packet could be returned.
Output Information about transmitted ILMI packets:
• Packets—Total number of messages passed from the ILMI entity to the transport service.
• Too bigs—Total number of ILMI packets generated by the ILMI entity with an error status field of tooBig.
• No such names—Total number of ILMI packets generated by the ILMI entity with an error status field of noSuchName.
• Bad values—Total number of ILMI packets generated by the ILMI entity with an error status field of badValue.
• General errors—Total number of ILMI packets generated by the ILMI entity with an error status field of genErr.
• Get requests—Total number of ILMI GetRequest packets that have been generated by the ILMI entity.
• Get nexts—Total number of ILMI GetNext packets that have been generated by the ILMI entity.
• Set requests—Total number of ILMI SetRequest packets that have been generated by the ILMI entity.
• Get responses—Total number of ILMI GetResponse packets that have been generated by the ILMI entity.
• Traps—Total number of ILMI traps generated by the ILMI entity.

Sample Output
show ilmi statistics
user@host> show ilmi statistics
ILMI statistics:
Input:
Output:

show security alarms
Syntax show security alarms

<detail>
<alarm-id id-number>
<alarm-type [ types ]>
<newer-than YYYY-MM-DD.HH:MM:SS>
<older-than YYYY-MM-DD.HH:MM:SS>
<process process>
<severity severity>
Description Display the alarms that are active on the device. Run this command when the CLI prompt
indicates that a security alarm has been raised, as shown here:
[1 SECURITY ALARM] user@host#
Options none—Display all active alarms.
detail—(Optional) Display detailed output.
alarm-id id-number—(Optional) Display the specified alarm.
alarm-type [ types ]—(Optional) Display the specified alarm type or a set of types.
You can specify one or more of the following alarm types:
• authentication
• cryptographic-self-test
• decryption-failures
• encryption-failures
• ike-phase1-failures
• ike-phase2-failures
• key-generation-self-test
• non-cryptographic-self-test
• policy
• replay-attacks
newer-than YYYY-MM-DD.HH:MM:SS—(Optional) Display active alarms that were raised

after the specified date and time.
older-than YYYY-MM-DD.HH:MM:SS—(Optional) Display active alarms that were raised

before the specified date and time.

process process—(Optional) Display active alarms that were raised by the specified
system process.
severity severity—(Optional) Display active alarms of the specified severity.

You can specify the following severity levels:
• alert
• crit
• debug
• emerg
• err
• info
• notice
• warning

Level
Related • clear security alarms

Documentation
• Example: Generating a Security Alarm in Response to Policy Violations
List of Sample Output show security alarms on page 838

show security alarms detail on page 838
show security alarms alarm-id on page 838
show security alarms alarm-type authentication on page 839
show security alarms newer-than <time> on page 839
show security alarms older-than <time> on page 839
show security alarms process <process> on page 839
show security alarms severity <severity> on page 839
Output Fields Table 142 on page 837 lists the output fields for the show security alarms command. Output
fields are listed in the approximate order in which they appear. Field names might be
abbreviated (as shown in parentheses) when no level of output is specified or when the
detail keyword is used.
Table 142: show security alarms

ID Identification number of the alarm. All levels
Alarm time Date and time the alarm was raised.. All levels
Message Information about the alarm, including the alarm type, username, IP address, All levels
and port number.

Table 142: show security alarms (continued)

Process System process (For example, login or sshd) and process identification number detail
associated with the alarm.
Severity Severity level of the alarm. detail
Sample Output
show security alarms
[3 SECURITY ALARMS] user@router> show security alarms
ID Alarm time Message

1 2010-01-19 13:41:36 PST SSHD_LOGIN_FAILED_LIMIT: Specified number of login
failures (1) for user 'user' reached from '203.0.113.2’
show security alarms detail

[3 SECURITY ALARMS] user@router> show security alarms detail
Alarm ID : 1
Alarm Type : authentication
Time : 2010-01-19 13:41:36 PST
Message : SSHD_LOGIN_FAILED_LIMIT: Specified number of login failures (1) for
user 'user' reached from '203.0.113.2’
Process : sshd (pid 1414)
Severity : notice
Alarm ID : 2
Time : 2010-01-19 13:41:52 PST
Severity : notice
Alarm ID : 3
Time : 2010-01-19 13:42:13 PST
Severity : notice
show security alarms alarm-id

[3 SECURITY ALARMS] user@router> show security alarms alarm-id 1


show security alarms alarm-type authentication

[3 SECURITY ALARMS] user@router> show security alarms alarm-type authentication

show security alarms newer-than <time>

[3 SECURITY ALARMS] user@router> show security alarms newer-than 2010-01-19.13:41:59

show security alarms older-than <time>

[3 SECURITY ALARMS] user@router> show security alarms older-than 2010-01-19.13:41:59

show security alarms process <process>

[3 SECURITY ALARMS] user@router> show security alarms process sshd

show security alarms severity <severity>

[3 SECURITY ALARMS] user@router> show security alarms severity notice


show security datapath-debug capture
Syntax show security datapath-debug capture
Description Display details of the data path debugging capture file.

Level
Related • show security datapath-debug counter on page 841

Documentation
• Understanding Data Path Debugging for Logical Systems
List of Sample Output show security datapath—debug capture on page 840
Output Fields Output fields are listed in the approximate order in which they appear.
Sample Output
show security datapath—debug capture
user@host> show security datapath-debug capture
Packet 1, len 120: (C0/F0/P0/SEQ:71:lbt)
91 00 00 47 11 00 10 00 9a 14 00 19 03 00 00 00
00 00 00 00 00 01 00 47 10 00 00 00 00 00 00 00
00 1f 12 f8 dd 29 00 21 59 84 f4 01 81 00 02 1e
08 00 45 60 01 f4 00 00 00 00 3f 06 73 9f 01 01
01 02 03 01 01 02 d4 31 d4 31 00 00 00 00 00 00
00 00 50 02 00 00 ff ad 00 00 00 00
Packet 2, len 120: (C0/F0/P0/SEQ:71:lbt)
90 00 00 47 04 00 00 00 00 00 00 00 02 02 00 47
10 00 00 00 00 00 00 00 50 00 a6 1c 00 00 00 00
00 00 00 0a 00 00 00 00 00 00 09 d9 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 1f 12 f8
dd 29 00 21 59 84 f4 01 81 00 02 1e

show security datapath-debug counter
Syntax show security datapath-debug counter
Description Display details of the data path debugging counter.

Level
Related • show security datapath-debug capture on page 840

Documentation
• Understanding Data Path Debugging for Logical Systems
List of Sample Output show security datapath-debug counter on page 841
Output Fields Output fields are listed in the approximate order in which they appear.
Sample Output
show security datapath-debug counter
user@host> show security datapath-debug counter
Datapath debug counters
Packet Filter 1:
np-ingress
Chassis 0 FPC 4 : 1
np-ingress
Chassis 0 FPC 3 : 0
np-egress
Chassis 0 FPC 4 : 1
np-egress
Chassis 0 FPC 3 : 0
jexec
Chassis 0 FPC 0 PIC 1: 0
jexec
lbt
lbt
pot
pot

show security monitoring
Syntax show security monitoring
Description Displays a count of security flow and central point (CP) sessions, CPU utilization (as a
percentage of maximum), and memory in use (also as a percentage of maximum) at
the moment the command is run. This command is supported on SRX1500, SRX5400,
SRX5600, and SRX5800 devices and vSRX.
Required Privilege View

Level
Related • show security monitoring fpc fpc-number on page 844

Documentation
• show security monitoring performance session on page 847
• show security monitoring performance spu on page 848
show security monitoring

user@host>show security monitoring
user@host> show security monitoring

-----------------------------------------------------------------------–--
Flow session Flow session CP session CP session
FPC PIC CPU Mem current maximum current maximum
---------------------------------------------------------------------------
1 0 0 11 0 0 0 0
1 1 0 5 3 6291456 1 7549747
1 2 0 5 2 6291456 0 7549747
1 3 0 5 3 6291456 1 7549747
8 0 0 65 4 6963 2 8355
8 1 0 65 2 6963 0 8355
Total Sessions: 14 18888294 4 22665951
show security monitoring (vSRX)

user@host> show security monitoring

-----------------------------------------------------------------------–--
---------------------------------------------------------------------------
0 0 0 68 2 524288 N/A N/A
show security monitoring (vSRX in a Chassis Cluster)


node0:
--------------------------------------------------------------------------
---------------------------------------------------------------------------
0 0 0 67 0 524288 N/A N/A
node1:
--------------------------------------------------------------------------
---------------------------------------------------------------------------
0 0 0 67 0 524288 N/A N/A

show security monitoring fpc fpc-number
Syntax show security monitoring fpc fpc-number

<node ( node-id | all | local | primary)>
Description Display security monitoring information about the FPC slot.
Options • fpc-number —Display security monitoring information for the specified FPC slot. It can
be in the range from 0 to 11.
• node—(Optional) For chassis cluster configurations, display security monitoring

information for the specified FPC on a specific node (device) in the cluster.
• node-id —Identification number of the node. It can be 0 or 1.
• all—Display information about all nodes.
• local—Display information about the local node.
• primary—Display information about the primary node.
Additional Information For complete list of slot numbering, physical port, and logical interface numbering for
SRX Series devices in chassis cluster, see Chassis Cluster Feature Guide for SRX Series
Devices.

Level

Documentation
List of Sample Output show security monitoring fpc 0 on page 845

show security monitoring fpc 1 on page 845
show security monitoring fpc 8 on page 846
Output Fields Table 143 on page 844 lists the output fields for the show security monitoring fpc fpc-number
Table 143: show security monitoring fpc fpc-number Output Fields

FPC Slot number in which the FPC is installed.
PIC Slot number in which the PIC is installed.
CPU Utilization (%) Total percentage of CPU being used by the PIC's processors.

Table 143: show security monitoring fpc fpc-number Output Fields (continued)
Memory Utilization (%) Percentage of heap space (dynamic memory) being used by the PIC's processor. If this
number exceeds 80 percent, there might be a software problem (memory leak).
Current flow session The current number of flow sessions. When SRX Series devices operate in packet mode,
flow sessions will not be created and this field will remain zero.
Max flow session The maximum number of flow sessions allowed. This number will differ from one device
to another.
SPU current cp session The current number of cp sessions for the SPU (on SRX5600, and SRX5800 devices
only).
SPU max cp session The maximum number of cp sessions allowed for the SPU (on SRX5600, and SRX5800
devices only).
Sample Output
show security monitoring fpc 0
user@host> show security monitoring fpc 0
FPC 0
PIC 0
CPU utilization : 0 %
Memory utilization : 82 %
Current flow session : 0
Max flow session : 0
Current CP session : 0
Max CP session : 12000000
Session Creation Per Second (for last 96 seconds on average): 0
PIC 1
Max CP session : 0
Sample Output
FPC 1
PIC 0

Sample Output
FPC 5
PIC 0
PIC 1
Max CP session : 0

show security monitoring performance session
Syntax show security monitoring performance session
<fpc slot-number>
<pic slot-number>
Release Information Command introduced in Junos OS Release of 10.2.
Description Display the current session (total number of sessions at that time) for the last 60 seconds.
Options • fpc slot-number — Display information about the FPC slot. Use this option to filter the
output based on the slot number.
• pic slot-number — Display information about existing PIMs or Mini-PIMs in a particular

PIC slot. Use this option to filter the output based on PIC slot.
NOTE: The fpc slot-number and pic slot-number options are not available
on SRX300, SRX320, and SRX340 devices.

Level

Documentation
show security monitoring performance session

user@host> show security monitoring performance session
fpc 0 pic 0
Last 60 seconds:
0: 8 1: 8 2: 8 3: 8 4: 8 5: 7
6: 7 7: 7 8: 7 9: 7 10: 7 11: 8
12: 8 13: 8 14: 7 15: 7 16: 7 17: 7
18: 7 19: 7 20: 7 21: 5 22: 5 23: 5
24: 5 25: 5 26: 5 27: 5 28: 5 29: 4
30: 4 31: 4 32: 3 33: 3 34: 3 35: 3
36: 5 37: 5 38: 6 39: 6 40: 5 41: 5
42: 5 43: 5 44: 5 45: 5 46: 5 47: 5
48: 7 49: 7 50: 6 51: 8 52: 8 53: 6
54: 5 55: 7 56: 7 57: 5 58: 5 59: 8

show security monitoring performance spu
Syntax show security monitoring performance spu
<fpc slot-number>
<pic slot-number>
Description Display the services processing unit (SPU) percent utilization for all FPC slots over the
last 60 seconds. Use this command to track the percent utilization statistics per second
for the past 60 seconds for each FPC slot and PIC.
Options • fpc slot-number — Display information about the FPC slot. Use this option to filter the
output based on the slot number.
• pic slot-number — Display information about existing PIMs or Mini-PIMs in a particular

PIC slot. Use this option to filter the output based on PIC slot.
NOTE: The fpc slot-number and pic slot-number options are not available
on SRX300, SRX320, or SRX340 devices or on vSRX instances.

Level

Documentation
show security monitoring performance spu

This sample shows 46% utilization of the SPU for second 42 in the past 60 seconds for
FPC 0 and PIC 0.
user@host>show security monitoring performance spu
fpc 0 pic 0
Last 60 seconds:
0: 48 1: 48 2: 48 3: 48 4: 48 5: 48
6: 48 7: 48 8: 49 9: 48 10: 48 11: 48
12: 48 13: 48 14: 48 15: 48 16: 48 17: 48
18: 48 19: 48 20: 48 21: 48 22: 49 23: 48
24: 49 25: 49 26: 48 27: 48 28: 48 29: 48
30: 48 31: 48 32: 48 33: 48 34: 48 35: 48
36: 46 37: 47 38: 46 39: 46 40: 46 41: 46
42: 46 43: 46 44: 46 45: 46 46: 46 47: 46
48: 46 49: 46 50: 46 51: 46 52: 46 53: 46
54: 46 55: 46 56: 46 57: 46 58: 46 59: 46


show services ip-monitoring status
Syntax show services ip-monitoring status
Release Information Command modified in Junos OS Release 11.4 R2. Next-hop functionality added in Junos
Description Display a brief summary of IP monitoring status along with the current state for a given
policy.

Level
Related • show security monitoring on page 842

Documentation
List of Sample Output show services ip-monitoring status on page 851

show services ip-monitoring status on page 851
Output Fields Table 144 on page 850 lists the output fields for the show services ip-monitoring status
Table 144: show services ip-monitoring status Output Fields

Policy Name of the policy configured.
Probe Name Name of the probe configured.
Address Displays the configured target address.
Status Displays the status of the probe on the target address. If the status is PASS, then the
target address is reached.
Route-Action Displays route injection information configured for the policy and its failover status.
Route-Instance Displays the routing instance of the route to be injected during failover.
Route Routing address of the route to be injected during failover.
Next-Hop Specifies the next-hop address of the route to be injected during failover. P2P interfaces
only.
State Display the state of the route injection action. If the state is APPLIED, then the
ip-monitoring policy is in failover state.

Table 144: show services ip-monitoring status Output Fields (continued)

Interface Action Displays the interface action type as enable or disable.
Policy Action Displays the policy action type as enable or disable.
Admin State Displays the current admin state of the interface.
Action Status Displays the current action status of the interface.
Sample Output
user@host> show services ip-monitoring status
Policy - policy1 (Non-preemptive. Status: FAIL)

RPM Probes:
Probe name Test Name Address Status
---------------------- --------------- ---------------- ---------
probe_a a1 15.1.1.10 FAIL
probe_a a2 200.1.1.1 FAIL
Route-Action:
route-instance route next-hop State
----------------- ----------------- ---------------- -------------
inet.0 200.1.1.0 150.1.1.1 APPLIED
Interface-Action:
interface policy action admin state action status
----------------- --------------- ----------- -----------------
fe-0/0/5.2 Enable UP FAILOVER
fe-0/0/5.4 Disable DOWN FAILOVER
t1-1/0/0 Enable UP FAILOVER
dl0 Enable UP FAILOVER
ge-0/0/1 Enable UP FAILOVER
Sample Output
In this example, the policy is in the failback state, and the no-preempt option is not
configured.
Policy - policy1 (Status: PASS)

RPM Probes:
---------------------- --------------- ---------------- ---------
probe1 a1 99.1.1.2 PASS
Route-Action:
route-instance route next-hop state
----------------- ----------------- ---------------- -------------
inet.0 99.1.1.0 12.12.12.2 NOT-APPLIED
Interface-Action:


----------------- --------------- ----------- -----------------
at-2/0/0 Enable DOWN MARKED-DOWN
ge-0/0/2.2 Enable DOWN MARKED-DOWN
ge-0/0/2.3 Enable DOWN MARKED-DOWN
Sample Output
In this example, the policy is in the failover state, and the primary is restored. The
no-preempt option is configured.
Policy - policy1 (Non-preemptive. Status: FAILOVER-NO-PREEMPT)

RPM Probes:
---------------------- --------------- ---------------- ---------
probe1 a1 99.1.1.2 PASS
Route-Action:
----------------- ----------------- ---------------- -------------
inet.0 99.1.1.0 12.12.12.2 APPLIED
Interface-Action:
----------------- --------------- ----------- -----------------
at-2/0/0 Enable UP FAILOVER
ge-0/0/2.2 Enable UP FAILOVER
ge-0/0/2.3 Enable UP FAILOVER
Sample Output
When the probe succeeds and the policy is not applied, the output is as follows:

Policy payment (Status: PASS)
RPM Probes:
---------------------- --------------- ---------------- ---------
Probe-Payment-Server paysvr 9.9.9.2 PASS
Route-Action:
----------------- ----------------- ---------------- -------------
inet.0 9.9.9.0/24 e1-6/0/0.0 NOT-APPLIED
Sample Output
When the probe fails and the policy is applied, the output is as follows:

Policy payment (Status: FAIL)
RPM Probes:
---------------------- --------------- ---------------- ---------
Probe-Payment-Server paysvr 9.9.9.2 FAIL

Route-Action:
----------------- ----------------- ---------------- -------------
inet.0 9.9.9.0/24 e1-6/0/0.0 APPLIED

show snmp health-monitor
Supported Platforms EX Series, M Series, MX Series, PTX Series, QFabric System, QFX Series, T Series
Syntax show snmp health-monitor

<alarms <detail>> | <logs>

Description Display information about Simple Network Management Protocol (SNMP) health monitor
alarms and logs.
Options none—Display information about all health monitor alarms and logs.
alarms <detail>—(Optional) Display detailed information about health monitor alarms.
logs—(Optional) Display information about health monitor logs.

Level
List of Sample Output show snmp health-monitor on page 856

show snmp health-monitor alarms detail on page 858
Output Fields Table 145 on page 854 describes the output fields for the show snmp health-monitor
Table 145: show snmp health-monitor Output Fields

Alarm Index Alarm identifier. All levels
Variable description Description of the health monitor object instance being monitored. All levels
Variable name Name of the health monitor object instance being monitored. All levels
Value Current value of the monitored variable in the most recent sample interval. All levels

Table 145: show snmp health-monitor Output Fields (continued)

State State of the alarm or event entry: All levels
• Alarms:
• active—Entry is fully configured and activated.
• falling threshold crossed—Value of the variable has crossed the lower
threshold limit.
• rising threshold crossed—Value of the variable has crossed the upper
threshold limit.
• under creation—Entry is being configured and is not yet activated.
• startup—Alarm is waiting for the first sample of the monitored variable.
• object not available—Monitored variable of that type is not available to the
health monitor agent.
• instance not available—Monitored variable's instance is not available to
the health monitor agent.
• object type invalid—Monitored variable is not a numeric value.
• object processing errored—An error occurred when the monitored variable
was processed.
• unknown—State is not one of the above.
Variable OID Object ID to which the variable name is resolved. The format is x.x.x.x. detail
Sample type Method of sampling the monitored variable and calculating the value to compare detail
against the upper and lower thresholds. It can have the value of absolute value
or delta value.
Startup alarm Alarm that might be sent when this entry is first activated, depending on the detail
following criteria:
• Alarm is sent when one of the following situations exists:

• Value of the alarm is above or equal to the rising threshold and the startup
type is either rising alarm or rising or falling alarm.
• Value of the alarm is below or equal to the falling threshold and the startup
type is either falling alarm or rising or falling alarm.
• Alarm is not sent when one of the following situations exists:

type is falling alarm.
type is rising alarm.
• Value of the alarm is between the thresholds.
Owner Name of the entry configured by the user. If the entry was created through the detail
CLI, the owner has monitor prepended to it.
Creator Mechanism by which the entry was configured (Health Monitor). detail
Sample interval Time period between samples (in seconds). detail
Rising threshold Upper limit threshold value as a percentage of the maximum possible value. detail

Table 145: show snmp health-monitor Output Fields (continued)

Falling threshold Lower limit threshold value as a percentage of the maximum possible value. detail
Rising event index Event triggered when the rising threshold is crossed. detail
Falling event index Event triggered when the falling threshold is crossed. detail
Sample Output
show snmp health-monitor
user@host> show snmp health-monitor
Alarm
Index Variable description Value State
32768 Health Monitor: root file system utilization

jnxHrStoragePercentUsed.1 58 active
32769 Health Monitor: /config file system utilization

jnxHrStoragePercentUsed.2 0 active
32770 Health Monitor: RE 0 CPU utilization

jnxOperatingCPU.9.1.0.0 0 active
32773 Health Monitor: RE 0 Memory utilization

jnxOperatingBuffer.9.1.0.0 35 active
32775 Health Monitor: jkernel daemon CPU utilization

Init daemon 0 active
Chassis daemon 50 active
Firewall daemon 0 active
Interface daemon 5 active
SNMP daemon 11 active
MIB2 daemon 42 active
Sonet APS daemon 0 active
VRRP daemon 0 active
Alarm daemon 3 active
PFE daemon 0 active
CRAFT daemon 0 active
Traffic sampling control daemon 0 active
Ilmi daemon 0 active
Remote operations daemon 0 active
CoS daemon 0 active
Pic Services Logging daemon 0 active
Internal Routing Service Daemon 3 active
Network Access Service daemon 0 active
Forwarding UDP daemon 0 active
Routing socket proxy daemon 0 active
Disk Monitoring daemon 1 active
Inet daemon 0 active
Syslog daemon 0 active
Adaptive Services PIC daemon 0 active
ECC parity errors logging Daemon 0 active
Layer 2 Tunneling Protocol daemon 0 active
PPPoE daemon 3 active

Redundancy device daemon 0 active

PPP daemon 0 active
Dynamic Flow Capture Daemon 0 active
32776 Health Monitor: jroute daemon CPU utilization

Routing protocol daemon 1 active
Management daemon 0 active
Command line interface 4 active
Periodic Packet Management daemon 0 active
Link Management daemon 0 active
Pragmatic General Multicast daemon 0 active
Bidirectional Forwarding Detection daemon 0 active
SRC daemon 0 active
audit daemon 0 active
Event daemon 0 active
32777 Health Monitor: jcrypto daemon CPU utilization

IPSec Key Management daemon 0 active
32779 Health Monitor: jkernel daemon Memory utilization

Init daemon 47384 active
Chassis daemon 20204 active
Firewall daemon 1956 active
Interface daemon 3340 active
SNMP daemon 4540 active
MIB2 daemon 3880 active
Sonet APS daemon 2632 active
VRRP daemon 2672 active
Alarm daemon 1856 active
PFE daemon 2600 active
CRAFT daemon 2000 active
Traffic sampling control daemon 3164 active
Ilmi daemon 2132 active
Remote operations daemon 2964 active
CoS daemon 3044 active
Pic Services Logging daemon 1944 active
Internal Routing Service Daemon 1392 active
Network Access Service daemon 1992 active
Forwarding UDP daemon 1876 active
Routing socket proxy daemon 1296 active
Disk Monitoring daemon 1180 active
Inet daemon 1296 active
Syslog daemon 1180 active
Adaptive Services PIC daemon 3220 active
ECC parity errors logging Daemon 1100 active
Layer 2 Tunneling Protocol daemon 3372 active
PPPoE daemon 1424 active
Redundancy device daemon 1820 active
PPP daemon 2060 active
Dynamic Flow Capture Daemon 10740 active
32780 Health Monitor: jroute daemon Memory utilization
Routing protocol daemon 8104 active
Command line interface 9912 active
Periodic Packet Management daemon 1484 active
Link Management daemon 2016 active
Pragmatic General Multicast daemon 1968 active
Bidirectional Forwarding Detection daemon 1956 active
SRC daemon 1772 active

audit daemon 1772 active

Event daemon 1808 active
32781 Health Monitor: jcrypto daemon Memory utilization

IPSec Key Management daemon 5600 active
show snmp health-monitor alarms detail

user@host> show snmp health-monitor alarms detail
Alarm Index 32768:

Variable name jnxHrStoragePercentUsed.1
Variable OID 1.3.6.1.4.1.2636.3.31.1.1.1.1.1
Sample type absolute value
Startup alarm rising alarm
Owner Health Monitor: root file system
utilization
Creator Health Monitor
State active
Sample interval 300 seconds
Rising threshold 80
Falling threshold 70
Rising event index 32768
Falling event index 32768
Instance Value: 58
Instance State: active
Alarm Index 32769:

Variable name jnxHrStoragePercentUsed.2
Variable OID 1.3.6.1.4.1.2636.3.31.1.1.1.1.2
Owner Health Monitor: /config file system
utilization
State active
Rising threshold 80
Instance Value: 0
Alarm Index 32770:

Variable name jnxOperatingCPU.9.1.0.0
Variable OID 1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0
Owner Health Monitor: RE 0 CPU utilization

State active
Rising threshold 80
Instance Value: 0

Alarm Index 32773:

Variable name jnxOperatingBuffer.9.1.0.0
Variable OID 1.3.6.1.4.1.2636.3.1.13.1.11.9.1.0.0
Owner Health Monitor: RE 0 Memory utilization

State active
Rising threshold 80
Instance Value: 35
Alarm Index 32775:

Variable name sysApplElmtRunCPU.3
Variable OID 1.3.6.1.2.1.54.1.2.3.1.9.3
Sample type delta value
Owner Health Monitor: jkernel daemon CPU
utilization
State active
Rising threshold 24000
Instance Name: sysApplElmtRunCPU.3.1.1
Instance Description: Init daemon
Instance Value: 0

Instance Description: Chassis daemon
Instance Value: 50

Instance Description: Firewall daemon
Instance Value: 0

Instance Description: Interface daemon
Instance Value: 5

Instance Description: SNMP daemon
Instance Value: 11

Instance Description: MIB2 daemon
Instance Value: 42


Instance Description: Sonet APS daemon
Instance Value: 0

Instance Description: VRRP daemon
Instance Value: 0

Instance Description: Alarm daemon
Instance Value: 3

Instance Description: PFE daemon
Instance Value: 0

Instance Description: CRAFT daemon
Instance Value: 0

Instance Description: Traffic sampling control daemon
---(more 23%)---

show snmp inform-statistics
Syntax show snmp inform-statistics

Description Display information about Simple Network Management Protocol (SNMP) inform
requests.

Level
List of Sample Output show snmp inform-statistics on page 861
Output Fields Table 146 on page 861 describes the output fields for the show snmp inform-statistics
Table 146: show snmp inform-statistics Output Fields

Target Name Name of the device configured to receive and respond to SNMP informs.
Address IP address of the target device.
Sent Number of informs sent to the target device and acknowledged by the target device.
Pending Number of informs held in memory pending a response from the target device.
Discarded Number of informs discarded after the specified number of retransmissions to the target device were
attempted.
Timeouts Number of informs that did not receive an acknowledgement from the target device within the timeout
specified.
Probe Failures Connection failures that occurred (for example, when the target server returned invalid content or
you incorrectly configured the target address).
Sample Output
show snmp inform-statistics
user@host> show snmp inform-statistics
Inform Request Statistics:
Target Name: TA1_v3_md5_none Address: 172.17.20.184

Sent: 176, Pending: 0

Discarded: 0, Timeouts: 0, Probe Failures: 0
Target Name: TA2_v3_sha_none Address: 192.168.110.59
Sent: 0, Pending: 4
Target Name: TA5_v2_none Address: 172.17.20.184
Sent: 0, Pending: 0

show snmp mib
Supported Platforms EX Series, M Series, MX Series, OCX1100, PTX Series, QFX Series, T Series
Syntax show snmp mib (get | get-next | walk) (ascii | decimal) object-id

ascii and decimal options introduced in Junos OS Release 9.6.
ascii and decimal options introduced in Junos OS Release 9.6 for EX Series switches.
Description Display local Simple Network Management Protocol (SNMP) Management Information
Base (MIB) object values.
Options get—Retrieve and display one or more SNMP object values.
get-next—Retrieve and display the next SNMP object values.
walk—Retrieve and display the SNMP object values that are associated with the requested
object identifier (OID). When you use this option, the Junos OS displays the objects
below the subtree that you specify.
ascii—Display the SNMP object’s string indices as an ASCII-key representation.
decimal—Display the SNMP object values in the decimal (default) format. The decimal
option is the default option for this command. Therefore, issuing the show snmp mib
(get | get-next | walk) decimal object-id and the show snmp mib (get | get-next | walk)
object-id commands display the same output.
object-id—The object can be represented by a sequence of dotted integers (such as

1.3.6.1.2.1.2) or by its subtree name (such as interfaces). When entering multiple
objects, enclose the objects in quotation marks.

Level
List of Sample Output show snmp mib get on page 864

show snmp mib get (Multiple Objects) on page 864
show snmp mib get (Layer 2 Policer) on page 864
show snmp mib get-next on page 864
show snmp mib get-next (Specify an OID) on page 864
show snmp mib walk on page 864
show snmp mib walk (QFX Series) on page 864
show snmp mib walk decimal on page 865
show snmp mib walk (ASCII) on page 865
show snmp mib walk (Multiple Indices) on page 865
show snmp mib walk decimal (Multiple Indices) on page 865

Output Fields Table 147 on page 864 describes the output fields for the show snmp mib command.
Output fields are listed in the approximate order in which they appear.
Table 147: show snmp mib Output Fields

name Object name and numeric instance value.
object value Object value. The Junos OS translates OIDs into the corresponding
object names.
Sample Output
show snmp mib get
user@host> show snmp mib get sysObjectID.0
sysObjectID.0 = jnxProductNameM20
show snmp mib get (Multiple Objects)

user@host> show snmp mib get ?sysObjectID.0 sysUpTime.0?
sysUpTime.0 = 1640992
show snmp mib get (Layer 2 Policer)

user@host> show snmp mib get ifInOctets.25970
ifInOctets.25970 = 7545720
show snmp mib get-next

user@host> show snmp mib get-next jnxMibs
jnxBoxClass.0 = jnxProductLineM20.0
show snmp mib get-next (Specify an OID)

user@host> show snmp mib get-next 1.3.6.1
sysDescr.0 = Juniper Networks, Inc. m20 internet router, kernel
Junos OS Release: 2004-1 Build date: build date UTC Copyright (c) 1996-2004 Juniper
Networks, Inc.
show snmp mib walk

user@host> show snmp mib walk system
sysDescr.0 = Juniper Networks, Inc. m20 internet router, kernel
Junos OS Release #0: 2004-1 Build date: build date UTC Copyright (c) 1996-2004
Juniper Networks, Inc.
sysUpTime.0 = 1640992
sysContact.0 = Your contact
sysName.0 = my router
sysLocation.0 = building 1
sysServices.0 = 4
show snmp mib walk (QFX Series)

user@switch> show snmp mib walk system

sysDescr.0 = Juniper Networks, Inc. qfx3500s internet router, kernel JUNOS

11.1-20100926.0 #0: 2010-09-26 06:17:38 UTC Build date: 2010-09-26 06:00:10
sysObjectID.0 = jnxProductQFX3500
sysUpTime.0 = 138980301
sysContact.0 = System Contact
sysName.0 = LabQFX3500
sysLocation.0 = Lab
sysServices.0 = 4
show snmp mib walk decimal

user@host show snmp mib walk decimal jnxUtilData
jnxUtilCounter32Value.102.114.101.100 = 100
show snmp mib walk (ASCII)

show snmp mib walk ascii jnxUtilData
jnxUtilCounter32Value."fred" = 100
show snmp mib walk (Multiple Indices)

show snmp mib walk ascii jnxFWCounterByteCount
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_BE-fe-1/3/0.0-i".2 = 0
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_CC-fe-1/3/0.0-i".2 = 0
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_RT-fe-1/3/0.0-i".2 = 0
.......
show snmp mib walk decimal (Multiple Indices)

show snmp mib walk ascii jnxFWCounterByteCount
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_BE-fe-1/3/0.0-i".2 = 0
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_CC-fe-1/3/0.0-i".2 = 0
jnxFWCounterByteCount."fe-1/3/0.0-i"."CLASS_RT-fe-1/3/0.0-i".2 = 0
.......

show snmp rmon
Syntax show snmp rmon

<alarms <brief | detail> | events <brief | detail> | logs>

Description Display information about Simple Network Management Protocol (SNMP) Remote
Monitoring (RMON) alarms and events.
Options none—Display information about all RMON alarms and events.
alarms—(Optional) Display information about RMON alarms.
brief | detail—(Optional) Display brief or detailed information about RMON alarms or

events.
events—(Optional) Display information about RMON events.
logs—(Optional) Display information about RMON monitoring logs.

Level
List of Sample Output show snmp rmon on page 868

show snmp rmon alarms detail on page 868
show snmp rmon events detail on page 869
Output Fields Table 148 on page 866 describes the output fields for the show snmp rmon command.
Table 148: show snmp rmon Output Fields

Alarm Index Alarm identifier. All levels

Table 148: show snmp rmon Output Fields (continued)

State State of the alarm or event entry: All levels
Alarms:
• active—Entry is fully configured and activated.

• falling threshold crossed—Value of the variable has crossed the lower threshold
limit.
• rising threshold crossed—Value of the variable has crossed the upper threshold
limit.
• startup—Alarm is waiting for the first sample of the monitored variable.
• object not available—Monitored variable of that type is not available to the
SNMP agent.
• instance not available—Monitored variable's instance is not available to the
SNMP agent.
• object type invalid—Monitored variable is not a numeric value.
• object processing errored—An error occurred when the monitored variable
was processed.
Events:
• active—Entry has been fully configured and activated.

Variable name Name of the SNMP object instance being monitored. All levels
Event Index Event identifier. All levels
Type Type of notification made when an event is triggered. It can be one of the detail
following:
• log—A system log message is generated and an entry is made to the log table.
• snmptrap—An SNMP trap is sent to the configured destination.
• log and trap—A system log message is generated, an entry is made to the log
table, and an SNMP trap is sent to the configured destination.
• none—Neither log nor trap will be sent.
Last Event Date and time of the last event. It has the format yyyy-mm-dd hh:mm:ss brief
timezone.
Community Identifies the trap group used for sending the SNMP trap. detail
Variable OID Object ID to which the variable name is resolved. The format is x.x.x.x. detail
Sample type Method of sampling the monitored variable and calculating the value to compare detail
against the upper and lower thresholds. It can have the value of absolute value
or delta value.

Table 148: show snmp rmon Output Fields (continued)

Startup alarm Alarm that might be sent when this entry is first activated, depending on the detail
following criteria:
• Alarm is sent when one of the following situations exists:

type is either rising alarm or rising or falling alarm.
type is either falling alarm or rising or falling alarm.
• Alarm is not sent when one of the following situations exists:

type is falling alarm.
type is rising alarm.
• Value of the alarm is between the thresholds.
Owner Name of the entry configured by the user. If the entry was created through the detail
CLI, the owner has monitor prepended to it.
Creator Mechanism by which the entry was configured (CLI or SNMP). detail
Sample interval Time period between samples (in seconds). detail
Rising threshold Upper limit threshold value configured by the user. detail
Falling threshold Lower limit threshold value configured by the user. detail
Rising event index Event triggered when the rising threshold is crossed. detail
Falling event index Event triggered when the falling threshold is crossed. detail
Current value Current value of the monitored variable in the most recent sample interval. detail
Sample Output
show snmp rmon
user@host> show snmp rmon
Alarm
Index State Variable name
1 falling threshold crossed ifInOctets.1
Event
Index Type Last Event
1 log and trap 2002-01-30 01:13:01 PST
show snmp rmon alarms detail

user@host> show snmp rmon alarms detail

Alarm Index 1:
Variable name ifInOctets.1
Variable OID 1.3.6.1.2.1.2.2.1.10.1
Sample type delta value
Startup alarm rising or falling alarm
Owner monitor
Creator CLI
State falling threshold crossed
Rising threshold 100000
Current value 0
show snmp rmon events detail

user@host> show snmp rmon events detail
Event Index 1:
Type log and trap
Community boy-elroy
Last event 2002-01-30 01:13:01 PST
Creator CLI
State active

show snmp statistics
Syntax show snmp statistics

<subagents>

Command introduced in Junos OS Release 14.1X53-D20 for OCX Series switches.
Option subagents introduced in Junos OS Release 14.2.
Description Display statistics about Simple Network Management Protocol (SNMP) packets sent
and received by the router or switch.
Options subagents—(Optional) Display the statistics of the protocol data unit (PDU), the number
of SNMP requests and responses per subagent, and the SNMP statistics received
from each subagent per logical system.

Level
Related • clear snmp statistics on page 783

Documentation
List of Sample Output show snmp statistics on page 875

show snmp statistics subagents on page 875
Output Fields Table 149 on page 871 describes the output fields for the show snmp statistics command.

Table 149: show snmp statistics Output Fields

Input Information about received packets:
• Packets(snmpInPkts)—Total number of messages delivered to the SNMP entity

from the transport service.
• Bad versions—(snmpInBadVersions) Total number of messages delivered to the
SNMP entity that were for an unsupported SNMP version.
• Bad community names—(snmpInBadCommunityNames) Total number of
messages delivered to the SNMP entity that used an SNMP community name
not known to the entity.
• Bad community uses—(snmpInBadCommunityUses) Total number of messages
delivered to the SNMP entity that represented an SNMP operation that was not
allowed by the SNMP community named in the message.
• ASN parse errors—(snmpInASNParseErrs) Total number of ASN.1 or BER errors
encountered by the SNMP entity when decoding received SNMP messages.
• Too bigs—(snmpInTooBigs) Total number of SNMP PDUs delivered to the SNMP
entity with an error status field of tooBig.
• No such names—(snmpInNoSuchNames) Total number of SNMP PDUs delivered
to the SNMP entity with an error status field of noSuchName.
• Bad values—(snmpInBadValues) Total number of SNMP PDUs delivered to the
SNMP entity with an error status field of badValue.
• Read onlys—(snmpInReadOnlys) Total number of valid SNMP PDUs delivered to
the SNMP entity with an error status field of readOnly. Only incorrect
implementations of SNMP generate this error.

Table 149: show snmp statistics Output Fields (continued)

Input (continued) • General errors—(snmpInGenErrs) Total number of SNMP PDUs delivered to the
SNMP entity with an error status field of genErr.
• Total requests varbinds—(snmpInTotalReqVars) Total number of MIB objects
retrieved successfully by the SNMP entity as a result of receiving valid SNMP
GetRequest and GetNext PDUs.
• Total set varbinds—(snmpInSetVars) Total number of MIB objects modified
successfully by the SNMP entity as a result of receiving valid SNMP SetRequest
PDUs.
• Get requests—(snmpInGetRequests) Total number of SNMP GetRequest PDUs
that have been accepted and processed by the SNMP entity.
• Get nexts—(snmpInGetNexts) Total number of SNMP GetNext PDUs that have
been accepted and processed by the SNMP entity.
• Set requests—(snmpInSetRequests) Total number of SNMP SetRequest PDUs
that have been accepted and processed by the SNMP entity.
• Get responses—(snmpInGetResponses) Total number of SNMP GetResponse
PDUs that have been accepted and processed by the SNMP entity.
• Traps—(snmpInTraps) Total number of SNMP traps generated by the SNMP
entity.
• Silent drops—(snmpSilentDrops) Total number of GetRequest, GetNextRequest,
GetBulkRequest, SetRequests, and InformRequest PDUs delivered to the SNMP
entity that were silently dropped because the size of a reply containing an
alternate response PDU with an empty variable-bindings field was greater than
either a local constraint or the maximum message size associated with the
originator of the requests.
• Proxy drops—(snmpProxyDrops) Total number of GetRequest, GetNextRequest,
GetBulkRequest, SetRequests, and InformRequest PDUs delivered to the SNMP
entity that were silently dropped because the transmission of the message to a
proxy target failed in such a way (other than a timeout) that no response PDU
could be returned.
• Commit pending drops—Number of SNMP packets for Set requests dropped
because of a previous pending SNMP Set request on the committed configuration.
• Throttle drops—Number of SNMP packets for any requests dropped reaching the
throttle limit.


V3 Input Information about SNMP version 3 packets:
• Unknown security models—(snmpUnknownSecurityModels) Total number of

packets received by the SNMP engine that were dropped because they referenced
a security model that was not known to or supported by the SNMP engine.
• Invalid messages—(snmpInvalidMsgs) Number of packets received by the SNMP
engine that were dropped because there were invalid or inconsistent components
in the SNMP message.
• Unknown pdu handlers—(snmpUnknownPDUHandlers) Number of packets received
by the SNMP engine that were dropped because the PDU contained in the packet
could not be passed to an application responsible for handling the PDU type.
• Unavailable contexts—(snmpUnavailableContexts) Number of requests received
for a context that is known to the SNMP engine, but is currently unavailable.
• Unknown contexts—(snmpUnknownContexts) Total number of requests received
for a context that is unknown to the SNMP engine.
• Unsupported security levels—(usmStatsUnsupportedSecLevels) Total number of
packets received by the SNMP engine that were dropped because they requested
a security level unknown to the SNMP engine (or otherwise unavailable).
• Not in time windows—(usmStatsNotInTimeWindows) Total number of packets
received by the SNMP engine that were dropped because they appeared outside
the authoritative SNMP engine’s window.
• Unknown user names—(usmStatsUnknownUserNames) Total number of packets
received by the SNMP engine that were dropped because they referenced a user
that was not known to the SNMP engine.
• Unknown engine ids—(usmStatsUnknownEngineIDs) Total number of packets
received by the SNMP engine that were dropped because they referenced an
SNMP engine ID that was not known to the SNMP engine.
• Wrong digests—(usmStatsWrongDigests) Total number of packets received by
the SNMP engine that were dropped because they did not contain the expected
digest value.
• Decryption errors—(usmStatsDecryptionErrors) Total number of packets received
by the SNMP engine that were dropped because they could not be decrypted.


Output Information about transmitted packets:
• Packets—(snmpOutPkts) Total number of messages passed from the SNMP

entity to the transport service.
• Too bigs—(snmpOutTooBigs) Total number of SNMP PDUs generated by the
SNMP entity with an error status field of tooBig.
• No such names—(snmpOutNoSuchNames) Total number of SNMP PDUs delivered
to the SNMP entity with an error status field of noSuchName.
• Bad values—(snmpOutBadValues) Total number of SNMP PDUs generated by
the SNMP entity with an error status field of badValue.
• General errors—(snmpOutGenErrs) Total number of SNMP PDUs generated by
the SNMP entity with an error status field of genErr.
• Get requests—(snmpOutGetRequests) Total number of SNMP GetRequest PDUs
generated by the SNMP entity.
• Get nexts—(snmpOutGetNexts) Total number of SNMP GetNext PDUs generated
by the SNMP entity.
• Set requests—(snmpOutSetRequests) Total number of SNMP SetRequest PDUs
generated by the SNMP entity.
• Get responses—(snmpOutGetResponses) Total number of SNMP GetResponse
PDUs generated by the SNMP entity.
• Traps—(snmpOutTraps) Total number of SNMP traps generated by the SNMP
entity.
Table 150 on page 874 describes the output fields for the show snmp statistics subagents
Table 150: show snmp statistics subagents Output Fields

Subagent Location of the SNMP subagent.
Request PDUs Number of PDUs requested by the SNMP manager.
Response PDUs Number of response PDUs sent by the SNMP subagent.
Request Variables Number of variable bindings on the PDUs requested by the SNMP
manager.
Response Variables Number of variable bindings on the PDUs sent by the SNMP
subagent.
Average Response Time Average time taken by the SNMP subagent to send statistics
response.
Maximum Response Time Maximum time taken by the SNMP subagent to send the
statistics response.

Sample Output
show snmp statistics
SNMP statistics:
Input:
Throttle drops: 0,
V3 Input:
Output:
show snmp statistics subagents

user@host> show snmp statistics subagents
Subagent: /var/run/cosd-20
Request PDUs: 0, Response PDUs: 0,
Request Variables: 0, Response Variables: 0,
Average Response Time(ms): 0.00,
Maximum Response Time(ms): 0.00
Subagent: /var/run/pfed-30
Subagent: /var/run/rmopd-15
Subagent: /var/run/chassisd-30
Subagent: /var/run/pkid-13

Subagent: /var/run/apsd-13
Subagent: /var/run/dfcd-32
Subagent: /var/run/mib2d-33
Subagent: /var/run/license-check-16
Subagent: /var/run/craftd-14
Subagent: /var/run/bfdd-19
Subagent: /var/run/smihelperd-24
Subagent: /var/run/cfmd-18
Subagent: /var/run/rpd_snmp
Subagent: /var/run/l2tpd-18


show snmp stats-response-statistics
Supported Platforms ACX Series, E Series, EX Series, M Series, MX Series, PTX Series, QFX Series, T Series
Syntax show snmp stats-response-statistics
Description Display statistics of SNMP statistics responses sent from the Packet Forwarding Engine
during the MIB II process (mib2d).

Level
List of Sample Output show snmp stats-response-statistics on page 879
Output Fields Table 151 on page 878 describes the output fields for the show snmp
stats-response-statistics command. Output fields are listed in the approximate order in
which they appear.
Table 151: show snmp stats-response-statistics Output Fields

Average response time Display the average response time in milliseconds per protocol data unit (PDU) by snmpd. It includes
statistics the following information:
• Stats Type—Type of SNMP statistics.

• Stats Responses—Number of SNMP statistics responses received from the Packet Forwarding
Engine.
• Average Response Time—Average time taken to receive the statistics response from the Packet
Forwarding Engine in milliseconds.
Bucket statistics Information about SNMP statistics responses:
• Bucket Type—Category of time intervals in which SNMP statistics responses are received from the
Packet Forwarding Engine.
• Stats Responses—Number of SNMP statistics responses received from the Packet Forwarding
Engine.
Bad responses Information about top 20 bad responses from a subagent:
• Response—Time taken to receive the SNMP statistics response from the Packet Forwarding Engine
in milliseconds.
• Request Time—Date and time of SNMP request.
• Key—Display the attribute of SNMP Stats Type. For example, in the case of SNMP statistics responses
for interfaces, the Key value is SNMP ifIndex, and for firewalls, the Key value is the filter name.

Sample Output
show snmp stats-response-statistics
user@host> show snmp stats-response-statistics
Average response time statistics:
Stats Stats Average
Type Responses Response
Time (ms)
ifd(non ae) 34182 175.48
ifd(ae) 0 0.00
ifl(non ae) 5472 5.40
ifl(ae) 0 0.00
firewall 15 1141.73
Bucket statistics:
Bucket Stats
Type(ms) Responses
0 - 10 39078
11 - 50 588
51 - 100 0
101 - 200 0
201 - 500 1
501 - 1000 2
1001 - 2000 0
2001 - 5000 0
More than 5001 0
Bad responses:
Response Request Stats Key
Time Type
(ms) (UTC)
927.80 2014-03-26 05:44:16 firewall __default_arp_policer__
908.68 2014-03-26 05:44:16 firewall __default_bpdu_filter__
421.00 2014-03-26 05:46:25 ifd(non ae) 504
49.76 2014-04-13 04:15:18 ifd(non ae) 503
49.62 2014-04-13 04:30:18 ifd(non ae) 504
48.52 2014-04-05 10:06:55 ifd(non ae) 504
47.61 2014-04-11 04:06:27 ifd(non ae) 505
47.38 2014-04-13 03:30:18 ifd(non ae) 501
47.22 2014-03-27 20:08:07 ifd(non ae) 502
46.26 2014-03-31 13:08:58 ifd(non ae) 506
46.00 2014-04-13 04:00:18 ifd(non ae) 503
45.95 2014-04-05 17:15:17 ifd(non ae) 503
45.75 2014-04-15 13:06:10 ifd(non ae) 507
45.60 2014-04-01 03:07:28 ifd(non ae) 517
45.56 2014-04-08 13:09:15 ifd(non ae) 502
45.23 2014-04-13 03:15:18 ifd(non ae) 501
45.15 2014-04-05 16:45:17 ifd(non ae) 501
44.74 2014-04-08 22:08:47 ifd(non ae) 505
44.10 2014-04-05 16:30:17 ifd(non ae) 501
44.00 2014-04-08 09:09:23 ifd(non ae) 524

show snmp v3
Syntax show snmp v3

<access <brief | detail> | community | general | groups | notify <filter> | target <address |
parameters> | users>

Description Display the Simple Network Management Protocol version 3 (SNMPv3) operating
configuration.
Options none—Display all of the SNMPv3 operating configuration.
access—(Optional) Display SNMPv3 access information.
brief | detail—(Optional) Display brief or detailed information about SNMPv3 access

information.
community—(Optional) Display SNMPv3 community information.
general—(Optional) Display SNMPv3 general information.
groups—(Optional) Display SNMPv3 security-to-group information.
notify <filter>—(Optional) Display SNMPv3 notify and, optionally, notify filter information.
target <address | parameters>—(Optional) Display SNMPv3 target and, optionally, either

target address or target parameter information.
users—(Optional) Display SNMPv3 user information.
Additional Information To edit the default display of the show snmp v3 command, specify options in the show
statement at the [edit snmp v3] hierarchy level.

Level
List of Sample Output show snmp v3 on page 882
Output Fields Table 152 on page 881 describes the output fields for the show snmp v3 command. Output

Table 152: show snmp v3 Output Fields

Access control Information about access control:
• Group—Group name for which the configured access privileges apply. The group, together with the
context prefix and the security model and security level, forms the index for this table.
• Context prefix—SNMPv3 context for which the configured access privileges apply.
• Security model/level—Security model and security level for which the configuration access privileges
apply.
• Read view—Identifies the MIB view applied to SNMPv3 read operations.
• Write view—Identifies the MIB view applied to SNMPv3 write operations.
• Notify view—Identifies the MIB view applied to outbound SNMP notifications.
Engine Information about local engine configuration:
• Local engine ID—Identifier that uniquely and unambiguously identifies the local SNMPv3 engine.
• Engine boots—Number of times the local SNMPv3 engine has rebooted or reinitialized since the
engine ID was last changed.
• Engine time—Number of seconds since the local SNMPv3 engine was last rebooted or reinitialized.
• Max msg size—Maximum message size the sender can accommodate.
Engine ID Information about engine ID:
• Local engine ID—Identifier that uniquely and unambiguously identifies the local SNMPv3 engine.
• Engine boots—Number of times the local SNMPv3 engine has rebooted or reinitialized since the
engine ID was last changed.
• Engine time—Number of seconds since the local SNMPv3 engine was last rebooted or reinitialized.
• Max msg size—Maximum message size the sender can accommodate.
• Engine ID—SNMPv3 engine ID associated with each user.
• User—SNMPv3 user.
• Auth/Priv—Authentication and encryption algorithm available for use by each user.
• Storage—Indicates whether a user is saved to the configuration file (nonvolatile) or not (volatile).
Applies only to users with active status.
• Status—Status of the conceptual row. Only rows with an active status are used by the SNMPv3
engine.
Group name Name of the group to which this entry belongs.
Security model Identifies the security model context for the security name.
Security name Used with the security model; identifies a specific security name instance. Each security model/security
name combination can be assigned to a specific group.
Storage type Indicates whether a user is saved to the configuration file (nonvolatile) or not (volatile). Applies only
to users with active status.
Status Status of the conceptual row. Only rows with active status are used by the SNMPv3 engine.

Sample Output
show snmp v3
user@host> show snmp v3
Local engine ID: 80 00 0a 4c e04 31 32 33 34
Engine boots: 38
Engine time: 64583 seconds
Max msg size: 2048 bytes
Engine ID: local

user1 md5/des nonvolatile active
user2 sha/none nonvolatile active
user3 none/none nonvolatile active
Engine ID: 81 00 0a 4c 04 64 64 64 64
UNEW md5/none nonvolatile active
Group name Security Security Storage Status
model name type
g1 usm user1 nonvolatile active
Access control:
Group Context Security Read Write Notify
prefix model/level view view view
g1 usm/privacy v1 v1
g2 usm/authent v1 v1
g3 usm/none v1 v1

show system alarms
Syntax show system alarms
Release Information Command introduced in Junos OS Release 11.1 for SRX Series devices.
Description Display active system alarms.
Additional Information System alarms are preset. They include a configuration alarm that appears when no
rescue configuration alarm is set and a license alarm that appears when a software
feature is configured but no valid license is configured for the feature.
Required Privilege admin

Level
List of Sample Output show system alarms on page 883
Sample Output
show system alarms
user@host> show system alarms
5 alarms currently active
Alarm time Class Description
2012-05-29 16:47:18 UTC Major /var partition usage crossed critical threshold
2012-05-29 16:47:18 UTC Minor /var partition usage crossed high threshold
2012-05-29 16:47:18 UTC Major /root partition usage crossed critical threshold
2012-05-29 16:47:18 UTC Minor /root partition usage crossed high threshold
2012-05-29 16:47:18 UTC Minor Rescue configuration is not set

show system resource-monitor fpc
Supported Platforms EX9200, EX9204, EX9208, EX9214, MX104, MX2010, MX2020, MX240, MX480, MX80,
MX960
Syntax show system resource-monitor fpc slot-number
Release Information Command introduced in Junos OS Release 15.1 for MX80, MX104, MX240, MX480, MX960,
Command introduced in Junos OS Release 16.1 for EX9200 switches.
Description Display the utilization of memory resources on the Packet Forwarding Engines of an FPC.
The filter memory denotes the filter counter memory used for firewall filter counters. The
asterisk (*) displayed next to each of the memory regions denotes the ones for which
the configured threshold is being currently exceeded.
Options fpc slot-number—Display the Junos OS utilization information of memory resources for
the specified slot number in which the FPC is installed.
• MX80 router—Replace fpc-slot with a value from 1. This command is not supported
on FPC slot 0.
• MX104 router—Replace fpc-slot with a value from 0 through 2.
• MX-960 router—Replace fpc-slot with a value from 0 through 11.
• MX2010 router—Replace fpc-slot-number with a value from 0 through 9.
• MX2020 router—Replace fpc-slot-number with a value from 0 through 19.
• EX9204 switches—Replace fpc-slot-number with a value from 0 through 2.
Additional Information The filter memory denotes the filter counter memory used for firewall filter counters.
From the Ukern perspective, MPC5E contains only one Packet Forwarding Engine instance.
The show chassis fabric plane command output displays the state of fabric plane
connections to the Packet Forwarding Engine. Because two Packet Forwarding Engines
exist, you notice PFE-0 and PFE-1 in the output.

Level
List of Sample Output show system resource-monitor fpc on page 885
Output Fields Table 153 on page 885 lists the output fields for the show system resource-monitor fpc

Table 153: show system resource-monitor fpc Output Fields

Free Heap Memory Watermark Configured watermark value for the percentage of free memory space
used for ukernel or heap memory to be monitored
Free FW Memory Watermark Configured watermark value for the percentage of free memory space
used for firewall or filter memory to be monitored
Free NH Memory Watermark Configured watermark value for the percentage of free memory space
used for next-hop memory to be monitored
* - watermark reached An asterix (*) displayed beside any of the memory regions denotes the
memory types for which the configured threshold is being currently
exceeded.
Slot # Slot number in which the line card is installed
PFE # Number or identifier of the Packet Forwarding Engine in the specified

line card slot
Heap % free Percentage of free space associated with heap or ukernel memory
Encap mem % free Percentage of free space associated with encapsulation memory
NH mem % free Percentage of free space associated with next-hop memory
Filter / FW mem % free Percentage of free space associated with firewall or filter memory
Sample Output
show system resource-monitor fpc
user@host> show system resource-monitor fpc

Heap ENCAP mem NH mem FW

mem
Slot # % Free PFE # % Free % Free % Free
0 94 0 NA 83
99


Junos OS Network Management Admin Guide

Uploaded by

Document Information

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

Junos OS Network Management Admin Guide

Uploaded by

Copyright:

Available Formats

Junos® OS

Network Management Administration Guide

Copyright © 2017, Juniper Networks, Inc.

YEAR 2000 NOTICE

END USER LICENSE AGREEMENT

ii Copyright © 2017, Juniper Networks, Inc.

Part 2 Network Monitoring Using SNMP

Copyright © 2017, Juniper Networks, Inc. iii

Chapter 5 Loading MIB Files to a Network Management System . . . . . . . . . . . . . . . . . . 79

iv Copyright © 2017, Juniper Networks, Inc.

Creating SNMPv3 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Copyright © 2017, Juniper Networks, Inc. v

vi Copyright © 2017, Juniper Networks, Inc.

Generating Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Part 3 Remote Monitoring (RMON) with SNMP

Copyright © 2017, Juniper Networks, Inc. vii

Configuring the Falling Threshold or Rising Threshold . . . . . . . . . . . . . . . . . 246

viii Copyright © 2017, Juniper Networks, Inc.

Defining and Measuring Network Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Part 4 Health Monitoring with SNMP

Part 5 Gathering Statistics for Accounting Purposes Using Accounting

Copyright © 2017, Juniper Networks, Inc. ix

Configuring the Transfer Interval of the File . . . . . . . . . . . . . . . . . . . . . . . . . 308

Part 6 Configuring Monitoring Options

x Copyright © 2017, Juniper Networks, Inc.

Alarm Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Part 7 Monitoring Common Security Features

Copyright © 2017, Juniper Networks, Inc. xi

Monitoring MGCP ALG Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

xii Copyright © 2017, Juniper Networks, Inc.

Monitoring BGP Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Copyright © 2017, Juniper Networks, Inc. xiii

Part 8 Resource Monitoring of Memory Regions and Types Using CLI

xiv Copyright © 2017, Juniper Networks, Inc.

Source Address for Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Copyright © 2017, Juniper Networks, Inc. xv

ISSU Support-Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600

Part 10 Configuration Statements and Operational Commands

xvi Copyright © 2017, Juniper Networks, Inc.

Chapter 36 Configuration Statements: Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 647

Copyright © 2017, Juniper Networks, Inc. xvii

xviii Copyright © 2017, Juniper Networks, Inc.

Chapter 43 Configuration Statements: SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

Copyright © 2017, Juniper Networks, Inc. xix

xx Copyright © 2017, Juniper Networks, Inc.

Part 3 Remote Monitoring (RMON) with SNMP

Part 6 Configuring Monitoring Options

Copyright © 2017, Juniper Networks, Inc. xxi

xxii Copyright © 2017, Juniper Networks, Inc.

Part 2 Network Monitoring Using SNMP

Copyright © 2017, Juniper Networks, Inc. xxiii

Chapter 10 Tracing SNMP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Part 3 Remote Monitoring (RMON) with SNMP

Part 4 Health Monitoring with SNMP

Part 5 Gathering Statistics for Accounting Purposes Using Accounting

Part 6 Configuring Monitoring Options

xxiv Copyright © 2017, Juniper Networks, Inc.

Part 7 Monitoring Common Security Features

Copyright © 2017, Juniper Networks, Inc. xxv

Table 87: Summary of Key BGP Routing Output Fields . . . . . . . . . . . . . . . . . . . . 452

Part 8 Resource Monitoring of Memory Regions and Types Using CLI

xxvi Copyright © 2017, Juniper Networks, Inc.

Table 120: J-Web Ping MPLS Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Part 10 Configuration Statements and Operational Commands