- play_arrow Overview
- play_arrow Operation, Administration, and Management Features
- play_arrow Ethernet OAM and Connectivity Fault Management for Routers
- Introduction to OAM Connectivity Fault Management (CFM)
- Configure Connectivity Fault Management (CFM)
- CFM Action Profile
- Ethernet Local Management Interface
- CFM Support for CCC Encapsulated Packets
- Configure Unified ISSU for 802.1ag CFM
- CFM Monitoring between CE and PE Devices
- Configure Continuity Check Messages
- Example: Configure Ethernet CFM on Physical Interfaces
- Example: Configure Ethernet CFM on Bridge Connections
- Example: Configure Ethernet CFM over VPLS
- play_arrow Link Fault Management for Routers
- play_arrow Ethernet OAM Link Fault Management for Switches
- play_arrow Ethernet OAM Connectivity Fault Management for Switches
- play_arrow Ethernet Frame Delay
- Ethernet Frame Delay Measurements on Switches
- Configure MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
- Configure One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- Configure an Iterator Profile on a Switch (CLI Procedure)
- Trigger an Ethernet Frame Delay Measurement Session on a Switch
- Configure Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- play_arrow Ethernet Service OAM (ITU-TY.1731) for Routers
- ITU-T Y.1731 Ethernet Service OAM Overview
- Configure Ethernet Frame Delay Measurement Sessions
- Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
- Configure Ethernet Frame Loss Measurement
- Configure an Iterator Profile
- Configure Ethernet Synthetic Loss Measurements
- Ethernet Alarm Indication
- Inline Transmission Mode
-
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow Port Mirroring
- play_arrow Port Mirroring and Analyzers
- Port Mirroring and Analyzers
- Configuring Port Mirroring and Analyzers
- Configuring Port Mirroring Instances
- Configuring Port Mirroring on Physical Interfaces
- Configuring Port Mirroring on Logical Interfaces
- Configuring Port Mirroring for Multiple Destinations
- Configuring Port Mirroring for Remote Destinations
- Configuring Port Mirroring Local and Remote Analysis
- 1:N Port Mirroring to Multiple Destinations on Switches
- Example: Configure Port Mirroring with Family any and a Firewall Filter
- Monitoring Port Mirroring
- Configure Packet Mirroring with Layer 2 Headers for Layer 3 Forwarded Traffic
- Troubleshooting Port Mirroring
-
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
Configure Local Engine ID on SNMPv3
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. For more information about this statement, see No link title.
If you are using SNMPv3 and if the engine ID is based on the MAC address and you upgrade from an earlier release to one of the releases (14.1X53-D50, 16.1R5, 17.1R2, 17.2R1, 15.1X53-D231, 14.1X53-D43, 15.1X53-D232), you must reconfigure SNMPv3 because the engine ID is changed by the upgrade. If you do not reconfigure SNMPv3, you will see authentication error for SNMPv3 polling because the engine ID is changed after the upgrade. You only need to reconfigure SNMPv3 on the first such upgrade. If you then upgrade from one of the mentioned releases to another of these releases, you do not have to upgrade SNMPv3 again.
To reconfigure SNMPv3, use the following procedure. Do not use the rollback
1 command.
Check what the SNMPv3 configuration is.
content_copy zoom_out_mapuser@host# show snmp v3
Delete the SNMPv3 configuration.
content_copy zoom_out_mapuser@host# delete snmp v3
Reconfigure SNMPv3 configuration (see ouput from Step 1).
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.
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 primary IP address of the device if the device has multiple routing engines and has the primary IP address configured. Alternatively, you can use the MAC address of the management port if the device has only one Routing Engine.
