2.8. Configuring Global Service Entities with CLI

This section provides information to create subscriber (customer) accounts using the command line interface.

2.9. Service Model Entities

The Nokia service model uses logical entities to construct a service. The service model contains four main entities to configure a service.

2.10. Basic Configuration

The most basic service configuration must have the following:

A customer ID
A service type
A service ID
A SAP identifying a port and encapsulation value
An associated SDP for distributed services in the network mode. The SDPs are not supported on the access uplink mode.

The following is a sample Epipe service configuration output displaying the SDP and Epipe service entities. SDP ID 1 was created with the far-end node 10.20.1.2. Epipe ID 101 was created for customer ID 1 which uses the SDP ID 1.

A:ALA-7210M>config>service#

------------------------------------------

...

sdp 1 mpls create

description "Default sdp description"

far-end 10.20.1.2

lsp "lsp_1_to_B"

signaling tldp

no vlan-vc-etype

path-mtu 9194

no adv-mtu-override

keep-alive

shutdown

hello-time 10

hold-down-time 10

max-drop-count 3

timeout 5

no message-length

exit

no collect-stats

no accounting-policy

no shutdown

exit

...

epipe 101 customer 1 vpn 101 create

description "Default epipe description for service id 101"

service-mtu 9194

sap lag-2:101 create

description "Default sap description for service id 101"

no tod-suite

dot1ag

exit

ingress

qos 1

no filter

exit

spoke-sdp 101:101 vc-type ether create

no vlan-vc-tag

ingress

no vc-label

exit

egress

no vc-label

exit

no control-word

no

dot1ag

mep 1 domain 5 association 101 direction down

ccm-enable

no ccm-ltm-priority

low-priority-defect remErrXcon

no mac-address

no shutdown

exit

mep 1 domain 6 association 101 direction down

ccm-enable

no ccm-ltm-priority

low-priority-defect remErrXcon

no mac-address

no shutdown

exit

no collect-stats

no accounting-policy

no precedence

no shutdown

exit

no shutdown

...

------------------------------------------

A:ALA-7210M>config>service#

2.11. Common Configuration Tasks

This section provides a brief overview of the tasks that must be performed to configure a customer account and an SDP.

2.11.1. Configuring Customers

The most basic customer account must have a customer ID. Optional parameters include:

Description
Contact name
Telephone number

2.11.1.1. Customer Information

Use the following syntax to create and input customer information.

CLI Syntax:

config>service# customer customer-id create

contact contact-information

description description-string

phone phone-number

The following is a sample basic customer account configuration output.

A:ALA-12>config>service# info

-------------------------------------------

...

customer 5 create

description "Nokia Customer"

contact "Technical Support"

phone "650 555-5100"

exit

...

-------------------------------------------

A:A:ALA-12>config>service#

2.11.2. Configuring an SDP

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

The most basic SDP must have the following:

A locally unique SDP identification (ID) number.
The system IP address of the far-end routers.
An SDP encapsulation type, MPLS.

2.11.2.1. SDP Configuration Tasks

This section provides a brief overview of the tasks that must be performed to configure SDPs and provides the CLI commands.

Consider the following SDP characteristics:

SDPs can be created as MPLS.
Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, and VPRN services.
A distributed service must be bound to an SDP. By default, no SDP is associated with a service. When an SDP is created, services can be associated to that SDP.
An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than one service bound to it.
The SDP IP address must be a 7210 SAS-Series system IP address.
To configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created.
In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a TLDP connection between two 7210 SAS-Series routers.
Note that if signaling is disabled for an SDP, then services using that SDP must configure ingress and egress vc-labels manually.

To configure a basic SDP, perform the following steps:

Specify an originating node.
Create an SDP ID.
Specify an encapsulation type.
Specify a far-end node.

2.11.2.2. Configuring an SDP

Use the following syntax to create an SDP and select an encapsulation type. Only MPLS encapsulation is supported.

Note:

When you specify the far-end ip address, you are creating the tunnel. In essence, you are creating the path from Point A to Point B. When you configure a distributed service, you must identify an SDP ID. Use the show service sdp command to display the qualifying SDPs.

When specifying MPLS SDP parameters, you must specify an LSP. If an LSP name is specified, then RSVP is used for dynamic signaling within the LSP.

LSPs are configured in the config>router>mpls context. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S MPLS Guide for configuration and command information.

Use the following syntax to create an MPLS SDP.

CLI Syntax:

config>service>sdp sdp-id [mpls] create

adv-mtu-override

description description-string

far-end ip-address

keep-alive

hello-time seconds

hold-down-time seconds

max-drop-count count

message-length octets

timeout timeout

no shutdown

lsp lsp-name [lsp-name](only for MPLS SDPs)

path-mtu octets

signaling {off | tldp}

no shutdown

The following is a sample LSP-signaled MPLS SDP configuration output.

A:ALA-12>config>service# info

-------------------------------------------

...

sdp 8 mpls create

description "MPLS-10.10.10.104"

far-end 10.10.10.104

lsp "to-104"

keep-alive

mixed-lsp-mode

revert-time 1

shutdown

exit

no shutdown

exit

...

-----------------------------------------

A:ALA-12>config>service#

2.11.2.3. Configuring a Mixed-LSP SDP

The following shows the command usage to configure an SDP with mixed-LSP mode of operation.

config>service>sdp mpls>mixed-lsp-mode

The primary is backed up by the secondary. Two combinations are possible: primary of RSVP is backed up by LDP and primary of LDP is backed up by 3107 BGP.

The no form of this command disables the mixed-LSP mode of operation. The user first has to remove one of the LSP types from the SDP configuration or the command will fail.

The user can also configure how long the service manager must wait before it reverts the SDP to a higher priority LSP type, when it becomes available by using the following command.

config>service>sdp mpls>mixed-lsp-mode>revert-time revert-time

A special value of the timer dictates that the SDP must never revert to another higher priority LSP type unless the currently active LSP type is down:

config>service>sdp mpls>mixed-lsp-mode>revert-time infinite

The BGP LSP type is allowed. The bgp-tunnel command can be configured under the SDP with the lsp or ldp commands.

2.12. Ethernet Connectivity Fault Management

Ethernet Connectivity Fault Management (ETH-CFM) is defined in two similar standards: IEEE 802.1ag and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects to support transport fault management, including discovery and verification of the path, detection and isolation of a connectivity fault for each Ethernet service instance.

ETH-CFM configuration is split into multiple CLI contexts. The ETH-CFM configuration, which defines the different management constructs and administrative elements, is performed in the eth-cfm context. The individual management points are configured within the specific service contexts in which they are applied (port, SAP, and so on).

Refer to the 7210 SAS-M, T, Mxp, Sx, S Services Guide for detailed information about the basic service applicable material to build the service specific management points, MEPs, and MIPs. The different service types support a subset of the features from the complete ETH-CFM suite.

ETH-CC used for continuity is available to all MEPs configured within a service. 7210 SAS devices support Down MEPs and UP MEPs, though the support is not available on all platforms. See Table 11, Table 12, Table 13, Table 14, Table 15, Table 16, and Table 17for more information about platform support follows.

Note:

UP MEPs cannot be created by default on system bootup. The user needs to explicitly allocate hardware resources for use with UP MEP feature, using the commands that appear under the configure>system>resource-profile CLI context. Only after resources have been allocated by the user, UP MEPs are allowed to be created. Until resources are not allocated to UP MEP, the software fails all attempts to create an UP MEP.

The troubleshooting tools ETH-LBM, ETH-LBR, LTM ETH-TST, and LTR ETH-TST defined by the IEEE 802.1ag specification and the ITU-T Y.1731 recommendation are applicable to all MEPs (and MIPs where appropriate).The advanced notification function, Alarm Indication Signal (AIS), defined by the ITU-T Y.1731 is supported on Epipe services.

The advanced performance functions, 1DM, DMM/DMR, and SLM/SLR are supported on all service MEPs.

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S OAM and Diagnostics Guide for a description of the individual features and functions that are supported.

Table 9 lists ETH-CFM acronym expansions.

Table 9: ETH-CFM Acronym Expansions

Acronym	Expansions
1DM	One way Delay Measurement (Y.1731)
AIS	Alarm Indication Signal
CCM	Continuity Check Message
CFM	Connectivity Fault Management
DMM	Delay Measurement Message (Y.1731)
DMR	Delay Measurement Reply (Y.1731)
LBM	Loopback Message
LBR	Loopback Reply
LTM	Linktrace Message
LTR	Linktrace Reply
ME	Maintenance Entity
MA	Maintenance Association
MA-ID	Maintenance Association Identifier
MD	Maintenance Domain
MEP	Maintenance Association Endpoint
MEP-ID	Maintenance Association Endpoint Identifier
MHF	MIP Half Function
MIP	Maintenance Domain Intermediate Point
OpCode	Operational Code
RDI	Remote Defect Indication
TST	Ethernet Test (Y.1731)
SLM	Synthetic Loss Message (Y.1731)
SLR	Synthetic Loss Reply (Y.1731)

2.12.1. MA, MEP, MIP and MD Levels

ETH-CFM capabilities may be deployed in many different Ethernet service architectures. The Ethernet based SAPs and SDP bindings provide the endpoint on which the management points may be created. The basic functions can be used in different services, VPLS and Epipe. Figure 13 and Figure 14 show two possible example scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.

Figure 13: Ethernet OAM Model for Ethernet Access - Business

Figure 14: Ethernet OAM Model for Ethernet Access - Wholesale

The following functions are supported.

CFM can be enabled or disabled on a SAP or SDP bindings basis.
The eight ETH-CFM levels are suggested to be broken up numerically between customer 7-5, service provider 4-3 and Operator 2-1. Level 0 typically is meant to monitor direct connections without any MIPs and should be reserved for port-based G8032 MEPs.
Down MEP and UP MEP with an MEP-ID on a SAP/SDP binding for each MD level can be configured, modified, or deleted. Each MEP is uniquely identified by the MA-ID, MEP-ID tuple.
1. MEP creation on a SAP is allowed only for Ethernet ports (with null, q-tags, qinq encapsulations).
2. MEP support in different service and the endpoints configured in the service (SAPs, SDPs, IP interfaces, etc.) varies across service and 7210 SAS platforms. Table 10 lists the support available for MEP on different 7210 SAS platforms.
MIP creation on a SAP for each MD level can be enabled and disabled. MIP creation is automatic or manual when it is enabled. When MIP creation is disabled for an MD level, the existing MIP is removed. 7210 SAS platforms have the notion of ingress and egress MIPs. Ingress MIP responds to OAM messages that is received from the wire. Egress MIP responds to OAM messages that is being sent out to the wire. Ingress and Egress MIP support for SAP, SDP Bindings and services varies and is listed in Table 10. For more information about MEP and MIP support, see MEP and MIP Support

2.12.1.1. Common Actionable Failures

It is important to note that AIS operates independently from the low-priority-defect setting. The low-priority-defect setting configuration parameter affects only the ETH-CFM fault propagation and alarming outside the scope of AIS. Any fault in the MEP state machine generates AIS when it is configured. Table 10 describes the ETH-CC defect condition groups, configured low-priority-defect setting, priority and defect as it applies to fault propagation.

Table 10: Defect conditions and priority settings

Defect	Low Priority Defect	Description	Causes	Priority
DefNone	n/a	No faults in the association	Normal operations	n/a
DefRDICCM	allDef	Remote Defect Indication	Feedback mechanism to inform unidirectional faults exist. It provides the feedback loop to the node with the unidirectional failure conditions	1
DefMACStatus (default)	macRemErrXcon	MAC Layer	Remote MEP is indicating a remote port or interface not operational.	2
DefRemoteCCM	remErrXon	No communication from remote peer.	MEP is not receiving CCM from a configured peer. The timeout of CCM occurs at 3.5x the local CC interval. As per the specification, this value is not configurable.	3
DefErrorCCM	errXcon	Remote and local configures do not match required parameters.	Caused by different interval timer, domain level issues (lower value arriving at a MEP configured with a higher value), MEP receiving CCM with its MEPID	4
DefXconn	Xcon	Cross Connected Service	The service is receiving CCM packets from a different association. This could indicate that two services have merged or there is a configuration error on one of the SAP or bindings of the service, incorrect association identification.	5

2.12.1.2. MEP and MIP Support

Table 11, Table 12, Table 13, Table 14, Table 15, Table 16, and Table 17 are general tables that indicate the ETH-CFM support for the different services and endpoints. It is not meant to indicate the services that are supported or the requirements for those services on the individual platforms.

Table 11: ETH-CFM Support Matrix for 7210 SAS-M Network Mode

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
Epipe	SDP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP	Yes	Yes	Ingress MIP only	Not Supported
	Spoke-SDP	Yes	Yes	Ingress MIP only	Not Supported
	Mesh-SDP	Yes	Yes	Not supported	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
PBB Epipe	I-SAP	Not Supported	Yes	Not Supported	Not Supported
PBB VPLS	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB B-VPLS	B-SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not Supported	Not Supported
VPRN	SAP	Not Supported	Not Supported	Not Supported	Not Supported

Table 12: ETH-CFM Support Matrix for 7210 SAS-M Access-Uplink Mode

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP (Access and Access-uplink SAP)	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP (Access and Access-uplink SAP)	Yes	Yes	Only Ingress MIP on VPLS in MTU-A	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not supported	Not Supported

Table 13: ETH-CFM Support Matrix for 7210 SAS-T Access-Uplink Mode

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP (Access and Access-uplink SAP)	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP (Access and Access-uplink SAP)	Yes	Yes	Ingress MIP only	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not supported	Not Supported

Table 14: ETH-CFM Support Matrix for 7210 SAS-T Network Mode

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP	Yes	Yes	Ingress MIP and Egress MIP	Yes (only on Down MEP)
Epipe	SDP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP	Yes	Yes	Ingress MIP only	Yes (only on Down MEP)
	Spoke-SDP	Yes	Yes	Ingress MIP only	Not Supported
	Mesh-SDP	Yes	Yes	Not supported	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
PBB Epipe	I-SAP	Not Supported	Yes	Not Supported	Not Supported
PBB VPLS	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB B-VPLS	B-SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not Supported	Not Supported
VPRN	SAP	Not Supported	Not Supported	Not Supported	Not Supported

Table 15: ETH-CFM Support Matrix for 7210 SAS-Mxp devices

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP	Yes	Yes	Ingress MIP and Egress MIP	Yes (only on Down MEP)
Epipe	SDP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP	Yes	Yes	Ingress MIP	Yes (only on Down MEP)
	Spoke-SDP	Yes	Yes	Ingress MIP	Not Supported
	Mesh-SDP	Yes	Yes	Not Supported	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
PBB Epipe	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB VPLS	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB B-VPLS	B-SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not Supported	Not Supported
VPRN	SAP	Not Supported	Not Supported	Not Supported	Not Supported

Table 16: ETH-CFM Support Matrix for 7210 SAS-Sx/S 1/10GE devices

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP	Yes	Yes	Ingress MIP and Egress MIP	Yes (only on Down MEP)
Epipe	SDP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP	Yes	Yes	Ingress MIP only	Yes (only on Down MEP)
	Spoke-SDP	Yes	Yes	Ingress MIP only	Not Supported
	Mesh-SDP	Yes	Yes	Not supported	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
PBB Epipe	I-SAP	Not Supported	Yes	Not Supported	Not Supported
PBB VPLS	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB B-VPLS	B-SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not Supported	Not Supported
VPRN	SAP	Not Supported	Not Supported	Not Supported	Not Supported

Table 17: ETH-CFM Support Matrix for 7210 SAS-Sx 10/100GE devices

Service	Ethernet Connection Type	Down MEP	UP MEP	MIP	Primary VLAN
Epipe	SAP	Yes	Yes	Ingress MIP and Egress MIP	Yes (only on Down MEP)
Epipe	SDP	Yes	Yes	Ingress MIP and Egress MIP	Not Supported
VPLS	SAP	Yes	Yes	Ingress MIP only	Yes (only on Down MEP)
	Spoke-SDP	Yes	Yes	Ingress MIP only	Not Supported
	Mesh-SDP	Yes	Yes	Not supported	Not Supported
RVPLS	SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	IES IPv4 interface	Not Supported	Not Supported	Not Supported	Not Supported
PBB Epipe	I-SAP	Not Supported	Yes	Not Supported	Not Supported
PBB VPLS	I-SAP	Not Supported	Not Supported	Not Supported	Not Supported
PBB B-VPLS	B-SAP	Not Supported	Not Supported	Not Supported	Not Supported
IES	SAP	Not Supported	Not Supported	Not Supported	Not Supported
VPRN	SAP	Not Supported	Not Supported	Not Supported	Not Supported

Note:

Ethernet rings cannot be configured under all service types. Any service restrictions for MEP direction or MIP support will override the generic capability of the Ethernet ring MPs. For more information about Ethernet rings, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide.
Some services only support ingress MIP functionality. An ingress MIP or a Down MIP processes messages in the ingress direction when the OAM message is received on ingress of the SAP/port (subject to the other checks). An egress MIP or an UP MIP refers to a MIP that processes message in the egress direction when the OAM message is being sent out of the SAP/port. For more information about service entities that support ingress MIP, egress MIP, or both, see Table 11, Table 12, Table 13, Table 14, Table 15, Table 16, and Table 17.
On 7210 SAS platforms, when two bidirectional MIPs are configured in an Epipe service on both the service entities/endpoints (for example, on both the SAP and the SDP configured in the Epipe service), only the MIP ingressing to the direction of linktrace messages responds. This is applicable to 7210 SAS platforms that support both ingress and egress MIPs (also referred to as bidirectional MIPs).

2.12.2. Configuring ETH-CFM Parameters

Configuring ETH-CFM requires commands at two different hierarchy levels of the CLI.

A sample of the global ETH-CFM configuration which defines the domains, associations, linkage o the service id or function, and the globally applicable CCM parameters including the interval and building of the remote MEPs database is shown as follows.

The following is a sample configuration output.

*A:ALU-7_A>config>eth-cfm# info

----------------------------------------------

domain 1 name "1" level 1

association 2 name "1345"

bridge-identifier 100

exit

ccm-interval 60

remote-mepid 2

remote-mepid 3

exit

----------------------------------------------

*A:ALU-7_A>config>eth-cfm#

Defining the MEP and configuring service specific ETH-CFM parameters is performed within the service on the specific SAP or SDP binding. The following is sample output using the service VPLS 100 on the SAP.

#*A:ALU-7_A>config>service# info

----------------------------------------------

vpls 100 customer 1 create

description "VPLS service 100 - Used for MEP configuration example"

sap 2/2/1:20 create

description "2/2/1:20"

eth-cfm

mep 1 domain 1 association 1 direction down

no shutdown

exit

no shutdown

exit

customer 1 create

description "Default customer"

exit

----------------------------------------------

*A:ALU-7_A>config>service#

All of the previous examples were based on IEEE 802.1ag. They are not capable of running Y.1731 functions. To build a Y.1731 context the domain format must be none.

The following are sample global ETH-CFM configuration outputs and the advanced Y.1731 functions that can be configured. The configuration will reject the configuration of Y.1731 functions within an IEEE 802.1ag context.

*A:7210-2# config>eth-cfm# info

----------------------------------------------

domain 1 format none level 1

association 1 format icc-based name "1234567890123"

bridge-identifier 100

exit

ccm-interval 1

exit

*A:7210-2# config>service# info

----------------------------------------------

vpls 100 customer 1 create

stp

shutdown

exit

sap 2/2/1:40 create

eth-cfm

mep 1 domain 1 association 1 direction up

ais-enable

priority 2

interval 60

exit

eth-test-enable

test-pattern all-ones crc-enable

exit

no shutdown

exit

no shutdown

exit

----------------------------------------------

Notes:

Note:

To transmit and receive AIS PDUs, Y.1731 MEPs must have ais-enable configured.
To transmit and receive ETH-Test PDUs, Y.1731 MEPs must have eth-test-enable configured.

2.12.3. Applying ETH-CFM Parameters

Use the following syntax to apply ETH-CFM parameters to the following entities.

CLI Syntax:

config>service>epipe>sap

eth-cfm

mep mep-id domain md-index association ma-index [direction

{up | down}]

ais-enable

client-meg-level [[level [level ...]]

interval {1 | 60}

priority priority-value

ccm-enable

ccm-ltm-priority priority

eth-test-enable

test-pattern {all-zeros | all-ones} [crc-enable]

low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}

[no] shutdown

CLI Syntax:

config>service>epipe>spoke-sdp

eth-cfm

mep mep-id domain md-index association ma-index [direction

{up | down}]

ccm-enable

ccm-ltm-priority priority

eth-test-enable

test-pattern {all-zeros | all-ones} [crc-enable]

low-priority-defect {allDef|macRemErrXcon|remErrXcon|

errXcon|xcon|noXcon}

[no] shutdown

CLI Syntax:

config>service>vpls>sap

eth-cfm

mip

mep mep-id domain md-index association ma-index [direction {up | down}]

no mep mep-id domain md-index association ma-index

ccm-enable

ccm-ltm-priority priority

eth-test-enable

test-pattern {all-zeros | all-ones} [crc-enable]

low-priority-defect {allDef|macRemErrXcon|remErrXcon|errXcon|xcon|noXcon}

mac-address mac-address

[no] shutdown

CLI Syntax:

config>service>vpls>mesh-sdp sdp-id[:vc-id] [vc-type {ether|vlan}]

eth-cfm

mep mep-id domain md-index association ma-index [direction

{up | down}]

ccm-enable

ccm-ltm-priority priority

eth-test-enable

test-pattern {all-zeros | all-ones} [crc-enable]

low-priority-defect {allDef|macRemErrXcon|remErrXcon|

errXcon|xcon|noXcon}

mac-address mac-address

no] shutdown

CLI Syntax:

config>service>vpls

spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] [no-endpoint]

spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] endpoint endpoint

eth-cfm

map mep-id domain md-index association ma-index [direction

{up | down}]

ccm-enable

ccm-ltm-priority priority

eth-test-enable

test-pattern {all-zeros | all-ones} [crc-enable]

low-priority-defect {allDef | macRemErrXcon|remErrXcon|errXcon|xcon|noXcon}

mac-address mac-address

no] shutdown

CLI Syntax:

oam

eth-cfm linktrace mac-address mep mep-id domain md-index association ma-index [ttl ttl-value]

eth-cfm loopback mac-address mep mep-id domain md-index association ma-index [send-count send-count] [size data-size] [priority priority]

eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]

eth-cfm one-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]

eth-cfm two-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]

eth-cfm two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority priority]

2.13. Layer 2 Control Processing (L2CP)

Operators providing Epipe service need to be able to transparently forward Layer 2 control frames received from the customers. This allows their customers to run these control protocols between the different locations which are part of the Layer 2 VPN service. The 7210 SAS platforms provide user with the following capability:

An option to tunnel, discard or peer for EFM OAM, LLDP, Dot1x, and LACP.
BPDU translation and Layer 2 Protocol Tunneling support for xSTP and CISCO control protocols. This is supported only in a VPLS service. For more information, see L2PT and BPDU Translation.

Note:

The CDP, VTP, DTP, PAgP, and UDLD management protocols, are forwarded transparently in an Epipe service.

By default, LACP, LLDP, EFM OAM, and Dot1x Layer 2 control protocol untagged packets are discarded if the protocol is not enabled on the port where these frames are received. User has an option to enable peering by enabling the protocol on the port and configuring the appropriate parameters for the protocol. User also has an option to tunnel these packets using an Epipe or VPLS service.

In a VPLS service, the Layer 2 control frames are sent out of all the SAPs configured in the VPLS service. It is recommended to use this feature carefully and only when an VPLS is used to emulate an end-to-end Epipe service (that is, an Epipe configured using a 3-point VPLS Service, with one access SAP and 2 access-uplink SAP/SDPs for redundant connectivity). That is, if the VPLS service is used for multipoint connectivity, it is not recommended to use this feature. When a Layer 2 control frame is forwarded out of dot1q SAP or a QinQ SAP, the SAP tags of the egress SAP are added to the packet.

The following SAPs can be configured for tunneling the untagged L2CP frames (corresponding protocol tunneling needs to be enabled on the port):

If the port encapsulation is null, user has an option to tunnel these packets by configuring a NULL SAP on a port
If the port encapsulation is dot1q, user an option to use dot1q explicit null SAP (e.g. 1/1/10:0) or a dot1q default SAP (For example: 1/1/11:*) to tunnel these packets.
If the port encapsulation is QinQ, user has an option to use 0.* SAP (For example 1/1/10:0.*) to tunnel these packets.

In addition to the protocols listed previously, protocols that are not supported on 7210, For example: GARP, GVRP, ELMI, and others are transparently forwarded in case of a VPLS service. These protocols are transparently forwarded if a NULL SAP, dot1q default SAP, dot1q explicit null SAP or 0.* SAP is configured on the port and received packet is untagged. If the received packet is tagged and matches the tag of any of the SAPs configured on the port, it is forwarded in the context of the SAP and the service. Else if the received packet is untagged and none of the NULL or dot1q default or dot1q explicit null or 0.* SAP is configured, it is discarded.

If a 7210 receives a tagged L2CP packet on any SAP (includes NULL, dot1q, dot1q range, QinQ, QinQ default), it is forwarded transparently in the service similar to normal service traffic (xSTP processing behavior is different in VPLS service and is listed as follows).

The xSTP processing behavior in a VPLS service is as follows:

If xSTP is enabled in the service, and if the tag in the STP BPDU matches the tag of the configured SAP, the received xSTP BPDU is processed by the local xSTP instance on the node for that service when xSTP is enabled on the SAP and discarded when xSTP is disabled on the SAP.
If the tags do not match, xSTP BPDU packets are transparently forwarded in the service similar to normal service traffic.

If xSTP is disabled in the service, STP BPDU packets are transparently forwarded in the service similar to normal service traffic

Table 18 describes L2CP support for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Mxp access-uplink and network media platforms.

Table 18: L2CP support for 7210 SAS-M,7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE and 7210 SAS-Mxp access-uplink and network mode platforms

Packet Type	7210 SAS-M	7210 SAS-T	7210 SAS-Mxp	7210 SAS-Sx/S 1/10GE	7210 SAS-Sx 10/100GE
LACP	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer
Dot1x	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer
LLDP	Option to Tunnel or Discard or Peer 1	Option to Tunnel or Discard or Peer 1	Option to Tunnel or Discard or Peer 1	Option to Tunnel or Discard or Peer 1	Option to Tunnel or Discard or Peer 1
EFM	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer	Option to Tunnel or Discard or Peer
L2PT	Supported 2	Supported 2	Supported 2	Supported 2	Supported 2
BPDU Tunneling	Supported	Supported	Supported	Supported	Supported
xSTP	Option to Peer or Tunnel	Option to Peer or Tunnel	Option to Peer or Tunnel	Option to Peer or Tunnel	Option to Peer or Tunnel

Notes:

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for more information about options available for LLDP tunneling.
L2TP support on 7210 SAS platforms varies among the platforms. Not all platforms support tunneling of all CISCO protocols. For more information, see “L2PT and BPDU Translation”.

2.14. Service Management Tasks

This section describes the service management tasks.

2.14.1. Modifying Customer Accounts

To access a specific customer account, you must specify the customer ID.

Use the following syntax to display a list of customer IDs.

Enter the parameter (description, contact, phone) and then enter the new information.

CLI Syntax:

config>service# customer customer-id create

[no] contact contact-information

[no] description description-string

[no] phone phone-number

Example:

config>service# customer 27 create

config>service>customer$ description “Western Division”

config>service>customer# contact “John Dough”

config>service>customer# no phone “(650) 237-5102”

2.14.2. Deleting Customers

The no form of the customer command removes a customer ID and all associated information. All service references to the customer must be shut down and deleted before a customer account can be deleted.

CLI Syntax:

config>service# no customer customer-id

Example:

config>service# epipe 5 customer 27 shutdown

config>service# epipe 9 customer 27 shutdown

config>service# no epipe 5

config>service# no epipe 9

config>service# no customer 27

2.14.3. Modifying SDPs

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

To access a specific SDP, you must specify the SDP ID. To display a list of SDPs, use the show service sdp command. Enter the parameter, such as description, far-end, and lsp, and then enter the new information.

Note:

Once an SDP is created, the SDP encapsulation type cannot be modified.

CLI Syntax:

config>service# sdp sdp-id

Example:

config>service# sdp 79

config>service>sdp# description “Path-to-107”

config>service>sdp# shutdown

config>service>sdp# far-end “10.10.10.107”

config>service>sdp# path-mtu 1503

config>service>sdp# no shutdown

2.14.4. Deleting SDPs

The no form of the sdp command removes an SDP ID and all associated information. Before an SDP can be deleted, the SDP must be shutdown and removed (unbound) from all customer services where it is applied.

CLI Syntax:

config>service# no sdp 79

Example:

config>service# epipe 5 spoke-sdp 79:5

config>service>epipe>sdp# shutdown

config>service>epipe>sdp# exit

config>service>epipe# exit

config>service# no sdp 79