- play_arrow Overview
- play_arrow Network Monitoring by using SNMP
- SNMP Architecture and SNMP MIBs Overview
- Understand SNMP Implementation in Junos OS
- Configure SNMP in Junos OS
- Configure Options on Managed Devices for Better SNMP Response Time
- Enterprise Specific Utility MIB to Enhance SNMP Coverage
- Optimize the Network Management System Configuration for the Best Results
- Interfaces to Accept SNMP Requests
- Configure SNMP for Routing Instances
- Configure SNMP Remote Operations
- SNMP Traps
- SNMP Traps Supported by Junos OS
- Trace SNMP Activity
- Access Privileges for an SNMP Group
- Configure Local Engine ID on SNMPv3
- Configure SNMPv3
- Configure SNMPv3 Authentication Type and Encryption Type
- SNMPv3 Traps
- SNMPv3 Informs
- SNMP Communities
- MIB Views
- SNMP MIBs Supported by Junos OS and Junos OS Evolved
- Junos OS SNMP FAQs
- 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
Introduction to OAM Link Fault Management (LFM)
This section describes the Operation, Administration, and Management (OAM) of link fault management (LFM).
Use Feature Explorer to confirm platform and release support for specific features.
Review the Platform-Specific OAM LFM Behavior section for notes related to your platform.
IEEE 802.3ah OAM Link Fault Management Overview
Junos OS supports IEEE 802.3ah link-fault management. Junos OS enables routers and switches to support the IEEE 802.3ah OAM standard for Ethernet interfaces in access networks. The standard defines OAM LFM. You can configure IEEE 802.3ah OAM LFM on point-to-point Ethernet links that are connected either directly or through Ethernet repeaters. The IEEE 802.3ah standard meets the requirement for OAM capabilities as Ethernet moves from being solely an enterprise technology to being a WAN and access technology, as well as being backward-compatible with existing Ethernet technology.
Ethernet OAM provides tools that network management software and network managers can use to determine how a network of Ethernet links is functioning. Ethernet OAM should:
Rely only on the media access control (MAC) address or virtual LAN identifier for troubleshooting.
Work independently of the actual Ethernet transport and function over physical Ethernet ports or a virtual service such as a pseudowire.
Isolate faults over a flat (or single-operator) network architecture or nested or hierarchical (or multiprovider) networks.
The features of LFM are:
Discovery and Link Monitoring
The discovery process is triggered automatically when OAM is enabled on the interface. The discovery process permits Ethernet interfaces to discover and monitor the peer on the link if it also supports the IEEE 802.3ah standard. You can specify the discovery mode used for IEEE 802.3ah OAM support. In active mode, the interface discovers and monitors the peer on the link if the peer also supports IEEE 802.3ah OAM functionality. In passive mode, the peer initiates the discovery process. After the discovery process has been initiated, both sides participate in the process. The router performs link monitoring by sending periodic OAM protocol data units (PDUs) to advertise OAM mode, configuration, and capabilities.
You can specify the number of OAM PDUs that an interface can skip before the link between peers is considered down.
Remote Fault Detection
Remote fault detection uses flags and events. Flags are used to convey the following:
Link Fault means a loss of signal
Dying Gasp means an unrecoverable condition such as a power failure. In this condition, the local peer informs the remote peer about the failure state. When the remote peer receives a dying-gasp PDU, it takes an action corresponding to the action profile configured with the link-adjacency-loss event.
When LFM is configured on an interface, a dying-gasp PDU is generated for the interface on the following failure conditions:
Power failure
Packet Forwarding Engine panic or a crash
Critical Event means an unspecified vendor-specific critical event.
You can specify the interval at which OAM PDUs are sent for fault detection.
Remote Loopback Mode
Remote loopback mode ensures link quality between the router and a remote peer during installation or troubleshooting. In this mode, when the interface receives a frame that is not an OAM PDU or a PAUSE frame, it sends it back on the same interface on which it was received. The link appears to be in the active state. You can use the returned loopback acknowledgement to test delay, jitter, and throughput.
If a remote data terminal equipment (DTE) supports remote loopback mode, Junos OS can place the remote DTE into loopback mode. When you place a remote DTE into loopback mode, the interface receives the remote loopback request and puts the interface into remote loopback mode. When the interface is in remote loopback mode, all frames except OAM PDUs and PAUSE frames are looped back. No changes are made to the frames. OAM PDUs continue to be sent and processed.
The Ethernet link fault management daemon (lfmd) runs on the backup Routing Engine when graceful Routing Engine switchover (GRES) is configured.
Aggregated Ethernet member links use the physical MAC address as the source MAC address in 802.3ah OAM packets.
Configure Ethernet 802.3ah OAM
The IEEE 802.3ah standard for Operation, Administration, and Management (OAM) provides a specification for Ethernet in the first mile (EFM) connectivity. EFM defines how Ethernet can be transmitted over new media types using new Ethernet physical layer (PHY) interfaces. You can configure IEEE 802.3ah OAM on Ethernet point-to-point direct links or links across Ethernet repeaters. The IEEE 802.3ah OAM standard meets the requirement for OAM capabilities as Ethernet moves from being solely an enterprise technology to being a WAN and access technology, as well as being backward-compatible with existing Ethernet technology.
For Ethernet interfaces capable of running at 100 Mbps or faster, the IEEE 802.3ah OAM standard is supported on numerous Juniper Networks routers and switches. This topic describes configuration support for IEEE 802.3ah OAM features on routers.
To configure 802.3ah OAM support for Ethernet interfaces, include
the oam statement at the [edit protocols] hierarchy
level:
oam {
ethernet {
link-fault-management {
interfaces {
interface-name {
pdu-interval interval;
link-discovery (active | passive);
pdu-threshold count;
}
}
}
}
}
You can configure threshold values for fault events that trigger
the sending of link event TLVs when the values exceed the threshold.
To set threshold values for fault events on an interface, include
the event-thresholds statement at the [edit protocols
oam ethernet link-fault-management interface] hierarchy level.
You can also configure OAM threshold values within an action
profile and apply the action profile to multiple interfaces. To create
an action profile, include the action-profile statement
at the [edit protocols oam ethernet link-fault-management] hierarchy level.
You can configure Ethernet OAM either on an aggregate interface or on each of its member links. However, we recommend that you configure Ethernet OAM on the aggregate interface, and this will internally enable Ethernet OAM on the member links.
To view OAM statistics, use the show oam ethernet link-fault-management operational mode command. To clear OAM statistics, use the clear oam ethernet link-fault-management statistics operational
mode command. To clear link-fault management state information and
restart the link discovery process on Ethernet interfaces, use the clear oam ethernet link-fault-management state operational
mode command. For more information about these commands, see the CLI Explorer.
To enable IEEE 802.3ah OAM support, include the interface statement at the [edit protocols oam ethernet link-fault-management] hierarchy level:
[edit protocols oam ethernet link-fault-management interface interface-name]
When you enable IEEE 802.3ah OAM on a physical interface, the discovery process is automatically triggered.
See Also
Platform-Specific OAM LFM Behavior
Use Feature Explorer to confirm platform and release support for specific features.
Use the following table to review platform-specific behaviors for your platform.
| Platform | Difference |
|---|---|
ACX Series |
|
MX Series |
|
PTX Series |
|
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
