Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

CFM Monitoring between CE and PE Devices

Use this topic to understand more about CFM monitoring between provider edge devices and customer edge devices when the customer edge device is not a Juniper device. Also, you can understand more about how Interface Status TLVs, port status TLVs, chassis ID TLV, and connection protection TLV help in monitoring your network.

CFM Action Profile Asynchronous Notification

SUMMARY CFM driven asynchronous notification enables link status synchronization between two CE devices connectedto each other through a pseudo wire originating from their respective PE devices It emulatesthe scenario as if two CE devicesare 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

Configuring a CFM Action Profile to Asyncronus Notification

SUMMARY CFM UP-MEP on PE1 to PE2, monitors the connectivity between PE1 to PE2. Use of interface-status-tlv on these UP-MEP end points conveys the link status between PE1 to CE1 to PE2 and link-status between PE2 to CE2 to PE1. Action profile must be configured on PE1 to PE2 to drive asynchronous-notification towards respective CE devices . It is triggered when either adjacency-loss is detected or link-down is detected in the received interface-status-tlv.

  1. Enable asynchronous-notification at interface level

    For example

  2. Configure the action profile and the CFM event(s) to triggered this action profile at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can configure more than one event in the action profile

    For example

    The action asynchronous-notification is not supported with events other than interface-status-tlv down, interface-status-tlv lower-layer-down and adjacency-loss. Any other events configured results in a commit error

    .
  3. Define the action to asynchronous-notification at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name] hierarchy level.
  4. Define the maintenance domain at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level and specify the maintenance-association parameters

    For example

  5. Configure the generation of interface-status-tlv .it is required if asynchronous-notification configured based on interface-status-tlv.

    For example

  6. Define the maintenance association endpoint at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level and specify the associated parameters.

    For example

  7. Set asynchronous-notification action profile at the RMEP level.

    For example,

Understanding CFM Monitoring between CE and PE Devices

You can enable connectivity fault management (CFM) monitoring between provider edge devices and customer edge devices when the customer edge device is not a Juniper device. When the interface is down, CFM propagates the status of the interface in the CC messages. The CC message informs the customer edge device that the provider edge device is down.

You can configure CFM monitoring using either of the following two options:

  • Interface Status TLV (Type, Length, and Value)—You can enable connectivity fault management (CFM) monitoring between provider edge devices and customer edge devices when the customer edge device is not a Juniper device by using Interface Status TLV. When the interface is down, CFM propagates the status of the interface using interface status TLV. The Interface Status TLV indicates the status of the interface on which the MEP transmitting the CCM is configured, or the next-lower interface in the IETF RFC 2863 IF-MIB. Thus, the customer edge device is aware that the provider edge device is down. To configure CFM monitoring using Interface Status TLV, use the interface-status-tlv statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check hierarchy level. This is the standard option.

  • RDI (Remote Defect Indication)—Starting in Junos OS Release 17.3R1, you can enable connectivity fault management (CFM) monitoring between provider edge devices and customer edge devices when the customer edge device is not a Juniper device by using the remote defect indication (RDI) bit. When you enable CFM monitoring, CFM propagates the status of the provider edge device via the remote defect indication (RDI) bit in the CC messages. Thus, the customer edge device is aware that the provider edge device is down. The RDI bit is cleared when the service is back up. To configure CFM monitoring using the RDI bit, use the interface-status-send-rdi statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check hierarchy level. This option is required if the customer edge device does not support Interface Status TLV.

Note:

When the interface is set to CCC down and you have configured RDI, then RDI bit is sent. CFM does not monitor the status of the interface. If CCC down is set when the interface is not standby, RDI bit is sent with the CC messages if you have configured RDI.

Single Active Multi-homing Use Case using RDI bit

Consider the following topology where there are two provider edge devices (PE1 and PE2) as well as two customer edge devices (CE1 and CE2). PE1 is in active state while PE2 is in standby state. CFM down MEP is configured between the PE and CE. CFM detects that the CCC down and because CFM down MEP is configured, the CC messages generated have the RDI bit. The CC messages from PE2 to CE2 have the RDI bit set to indicate the blocked state. When PE2 becomes active, CCM down is cleared and the RDI bit is cleared from the subsequent CC messages.

Active/Active Multihoming Use case using RDI bit

Consider the topology where there are two provider edge devices (PE1 and PE2) and two customer edge devices (CE1 and CE2). PE1 is in active state while PE2 is in standby state. If CFM down MEP is not configured between the PE and CE to monitor the link connectivity, the CC messages generated do not have the RDI bit. CFM down MEP is configured between the PE and CE. CFM detects that the CCC down and because CFM down MEP is configured, the CC messages generated have the RDI bit. The CC messages from PE2 to CE2 have the RDI bit set to indicate the blocked state. When PE2 becomes active, CCM down is cleared and the RDI bit is cleared from the subsequent CC messages.

Configuring Port Status TLV and Interface Status TLV

TLVs Overview

Type, Length, and Value (TLVs) are described in the IEEE 802.1ag standard for CFM as a method of encoding variable-length and/or optional information in a PDU. TLVs are not aligned to any particular word or octet boundary. TLVs follow each other with no padding between them.

Table 1 shows the TLV format and indicates if it is required or optional.

Table 1: Format of TLVs

Parameter

Octet (sequence)

Description

Type

1

Required. If 0, no Length or Value fields follow. If not 0, at least the Length field follows the Type field.

Length

2–3

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.

Value

4

Length specified by the Length field. Optional. Not present if the Type field is 0 or if the Length field is 0.

Various TLVs for CFM PDUs

Table 2 shows a set of TLVs defined by IEEE 802.1ag for various CFM PDU types. Each TLV can be identified by the unique value assigned to its type field. Some type field values are reserved.

Table 2: Type Field Values for Various TLVs for CFM PDUs

TLV or Organization

Type Field

End TLV

0

Sender ID TLV

1

Port Status TLV

2

Data TLV

3

Interface Status TLV

4

Reply Ingress TLV

5

Reply Egress TLV

6

LTM Egress Identifier TLV

7

LTR Egress Identifier TLV

8

Reserved for IEEE 802.1

9 to 30

Organization-Specific TLV

31

Defined by ITU-T Y.1731

32 to 63

Reserved for IEEE 802.1

64 to 255

Not every TLV is applicable for all types of CFM PDUs.

  • TLVs applicable for continuity check message (CCM):

    • End TLV

    • Sender ID TLV

    • Port Status TLV

    • Interface Status TLV

    • Organization-Specific TLV

  • TLVs applicable for loopback message (LBM):

    • End TLV

    • Sender ID TLV

    • Data TLV

    • Organization-Specific TLV

  • TLVs applicable for loopback reply (LBR):

    • End TLV

    • Sender ID TLV

    • Data TLV

    • Organization-Specific TLV

  • TLVs applicable for linktrace message (LTM):

    • End TLV

    • LTM Egress Identifier TLV

    • Sender ID TLV

    • Organization-Specific TLV

  • TLVs applicable for linktrace reply (LTR):

    • End TLV

    • LTR Egress Identifier TLV

    • Reply Ingress TLV

    • Reply Egress TLV

    • Sender ID TLV

    • Organization-Specific TLV

The following TLVs are currently supported in the applicable CFM PDUs:

  • End TLV

  • Reply Ingress TLV

  • Reply Egress TLV

  • LTR Egress Identifier TLV

  • LTM Egress Identifier TLV

  • Data TLV

Support for Additional Optional TLVs

The following additional optional TLVs are supported:

  • Port Status TLV

  • Interface Status TLV

MX Series routers support configuration of port status TLV and interface status TLV. Configuring the Port Status TLV allows the operator to control the transmission of the Port Status TLV in CFM PDUs.

Note:

Although Port Status TLV configuration statements are visible in the CLI on M120 and M320 routers, Port Status TLV cannot be configured on these systems. Port Status TLV can be enabled on a MEP interface only if it is a bridge logical interface, which is not possible on these systems.

For configuration information, see the following sections:

Port Status TLV

The Port Status TLV indicates the ability of the bridge port on which the transmitting MEP resides to pass ordinary data, regardless of the status of the MAC. The value of this TLV is driven by the MEP variable enableRmepDefect, as shown in Table 4. The format of this TLV is shown in Table 3.

Any change in the Port Status TLVs value triggers one extra transmission of that bridge ports MEP CCMs.

Table 3: Port Status TLV Format

Parameter

Octet (Sequence)

Type = 2

1

Length

2–3

Value (See Table 4)

4

Table 4: Port Status TLV Values

Mnemonic

Ordinary Data Passing Freely Through the Port

Value

psBlocked

No: enableRmepDefect = false

1

psUp

Yes: enableRmepDefect = true

2

The MEP variable enableRmepDefect is a boolean variable indicating whether frames on the service instance monitored by the maintenance associations if this MEP are enabled to pass through this bridge port by the Spanning Tree Protocol and VLAN topology management. It is set to TRUE if:

  • The bridge port is set in a state where the traffic can pass through it.

  • The bridge port is running multiple instances of the spanning tree.

  • The MEP interface is not associated with a bridging domain.

Configuring Port Status TLV

Junos OS provides configuration support for the Port Status TLV, allowing you to control the transmission of this TLV in CCM PDUs. The Junos OS provides this configuration at the continuity-check level. By default, the CCM does not include the Port Status TLV. To configure the Port Status TLV, use the port-status-tlv statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] hierarchy level.

Note:

Port Status TLV configuration is not mandated by IEEE 802.1ag. The Junos OS provides it in order to give more flexibility to the operator; however it receives and processes CCMs with a Port Status TLV, regardless of this configuration.

An example of the configuration statements follows:

You cannot enable Port Status TLV transmission in the following two cases:

  • If the MEP interface under the maintenance-association is not of type bridge.

  • If the MEP is configured on a physical interface.

Displaying the Received Port Status TLV

The Junos OS saves the last received Port Status TLV from a remote MEP. If the received Port Status value does not correspond to one of the standard values listed in Table 4, then the show command displays it as "unknown." You can display the last saved received Port Status TLV 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:

Displaying the Transmitted Port Status TLV

The Junos OS saves the last transmitted Port Status TLV from a local MEP. If the transmission of the Port Status TLV has not been enabled, then the show command displays "none." You can display the last saved transmitted Port Status TLV 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:

Interface Status TLV

The Interface Status TLV indicates the status of the interface on which the MEP transmitting the CCM is configured, or the next-lower interface in the IETF RFC 2863 IF-MIB. The format of this TLV is shown in Table 5. The enumerated values are shown in Table 6.

Table 5: Interface Status TLV Format

Parameter

Octet (Sequence)

Type = 4

1

Length

2–3

Value (See Table 6)

4

Table 6: Interface Status TLV Values

Mnemonic

Interface Status

Value

isUp

up

1

isDown

down

2

isTesting

testing

3

isUnknown

unknown

4

isDormant

dormant

5

isNotPresent

notPresent

6

isLowerLayerDown

lowerLayerDown

7

Note:

When the operational status of a logical interface changes from the down state (status value of 2) to the lower layer down state (status value of 7) and vice versa, the LinkDown SNMP trap is not generated. For example, if you configure an aggregated Ethernet interface bundle with a VLAN tag and add a physical interface that is in the operationally down state to the bundle, the operational status of the aggregated Ethernet logical interface bundle at that point is lower layer down (7). If you take the MIC associated with the interface offline, the LinkDown trap is not generated when the logical interface shifts from the lower layer down state to the down state.

Similarly, consider another sample scenario in which an physical interface is added to an aggregated Ethernet bundle that has VLAN tagging and the aggregated Ethernet logical interface is disabled. When the logical interface is disabled, the operational status of the logical interface changes to down. If you disable the physical interface that is part of the aggregated Ethernet bundle, the operational status of the aggregated Ethernet logical interface remains down. If you reenable the aggregated Ethernet logical interface, the operational status of it changes from down to lower layer down. The LinkDown SNMP trap is not generated at this point.

Configuring Interface Status TLV

The Junos OS provides configuration support for the Interface Status TLV, thereby allowing operators to control the transmission of this TLV in CCM PDUs through configuration at the continuity-check level.

Note:

This configuration is not mandated by IEEE 802.1ag; rather it is provided to give more flexibility to the operator. The Junos OS receives and processes CCMs with the Interface Status TLV, regardless of this configuration.

The interface status TLV configuration is shown below:

Note:

The Junos OS supports transmission of only three out of seven possible values for the Interface Status TLV. The supported values are 1, 2, and 7. However, the Junos OS is capable of receiving any value for the Interface Status TLV.

Displaying the Received Interface Status TLV

The Junos OS saves the last received Interface Status TLV from the remote MEP. If the received Interface Status value does not correspond to one of the standard values listed in Table 5, then the show command displays "unknown."

You can display this last saved Interface Status TLV 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:

Displaying the Transmitted Interface Status TLV

The Junos OS saves the last transmitted Interface Status TLV from a local MEP. If the transmission of Interface Status TLV has not been enabled, then the show command displays "none."

You can display the last transmitted Interface Status TLV 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:

MAC Status Defects

The Junos OS provides MAC status defect information, indicating that one or more of the remote MEPs is reporting a failure in its Port Status TLV or Interface Status TLV. It indicates “yes” if either some remote MEP is reporting that its interface is not isUp (for example, at least one remote MEPs interface is unavailable), or if all remote MEPs are reporting a Port Status TLV that contains some value other than psUp (for example, all remote MEPs Bridge Ports are not forwarding data). There are two show commands you can use to view the MAC Status Defects indication.

Use the mep-database command to display MAC status defects:

Use the interfaces command to display MAC status defects:

Configuring Remote MEP Action Profile Support

Based on values of interface-status-tlv and port-status-tlv in the received CCM packets, a specific action, such as interface-down, can be taken using the action-profile options. Multiple action profiles can be configured on the router, but only one action profile can be assigned to a remote MEP.

The action profile can be configured with at least one event to trigger the action; but the action will be triggered if any one of these events occurs. It is not necessary for all of the configured events to occur to trigger action.

An action-profile can be applied only at the remote MEP level.

The following example shows an action profile configuration with explanatory comments added:

Monitoring a Remote MEP Action Profile

You can use the show oam ethernet connectivity-fault-management mep-database command to view the action profile status of a remote MEP, as in the following example:

show oam ethernet connectivity-fault- management mep-database remote-mep (Action Profile Event)

Configuring Chassis ID TLV

In Release 16.1R2 and later, you can configure Junos OS to send the sender ID TLV along with the packets. The sender ID TLV is an optional TLV that is sent in continuity check messages (CCMs), loopback messages, and Link Trace Messages (LTMs), as specified in the IEEE 802.1ag standard. The sender ID TLV contains the chassis ID, which is the unique, CFM-based MAC address of the device, and the management IP address, which is an IPv4 or an IPv6 address.

The value of the length field in the TLV indicates whether or not the TLV contains the chassis ID information. The possible values for the length field are zero (0) or any valid number, which indicates the absence or presence of chassis ID information in the TLV, respectively.

You can enable Junos OS to send the sender ID TLV at the global level by using the set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv command. If the sender ID TLV is configured at the global level, then the default maintenance domain, maintenance association, and the maintenance association intermediate point (MIP) half function inherit this configuration.

You can also configure the sender ID TLV at the following hierarchy levels:

  • [edit protocols oam ethernet connectivity-fault-management].

  • [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check].

The sender ID TLV configuration at the maintenance-association level takes precedence over the global-level configuration.

Note:

The sender ID TLV is supported only for 802.1ag PDUs and is not supported for performance monitoring protocol data units (PDUs).

Configuring MAC Flush Message Processing in CET Mode

In carrier Ethernet transport (CET) mode, MX Series routers are used as provider edge (PE) routers, and Nokia Siemens Networks A2200 Carrier Ethernet Switches (referred to as E-domain devices) that run standard-based protocols are used in the access side. On the MX Series routers, VPLS pseudowires are configured dynamically through label distribution protocol (LDP). On the E-domain devices, topology changes are detected through connectivity fault management (CFM) sessions running between the E-domain devices and the MX Series PE routers. The MX Series PE routers can bring the carrier Ethernet interface down if there is CFM connectivity loss. This triggers a local MAC flush as well as a targeted label distribution protocol (T-LDP) MAC flush notification that gets sent towards the remote MX Series PEs to trigger MAC flush on them.

In CET inter-op mode, MX Series routers need to interoperate with the Nokia Siemens Networks Ax100 Carrier Ethernet access devices (referred to as A-domain devices) that run legacy protocols. Nokia Siemens Networks A4100 and A8100 devices act as an intermediate between the MX Series PE routers and A-domain devices. These intermediate devices perform interworking function (IWF) procedures so that operations administration management (OAM) sessions can be run between MX Series routers and A-domain devices. There are no VPLS pseudowires between the MX Series PE routers and the Nokia Siemens Networks A4100 and A8100 intermediate devices, so there is no LDP protocol running between the PE routers to send topology change notifications. In order to communicate topology changes, MX Series routers can trigger a MAC flush and propagate it in the core. MX Series routers can use action profiles based upon the connection protection type length value (TLV) event. The action profile brings down the carrier edge logical interface in MX Series PE routers, which will trigger a local MAC flush and also propagate the topology change to the core using LDP notification.

For VPLS there is no end-to-end connectivity monitored. The access rings are independently monitored by running CFM down multiple end points (MEPs) on the working and protection paths for each of the services between the E-domain devices and the MX Series PE routers, and between the A-domain devices and the MX Series PE routers the IWF hosted by the Nokia Siemens Networks A-4100 devices. When there is a connectivity failure on the working path, the Nokia Siemens Networks Ax200 devices perform a switchover to the protection path, triggering a topology change notification (in the form of TLVs carried in CCM) to be sent on the active path.

Figure 1: CET inter-op Dual Homed TopologyCET inter-op Dual Homed Topology

Figure 1 describes the dual homed topology on MX Series PE routers connected to the A-domain. When an A-domain device triggers a switchover, it starts switching the service traffic to the new active path. This change is communicated in the HELLO protocol data units (PDUs) sent by that A-domain device on the working and protection paths. When the IWF in A4100 recieves these HELLO PDUs, it converts them to standard CCM messages and also inserts a connection protection TLV. The “Protection-in-use” field of the connection protection TLV is encoded with the currently active path, and is included in the CCM message. CCM messages are received by the MX Series PE routers through the VLAN spoke in A4100. In the above dual homed scenario, one MX Series PE router monitors the working path, and the other MX Series PE router monitors the protection path.

A MAC flush occurs when the CFM session that is monitoring the working path detects that the service traffic has moved to the protection path or when the CFM session that is monitoring the protection path detects that the service traffic has moved to the working path.

Figure 2: CET inter-op Dual Attached TopologyCET inter-op Dual Attached Topology

Figure 2 describes the dual attached topology on MX Series PE routers connected to the A-domain. The MAC flush mechanism used in this case is also the same as the one used for the A-domain in the dual homed scenario (Figure 1). However in this case both the CFM sessions are hosted by only one MX Series PE router. When Ax100 in the A-domain detects topology changes, the MX Series PE router receives the connection protection TLV in the CCM message for the working and protection paths with the value of “Protection-in-use” indicating which path is the active one. Based upon the event that is generated for the CFM session, the MX Series PE router will bring down the appropriate interface which will trigger a local MAC flush.

Configuring a Connection Protection TLV Action Profile

An action profile can be configured to perform the interface-down action based on the values of connection-protection-tlv in the received CCM packets.

The following example shows an action profile configuration with explanatory comments added:

Example: Configuring an Action Profile Based on Connection Protection TLVs

This example shows how to configure an action profile based on the connection protection TLV for the purposes of triggering MAC flushes based on topology changes in a CET network.

Requirements

This example uses the following hardware and software components:

  • Junos OS Release 11.2 or later

  • A MX series PE router

Overview and Topology

The physical topology of a CET network using MX series PE routers is shown in Figure 3

Topology

Figure 3: Topology of CET networkTopology of CET network

The following definitions describe the meaning of the device abbreviation and terms used in Figure 3.

  • Provider edge (PE) device—A device, or set of devices, at the edge of the provider network that presents the provider's view of the customer site.

  • E-domain—Nokia Siemens Networks Carrier Ethernet Switches that run standard based protocols and are used in the access side.

  • A-domain—Nokia Siemens Networks Carrier Ethernet Switches that run legacy protocols.

Configuration

Procedure

Step-by-Step Procedure

To configure an action profile based on the connection protection TLV, preform these tasks:

  1. Configure an action profile

  2. If the connection protection TLV is received with a “Protection-in-use” value of SET, then the connection protection TLV should use the protection path

  3. If the connection protection TLV is received with a “Protection-in-use” value of RESET, then the connection protection TLV should use the working path

  4. Configure the action profile to bring the interface down

Results

Check the results of the configuration

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.3R1
Starting in Junos OS Release 17.3R1, you can enable connectivity fault management (CFM) monitoring between provider edge devices and customer edge devices when the customer edge device is not a Juniper device by using the remote defect indication (RDI) bit.
16.1
In Release 16.1R2 and later, you can configure Junos OS to send the sender ID TLV along with the packets.