Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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.

Note:

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:

  1. In configuration mode, create a maintenance domain by specifying the name and the name format at the [edit protocols oam ethernet connectivity-fault-management ] hierarchy level.
    Note:

    If you configure the maintenance domain name length greater than 45 octet, then the following error message is displayed: error: configuration check-out failed.

  2. Specify the maintenance domain level by specifying the value at the [edit protocols oam ethernet connectivity-fault-management ] hierarchy level.

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):

  1. Configure a bridge domain under a user-defined virtual switch by specifying the virtual-switch statement and the name of the user-defined virtual switch, at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name default-x] hierarchy level.
    Note:

    A bridge domain must be specified by name only if it is configured by including the vlan-id statement under the virtual-switch statement. If a bridge domain is configured with a range of VLAN IDs, then the VLAN IDs must be explicitly listed after the bridge domain name.

    Note:

    You can also configure the bridge domain for the default virtual switch by including the bridge-domain statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] hierarchy level.

  2. Configure the VPLS routing instance for the default maintenance domain.
  3. Configure the maintenance intermediate point (MIP) half function to divide the MIP fuctionality into two unidirectional segments to improve network coverage by increasing the number of MIPs that are monitored. The MIP half function also responds to loop-back and link-trace messages to identify faults.
    Note:

    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.

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.

Note:

ACX5048 and ACX5096 routers do not support MIP configuration on VPLS services.

Note:

ACX5448 router do not support MIP.

Note:

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

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.

Note:

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:

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:

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:

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:

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.

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.

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:

  1. Specify the time to wait in minutes before flushing the MEP database, if no updates occur, with a value from 1 minute through 30,240 minutes. The default value is 10 minutes.
    Note:

    Flushing based on the hold timer is applicable only for autodiscovered remote MEPs and not for statically configured remote MEPs.

  2. Specify the time to wait (duration) between the transmissions of CCMs. The duration can be one of the following values: 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.
  3. Specify the 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.

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)

To configure a maintenance association end point:

  1. Specify an ID for the MEP at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. You can specify any value from 1 through 8191.
  2. Enable maintenance end point automatic discovery so the MEP can accept continuity check messages (CCMs) from all remote MEPs of the same maintenance association.
  3. Specify the direction in which the CCM packets are transmitted for the MEP. You can specify up or down. If you specify the direction as up, CCMs are transmitted out of every logical interface that is part of the same bridging or VPLS instance except for the interface configured on the MEP. If you specify the direction as down, CCMs are transmitted only out of the interface configured on the MEP.
    Note:

    Ports in the Spanning Tree Protocol (STP) blocking state do not block CFM packets destined to a down MEP. Ports in an STP blocking state without the continuity check protocol configured do block CFM packets.

    Note:

    Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs. For all other interfaces on MX Series routers and on all other routers and switches, you must continue to configure the no-control-word statement at the [edit routing-instances routing-instance-name protocols l2vpn] or [edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarchy level when you configure CFM MEPs. Otherwise, the CFM packets are not transmitted, and the show oam ethernet connectivity-fault-management mep-database command does not display any remote MEPs.

  4. Specify the interface to which the MEP is attached. It can be a physical interface, logical interface, or trunk interface. On MX Series routers, the MEP can be attached to a specific VLAN of a trunk interface.
  5. Specify the IEEE 802.1 priority bits that are used by continuity check and link trace messages. You can specify a value from through 7 as the priority.
  6. Specify the lowest priority defect that generates a fault alarm whenever CFM detects a defect. Possible values include: all -defects, err-xcon, mac-rem-err-xcon, no-defect, rem-err-xcon, and xcon.
  7. Specify the ID of the remote MEP at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id]. You can specify any value from 1 through 8191.

Configuring a remote Maintenance Association End Point (MEP)

To configure a remote maintenance association end point:

  1. Configure the remote MEP by specifying the MEP ID at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id]. You can specify any value from 1 through 8191.
  2. Specify the name of the action profile to be used for the remote MEP by including the action-profile profile-name statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id remote-mep remote-mep-id]. The profile must be defined at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level.
  3. Configure the remote MEP to detect initial loss of connectivity. By default, the MEP does not generate loss-of-continuity (LOC) defect messages. When you configure the detect-loc statement, a loss-of-continuity (LOC) defect is detected if no continuity check message is received from the remote MEP within a period equal to 3.5 times the continuity check interval configured for the maintenance association. If a LOC defect is detected, a syslog error message is generated.
    Note:

    When you configure connectivity-fault management (CFM) along with detect-loc, any action-profile configured to bring down the interface is executed if continuity check message is not received . However, the action-profile is not executed if you have not configured detect-loc and continuity check message is not received.

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:

  1. To enable Ethernet frame delay measurement hardware assistance on the reception path, include the hardware-assisted-timestamping statement at the [edit protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level:
  2. Ethernet frame delay measurement requires that distributed PPMD is enabled. Before you can gather statistics for Ethernet frame delay measurement, you must make sure that PPMD is configured properly. Without distributed PPMD, delay measurement results are not valid.

    To perform Ethernet frame delay measurement, make sure that the following configuration statement is NOT present:

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.

Note:

If the path is not specified, the session monitors the active path.

Table 1 describes the available service protection options.

Table 1: Service Protection Options

Option

Description

working

Specifies the working path.

protect

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:

  1. In configuration mode, create a maintenance domain by specifying the name and the name format at the [edit protocols oam ethernet connectivity-fault-management ] hierarchy level.
    Note:

    If you configure the maintenance domain name length greater than 45 octet, then the following error message is displayed: error: configuration check-out failed.

  2. Specify the maintenance domain level by specifying the value at the [edit protocols oam ethernet connectivity-fault-management ] hierarchy level.
  3. Create a maintenance association for the working path by specifying the name and the short name format at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name] hierarchy level.
  4. Specify the maintenance association name used for connection protection and the name of the automatic-protection-switching profile (aps-profile) at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level.
  5. Specify the time to wait between transmissions of continuity check messages at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check ] hierarchy level. The duration can be one of the following values: 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.
  6. Specify an ID for the MEP at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. You can specify any value from 1 through 8191.
  7. Enable maintenance end point automatic discovery so the MEP can accept continuity check messages (CCMs) from all remote MEPs of the same maintenance association.
  8. Specify the direction in which the CCM packets are transmitted for the MEP. You can specify up or down. If you specify the direction as up, CCMs are transmitted out of every logical interface that is part of the same bridging or VPLS instance except for the interface configured on the MEP. If you specify the direction as down, CCMs are transmitted only out of the interface configured on the MEP.
    Note:

    Ports in the Spanning Tree Protocol (STP) blocking state do not block CFM packets destined to a down MEP. Ports in an STP blocking state without the continuity check protocol configured do block CFM packets.

    Note:

    Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs. For all other interfaces on MX Series routers and on all other routers and switches, you must continue to configure the no-control-word statement at the [edit routing-instances routing-instance-name protocols l2vpn] or [edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarchy level when you configure CFM MEPs. Otherwise, the CFM packets are not transmitted, and the show oam ethernet connectivity-fault-management mep-database command does not display any remote MEPs.

  9. Specify the interface to which the MEP is attached. It can be a physical interface, logical interface, or trunk interface. On MX Series routers, the MEP can be attached to a specific VLAN of a trunk interface. Also, specify the transport path as working.
  10. Create a maintenance association for the protection path by specifying the name and the short name format at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name] hierarchy level.
  11. Specify the time to wait between transmissions of continuity check messages at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check ] hierarchy level. The duration can be one of the following values: 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.
  12. Specify an ID for the MEP at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. You can specify any value from 1 through 8191.
  13. Enable maintenance end point automatic discovery so the MEP can accept continuity check messages (CCMs) from all remote MEPs of the same maintenance association.
  14. Specify the direction in which the CCM packets are transmitted for the MEP. You can specify up or down. If you specify the direction as up, CCMs are transmitted out of every logical interface that is part of the same bridging or VPLS instance except for the interface configured on the MEP. If you specify the direction as down, CCMs are transmitted only out of the interface configured on the MEP.
    Note:

    Ports in the Spanning Tree Protocol (STP) blocking state do not block CFM packets destined to a down MEP. Ports in an STP blocking state without the continuity check protocol configured do block CFM packets.

    Note:

    Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs. For all other interfaces on MX Series routers and on all other routers and switches, you must continue to configure the no-control-word statement at the [edit routing-instances routing-instance-name protocols l2vpn] or [edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarchy level when you configure CFM MEPs. Otherwise, the CFM packets are not transmitted, and the show oam ethernet connectivity-fault-management mep-database command does not display any remote MEPs.

  15. Specify the interface to which the MEP is attached. It can be a physical interface, logical interface, or trunk interface. On MX Series routers, the MEP can be attached to a specific VLAN of a trunk interface. Also, specify the transport path as working.

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:

  1. Configure the time to wait for a linktrace response at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can specify the value in minutes or seconds. The default value is 10 minutes.
  2. Configure the number of linktrace reply entries to be stored per linktrace request. You can specify a value from 1 through 500. The default value is 100.

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:

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.

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.

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.

Note:

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 a policer all or policer other configuration.

  • If one session is configured with policer other, then the other session cannot have a policer all or policer other configuration.

A commit error will occur if such a configuration is committed.

Note:

Policers with PBB and MIPs are not supported.

Configuring 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).

Note:

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.

Figure 1: Scope of the E-LMI ProtocolScope of the E-LMI Protocol

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 and l2vpn 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.

Note:

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)

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:

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:

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.

Figure 2: E-LMI Configuration for a Point-to-Point EVC (SVLAN) Monitored by CFME-LMI Configuration for a Point-to-Point EVC (SVLAN) Monitored by CFM

Configuring PE1

Configuring PE2

Configuring Two UNIs Sharing the Same EVC

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.

Note:

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:

  1. In configuration mode, at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level, specify the name of the action profile and the CFM event(s). You can configure more than one event in the action profile. Possible events include: interface-status-tlv, port-status-tlv, adjacency-loss, RDI.
  2. Specify the action to be taken by the router when the event occurs. The action is triggered when the event occurs. If you have configured more than one event in the action profile, it is not necessary for all events to occur to trigger the action.
  3. Specify the default action to be taken by the router when connectivity to a remote MEP fails. If no action is configured, no action is taken.
    Note:

    Associating an action profile with the interface-down action on an up MEP CFM session running over a circuit cross-connect (CCC) interface (l2circuit/l2vpn) is not advisable and can result in a deadlock situation.

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.

Figure 3: Topology of Multiple VLAN Services Sharing a Single Port on PE Router Destined to Multiple CE Routers Topology of Multiple VLAN Services Sharing a Single Port on PE Router Destined to Multiple CE Routers

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.

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.

  1. In configuration mode, at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level, specify the name of the action profile and the CFM event(s). You can configure more than one event in the action profile.

    For example,

    Note:

    The action interface-group-down will not be supported with events other than adjacency-loss and RDI. Any other events configured results in a commit error.

  2. In configuration mode, at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name ] hierarchy level, define the action to bring down the interface group.
    Note:

    The action interface-group-down will not be supported with other interface related actions. Any other actions configured results in a commit error.

  3. At the [edit protocols oam ethernet connectivity-fault-management] hierarchy level, define the maintenance domain. Specify the maintenance-association parameters.

    For example,

  4. At the edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name, define the maintenance association endpoint and the associated parameters.

    For example,

  5. If the action-profile has interface-group-down action configured, it is mandatory to configure the interface-group at the RMEP level. In the configuration mode at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name include the interface-group statement to bring down the interface group marked with the action profile as interface-group-down.

    For example,

    Note:

    If the interface-group configuration is not included in the RMEP configuration. The configuration results in commit error.

  6. A logical interface is represented by a combination of the interface-device-name and unit-list. Configure the device interface name and the number of logical interfaces at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name interface-group.

    For example,

    In this configuration example, the interface ge-0/0/0.0 is brought down.

    Note:
    • At least one of the interface-group parameters, interface-device-name or unit-list must be configured. If the interface device name is not configured, the MEP interface is considered as the device name and the logical interface on that device is brought down.

    • If the unit-list parameter exceeds the recommended limit, a commit error occurs.

    • If the interface-device-name is not specified in the interface-group, the logical interface numbers mentioned in unit-list for the physical interface is brought down.

    • If the unit-list is not specified in the interface-group, IFLs are brought down for the configured interface.

  7. Verify the configuration using show protocols oam command.

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.

Note:

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:

  1. In configuration mode, go to the [edit protocols oam ethernet connectivity-fault-management] hierarchy level.
  2. Enable effective Ethernet OAM deployment by enabling enhanced CFM mode.
  3. Commit the mode change. A warning message is displayed asking you to restart CFM. If you do not restart CFM, CFM is automatically restarted by Junos OS.
  4. To verify if the enhanced CFM mode has been configured, use the show oam ethernet connectivity-fault-management state command.

Configuring M120 and MX Series Routers 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.

Figure 4: Layer 2 VPN TopologyLayer 2 VPN Topology

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.

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:

  1. Enable inline keepalives.
  2. Set the CCM interval to 1 second.

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.

Note:

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.

Table 2: 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:

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:

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:

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.

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.

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.

Note:

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.

Figure 5: Ethernet CFM on Physical InterfacesEthernet CFM on Physical Interfaces

To configure Ethernet CFM on physical interfaces, perform these tasks:

CLI Quick Configuration

Router 1

Configure the interface and CFM:

The configuration on Router 2 mirrors that on Router 1, with the exception of the mep-id.

Router 2

Configure the interface and CFM:

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.

Note:

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.

Figure 6: Ethernet CFM over a Bridge NetworkEthernet CFM over a Bridge Network

Here are the configurations of CFM on the customer routers.

CFM on L2-CE1

CFM on L2-CE2

Here are the configurations of CFM on the provider routers.

CFM on PE1

CFM on PE2

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.

Note:

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.

Figure 7: Ethernet OAM with VPLSEthernet OAM with VPLS
Note:

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.

Note:

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

Configuration of PE2

Configuration of P router

MPLS only, no CFM needed:

CFM on L2-CE1

Here is the configuration of CFM on L2-E1:

CFM on L2-CE2

Here is the configuration of CFM L2-CE2:

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

Release History Table
Release
Description
17.1
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.
15.1
Starting in Junos OS Release 15.1, configuring ISSU with CFM (802.1ag) is supported only on MX and PTX routers that support TLV.
12.3
Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.
12.3
Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.
12.3
Starting with Junos OS Release 12.3, for all interfaces configured on Modular Port Concentrators (MPCs) on MX Series 5G Universal Routing Platforms, you no longer need to configure the no-control-word statement for all Layer 2 VPNs and Layer 2 circuits over which you are running CFM MEPs.