ON THIS PAGE
Configuring Maintenance Association Intermediate Points in ACX Series
Configuring Continuity Check Protocol Parameters for Fault Detection
Configuring a MEP to Generate and Respond to CFM Protocol Messages
Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
Configuring Service Protection for VPWS over MPLS Using the MEP Interface
Configuring a CFM Action Profile to Specify CFM Actions for CFM Events
CFM Action Profile to Bring Down a Group of Logical Interfaces Overview
Configuring a CFM Action Profile to Bring Down a Group of Logical Interfaces
Configuring M120 and MX Series Routers for CCC Encapsulated Packets
Junos OS Support for Performance Monitoring Compliant with Technical Specification MEF 36
Damping CFM performance Monitoring Traps and Notifications to Prevent Congestion of The NMS
Configuring Connectivity Fault Management (CFM)
Use this topic to configure connectivity fault management features such as maintenance domains, maintenance associations, maintenance intermediate points (MIPs), and continuity check parameters. You can also use this topic to configure an action profile to specify the CFM action that must be performed when a specific CFM event occurs.
Starting in Junos OS Evolved 22.4R2 Release, the connectivity fault management process
(cfmd) runs only when the ethernet connectivity-fault-management
protocol is configured.
Creating a Maintenance Domain
To enable connectivity fault management (CFM) on an Ethernet interface, you must first configure a maintenance domain and specify the name of the maintenance domain. You can also specify the format of the name. For instance, if you specify the name format to be domain name service (DNS) format, you can specify the name of the maintenance domain as www.juniper.net. The default name format is ASCII character string.
For logical interfaces, the maintenance domain name must
be unique across logical systems. If you configure the same maintenance
domain name across logical systems, then you receive the following
error message: error: configuration check-out failed
.
During the creation of the maintenance domain, you can also specify the maintenance domain level. The maintenance domain level indicates the nesting relationship between various maintenance domains. The maintenance domain level is embedded in each of the CFM frames.
To create a maintenance domain:
See Also
Configuring Maintenance Intermediate Points (MIPs)
MX Series routers support maintenance intermediate points
(MIPs) for the Ethernet OAM 802.1ag CFM protocol at a bridge-domain
level. This enables you to define a maintenance domain for each default
level. The MIPs names are created as default-level-number
at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain]
hierarchy level. Use the bridge-domain
, instance
, virtual-switch
, and mip-half-function
MIP options to specify the MIP configuration.
Use the show oam ethernet connectivity-fault-management
mip (bridge-domain | instance-name | interface-name)
command
to display the MIP configurations.
To configure the maintenance intermediate point (MIP):
See Also
Configuring Maintenance Association Intermediate Points in ACX Series
Maintenance Intermediate Point (MIP) provides monitoring capability of intermediate points for services such as Layer 2 bridging, Layer 2 circuit, and Layer 2 VPN. ACX5048 and ACX5096 routers support MIPs for the Ethernet OAM 802.1ag CFM protocol. Use the bridge-domain, interface, and mip-half-function MIP options to specify the MIP configuration.
ACX5048 and ACX5096 routers do not support MIP configuration on VPLS services.
ACX5448 router do not support MIP.
Whenever a MIP is configured and a bridge domain is mapped
to multiple maintenance domains or maintenance associations, it is
essential that the mip-half-function
value for all maintenance
domains and maintenance associations be the same.
To display MIP configurations, use the show oam ethernet
connectivity-fault-management mip (bridge-domain | instance-name |
interface-name)
command.
The following MIP configurations are supported in ACX5048 and ACX5096 routers:
MIP with with bridge domain
MIP with circuit cross-connect (CCC)
MIP with bridge domain when maintenance association end point is configured
MIP with CCC when maintenance association end point is configured
The following sections describe MIP configuration:
- Configuring the Maintenance Domain Bridge Domain
- Configuring the Maintenance Domain MIP Half Function
- Configuring the Maintenance Association Intermediate Points with Bridge Domain
- Configuring the Maintenance Association Intermediate Points with Circuit Cross-Connect
- Configuring the Maintenance Association Intermediate Points with Bridge Domain when Maintenance Association End Point is Configured
- Configuring the Maintenance Intermediate Points with Circuit Cross-Connect when Maintenance Association End Point is Configured
Configuring the Maintenance Domain Bridge Domain
To configure the bridge domain, include the vlans
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain maintenance-domain-name]
hierarchy level.
The Layer 2 CLI configurations and show commands for ACX5048 and ACX5096 routers differ compared to other ACX Series routers. For more information, see Layer 2 Next Generation Mode for ACX Series.
Configuring the Maintenance Domain MIP Half Function
MIP Half Function (MHF) divides MIP functionality into two unidirectional segments, improves visibility with minimal configuration, and improves network coverage by increasing the number of points that can be monitored. MHF extends monitoring capability by responding to loopback and linktrace messages to help isolate faults.
Whenever a MIP is configured and a bridge domain is mapped to
multiple maintenance domains or maintenance associations, it is essential
that the MIP half function value for all maintenance
domains and maintenance associations be the same. To configure the
MIP half function, include the mip-half-function
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain maintenance-domain-name]
hierarchy level.
Configuring the Maintenance Association Intermediate Points with Bridge Domain
In ACX5048 and ACX5096 routers, you can configure the MIP with bridge domain. The following is a sample to configure the MIP with bridge domain:
[edit protocols] oam { ethernet { connectivity-fault-management { maintenance-domain default-6 { vlan bd1; mip-half-function default; } } } }
Configuring the Maintenance Association Intermediate Points with Circuit Cross-Connect
In ACX5048 and ACX5096 routers, you can configure the MIP with circuit cross-connect (CCC). The following is a sample to configure the MIP with CCC:
[edit protocols] oam { ethernet { connectivity-fault-management { maintenance-domain default-6 { interface xe-0/0/42.0; mip-half-function default; } } } }
Configuring the Maintenance Association Intermediate Points with Bridge Domain when Maintenance Association End Point is Configured
In ACX5048 and ACX5096 routers, you can configure the MIP with bridge domain when a maintenance association end point (MEP) is configured. The following is a sample to configure the MIP with bridge domain when MEP is configured:
[edit protocols] oam { ethernet { connectivity-fault-management { maintenance-domain md2 { level 5; mip-half-function default; maintenance-association ma2 { continuity-check { interval 1s; } mep 222 { interface xe-0/0/42.0; direction up; } } } } } }
Configuring the Maintenance Intermediate Points with Circuit Cross-Connect when Maintenance Association End Point is Configured
In ACX5048 and ACX5096 routers, you can configure the MIP with circuit cross-connect (CCC) when a maintenance association end point (MEP) is configured. The following is a sample to configure the MIP with CCC when MEP is configured:
[edit protocols] oam { ethernet { connectivity-fault-management { maintenance-domain md2 { level 5; mip-half-function default; maintenance-association ma2 { continuity-check { interval 1s; } mep 222 { interface xe-0/0/42.0; direction up; } } } } } }
See Also
Creating a Maintenance Association
To create a maintenance association, include the maintenance-association ma-name
statement at the [edit protocols oam
ethernet connectivity-fault-management maintenance-domain domain-name]
hierarchy level.
Maintenance association names can be in one of the following formats:
As a plain ASCII character string
As the VLAN identifier of the VLAN you primarily associate with the maintenance association
As a two-octet identifier in the range from 0 through 65,535
As a name in the format specified by RFC 2685
The default short name format is an ASCII character string.
To configure the maintenance association short name format,
include the short-name-format (character-string | vlan | 2octet
| rfc-2685-vpn-id)
statement at the [edit protocols oam
ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]
hierarchy level.
See Also
Continuity Check Protocol Parameters Overview
The continuity check protocol is used for fault detection by maintenance end points (MEPs) within a maintenance association. The MEP periodically sends continuity check multicast messages. The continuity check protocol packets use the ethertype value 0x8902 and the multicast destination MAC address 01:80:c2:00:00:32.
The following list describes the continuity check protocol parameters you can configure:
interval
—Frequency of the continuity check messages (CCM) i.e time between the transmission of the CCM messages. You can specify 10 minutes (10m
), 1 minute (1m
), 10 seconds (10s
), 1 second (1s
), 100 milliseconds (100ms
), or 10 milliseconds (10ms
). The default value is 1 minute. For instance, if you specify the interval as 1 minute, the MEP sends the continuity check messages every minute to the receiving MEP.Note:For the continuity check message interval to be configured for 10 milliseconds, periodic packet management (PPM) runs on the Routing Engine and Packet Forwarding Engine by default. You can only disable PPM on the Packet Forwarding Engine. To disable PPM on the Packet Forwarding Engine, use the
no-delegate-processing
statement at the[edit routing-options ppm]
hierarchy level.Continuity check interval of 10 milliseconds is not supported for CFM sessions over a label-switched interface (LSI).
hold-interval
—Frequency at which the MEP database can be flushed, if no updates occur. Receiving MEPs use the continuity check messages to build a MEP database of all MEPs in the maintenance association. The frequency is the number of minutes to wait before flushing the MEP database if no updates occur. The default value is 10 minutes.Note:Hold timer based flushing is applicable only for autodiscovered remote MEPs and not for statically configured remote MEPs.
The hold interval logic runs a polling timer per CFM session level (not per remote MEP level) where the polling timer duration is equal to the configured hold time. When the polling timer expires, it deletes all the autodiscovered remote MEP entries which have been in the failed state for a time period equal to or greater than the configured hold time. If the remote MEP completes the hold time duration in the failed state, then flushing will not occur until the next polling timer expires. Hence remote MEP flushing may not happen exactly at the configured hold time.
loss-threshold
—Number of continuity check messages that can be lost before the router marks the MEP as down. The value can be from 3 to 256 protocol data units (PDUs). The default value is 3 PDUs.
See Also
Configuring Continuity Check Protocol Parameters for Fault Detection
The continuity check protocol is used for fault detection by a maintenance association end point (MEP) within a maintenance association. A MEP periodically generates and responds to continuity check multicast messages. The continuity check protocol packets use the ethertype value 0x8902 and the multicast destination MAC address 01:80:c2:00:00:32. The receiving MEPs use the continuity check messages (CCMs) to build a MEP database of all MEPs in the maintenance association.
To configure continuity check protocol parameters:
See Also
Configuring a MEP to Generate and Respond to CFM Protocol Messages
A maintenance association end point (MEP) refers to the boundary of a domain. A MEP generates and responds to connectivity fault management (CFM) protocol messages. You can configure multiple up MEPs for a single combination of maintenance association ID and maintenance domain ID for interfaces belonging to a particular VPLS service or a bridge domain. You can configure multiple down MEPs for a single instance of maintenance domain identifier and maintenance association name to monitor services provided by Virtual Private LAN service (VPLS), bridge domain, circuit cross-connect (CCC), or IPv4 domains.
For layer 2 VPNs routing instances (local switching) and EVPN routing instances, you can also configure multiple up MEPs for a single combination of maintenance association ID and maintenance domain ID on logical interfaces. The logical interface can be configured on different devices or on the same device. To support multiple up MEPs on two IFLs, enhanced IP network services must be configured for the chassis.
You can enable automatic discovery of a MEP. With automatic discovery a MEP is enabled to accept continuity check messages (CCMs) from all remote MEPs of the same maintenance association. If automatic discovery is not enabled, the remote MEPs must be configured. If the remote MEP is not configured, the CCMs from the remote MEP are treated as errors.
Continuity measurement is provided by an existing continuity check protocol. The continuity for every remote MEP is measured as the percentage of time that remote MEP was operationally up over the total administratively enabled time. Here, the operational uptime is the total time during which the CCM adjacency is active for a particular remote MEP and the administrative enabled time is the total time during which the local MEP is active. You can also restart the continuity measurement by clearing the currently measured operational uptime and the administrative enabled time.
- Configuring a Maintenance Association End Point (MEP)
- Configuring a remote Maintenance Association End Point (MEP)
Configuring a Maintenance Association End Point (MEP)
To configure a maintenance association end point:
See Also
Configuring a remote Maintenance Association End Point (MEP)
To configure a remote maintenance association end point:
See Also
Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
Ethernet frame delay measurement is a useful tool for providing performance statistics or supporting or challenging Service Level Agreements (SLAs). By default, Ethernet frame delay measurement uses software for timestamping and delay calculations. You can optionally use hardware timing to assist in this process and increase the accuracy of the delay measurement results. This assistance is available on the reception path.
Before you can perform Ethernet frame delay measurements on MX Series routers, you must have done the following:
Configured Ethernet OAM and CFM correctly
Prepared the measurement between two compatibly configured MX Series routers
Enabled the distributed periodic packet management daemon (ppmd)
Avoided trying to perform Ethernet frame delay measurement on aggregated Ethernet or pseudowire interfaces, which are not supported
Made sure the hardware-assisted timestamping is supported if that feature is configured
At the end of this configuration, you create two MX Series routers that can perform and display Ethernet frame delay measurements on Ethernet interfaces using optional hardware timestamping. By default, Ethernet frame delay measurement uses software for timestamping and delay calculations. You can optionally use hardware timing to assist in this process and increase the accuracy of the delay measurement results. This assistance is available on the reception path.
To configure hardware-assisted timestamping:
See Also
Configuring Service Protection for VPWS over MPLS Using the MEP Interface
You can enable service protection for a virtual private wire service (VPWS) over MPLS by specifying a working path or protect path on the MEP. Service protection provides end-to-end connection protection of the working path in the event of a failure.
To configure service protection, you must create two separate
transport paths—a working path and a protect path. You can specify
the working path and protect path by creating two maintenance associations.
To associate the maintenance association with a path, you must configure
the interface
statement for the MEP within the maintenance
association and specify the path as working or protect.
If the path is not specified, the session monitors the active path.
Table 1 describes the available service protection options.
Option |
Description |
---|---|
|
Specifies the working path. |
|
Specifies the protect path. |
In this configuration, we enable service protection for
the VPWS service. The CCM session is configured for the working path
and references the CCM session configured for the protect path using
the protect-maintenance-association
statement. The name
of the protect transport path for the maintenance association is configured
and associated with the maintenance association for the working path.
To configure service protection for VPWS over MPLS:
See Also
Configuring Linktrace Protocol in CFM
The linktrace protocol is used for path discovery between
a pair of maintenance points. Linktrace messages are triggered by
an administrator using the traceroute
command to verify
the path between a pair of MEPs under the same maintenance association.
Linktrace messages can also be used to verify the path between an
MEP and an MIP under the same maintenance domain. The linktrace protocol
enables you to configure the time to wait for a response. If no response
is received for a linktrace request message, the request and response
entries are deleted after the interval expires. You can also configure
the number of linktrace reply entries to be stored for the corresponding
linktrace request.
The operation of IEEE 802.1ag linktrace request and response
messages is similar to the operation of Layer 3 traceroute
commands. For more information about the traceroute
command,
see the Junos OS Administration Library for Routing Devices.
To configure the linktrace protocol:
See Also
Configuring Rate Limiting of Ethernet OAM Messages
The M320 with Enhanced III FPC, M120, M7i, M10 with CFEB, and MX Series routers support rate limiting of Ethernet OAM messages. Depending on the connectivity fault management (CFM) configuration, CFM packets are discarded, sent to the CPU for processing, or flooded to other bridge interfaces. This feature allows the router to intercept incoming CFM packets for prevention of DoS attacks.
You can apply rate limiting of Ethernet OAM messages at either of two CFM policing levels, as follows:
Global-level CFM policing—uses a policer at the global level to police the CFM traffic belonging to all the sessions.
Session-level CFM policing—uses a policer created to police the CFM traffic belonging to one session.
To configure global-level CFM policing, include the policer
statement and its options at the [edit protocols oam ethernet
connectivity-fault-management]
hierarchy level.
To configure session-level CFM policing, include the policer
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain md-name level number maintenance-association ma-name]
hierarchy
level.
The following example shows a CFM policer used for rate-limiting CFM:
[edit] firewall { policer cfm-policer { if-exceeding { bandwidth-limit 8k; burst-size-limit 2k; } then discard; } }
Case 1: Global-Level CFM Policing
This example shows a global level policer, at the CFM
level, for rate-limiting CFM. The continuity-check cfm-policer
statement at the global [edit protocols
oam ethernet connectivity-fault-management policer]
hierarchy
level specifies the policer to use for policing all continuity check
packets of the CFM traffic belonging to all sessions. The other cfm-policer1
statement at the [edit protocols
oam ethernet connectivity-fault-management policer]
hierarchy
level specifies the policer to use for policing all non-continuity
check packets of the CFM traffic belonging to all sessions. The all cfm-policer2
statement specifies to
police all CFM packets with the specified policer cfm-policer2. If the all policer-name
option
is used, then the user cannot specify the previous continuity-check
and other
options.
[edit protocols oam ethernet] connectivity-fault-management { policer { continuity-check cfm-policer; other cfm-policer1 ; all cfm-policer2; } }
Case 2: Session-Level CFM Policing
This example shows a session-level CFM policer used for
rate-limiting CFM. The policer
statement at the session [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name]
hierarchy level specifies the policer to use for policing
only continuity check packets of the CFM traffic belonging to the
specified session. The other cfm-policer1
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain md-name maintenance-association ma-name]
hierarchy level specifies the policer to
use for policing all non-continuity check packets of the CFM traffic
belonging to this session only. The all cfm-policer2
statement specifies to police all CFM packets with the specified
policer cfm-policer2. If the all policer-name
option is used, then the user cannot
specify the previous continuity-check
and other
options.
[edit protocols oam ethernet] connectivity-fault-management { maintenance-domain md { level number; maintenance-association ma { continuity-check { interval 1s; } policer { continuity-check cfm-policer; other cfm-policer1; all cfm-policer2; } } mep 1 { interface ge-3/3/0.0; direction up; auto-discovery; } } }
In the case of global CFM policing, the same policer is shared across multiple CFM sessions. In per-session CFM policing, a separate policer must be created to rate-limit packets specific to that session.
Service-level policer configuration for any two CFM sessions on the same interface at different levels must satisfy the following constraints if the direction of the sessions is the same:
If one session is configured with
policer all
, then the other session cannot have apolicer all
orpolicer other
configuration.If one session is configured with
policer other
, then the other session cannot have apolicer all
orpolicer other
configuration.
A commit error will occur if such a configuration is committed.
Policers with PBB and MIPs are not supported.
See Also
Configuring Ethernet Local Management Interface
- Ethernet Local Management Interface Overview
- Configuring the Ethernet Local Management Interface
- Example E-LMI Configuration
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).
Configuring 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; } } } }
Configuring a CFM Action Profile to Specify CFM Actions for CFM Events
You can create a connectivity fault management (CFM) action profile to define event flags and thresholds to be monitored. You can also specify the action to be taken when any of the configured events occur. When the CFM events occur, the router performs the corresponding action based on your specification. You can configure one or more events in the action profile. Alternatively, you can configure an action profile and specify default actions when connectivity to a remote maintenance association endpoint (MEP) fails.
You cannot configure multiple actions at this time. Only
one action can be configured. This limitation affects both the action
and clear-action
statements.
To configure the CFM action profile:
See Also
CFM Action Profile to Bring Down a Group of Logical Interfaces Overview
With growing networks, there is a requirement of monitoring a large number of services using CFM. To monitor each service, one session per service logical interface is required. If the services are large in number, this method does not scale as the number of sessions are limited. Instead of one CFM session per service, a single CFM session can monitor multiple services.
Also, there are scenarios where the user-to-network interface (UNI) device needs to be brought down based on sessions on network-to-network Interface (NNI) logical interface. Here, the NNI logical interface refers to core interface and UNI physical interface refers to access interface hosting multiple service logical interfaces. Based on core interface monitoring, you can bring down service logical interfaces associated with access interface.
Figure 3 illustrates a topology where a number of services destined to customer-edge (CE) routers share a single port on a provider-edge (PE) router. Each service uses one logical interface. A set of services or logical interfaces (colored in yellow) are destined to one CE router and a set of services or logical interfaces colored in red are destined to another CE router. To monitor each service, you need dedicated down maintenance association end point (MEP) sessions for each service. You can bring down the service by bringing down the service logical interface whenever the session goes down. However, this approach is not scalable if we have large number of services. Monitoring the CFM session on the physical interface is also not feasible because multiple CE routers might be connected and the services to other CE router could be disrupted. To address this issue of monitoring multiple services with a single session, you can create a CCM action profile to bring down a group of logical interfaces by using a CFM session that is configured on a single logical interface.

You can configure CCM action profiles for the following scenarios:
To bring down a group of logical interfaces all having the same parent port when CCM monitoring session is running on one of the logical interface but on a different parent port.
To bring down a group of logical interfaces when CCM monitoring session is running on one of the logical interfaces, all belonging to the same parent port.
To bring down the port, when the CCM monitoring session is running on one of the logical interfaces of a different parent port.
Benefits of Creating CFM Action Profile to Bring Down a Group of Logical Interfaces
Reduces resource requirement in scaled networks where multiple services need to be monitored.
Avoids the need to create individual MEP sessions for each service in a topology that includes multiple services to be monitored, thereby enhancing the performance and scalability of the network.
See Also
Configuring a CFM Action Profile to Bring Down a Group of Logical Interfaces
To monitor multiple services or IFLs using CFM session
configured on a single logical interface, you can create a CCM action
profile to bring down a group of logical interfaces. You need to define
an action to bring down the interface group in the action profile.
You will then define the interface device name and the number of logical
interfaces that have to be brought down. A logical interface is represented
by a combination of the interface-device-name
and unit-list
. The following steps explain the procedure to bring
down a group of logical interfaces when the interface-device-name
and/or unit-list
are specified.
See Also
Enabling Enhanced Connectivity Fault Management Mode
You can enable enhanced connectivity fault management (CFM) mode to enable effective Ethernet OAM deployment in scaling networks. On enabling enhanced CFM mode, Junos OS supports 32, 000 maintenance association end points (MEPs) and maintenance intermediate points (MIPs) each per chassis for bridge, VPLS, L2VPN, and CCC domains. In previous releases, Junos OS supports 8, 000 MEPs and 8000 MIPS per chassis. If you do not enable enhanced CFM, Junos OS continues to support existing number of MIPs and MEPs per chassis.
To support enhanced CFM mode, configure the network services
mode on the router as enhanced-ip
. If the network services
mode is not enhanced-ip
, and you have enabled enhanced
CFM, the following warning message is displayed:[edit protocols oam ethernet]
'connectivity-fault-management'
enhanced ip is not effective please configure enhanced
ip and give router reboot
To enable enhanced CFM mode, perform the following steps:
See Also
Configuring M120 and MX Series Routers for CCC Encapsulated Packets
- IEEE 802.1ag CFM OAM Support for CCC Encapsulated Packets Overview
- CFM Features Supported on Layer 2 VPN Circuits
- Configuring CFM for CCC Encapsulated Packets
IEEE 802.1ag CFM OAM Support for CCC Encapsulated Packets Overview
Layer 2 virtual private network (L2VPN) is a type of virtual private network service used to transport customer's private Layer 2 traffic (for example, Ethernet, ATM or Frame Relay) over the service provider's shared IP/MPLS infrastructure. The service provider edge (PE) router must have an interface with circuit cross-connect (CCC) encapsulation to switch the customer edge (CE) traffic to the public network.
The IEEE 802.1ag Ethernet Connectivity Fault Management (CFM) is an OAM standard used to perform fault detection, isolation, and verification on virtual bridge LANs. M120 and MX Series routers provide CFM support for bridge/VPLS/routed interfaces and support 802.1ag Ethernet OAM for CCC encapsulated packets.
CFM Features Supported on Layer 2 VPN Circuits
CFM features supported on L2VPN circuits are as follows:
Creation of up/down MEPs at any level on the CE-facing logical interfaces.
Creation of MIPs at any level on the CE-facing logical interfaces.
Support for continuity check, loopback, and linkrace protocol.
Support for the Y1731 Ethernet Delay measurement protocol.
Support for action profiles to bring the CE-facing logical interfaces down when loss of connectivity is detected.

To monitor the L2VPN circuit, a CFM up MEP (Level 6 in Figure 4) can be configured on the CE-facing logical interfaces of provider edge routers PE1 and PE2. To monitor the CE-PE attachment circuit, a CFM down MEP can be configured on the customer logical interfaces of CE1-PE1 and CE2-PE2 (Level 0 in Figure 4).
Configuring CFM for CCC Encapsulated Packets
The only change from the existing CLI configuration is the introduction of a new command to create a MIP on the CE-facing interface of the PE router.
protocols { oam { ethernet { connectivity-fault-management { # Define a maintenance domains for each default level. #; These names are specified as DEFAULT_level_number maintenance-domain DEFAULT_x { # L2VPN CE interface interface (ge | xe)-fpc/pic/port.domain; } { level number; maintenance-association identifier { mep mep-id { direction (up | down); # L2 VPN CE interface on which encapsulation family CCC is configured. interface (ge | xe)-fpc/pic/port.domain; auto-discovery; priority number; } } } } } } }
See Also
Configuring Connectivity Fault Management for Interoperability During Unified In-Service Software Upgrades
Starting in Release 17.1, Junos OS connectivity fault management (CFM), during a unified in-service software upgrade (ISSU), works when the peer device is not a Juniper Networks router. Interoperating with the router of another vendor, the Juniper Networks router retains session information and continues to transmit continuity check message (CCM) PDUs during the unified ISSU. Connectivity fault management continues to operate.
This feature requires the following conditions be met:
Packet Forwarding Engine keepalives must be enabled to provide inline transmission of CCMs. The feature does not work when the CCMs are transmitted by the CPU of a line card, which is the default transmission method.
The interval between CCMs must be 1 second.
CFM interoperability during a unified ISSU is supported on the following MPCs: MPC1, MPC2, MPC2-NG, MPC3-NG, MPC5, and MPC6.
To enable CFM interoperability with third-party devices across a unified ISSU:
See Also
Configuring Unified ISSU for 802.1ag CFM
A unified in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is automatically enabled for the Connectivity Fault Management (CFM) protocols and interoperates between local and remote maintenance endpoints (MEPs).
The Junos OS provides support for unified ISSU using the loss threshold type length value (TLV), which is automatically enabled for CFM. TLVs are described in the IEEE 802.1ag standard for CFM as a method of encoding variable-length and optional information in a protocol data unit (PDU). The loss threshold TLV indicates the loss threshold value of a remote MEP. The loss threshold TLV is transmitted as part of the CFM continuity check messages.
Starting in Junos OS Release 15.1, configuring ISSU with CFM (802.1ag) is supported only on MX and PTX routers that support TLV. Interoperation with other vendors is not supported.
During a unified ISSU, the control plane may go down for several seconds and cause CFM continuity check packets to get dropped. This may cause the remote MEP to detect a connectivity loss and mark the MEP as down. To keep the MEP active during a unified ISSU, the loss threshold TLV communicates the minimum threshold value the receiving MEP requires to keep the MEP active. The receiving MEP parses the TLV and updates the loss threshold value, but only if the new threshold value is greater than the locally configured threshold value.
An overview of CFM is described starting in IEEE 802.1ag OAM Connectivity Fault Management Overview, and you should further observe the additional requirements described in this topic.
Table 2 shows the Loss Threshold TLV format.
Parameter |
Octet (sequence) |
Description |
---|---|---|
Type=31 |
1 |
Required. Required. If 0, no Length or Value fields follow. If not 0, at least the Length field follows the Type field. |
Length=12 |
2 |
Required if the Type field is not 0. Not present if the Type field is 0. The 16 bits of the Length field indicate the size, in octets, of the Value field. 0 in the Length field indicates that there is no Value field. |
OUI |
3 |
Optional. Organization unique identifier (OUI), which is controlled by the IEEE and is typically the first three bytes of a MAC address (Juniper OUI 0x009069). |
Subtype |
1 |
Optional. Organizationally defined subtype. |
Value |
4 |
Optional. Loss threshold value. |
Flag |
4 |
Optional. Bit0 (identifies an ISSU is in progress) Bit1-31 (reserved) |
Junos OS provides configuration support for the convey-loss-threshold
statement, allowing you to control the transmission of the loss
threshold TLV in continuity check messages PDUs. The convey-loss-threshold
statement specifies that the loss threshold TLV must be transmitted
as part of the continuity check messages. If the convey-loss-threshold
statement is not specified, continuity check messages transmit this
TLV only when a unified ISSU is in progress. The Junos OS provides
this configuration at the continuity-check level. By default, continuity
check messages do not include the loss threshold TLV.
To configure the convey loss threshold, use the convey-loss-threshold
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain identifier maintenance-association identifier continuity-check]
hierarchy level.
For the remote MEP, the loss threshold TLV is transmitted only
during the unified ISSU if the convey-loss-threshold
statement
is not configured. The remote MEP switches back to the default loss
threshold if no loss threshold TLV is received or the TLV has a default
threshold value of 3.
An example of the ISSU configuration statements follows:
protocols { oam { ethernet { connectivity-fault-management { maintenance-domain identifier { level number; maintenance-association identifier { continuity-check { convey-loss-threshold; interval number; loss-threshold number; hold-interval number; } } } } } } }
The Junos OS saves the last received loss threshold TLV from
the remote MEP. You can display the last saved loss threshold TLV
that is received by the remote MEP, using the show oam ethernet
connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
command, as in the following example:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md3 maintenance-association ma5 local-mep 2 remote-mep 1 Maintenance domain name: md3, Format: string, Level: 3 Maintenance association name: ma3, Format: string Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames MEP identifier: 2, Direction: up, MAC address: 00:19:e2:b0:76:be Auto-discovery: enabled, Priority: 0 Interface status TLV: none, Port status TLV: none Connection Protection TLV: yes Prefer me: no, Protection in use: no, FRR Flag: no Interface name: xe-4/1/1.0, Interface status: Active, Link status: Up Loss Threshold TLV: Loss Threshold: 3 , Flag: 0x0 Remote MEP identifier: 1, State: ok MAC address: 00:1f:12:b7:ce:79, Type: Learned Interface: xe-4/1/1.0 Last flapped: Never Continuity: 100%, Admin-enable duration: 45sec, Oper-down duration: 0sec Effective loss threshold: 3 frames Remote defect indication: false Port status TLV: none Interface status TLV: none Connection Protection TLV: Prefer me: no, Protection in use: no, FRR Flag: no Loss Threshold TLV: #Displays last received value Loss Threshold: 3 , Flag: 0x0
The Junos OS saves the last transmitted loss threshold TLV from
a local MEP. You can display the last transmitted loss threshold TLV
and the effective loss (operational) threshold for the remote MEP,
using the show oam ethernet connectivity-fault-management mep-database
maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
command, as in the following example:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md3 maintenance-association ma5 local-mep 2 remote-mep 1 Maintenance domain name: md3, Format: string, Level: 3 Maintenance association name: ma3, Format: string Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames MEP identifier: 2, Direction: up, MAC address: 00:19:e2:b0:76:be Auto-discovery: enabled, Priority: 0 Interface status TLV: none, Port status TLV: none Connection Protection TLV: yes Prefer me: no, Protection in use: no, FRR Flag: no Interface name: xe-4/1/1.0, Interface status: Active, Link status: Up Loss Threshold TLV: #Displays last transmitted value Loss Threshold: 3 , Flag: 0x0 Remote MEP identifier: 1, State: ok MAC address: 00:1f:12:b7:ce:79, Type: Learned Interface: xe-4/1/1.0 Last flapped: Never Continuity: 100%, Admin-enable duration: 45sec, Oper-down duration: 0sec Effective loss threshold: 3 frames #Displays operational threshold Remote defect indication: falsePort status TLV: none Interface status TLV: none Connection Protection TLV: Prefer me: no, Protection in use: no, FRR Flag: no Loss Threshold TLV: Loss Threshold: 3 , Flag: 0x0
See Also
Junos OS Support for Performance Monitoring Compliant with Technical Specification MEF 36
Junos OS release 16.1R1 and later supports performance monitoring that is compliant with Technical Specification MEF 36. Technical Specification MEF 36 specifies the performance monitoring MIB. The performance monitoring MIB is required to manage service operations, administration, and maintenance (OAM) implementations that satisfy the Service OAM requirements and framework specified in MEF 17 and MEF 35, the management objects specified in MEF 7.1, and the performance monitoring functions defined in ITU-T Y.1731 and IEEE 802.1ag.
You can enable MEF-36-compliant performance monitoring by configuring
the measurement-interval
statement at the [edit protocols oam ethernet cfm performance-monitoring]
hierarchy level.
When MEF-36-compliant performance monitoring is enabled:
An SNMP get next request for a variable might not fetch the current value unless an SNMP walk is performed before performing the get next request. This limitation applies only to the current statistics for delay measurement, loss measurement, and synthetic loss measurement.
The output for the field
Current delay measurement statistics
might display a measurement interval of 0 (zero) and an incorrect timestamp until the first cycle time has expired.Supported data TLV size for performance monitoring protocol data units (PDUs) is 1386 bytes when MEF-36-compliant performance monitoring is enabled. The TLV size is 1400 bytes in legacy mode.
The maximum configurable value for the lower threshold bin is 4,294,967,294.
Frame loss ratio (FLR) is excluded in loss measurements during period of unavailability for synthetic loss measurement only. In case of loss measurement, FLR is included even during period of unavailability.
During a period of loss of continuity (adjacency down), although SOAM PDUs are not sent, FLR and availability calculations are not stopped. These calculations are performed with the assumption of 100% loss.
The number of SOAM PDUs that are sent during the first measurement interval might be less than expected. This is because of a delay in detecting the adjacency state at the performance monitoring session level.
The number of SOAM PDUs transmitted during a measurement interval for a cycle time of 100 ms might not be accurate. For example, in a measurement interval of two minutes with a cycle time 100 ms, the SOAM PDUs transmitted might be in the range of 1198—2000.
See Also
Damping CFM performance Monitoring Traps and Notifications to Prevent Congestion of The NMS
You can dampen the performance monitoring threshold-crossing traps and notifications that are generated every time a threshold-crossing event occurs to prevent congestion of the network management system (NMS).
Damping limits the number of jnxSoamPmThresholdCrossingAlarm traps sent to the NMS by summarizing the flap occurrences over a period of time, known as the flap trap timer, and sends a single jnxSoamPmThresholdFlapAlarm notification to the NMS. You can configure the duration of the flap trap timer to any value from 1 through 360 seconds.
The jnxSoamPmThresholdFlapAlarm notification is generated and sent when the following conditions are met:
At least one flap has occurred when the flap timer has expired.
You changed the value of the flap trap timer, which caused the timer to stop.
You can enable damping at the global level for the iterator
or you can enable damping at the individual threshold type of the
iterator. For instance, to enable damping at the global level, for
the iterator, use the following command: set protocols oam ethernet
cfm performance-monitoring sla-iterator-profiles profile-name flap-trap-monitor
. To enable damping at a specific threshold
type, for the avg-fd-twoway-threshold
, use the following
command: set protocols oam ethernet cfm performance-monitoring
sla-iterator-profiles profile-name avg-fdv-twoway-threshold
flap-trap-monitor
.
You can also disable damping.
See Also
Example: Configuring Ethernet CFM on Physical Interfaces
This example shows the configuration of Ethernet connectivity fault management (CFM) on physical interfaces.
Requirements
This example uses the following hardware and software components:
Junos OS Release 9.3 or later.
Overview
CFM can be used to monitor the physical link between two routers. This functionality is similar to that supported by the IEEE 802.3ah LFM protocol.
In Junos OS Release 9.3 and later, CFM also supports aggregated Ethernet interfaces. On interfaces configured on Modular Port Concentrators (MPCs) and Modular Interface Cards (MICs) on MX Series routers, CFM is not supported on untagged aggregated Ethernet member links. MPCs and MICs do support CFM on untagged and tagged aggregated Ethernet logical interfaces.
The configurations in this example are only partial examples of complete and functional router configurations. Do not copy these configurations and use them directly on an actual system.
Configuration
In the following example, two routers (Router 1 and Router 2) are connected by a point-to-point Gigabit Ethernet link. The link between these two routers is monitored using CFM. This is shown in Figure 5. The single boundary is a “down mep” in CFM terminology.

To configure Ethernet CFM on physical interfaces, perform these tasks:
CLI Quick Configuration
Router 1
Configure the interface and CFM:
[edit] interfaces ge-1/0/1 { unit 0 { family inet; } } protocols { oam { ethernet { connectivity-fault-management { maintenance-domain private { level 0; maintenance-association private-ma { continuity-check { interval 1s; } mep 100 { interface ge-1/0/1; direction down; auto-discovery; } } } } } } }
The configuration on Router 2 mirrors that on Router 1, with the exception of the mep-id.
Router 2
Configure the interface and CFM:
[edit] interfaces ge-0/2/5 { unit 0 { family inet; } } protocols { oam { ethernet { connectivity-fault-management { maintenance-domain private { level 0; maintenance-association private-ma { continuity-check { interval 1s; } mep 200 { interface ge-0/2/5; direction down; auto-discovery; } } } } } } }
To verify that the physical interface is configured correctly
for CFM, use the show interface
command. To verify the
CFM configuration, use one or more of the show oam ethernet connectivity-fault-management
commands listed in the CLI Explorer.
Example: Configuring Ethernet CFM on Bridge Connections
In this example, both the customer and service provider are running Ethernet CFM over a simple bridge network. The network is shown in Figure 6. The customer has configured Ethernet CFM on MX Series routers L2-CE1 and L2-CE2. The service provider has configured Ethernet CFM on MX Series routers PE1 and PE2.
The configurations in this example are only partial examples of complete and functional router configurations. Do not copy these configurations and use them directly on an actual system.
The service provider is using CFM level 3 for the link between PE1 and PE2 and level 5 from one CE facing port to the other. The customer is using CFM level 7. The boundaries are marked with “up mep” and “down mep” CFM terminology in the figure.

Here are the configurations of CFM on the customer routers.
CFM on L2-CE1
[edit interfaces] ge-0/2/9 { vlan-tagging; unit 0 { vlan-id 2000; } } [edit protocols oam ethernet] connectivity-fault-management { maintenance-domain customer { level 7; maintenance-association customer-site1 { continuity-check { interval 1s; } mep 700 { interface ge-0/2/9.0; direction down; auto-discovery; } } } }
CFM on L2-CE2
[edit interfaces] ge-1/0/7 { vlan-tagging; unit 0 { vlan-id 2000; } } [edit protocols oam ethernet] connectivity-fault-management { maintenance-domain customer { level 7; maintenance-association customer-site2 { continuity-check { interval 1s; } mep 800 { interface ge-1/0/7.0; direction down; auto-discovery; } } } }
Here are the configurations of CFM on the provider routers.
CFM on PE1
[edit interfaces] ge-5/0/9 { vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { encapsulation vlan-bridge; vlan-id 2000; } } ge-5/1/7 { vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { encapsulation vlan-bridge; vlan-id 2000; } } [edit bridge-domains] bridge-vlan2000 { domain-type bridge; vlan-id 2000; interface ge-5/0/9.0; interface ge-5/1/7.0; } [edit protocols oam ethernet connectivity-fault-management] maintenance-domain provider-outer { level 5; maintenance-association provider-outer-site1 { continuity-check { interval 1s; } mep 200 { interface ge-5/0/9.0; direction up; auto-discovery; } } } maintenance-domain provider-inner { level 3; maintenance-association provider-inner-site1 { continuity-check { interval 1s; } mep 200 { interface ge-5/1/7.0; direction down; auto-discovery; } } }
CFM on PE2
[edit interfaces] ge-5/1/7 { vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { encapsulation vlan-bridge; vlan-id 2000; } } ge-5/2/3 { vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { encapsulation vlan-bridge; vlan-id 2000; } } [edit bridge-domains] bridge-vlan2000 { domain-type bridge; interface ge-5/2/3.0; interface ge-5/1/7.0; } [edit protocols oam ethernet connectivity-fault-management] maintenance-domain provider-outer { level 5; maintenance-association provider-outer-site1 { continuity-check { interval 1s; } mep 100 { interface ge-5/2/3.0; direction up; auto-discovery; } } } maintenance-domain provider-inner { level 3; maintenance-association provider-inner-site1 { continuity-check { interval 1s; } mep 100 { interface ge-5/1/7.0; direction down; auto-discovery; } } }
See Also
Example: Configuring Ethernet CFM over VPLS
In this example, both the customer and service provider are running Ethernet CFM over a VPLS and a multiprotocol label switching (MPLS) network. The network is shown in Figure 7. The customer has configured Ethernet CFM on MX Series routers L2-CE1 and L2-CE2. The service provider has configured Ethernet CFM on MX Series routers PE1, P, and PE2.
The configurations in this example are only partial examples of complete and functional router configurations. Do not copy these configurations and use them directly on an actual system.
The service provider is using CFM level 5 and the customer is using CFM level 7. The boundaries are marked with “up mep” and “down mep” CFM terminology in the figure.

The logical interfaces in a VPLS routing instance might have the same or different VLAN configurations. VLAN normalization is required to switch packets correctly among these interfaces. Normalization supports automatic mapping of VLANs and performs operations on VLAN tags to achieve the desired translation. See Configuring a Normalized VLAN for Translation or Tagging.
The following forwarding path considerations must be observed:
Packet receive path:
This is the forwarding path for packets received on the interfaces.
802.1ag Ethernet OAM for VPLS uses implicit interface filters and forwarding table filters to flood, accept, and drop the CFM packets.
Packet transmit path:
Junos OS uses the router’s hardware-based forwarding for CPU-generated packets.
For down MEPs, the packets are transmitted on the interface on which the MEP is configured.
In MX series routers, for up MEPs, the packets must be flooded to other interfaces in the VPLS routing instance. The router creates a flood route tied to a flood next hop (with all interfaces to flood) and then sources the packets to be forwarded with this flood route.
The following are the configurations of the VPLS and CFM on the service provider routers.
Configuration of PE1
[edit chassis] fpc 5 { pic 0 { tunnel-services { bandwidth 1g; } } } [edit interfaces] ge-1/0/7 { encapsulation flexible-ethernet-services; vlan-tagging; unit 1 { encapsulation vlan-vpls; vlan-id 2000; } } ge-0/0/0 { unit 0 { family inet { address 10.200.1.1/24; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.168.231/32 { primary; } address 127.0.0.1/32; } } } [edit routing-instances] vpls-vlan2000 { instance-type vpls; vlan-id 2000; interface ge-1/0/7.1; route-distinguisher 10.255.168.231:2000; vrf-target target:1000:1; protocols { vpls { site-range 10; site vlan2000-PE1 { site-identifier 2; } } } } [edit protocols] rsvp { interface ge-0/0/0.0; } mpls { label-switched-path PE1-to-PE2 { to 10.100.1.1; } interface ge-0/0/0.0; } bgp { group PE1-to-PE2 { type internal; local-address 10.200.1.1; family l2vpn { signaling; } local-as 65000; neighbor 10.100.1.1; } } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } interface ge-0/0/0.0; } } oam { ethernet { connectivity-fault-management { maintenance-domain customer-site1 { level 5; maintenance-association customer-site1 { continuity-check { interval 1s; } mep 100 { interface ge-1/0/7.1; direction up; auto-discovery; } } } } } }
Configuration of PE2
[edit chassis] fpc 5 { pic 0 { tunnel-services { bandwidth 1g; } } } [edit interfaces] ge-5/0/9 { vlan-tagging; encapsulation flexible-ethernet-services; unit 1 { encapsulation vlan-vpls; vlan-id 2000; } } ge-5/2/7 { unit 0 { family inet { address 10.100.1.1/24; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.168.230/32 { primary; } address 127.0.0.1/32; } } } [edit routing-instances] vpls-vlan2000 { instance-type vpls; vlan-id 2000; interface ge-5/0/9.1; route-distinguisher 10.255.168.230:2000; vrf-target target:1000:1; protocols { vpls { site-range 10; site vlan2000-PE2 { site-identifier 1; } } } } [edit protocols] rsvp { interface ge-5/2/7.0; } mpls { label-switched-path PE2-to-PE1 { to 10.200.1.1; } interface ge-5/2/7.0; } bgp { group PE2-to-PE1 { type internal; local-address 10.100.1.1; family l2vpn { signaling; } local-as 65000; neighbor 10.200.1.1; } } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } interface ge-5/2/7.0; } } oam { ethernet { connectivity-fault-management { maintenance-domain customer-site1 { level 5; maintenance-association customer-site1 { continuity-check { interval 1s; } mep 200 { interface ge-5/0/9.1; direction up; auto-discovery; } } } } } }
Configuration of P router
MPLS only, no CFM needed:
[edit] interfaces { ge-5/2/7 { # Connected to PE1 unit 0 { family inet { address 10.200.1.10/24; } family mpls; } } ge-0/1/0 { # Connected to PE2 unit 0 { family inet { address 10.100.1.10/24; } family mpls; } } lo0 { unit 0{ family inet { address 10.255.168.240/32; } } } } [edit] protocols { rsvp { interface ge-0/1/0.0; interface ge-5/2/7.0; } mpls { interface ge-0/1/0.0; interface ge-5/2/7.0; } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } interface ge-0/1/0.0; interface ge-5/2/7.0; } } }
CFM on L2-CE1
Here is the configuration of CFM on L2-E1:
[edit interfaces] ge-5/2/3 { vlan-tagging; unit 0 { vlan-id 2000; } } [edit protocols oam] ethernet { connectivity-fault-management { maintenance-domain customer { level 7; maintenance-association customer-site1 { continuity-check { interval 1s; } mep 800 { interface ge-5/2/3.0; direction down; auto-discovery; } } } } }
CFM on L2-CE2
Here is the configuration of CFM L2-CE2:
[edit interfaces] ge-0/2/9 { vlan-tagging; unit 0 { vlan-id 2000; } } [edit protocols oam] ethernet { connectivity-fault-management { maintenance-domain customer { level 7; maintenance-association customer-site1 { continuity-check { interval 1s; } mep 700 { interface ge-0/2/9.0; direction down; auto-discovery; } } } } }
See Also
CFM Action Profile Asynchronous Notification
CFM driven asynchronous notification enables link status synchronization between two CE devices
connected to each other through a pseudo wire originating from their respective PE devices. It emulates
the scenario as if two CE devices are directly connected. CFM provides end-to-end signaling even if PE1
and PE2 are not connected through single network but a set of networks.
Layer 2 connectivity between PE1 and PE2
Figure 1 is an example of deployment scenario where CFM based asynchronous-notification can be used
to synchronize link status between CE1 and CE2. Following two requirements can be met with the
configuration of asynchronous-notification.
-
When the link between PE2 to CE2 goes down then the link between PE1 to CE1 also made down.
When the link is restored, it should restore the link status PE1 to CE1 also. The link status change between
PE1 to CE1 should work the similar way.
-
When there is a connectivity issue between PE1 to PE2, its triggers a link down between PE1 to CE1
and PE2 to CE2. If the connection status is restored, it should restore the link status on both ends
-
See Also
no-control-word
statement for all
Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.no-control-word
statement for all
Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.no-control-word
statement for all
Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.