2.7. Configuring global service entities with CLI

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

2.8. 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.9. Basic configuration

The most basic service configuration must have the following:

The following is a sample Epipe service configuration output showing 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.

2.10. 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.10.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:

1. a locally unique SDP identification (ID) number
2. the system IP address of the far-end routers
3. an SDP encapsulation type, MPLS

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

1. SDPs can be created as MPLS.
2. Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, and VPRN services.
3. 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.
4. 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.
5. The SDP IP address must be a 7210 SAS-series system IP address.
6. To configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created.
7. 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.
   If signaling is disabled for an SDP, services using that SDP must configure ingress and egress VC labels manually.

To configure a basic SDP, perform the following steps:

1. Specify an originating node.
2. Create an SDP ID.
3. Specify an encapsulation type.
4. Specify a far-end node.

2.10.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, RSVP is used for dynamic signaling within the LSP.

LSPs are configured in the config>router>mpls context. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T 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.10.2.3. Configuring a mixed-LSP SDP

The following is 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: the primary of RSVP is backed up by LDP and the 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

An infinite value for 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.11. 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-Mxp, S, Sx, T 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.

Ethernet continuity check (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. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information.

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-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for a description of the individual features and functions that are supported and configuration guidelines applicable to CFM entities on the 7210 SAS.

The following table lists ETH-CFM acronym expansions.

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

1. CFM can be enabled or disabled on a SAP or SDP bindings basis.
2. 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.
3. 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 services and the endpoints configured in the services (SAPs, SDPs, IP interfaces, and so on) varies across services and 7210 SAS platforms.
4. 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 are received. Egress MIP responds to OAM messages that are sent. Ingress and egress MIP support for SAP, SDP bindings, and services varies and is listed in Table 10. See MEP and MIP support for more information about MEP and MIP support.

2.11.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. The following table 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 that 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 that a remote port or interface is 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.5 times the local CC interval. As per the specification, this value is not configurable.	3
DefErrorCCM	errXcon	Remote and local configurations 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 SAPs or bindings of the service, incorrect association identification.	5

2.11.1.2. MEP and MIP support

Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM support for different services and endpoints.

2.11.2. Configuring ETH-CFM parameters

Note: Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM configuration guidelines for 7210 SAS platforms.

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

This section provides a sample of the global ETH-CFM configuration, which defines the domains, associations, linkage of the service ID or function, and the globally applicable CCM parameters, including the interval and building of the remote MEPs database.

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

        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

                    exit

               exit

          exit

          no shutdown

          exit

          customer 1 create

               description "Default customer"

          exit

          exit

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

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

The preceding samples 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

        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

                exit

            exit

            no shutdown

        exit

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

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. Layer 2 control processing

Operators providing the Epipe service must 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 that are part of the Layer 2 VPN service. The 7210 SAS platforms provide the user with the following capability:

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. The user has an option to enable peering by enabling the protocol on the port and configuring the appropriate parameters for the protocol. The 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. Nokia recommends using this feature carefully and only when a VPLS is used to emulate an end-to-end Epipe service (that is, an Epipe configured using a three-point VPLS service, with one access SAP and two access-uplink SAPs or 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 a 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):

In addition to the protocols listed previously, protocols that are not supported on the 7210 SAS (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 the 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. Otherwise, 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 (including 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:

2.13. Service management tasks

This section describes the service management tasks.

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