Configuring Connectivity Fault Management (CFM)

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.

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

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.

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

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.

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

This example shows the configuration of Ethernet connectivity fault management (CFM) on physical interfaces.

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

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 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 VPLS

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

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