Knowledge Search


[BTI] Eservice remote MEP cannot be learned on PacketVX

  [KB34726] Show Article Properties


In some cases, the Remote MEP (Maintenance Entity Group End Point) for an eService may not be learned correctly, causing the eService to show "Operational State is down".  This does not necessarily mean traffic is down, since the Remote MEP is only used for monitoring and is not needed to pass traffic. In this article, we will introduce the possible reasons that cause this issue and how to solve it.

When Eservices are established end-to-end on BTI PacketVX, monitoring is provided utilizing the Ethernet Service OAM mechanisms defined in ITU-T Recommendation Y.1731 and IEEE 802.1ag. These protocols use CFM (Connectivity Fault Management) which sends CCMs (Continuity Check Messages) to monitor the connectivity of Eservices. The CCMs non-intrusively monitor end-to-end connectivity. If connectivity is lost, determined by the loss of three consecutive CCM messages, the system reports an eservice as down.  

Automatic discovery enables the UNI to transmit the CFM CCMs periodically that announce the identity of the MEP. It also enables the UNIs to track the CCMs received from other remote MEPs. CFM adds the newly discovered remote MEP ID to the MEP list. Thus, CFM can discover the number of end points in an Eservice.


Each MEG has a unique MEG ID (that uniquely identifies the Ethernet service in the network). The MEG ID consists of the Unique MEG Code (UMC) and the ITU Carrier Code (ICC). In BTI 7000 Series equipment, the UMC is configured as the MEG name, and the ICC is configured as the ME name. The MEG name must be configured on a switch and the ME name must be configured on an Ethernet service before MEPs can be configured. By default, the MEG name is "BTI", and the ME name is "v" appended by the S-VLAN ID for the service. The MEG level provides a hierarchical relationship that parallels the structure of customer, service provider, and operator. By default, the MEG level on BTI7000 switches is 4.

When creating Ethernet services with PacketVX end to end, as both  MEG ID and MEG level are consistent at end points by default, the eservice can learn the remote MEP correctly. However, if the Ethernet service is created with another vendor's device with different MEG ID or MEG level, the remote MEP cannot be learned correctly.

Suppose that an EPLINE service has been built between BTI 7000 and a third vendor's device which has different MEG ID (UMC code "AAA" + ICC "BBB") and MEG level 3 at remote end.

Check the near end BTI7000 PacketVX eservice status with command "show eservice ". The output shows that the operation state is down and no remote MEP is listed:

Then check the UNI-to-Ethernet service associations with command "show uni-eservice eservices uni" and we can see the Remote MEP ID has been learned with defects due to the MEG level and MEG ID mismatch.

To fix the issue, modify both MEG ID and level to be consistent at both ends. In this example, we modify the MEG attribute at BTI7000 node.

The MEG ID and Level is configured under the virtual switches. If there is any Ethernet Services configured under the switch, it is not allowed to be modified. 

BTI7000-A:sw1(config)# cfm meg AAA level 3
% Valid EService exists, changing MEG name or MEG level not allowed.

To modify the MEG ID and MEG level, it is needed  to remove the Ethernet services from the virtual switch first:

BTI7000-A:sw1(config)# eservice evc01
BTI7000-A:sw1(config-eservice)# no uni gig 1/3/1
SW: 1, E-Service: evc01, UNI GigE 1/3/1 deleted.
BTI7000-A:sw1(config-eservice)# exit
BTI7000-A:sw1(config)# no eservice evc01
SW: 1, E-Service: evc01 deleted.
BTI7000-A:sw1(config)# cfm meg AAA level 3

The MEG UMC code and MEG level is configured under the virtual switch. Checking the virtual switch and the MEG UMC and Level has been updated:


After the MEG UMC code (MEG name) and MEG level is modified, reconfigure the Eservice again with correct MEG ICC code (ME name)

BTI7000-A:sw1(config)# eservice evc01 type epline
SW: 1, E-Service: evc01 created.
BTI7000-A:sw1(config-eservice)# s-vlan 100
BTI7000-A:sw1(config-eservice)# cfm me BBB
BTI7000-A:sw1(config-eservice)# uni gig 1/3/1
SW: 1, E-Service: evc01, UNI GigE 1/3/1 created.
BTI7000-A:sw1(config-uni-eservice)# exit

After modifying the MEG ID and level, check the eservice status. Now the Operation state is up and the remote MEP has been learned successfully which can be displayed in the MEP list.

In summary, to ensure remote MEP is learned correctly via CFM, the MEG ID and Level must match at the end points. Modify either end and make sure they are consistent. For BTI7000, to change the MEG ID and MEG level, note the following restrictions:
  1. MEG ICC code (ME name) is configured under Ethernet service EVC. To change the ME name, remove the UNI interface from the EVC first. After changing the ME name, add the UNI interface back to the EVC again.
  2. MEG UMC code (MEG name) and MEG Level is configured under virtual switch. If either of them need to be modified, all of the current Ethernet Service need to be removed first. After changing the MEG name and level, reconfigure all Ethernet services back. 
  3. When configuring the Ethernet service with CLI, the ME name is configured as is "v" appended by the S-VLAN ID for the service. Ethernet service created by ProNX service manager (PSM), the ME name is configured with several "v" appended by the S-VLAN of the service to make sure the ICC code is 6 characters length. For example,  if the s-vlan is 100, then ME name is "vvv100" and if S-VLAN id is 1000, then ME name is "vv1000". It is common to see that some of the Eservices are created via PSM first and then customer reconfigured the Ethernet services via CLI  at some end points which caused the ME name mismatch and Remote MEP cannot be learned.
Related Links: