2.7. Configuring Global Service Entities with CLI
This section provides information to create subscriber (customer) accounts using the command line interface.
2.7.1. 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.8. Basic Configuration
The most basic service configuration must have the following:
- customer ID
- service type
- service ID
- SAP identifying a port and encapsulation value
- associated SDP for distributed services in the network mode
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.9. Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure a customer account.
2.9.1. Configuring Customer Accounts
The most basic customer account must have a customer ID. Optional parameters include:
- description
- contact name
- telephone number
2.9.1.1. Customer Information
Use the following syntax to create and input customer information.
The following is a sample basic customer account configuration output.
2.9.2. Configuring an SDP
The most basic SDP must have the following:
- locally unique SDP identification (ID) number
- system IP address of the far-end routers
- SDP encapsulation type, MPLS
2.9.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, 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.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:
- Specify an originating node.
- Create an SDP ID.
- Specify an encapsulation type.
- Specify a far-end node.
2.9.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; 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-M, T, R6, R12, Mxp, Sx, S MPLS Guide for configuration and command information.
Use the following syntax to create an MPLS SDP.
The following is a sample LSP-signaled MPLS SDP configuration output.
2.9.2.3. Configuring a Mixed-LSP SDP
Use the following command 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.10. 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.
The configuration is split into multiple CLI contexts. There is the base ETH-CFM configuration that defines the different management constructs and administrative elements. This configuration 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-R6, R12 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. The 7210 SAS devices support Down MEPs and Up MEPs, though the support is not available on all platforms. See Table 9 and Table 10 for more information about platform support.
| Note: Up MEPs cannot be created by default on system bootup. The user needs to explicitly allocate hardware resources for use with the Up MEP feature, using the commands in the configure>system>resource-profile context. Up MEPs can be created only after resources have been allocated to Up MEP by the user. The software fails to create an Up MEP until resources are allocated. |
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 more information about the individual features and functions that are supported.
Table 7 lists ETH-CFM acronym expansions.
Table 7: ETH-CFM Acronym Expansions
Acronym | Expansion |
1DM | One-way Delay Measurement (Y.1731) |
AIS | Alarm Indication Signal |
BNM | Bandwidth Notification Message (Y.1731 sub OpCode of GMN) |
CCM | Continuity Check Message |
CFM | Connectivity Fault Management |
DMM | Delay Measurement Message (Y.1731) |
DMR | Delay Measurement Reply (Y.1731) |
GMN | Generic Message Notification |
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) |
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 12 and Figure 13 show two possible example scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.
Figure 12: Ethernet OAM Model for Ethernet Access - Business
Figure 13: 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 to 5, service provider 4 to 3 and operator 2 to 1. Level 0 typically is meant to monitor direct connections without any MIPs and should be reserved for port-based G8032 MEPs or facility MEPs. Facility MEPs are not supported on the 7210 SAS. It is mentioned here only for completeness. G8032 MEPs are supported on the 7210 SAS. These can be configured, deleted or modified.
- 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.
- MEP creation on a SAP is only allowed for Ethernet ports (with null, q-tags, QinQ encapsulations).
- MEP support in different services and the endpoints configured in the services (SAPs, SDPs, IP interfaces, and so on) varies across services and 7210 platforms. The following table lists the support available for MEP on different 7210 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. The 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 the following table. For more information, see MEP and MIP Support.
2.10.1. Common Actionable Failures
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 8 describes the ETH-CC defect condition groups, configured low-priority-defect setting, priority, and defect as it applies to fault propagation.
Table 8: 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.10.2. MEP and MIP Support
Table 9 is a general table that indicates 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 9: ETH-CFM Support Matrix for 7210 SAS-R6 and 7210 SAS-R12 Devices
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP | ✓ | ✓ | ✓ | ✓ | ✓ 1 |
SDP | ✓ | ✓ | ✓ | ✓ | ||
VPLS | SAP | ✓ | ✓ 2 | ✓ 3 | ✓ 4 | ✓ 5 |
Spoke-SDP | ✓ | ✓ 2 | ✓ | |||
Mesh-SDP | ✓ 2 | |||||
R-VPLS | SAP | |||||
IES | IES IPv4 interface | |||||
PBB Epipe | I-SAP | |||||
PBB VPLS | I-SAP | |||||
PBB B-VPLS | B-SAP | |||||
IES | SAP | |||||
VPRN | SAP | |||||
- Supported for Down MEP only.
- Supported for IMMv2 only.
- IMMv1 supports ingress MIP only.
- IMMv2 supports both ingress MIP and egress MIP. IMMv1 does not support egress MIP.
- Supported only for Down MEP and MIP.
Notes:
| Note:
|
2.10.3. Configuring ETH-CFM Parameters
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.
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 a sample service VPLS 100 showing this configuration output on the SAP.
All of the preceding 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.
| Note:
|
2.10.4. Applying ETH-CFM Parameters
Use the following syntax to apply ETH-CFM parameters to the following entities.
2.11. Service Management Tasks
This section describes the service management tasks.
2.11.1. Modifying Customer Accounts
To access a specific customer account, you must specify the customer ID. To display a list of customer IDs, use the show service customer command. Enter the parameter (description, contact, phone), then enter the new information.
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.11.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.
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.11.3. Modifying SDPs
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, then enter the new information.
| Note: After it is created, you cannot modify the SDP encapsulation type. |
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.11.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.
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
2.12. Layer 2 Control Processing
Operators providing Epipe service need to be able to transparently forward Layer 2 Control Processing (L2CP) 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:
- 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 L2CP 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 SAP/SDPs for redundant connectivity). That is, if the VPLS service is used for multipoint connectivity, Nokia does not recommend using 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):
- If the port encapsulation is null, the user has an option to tunnel these packets by configuring a null SAP on a port.
- If the port encapsulation is dot1q, the user has an option to use dot1q explicit null SAP (for example, 1/1/10:0) or a dot1q default SAP (for example, 1/1/11:*) to tunnel these packets.
- If the port encapsulation is QinQ, the user has an option to use 0.* SAP (for example, 1/1/10:0.*) to tunnel these packets.
In addition to the preceding list of protocols, 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 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:
- 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 10 describes L2CP support for the 7210 SAS-R6 and 7210 SAS-R12.
Table 10: L2CP Support for 7210 SAS-R6 and 7210 SAS-R12
Packet Type | 7210 SAS-R6 and 7210 SAS-R12 |
LACP | Option to tunnel or discard or peer |
Dot1x | Option to tunnel or discard or peer |
LLDP | Option to tunnel or discard or peer 1 |
EFM | Option to tunnel or discard or peer |
L2TP | Supported 2 |
BPDU Tunneling | Supported |
xSTP | Option to peer or tunnel |
- 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 depending on the platforms. Not all platforms support tunneling of all CISCO protocols. For more information, see L2PT and BPDU Translation.
Notes: