- 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
Ethernet Local Management Interface
Ethernet Local Management Interface Overview
Gigabit Ethernet (ge
), 10-Gigabit Ethernet (xe
), and Aggregated Ethernet (ae
) interfaces support
the Ethernet Local Management Interface (E-LMI).
On MX Series routers, E-LMI is supported on Gigabit Ethernet
(ge
), 10-Gigabit Ethernet (xe
), and Aggregated
Ethernet (ae
) interfaces configured on MX Series routers
with DPC only.
The E-LMI specification is available at the Metro Ethernet Forum. E-LMI procedures and protocols are used for enabling automatic configuration of the customer edge (CE) to support Metro Ethernet services. The E-LMI protocol also provides user-to-network interface (UNI) and Ethernet virtual connection (EVC) status information to the CE. The UNI and EVC information enables automatic configuration of CE operation based on the Metro Ethernet configuration.
The E-LMI protocol operates between the CE device and the provider edge (PE) device. It runs only on the PE-CE link and notifies the CE of connectivity status and configuration parameters of Ethernet services available on the CE port. The scope of the E-LMI protocol is shown in Figure 1.

The E-LMI implementation on ACX and MX Series routers includes only the PE side of the E-LMI protocol.
E-LMI interoperates with an OAM protocol, such as Connectivity Fault Management (CFM), that runs within the provider network to collect OAM status. CFM runs at the provider maintenance level (UNI-N to UNI-N with up MEPs at the UNI). E-LMI relies on the CFM for end-to-end status of EVCs across CFM domains (SVLAN domain or VPLS).
The E-LMI protocol relays the following information:
Notification to the CE of the addition/deletion of an EVC (active, not active, or partially active)
Notification to the CE of the availability state of a configured EVC
Communication of UNI and EVC attributes to the CE:
UNI attributes:
UNI identifier (a user-configured name for UNI)
CE-VLAN ID/EVC map type (all-to-one bundling, service multiplexing with bundling, or no bundling)
Bandwidth profile is not supported (including the following features):
CM (coupling mode)
CF (color flag)
CIR (committed Information rate)
CBR (committed burst size)
EIR (excess information rate)
EBS (excess burst size)
EVC attributes:
EVC reference ID
EVC status type (active, not active, or partially active)
EVC type (point-to-point or multipoint-to-multipoint)
EVC ID (a user-configured name for EVC)
Bandwidth profile (not supported)
CE-VLAN ID/EVC map
E-LMI on MX Series routers supports the following EVC types:
Q-in-Q SVLAN (point-to-point or multipoint-to-multipoint)—Requires an end-to-end CFM session between UNI-Ns to monitor the EVS status.
VPLS (BGP or LDP) (point-to-point or multipoint-to-multipoint)—Either VPLS pseudowire status or end-to-end CFM sessions between UNI-Ns can be used to monitor EVC status.
L2 circuit/L2VPN (point-to-point)—Either VPLS pseudowire status or end-to-end CFM sessions between UNI-Ns can be used to monitor EVC status.
Note:l2-circuit
andl2vpn
are not supported.
The E-LMI protocol on ACX Series routers supports Layer 2 circuit and Layer 2 VPN EVC types and enables link-loss forwarding for pseudowire (Layer 2 circuit and Layer 2 VPN) services as follows:
Interworking between the connectivity fault management (CFM) protocol and the E-LMI protocol for Layer 2 circuit and Layer 2 VPN.
End-to-end CFM session between UNIs to monitor EVC status.
In the case of pseudowire redundancy, CFM can be used to monitor active and backup pseudowire sessions. The EVC status is declared as down to CE devices only when both the active and backup pseudowire sessions go down.
Interworking between remote defect indication (RDI) and E-LMI for Layer 2 circuit and Layer 2 VPN.
If a maintenance association end point (MEP) receives an RDI bit set in a continuity check message (CCM) frame, and if RDI fault detection is enabled in the EVC configuration at
[edit protocols oam ethernet evcs evc-id evc-protocol cfm management-domain name management-association name faults rdi]
, then the pseudowire is declared as down to CE routers through E-LMI.
If an end-to-end CFM session does not exist between UNIs, the pseudowire (Layer 2 circuit or Layer 2 VPN) up and down state triggers an asynchronous EVC state change message to CE routers through E-LMI.
ACX Series routers do not support E-LMI for Layer 2 services (bridging).
Configure the Ethernet Local Management Interface
To configure E-LMI, perform the following steps:
- Configuring an OAM Protocol (CFM)
- Assigning the OAM Protocol to an EVC
- Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an EVC
Configuring an OAM Protocol (CFM)
For information on configuring the OAM protocol (CFM), see IEEE 802.1ag OAM Connectivity Fault Management Overview.
Assigning the OAM Protocol to an EVC
To configure an EVC, you must specify a name for the EVC using
the evcsevc-id
statement at the [edit protocols oam ethernet]
hierarchy level. You can set
the EVC protocol for monitoring EVC statistics to cfm
or vpls
using the evc-protocol
statement and its options
at the [edit protocols oam ethernet evcs]
hierarchy level.
You can set the number of remote UNIs in the EVC using the remote-uni-count number
statement at the [edit protocols oam ethernet evcs evcs-protocol]
hierarchy
level. The remote-uni-count
defaults to 1. Configuring
a value greater than 1 makes the EVC multipoint-to-multipoint. If
you enter a value greater than the actual number of endpoints, the
EVC status will display as partially active even if all endpoints
are up. If you enter a remote-uni-count
less than the actual
number of endpoints, the status will display as active, even if all
endpoints are not up.
You can configure an EVC by including the evcs
statement
at the [edit protocols oam ethernet]
hierarchy level:
[edit protocols oam ethernet] evcs evc-id { evc-protocol (cfm (management-domain name management-association name ) | vpls (routing-instance name)) { remote-uni-count <number>; # Optional, defaults to 1 multipoint-to-multipoint; # Optional, defaults to point-to-point if remote-uni-count is 1 } }
Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an EVC
To configure E-LMI, include the lmi
statement at
the [edit protocols oam ethernet]
hierarchy level:
[edit protocols oam ethernet] lmi { polling-verification-timer value; # Polling verification timer (T392), defaults to 15 seconds status-counter count; # Status counter (N393), defaults to 4 interface name { evc evc-id { default-evc; vlan-list [ vlan-ids ]; } evc-map-type (all-to-one-bundling | bundling | service-multiplexing); polling-verification-time value; # Optional, defaults to global value status-counter count; # Optional, defaults to global value uni-id value; # Optional, defaults to interface-name } }
You can set the status counter to count consecutive errors using
the status-counter count
statement
at the [edit protocols oam ethernet lmi]
hierarchy level.
The status counter is used to determine if E-LMI is operational or
not. The default value is 4.
You can set the polling-verification-timer value
statement at the [edit protocols oam ethernet lmi]
hierarchy level. The default value is 15 seconds.
You can enable an interface and set its options for use with
E-LMI using the interface name
statement
at the [edit protocols oam ethernet lmi]
hierarchy level.
Only ge
, xe
, and ae
interfaces are
supported. You can use the interface uni-id
option to specify
a name for the UNI. If uni-id
is not configured, it defaults
to the name variable of interface name
.
You can specify the CE-VLAN ID/EVC map type using the evc-map-type
type
interface option. The options are all-to-one-bundling
, bundling
, or service-multiplexing
. Service
multiplexing is with no bundling. The default type is all-to-one-bundling
.
To specify the EVC that an interface uses, use the evc evc-id
statement at the [edit protocols oam
ethernet lmi interface name]
hierarchy
level. You can specify an interface as the default EVC interface using
the default-evc
statement at the [edit protocols oam
ethernet lmi interface name evc evc-id]
hierarchy level. All VIDs that are not mapped to any other
EVCs are mapped to this EVC. Only one EVC can be configured as the
default.
You can map a list of VLANs to an EVC using the vlan-list vlan-id-list
statement at the [edit protocols
oam ethernet lmi interface name evc evc-id]
hierarchy level.
Example E-LMI Configuration
Example Topology
Figure 2 illustrates
the E-LMI configuration for a point-to-point EVC (SVLAN) monitored
by CFM. In this example, VLANs 1 through 2048 are mapped to evc1
(SVLAN 100) and 2049 through 4096 are mapped to evc2
(SVLAN
200). Two CFM sessions are created to monitor these EVCs.

Configuring PE1
[edit] interfaces { ge-1/1/1 { unit 0 { family bridge { interface-mode trunk; vlan-id-list 1-2048; } } unit 1 { family bridge { interface-mode trunk; vlan-id-list 2049-4096; } } } ge-1/1/2 { unit 0 { vlan-id 100; family bridge { interface-mode trunk; inner-vlan-id-list 1-2048; } } unit 1 { vlan-id 200; family bridge { interface-mode trunk; inner-vlan-id-list 2049-4096; } } } } protocols { oam { ethernet { connectivity-fault-management { maintenance-domain md { level 0; maintenance-association 1 { name-format vlan; mep 1 { direction up; interface ge-1/1/1.0 vlan 1; } } maintenance-association 2049 { name-format vlan; mep 1 { direction up; interface ge-1/1/1.1 vlan 2049; } } } } evcs { evc1 { evc-protocol cfm management-domain md management-association 1; remote-uni-count 1; } evc2 { evc-protocol cfm management-domain md management-association 2049; remote-uni-count 1; } } lmi { interface ge-1/1/1 { evc evc1 { vlan-list 1-2048; } evc evc2 { vlan-list 2049-4096; } evc-map-type bundling; uni-id uni-ce1; } } } } }
Configuring PE2
[edit] interfaces { ge-2/2/1 { unit 0 { family bridge { interface-mode trunk; vlan-id-list 1-2048; } } unit 1 { family bridge { interface-mode trunk; vlan-id-list 2049-4096; } } } ge-2/2/2 { unit 0 { vlan-id 100; family bridge { interface-mode trunk; inner-vlan-id-list 1-2048; } } unit 1 { vlan-id 200; family bridge { interface-mode trunk; inner-vlan-id-list 2049-4095; } } } } protocols { oam { ethernet { connectivity-fault-management { maintenance-domain md { level 0; maintenance-association 1 { name-format vlan; mep 1 { direction up; interface ge-2/2/1.0 vlan 1; } } maintenance-association 2049 { name-format vlan; mep 1 { direction up; interface ge-2/2/1.1 vlan 2049; } } } } evcs { evc1 { evc-protocol cfm management-domain md management-association 1; remote-uni-count 1; } evc2 { evc-protocol cfm management-domain md management-association 2049; uni-count 2; } } lmi { interface ge-2/2/1 { evc evc1 { vlan-list 1-2048; } evc evc2 { vlan-list 2049-4095; } evc-map-type bundling; uni-id uni-ce2; } } } } }
Configuring Two UNIs Sharing the Same EVC
[edit protocols] oam { ethernet { connectivity-fault-management { ...} evcs { evc1 { evc-protocol cfm management-domain md management-association 1; remote-uni-count 1; } } lmi { interface ge-2/2/1 { evc evc1 { vlan-list 0-4095; } evc-map-type all-to-one-bundling; uni-id uni-ce1; } interface ge-2/3/1 { evc evc1 { vlan-list 0-4095; } evc-map-type all-to-one-bundling; uni-id uni-ce2; } } } }