MEPs

MEP description

The MEPs are configured at the edge of an MD and perform the following functions:

• periodically send CFM continuity check messages

• validate CFM PDU replies

• discard CFM PDU messages that are not in the MEP configuration

• initiate and respond to CFM test messages

MEPs can be added to services automatically or manually. When a MEP is assigned to a service manually, it associates its MEG with a single site on the service. When a MEP is assigned to a service automatically, it associates its MEG with all sites on the service. MEPs which are generated automatically can inherit test generation options from the SAP or service site. See To configure an Ethernet CFM MD policy and subordinate objects for more information.

You can configure an initial MEP ID for automatic MEP ID assignment on an NE.

You can also add MEPs to services during Ethernet CFM test configuration from the Service Topology map. See Working with Ethernet CFM objects in Chapter 4, Topology map management for more information.

Each MEP is assigned an up or down direction. An up MEP is provisioned on an ingress port, and monitors the forwarding path inside a bridge NE to the egress port. A down MEP is provisioned on an egress port, and monitors the forwarding path between bridge NEs.

You can assign roles to managed MEPs and unmanaged remote MEPs during OAM test suite configuration. A MEP can be designated as a hub or spoke, and as a test source, a test target, or both. Assigning roles to MEPs in test suites can reduce the total number of automatic tests generated. See To configure an Ethernet CFM MD policy and subordinate objects .

MEPs can inherit their roles from the SAP or service site. You can propagate test generation role settings to all unmanaged remote and managed MEPs on a SAP or service site using the Propagate to MEPs button on the ETH-CFM tab of the Access Interface (Edit) and Site (Edit) forms.

MEP association

An up MEP can be associated with the following object types:

• Epipe and VPLS SAPs

• Epipe spoke SDP bindings

• VPLS mesh and spoke SDP bindings

• VPLS and MVPLS B-sites, as virtual MEPs

• B-L2 access interfaces

• OmniSwitch VLAN SAPs

A down MEP can be associated with the following object types:

• Epipe, Ipipe, IES, VPLS, and VPRN SAPs

• Epipe and IES spoke SDP bindings

• VPLS mesh and spoke SDP bindings

• B-L2 access interfaces

• MVPLS access interfaces

• OmniSwitch VLAN SAPs

• Network interfaces

• Ports

• LAGs

Virtual MEPs

A virtual MEP is an up MEP that is created on a VPLS site when a CFM continuity check test is run. Each virtual MEP transmits a CFM continuity check stream on all SAPs and SDPs of the site. A virtual MEP uses the site MAC address, if configured; otherwise, it uses the shelf MAC address. See Chapter 77, VPLS management for information about assigning virtual MEPs to a VPLS.

The following rules apply to virtual MEP management:

• One virtual MEP can be configured on a VPLS or MVPLS B-site.

• All regular MEPs on SAPs and SDP bindings in the same MEG as a virtual MEP must be configured as up MEPs.

• Regular MEPs in the same MEG and on the same B-site as a virtual MEP cannot be enabled when the virtual MEP is enabled.

• Virtual MEPs can be created in a MEG only when MIP creation in the MEG is disabled.

Facility MEP

A facility MEP is a MEP that is down and is created on a router interface, network interface, port, or LAG. A facility MEP detects failure conditions for an Ethernet transport network using ETH-CCM or AIS and, where appropriate, propagates alarm conditions so that the services that share this common transport are aware of the failure.

A virtual tunnel facility MEP is created by configuring a LAG MEP or a port MEP with a VLAN ID. In this instance the VLAN ID must match the outer encapsulation value of the SAP that is associated with the Tunnel MEP.

The following rules apply to facility MEP management:

• Only one facility MEP can be configured on a port, a LAG, or a network interface.

• A facility MEP can be configured on a port only if the MD level is 0.

• A facility MEP must be configured in the down direction.

• A facility MEP ID must be unique within the same device.

• Port facility MEPs are supported on ports in access, hybrid, or network mode with dot1q encapsulation, and on ports in access or hybrid mode with Q in Q encapsulation.

• Port facility MEPs cannot be configured on network elements that support Ethernet tunnels.

• Tunnel facility MEPs are supported on LAG ports configured with Q in Q encapsulation in access or hybrid mode.

• Tunnel facility MEPs must have a lower MD level than any service MEPs that are created on the same LAG.

• A tunnel facility MEP VLAN ID must be unique within the same port.

• Tunnel facility MEPs cannot be configured on LAGs with a VLAN ID of 0.

• Tunnel port facility MEPs cannot be configured on LAG members.

• Fast facility MEPs, which are MEPs with a CCM interval of 10 ms or 100 ms, cannot be configured when CCM padding is enabled.

• There must be 2 facility MEPs in a MEG subgroup to execute a CCM test.

Unicast MEPs

The following rules apply to Unicast MEP management:

• When a CCM test is executed, the NFM-P will deploy remote MEPs (with unicast-da) to spokes for NEs that support unicast CCM.

• MEG sub-groups will ignore Unicast remote MEP lists when discovering MEG sub-groups and only use the hub remote MEPs list.

• Remote MEPs configured as unicast will update the appropriate Unicast Hub MEP’s Operational MAC Address. If an appropriate Unicast Hub MEP cannot be found, the remote MEPs will auto-create an unmanaged remote MEP with the Unicast Hub’s target pointer set.

• An unmanaged remote MEP without a MAC Address configured cannot be used as a Unicast Hub.

• Hub MEPs should be configured with remote lists that target all regular (non-unicast) MEPs and only the unicast MEPs that point to the hub. This allows a mixture of unicast and regular MEPs for CCM testing.

• You can use a multi-selection of MEPs to set a Unicast Hub MEP pointer.

• A MEP cannot point to itself as a Hub.

• A MEP cannot point to a Hub on the same site.

• If a MEG site has more than one MEP, the NFM-P sets all the MEPs to have the same Hub pointer.

• The remote MEP list of a Hub will not include spokes that do no point to it.

• When listing available Hubs, the NFM-P will also list unmanaged remote MEPs that have a MAC address from the same sub-group.

• When the NFM-P discovers a remote MEP it manages that has an appropriate MAC address, it will update the hub pointer.

• When the managed MEPs point to a hub, then regardless of what other remote MEPs or unmanaged remote MEPs are deployed, NFM-P will only deploy the hub’s MEP ID with the Operational MAC Address. No other MEP IDs will be deployed.

• No local MEP is allowed when there is a remote MEP with a MAC address.

• No remote MAC address is allowed if multiple remote MEPs exist.

• If a MEP with a hub pointer exists on a MEG site, NFM-P will auto-populate the hub pointer when a new MEP is create

• When you create a remote MEP with a MAC address, the NFM-P creates an unmanaged remote MEP. This unmanaged remote MEP will be in the same sub-group as the spoke.

• Where MC-LAG redundant MEPs exist, the hub will point to the active one.