NE40E-M2H and NE40E-M2K V800R011C00 Configuration Guide - WAN Access 01

HUAWEI NE40E-M2 Series Universal Service
Router
V800R011C00
Configuration Guide - WAN Access
Issue 01
Date 2019-04-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. i

HUAWEI NE40E-M2 Series Universal Service Router
Configuration Guide - WAN Access Contents
Contents
1 About This Document.................................................................................................................. 1

2 Serial Interface Configuration.................................................................................................... 5
2.1 Overview of Serial Interfaces......................................................................................................................................... 5
2.2 Configuring a Serial Interface........................................................................................................................................ 6
2.2.1 Configuring the Link Layer Protocol for a Serial Interface........................................................................................ 6
2.2.2 Configuring the MTU for a Serial Interface................................................................................................................ 7
2.2.3 Enabling the Payload Scramble Function on a Serial Interface.................................................................................. 8
2.2.4 Verifying the Serial Interface Configuration............................................................................................................... 9
3 POS Interface Configuration.....................................................................................................10

3.1 Overview...................................................................................................................................................................... 10
3.2 Configuring a POS Interface........................................................................................................................................ 14
3.2.1 Configuring the Link Layer Protocol for a POS Interface........................................................................................ 14
3.2.2 Configuring the Clock Mode for a POS Interface..................................................................................................... 15
3.2.3 Configuring Overhead Bytes for a POS Interface..................................................................................................... 15
3.2.4 Configuring the Frame Format for a POS Interface.................................................................................................. 16
3.2.5 Configuring the Scrambling Function for a POS Interface....................................................................................... 17
3.2.6 Configuring the Length of the CRC Code for a POS Interface.................................................................................17
3.2.7 Configuring the MTU for a POS Interface................................................................................................................ 18
3.2.8 Configuring the Loopback Function for a POS Interface..........................................................................................19
3.2.9 Switching the Working Rate of a POS Subcard........................................................................................................ 20
3.2.10 Verifying the POS Interface Configuration............................................................................................................. 21
3.3 Configuring a POS-Trunk Interface............................................................................................................................. 21
3.3.1 Creating a POS-Trunk Interface................................................................................................................................ 21
3.3.2 Adding a POS Interface to a POS-Trunk Interface....................................................................................................22
3.3.3 Verifying the POS-Trunk Interface Configuration.................................................................................................... 22
3.4 Configuration Examples for POS Interfaces................................................................................................................ 22
3.4.1 Example for Directly Connecting Devices Through POS Interfaces........................................................................ 23
3.4.2 Example for Connecting Devices with POS Interfaces Through an FR Network.................................................... 25
4 E-Carrier Interface Configuration............................................................................................ 28

4.1 Overview of E-Carrier Interfaces................................................................................................................................. 28
4.2 Configuring a E1 Interface........................................................................................................................................... 30
4.2.1 Configuring the Working Mode for an E1 Interface................................................................................................. 30
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. ii

4.2.2 Configuring the Clock Mode for a CE1 Interface..................................................................................................... 32

4.2.3 Configuring the Frame Format for a CE1 Interface.................................................................................................. 32
4.2.4 Configuring the Loopback Function for an E1 Interface...........................................................................................33
4.2.5 Configuring ES-TCA Alarm Thresholds on a CE1 Interface....................................................................................34
4.2.6 Verifying the CE1 Interface Configuration................................................................................................................34
4.3 Configuring an E3 Interface......................................................................................................................................... 35
4.3.1 Creating a Synchronous Serial Interface on an E3 Interface.....................................................................................35
4.3.2 Configuring Loopback on an E3 Interface................................................................................................................ 36
4.3.3 Configuring a Clock Mode for an E3 Interface......................................................................................................... 37
4.3.4 Verifying the E3 Interface Configuration.................................................................................................................. 38
4.4 Maintaining E-Carrier Interface Configuration............................................................................................................ 38
4.4.1 Testing the Bit Error Rate of a CE1 Interface............................................................................................................38
4.5 Configuration Examples for E-carrier Interfaces......................................................................................................... 38
4.5.1 Example for Configuring E1 Interface Interconnection............................................................................................ 38
4.5.2 Configuring CE1 Interface Interconnection.............................................................................................................. 41
5 CPOS Interface Configuration..................................................................................................44

5.1 Overview of CPOS Interfaces...................................................................................................................................... 44
5.2 Configuring a CPOS Interface......................................................................................................................................51
5.2.1 Configuring the Working Mode of a CPOS Interface............................................................................................... 51
5.2.2 Configuring the Clock Mode for a CPOS Interface.................................................................................................. 52
5.2.3 Configuring the Working Modes for the E1 Channels of a CPOS Interface.............................................................53
5.2.4 Configuring Overhead Bytes for a CPOS Interface.................................................................................................. 54
5.2.5 Configuring the Mapping Mode for the E1 Channels of a CPOS Interface..............................................................55
5.2.6 Configuring the Clock Mode for the E1 Channels of a CPOS Interface...................................................................56
5.2.7 Configuring the Frame Format for the E1 Channels of a CPOS Interface................................................................57
5.2.8 Configuring the Loopback Function for the E1 Channels of a CPOS Interface....................................................... 57
5.2.9 Configuring the Loopback Function for a CPOS Interface....................................................................................... 58
5.2.10 Verifying the CPOS Interface Configuration...........................................................................................................59
5.3 Configuring a CPOS-Trunk Interface...........................................................................................................................59
5.3.1 Creating a CPOS-Trunk Interface..............................................................................................................................59
5.3.2 Configuring the Working Mode of a CPOS-Trunk Interface.................................................................................... 60
5.3.3 Configuring a Working Mode for an E1 Channel of a CPOS-Trunk Interface......................................................... 61
5.3.4 Creating a Global MP-Group or IMA-Group Interface and Adding a Trunk Serial Interface to It.......................... 62
5.3.5 Creating a Global MP-Group or IMA-Group Interface and Adding a Trunk Serial Interface to It.......................... 64
5.3.6 Verifying the CPOS-Trunk Interface Configuration..................................................................................................65
5.4 Maintaining a CPOS Interface......................................................................................................................................66
5.4.1 Testing the Bit Error Rate of a CPOS E1 Link..........................................................................................................66
5.4.2 Clearing Error Statistics and Alarm Status Information on an E1 Interface or on a CPOS Interface's E1 Channels
............................................................................................................................................................................................ 66
5.4.3 Monitoring the Physical Status of E1 Links.............................................................................................................. 67
5.5 Configuration Examples for CPOS Interfaces..............................................................................................................67
5.5.1 Example for Configuring CPOS Interfaces............................................................................................................... 67
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. iii

5.5.2 Example for Configuring CPOS Interface Interconnection.......................................................................................70

5.5.3 Example for Configuring CPOS Interface and E1 Interface Interconnection........................................................... 73
6 FR Configuration......................................................................................................................... 77
6.1 Overview of FR............................................................................................................................................................ 77
6.1.1 Introduction............................................................................................................................................................... 77
6.2 Configuring Basic FR Functions.................................................................................................................................. 80
6.2.1 Configuring Basic FR Functions on a DCE.............................................................................................................. 80
6.2.2 Configuring Basic FR Functions on a DTE...............................................................................................................82
6.2.3 Verifying the Basic FR Function Configuration........................................................................................................83
6.3 Configuration Examples for FR................................................................................................................................... 83
6.3.1 Example for Connecting LANs Through VCs.......................................................................................................... 83
7 HDLC and IP-Trunk Configurations.......................................................................................87

7.1 Overview...................................................................................................................................................................... 87
7.2 Configuring HDLC Functions...................................................................................................................................... 88
7.2.1 Configuring HDLC as the Link Layer Protocol of an Interface................................................................................88
7.2.2 Assigning an IP Address to an Interface................................................................................................................... 89
7.2.3 (Optional) Configuring HDLC Link Status Monitoring............................................................................................89
7.2.4 (Optional) Configuring HDLC Link Dampening Function.......................................................................................91
7.2.5 Verifying the HDLC Function Configuration............................................................................................................92
7.3 Configuring an IP-Trunk Interface............................................................................................................................... 92
7.3.1 Creating an IP-Trunk Interface and Adding Interfaces to the IP-Trunk Interface.....................................................93
7.3.2 Assigning an IP Address to an IP-Trunk Interface.................................................................................................... 94
7.3.3 (Optional) Configuring the Lower Threshold of Up Links....................................................................................... 95
7.3.4 (Optional) Setting the Lower Limit for an IP-Trunk Interface's Bandwidth............................................................. 95
7.3.5 (Optional) Configuring the Load Balancing Mode for an IP-Trunk Interface.......................................................... 96
7.3.6 (Optional) Configuring the Weight for a Member Link............................................................................................ 96
7.3.7 (Optional) Configuring the Method of Sending Trap Messages from an IP-Trunk Member Interface.................... 97
7.3.8 Verifying the IP-Trunk Interface Configuration........................................................................................................ 97
7.4 Maintaining HDLC and IP-Trunk.................................................................................................................................98
7.4.1 Deleting Statistics About HDLC or IP-Trunk Interfaces...........................................................................................98
7.5 Configuration Examples for HDLC and IP-Trunk....................................................................................................... 98
7.5.1 Example for Configuring Basic HDLC Functions.................................................................................................... 98
7.5.2 Example for Configuring IP Address Unnumbered................................................................................................ 100
7.5.3 Example for Configuring an IP-Trunk.....................................................................................................................103
8 PPP Configuration.....................................................................................................................107
8.1 Overview of PPP........................................................................................................................................................ 108
8.2 Configuring an Interface to Support PPP................................................................................................................... 108
8.2.1 Configuring PPP as the Link Layer Protocol of an Interface.................................................................................. 109
8.2.2 (Optional) Configuring PPP Negotiation Parameters..............................................................................................110
8.2.3 (Optional) Configuring PPP Link Status Monitoring.............................................................................................. 113
8.2.4 (Optional) Prohibiting a Local Device from Adding the Peer Host Route to the Local Routing Table of Direct
Routes............................................................................................................................................................................... 115
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. iv

8.2.5 (Optional) Configuring the PPP Link Dampening Function................................................................................... 116

8.2.6 Verifying the PPP Configuration............................................................................................................................. 116
8.3 Configuring Unidirectional CHAP Authentication.................................................................................................... 117
8.3.1 Configuring the Authenticator with a User Name to Authenticate Its Peer in CHAP Mode.................................. 118
8.3.2 Configuring the Authenticator Without a User Name to Authenticate Its Peer in CHAP Mode............................ 119
8.3.3 Verifying the Unidirectional CHAP Authentication Configuration........................................................................ 121
8.4 Configuring Unidirectional PAP Authentication........................................................................................................121
8.4.1 Configuring the Authenticator to Authenticate Its Peer in PAP Mode....................................................................122
8.4.2 Configuring the Supplicant to Be Authenticated in PAP Mode.............................................................................. 123
8.4.3 Verifying the Unidirectional PAP Authentication Configuration............................................................................ 123
8.5 Configuring MP.......................................................................................................................................................... 124
8.5.1 Configuring MP Implementations........................................................................................................................... 124
8.5.2 (Optional) Disabling Endpoint Discriminator Negotiation..................................................................................... 125
8.5.3 (Optional) Configuring the MRRU......................................................................................................................... 126
8.5.4 (Optional) Configuring the Short Sequence Number for Negotiation.....................................................................127
8.5.5 (Optional) Configuring MP Fragmentation............................................................................................................. 128
8.5.6 (Optional) Improving MP Link Reliability............................................................................................................. 129
8.5.7 Verifying the MP Configuration.............................................................................................................................. 130
8.6 Configuration Examples for PPP................................................................................................................................131
8.6.1 Example for Configuring PAP Authentication........................................................................................................ 131
8.6.2 Example for Configuring Unidirectional CHAP Authentication............................................................................ 133
8.6.3 Example for Configuring Bidirectional CHAP Authentication.............................................................................. 136
8.6.4 Example for Configuring MP Groups..................................................................................................................... 139
9 TDM Configuration.................................................................................................................. 144

9.1 Overview of TDM...................................................................................................................................................... 144
9.2 Licensing Requirements and Limitations for tdm--M2H.......................................................................................... 145
9.3 Licensing Requirements and Limitations for tdm--M2K.......................................................................................... 146
9.4 Configuring TDMoPSN............................................................................................................................................. 146
9.4.1 Configuring a Local TDMoPSN Service.................................................................................................................147
9.4.2 Configuring a Remote TDMoPSN Service............................................................................................................. 148
9.4.3 Configuring a Local CES Service........................................................................................................................... 150
9.4.4 Configuring a Remote CEP Service........................................................................................................................ 151
9.4.5 Verifying the TDM Service Configuration.............................................................................................................. 153
9.5 Configuring an IP-SDH Hybrid Network to Bear the CTS or GSM-R Service.........................................................153
9.5.1 Configuring Fast Alarm Detection.......................................................................................................................... 153
9.5.2 Configuring the Function to Send a Specific Bit Stream to Notify an Idle E1 Channel Timeslot.......................... 154
9.5.3 Configuring the Functions to Send Alarm Information on the Device Connected to an SNCP-Enabled SDH Device
.......................................................................................................................................................................................... 155
9.6 Configuration Examples for TDM............................................................................................................................. 155
9.6.1 Example for Configuring TDMoPSN......................................................................................................................155
9.6.2 Example for Configuring an IP-SDH Hybrid Network to Bear the CTS Service................................................... 161
9.6.3 Example for Configuring an IP-SDH Hybrid Network to Bear the GSM-R Service..............................................170
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. v

10 WDM Interface Configuration..............................................................................................181

10.1 Overview of WDM Interfaces.................................................................................................................................. 181
10.2 Configuring WDM Interfaces...................................................................................................................................185
10.2.1 Configuring Optical Parameters............................................................................................................................ 185
10.2.2 Configuring Service Parameters............................................................................................................................ 187
10.2.3 Configuring OTN Delay Measurement................................................................................................................. 188
10.2.4 Verifying the WDM Interface Configuration........................................................................................................ 189
11 ATM IMA Configuration.......................................................................................................190

11.1 Overview of ATM IMA............................................................................................................................................ 190
11.2 Licensing Requirements and Limitations for ATM IAM--M2H............................................................................. 191
11.3 Configuring an IMA Group to Transport ATM Services..........................................................................................191
11.3.1 Creating an IMA Group Interface and Adding an Interface to It.......................................................................... 192
11.3.2 (Optional) Configuring IMA Group Parameters................................................................................................... 193
11.3.3 Configuring a Service Type for a PVC.................................................................................................................. 195
11.3.4 (Optional) Configuring Continuity Check on ATM Services................................................................................196
11.3.5 Configuring the Alarm threshold of ATM Module................................................................................................197
11.3.6 Verifying the IMA Group Configuration............................................................................................................... 197
12 ATM Configuration................................................................................................................ 199

12.1 Overview of ATM.....................................................................................................................................................200
12.1.1 Introduction........................................................................................................................................................... 200
12.1.2 ATM Features Supported by the NE40E............................................................................................................... 200
12.2 Configuring ATM to Carry Upper-Layer Services................................................................................................... 201
12.2.1 Before You Start.................................................................................................................................................... 201
12.2.2 Configuring Basic PVC Functions........................................................................................................................ 202
12.2.3 (Optional) Configuring the Priority of an ATM PVC............................................................................................204
12.2.4 Verifying the ATM Configuration......................................................................................................................... 205
12.3 Configuring Parameters for an ATM OC-3/STM-1 Interface or an ATM OC-12/STM-4 Interface........................ 205
12.3.1 Before You Start.................................................................................................................................................... 205
12.3.2 Configuring the Frame Format on an Interface..................................................................................................... 206
12.3.3 Configuring the Overhead Byte on an Interface....................................................................................................207
12.3.4 Configuring the MTU of an Interface....................................................................................................................207
12.3.5 Configuring the Scrambling Function on an Interface.......................................................................................... 208
12.3.6 Configuring an Interval at Which Traffic Statistics Are Collected....................................................................... 209
12.3.7 Verifying the ATM Interface Parameter Configuration......................................................................................... 209
12.4 Configuring the Service Type and Optional Parameters for a PVC......................................................................... 210
12.4.1 Before You Start.................................................................................................................................................... 210
12.4.2 Configuring a Service Type for a PVC.................................................................................................................. 211
12.4.3 Configuring a Service Type for a PVP.................................................................................................................. 211
12.4.4 (Optional) Configuring the Overload Bandwidth for an ATM Interface...............................................................212
12.4.5 Verifying the Configuration...................................................................................................................................213
12.5 Configuring ATM OAM........................................................................................................................................... 213
12.5.1 Before You Start.................................................................................................................................................... 213
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. vi

12.5.2 (Optional) Activating the CC Function................................................................................................................. 214

12.5.3 (Optional) Configuring OAM End-to-End Loopback Detection...........................................................................215
12.5.4 (Optional) Configuring the Cell Loopback Function............................................................................................ 217
12.5.5 (Optional) Configuring a One-Click Test for ATM Services................................................................................ 217
12.5.6 Verifying the ATM OAM Configuration............................................................................................................... 218
12.6 Maintaining ATM..................................................................................................................................................... 218
12.6.1 Enabling Loopback to Check Interface Status.......................................................................................................218
12.6.2 Clearing ATM Interface Statistics......................................................................................................................... 219
12.7 Configuration Examples for ATM............................................................................................................................ 220
12.7.1 Example for Configuring the IPoA Service.......................................................................................................... 220
12.7.2 Example for Configuring ATM OAM................................................................................................................... 223
13 LMSP Configuration...............................................................................................................228
13.1 Introduction to LMSP............................................................................................................................................... 228
13.2 Licensing Requirements and Limitations for LMSP--M2H....................................................................................229
13.3 Licensing Requirements and Limitations for LMSP--M2K....................................................................................230
13.4 Licensing Requirements and Limitations for LMSP--M2K-B................................................................................230
13.5 Configuring Single-Chassis LMSP.......................................................................................................................... 231
13.5.1 Specifying a Working Interface and a Protection Interface for an LMSP Group..................................................232
13.5.2 Configuring a Working Mode for an LMSP Group...............................................................................................233
13.5.3 Adding Interfaces of an LMSP Group to a Trunk Interface.................................................................................. 235
13.5.4 Checking the Configurations................................................................................................................................. 236
13.6 Configuring MC-LMSP............................................................................................................................................236
13.6.1 Specifying a Working Interface and a Protection Interface for an LMSP Group..................................................237
13.6.2 Configuring a Working Mode for an LMSP Group...............................................................................................239
13.6.3 (Optional) Binding an LMSP Group to a BFD Session........................................................................................ 240
13.6.4 (Optional) Configuring MC-LMSP Negotiation and Authentication Parameters.................................................241
13.6.5 Adding Interfaces of an LMSP Group to a Trunk Interface.................................................................................. 243
13.6.6 Checking the Configurations................................................................................................................................. 244
13.7 Maintaining LMSP................................................................................................................................................... 244
13.7.1 Configuring a Command-Triggered Switching Mode for an LMSP Group..........................................................244
13.8 Configuration Examples........................................................................................................................................... 245
13.8.1 Example for Configuring TDM on the CPOS-TRUNK Configured with LMSP................................................. 245
13.8.2 Example for Configuring LMSP on a CPOS-Trunk..............................................................................................253
13.8.3 Example for Configuring Dual-System LMSP in the Scenario of Forwarding IP Packets Using PPP................ 257
14 Transmission Alarm Customization and Suppression Configuration......................... 267

14.1 Overview of Transmission Alarm Customization and Suppression.........................................................................267
14.2 Configuring Transmission Alarm Customization.....................................................................................................268
14.2.1 Configuring the Types of Alarms That Affect the Physical Status of Interfaces.................................................. 269
14.2.2 (Optional) Configuring b1tca, b2tca, b3tca, sdbere, and sfbere Alarm Thresholds.............................................. 271
14.2.3 Verifying the Transmission Alarm Customization Configuration.........................................................................272
14.3 Configuring a Transmission Alarm Filtering Interval.............................................................................................. 272
14.4 Configuring Transmission Alarm Suppression.........................................................................................................275
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. vii

14.5 Maintaining Transmission Alarm Customization and Suppression......................................................................... 276

14.5.1 Clearing the Information About Transmission Alarms......................................................................................... 276
15 PRBS Testing Configuration................................................................................................. 277

15.1 Overview of PRBS................................................................................................................................................... 277
15.2 Configuring PRBS Testing....................................................................................................................................... 278
15.2.1 (Optional) Configuring UNI-Side PRBS Testing.................................................................................................. 279
15.2.2 (Optional) Configuring Network-Side PRBS Testing........................................................................................... 280
15.2.3 Verifying the PRBS Testing Configuration........................................................................................................... 282
15.2.4 Example for Configuring a PRBS Test..................................................................................................................282
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. viii

Configuration Guide - WAN Access 1 About This Document
1 About This Document
Purpose
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the Wan Access feature supported by the
NE40E.
Related Version
The following table lists the product version related to this document.
Product Name Version
NE40E-M2 Series V800R011C00
U2000 V200R018C60
Intended Audience
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Security Declaration
l Encryption algorithm declaration
The encryption algorithms DES/3DES/RSA (RSA-1024 or lower)/MD5 (in digital
signature scenarios and password encryption)/SHA1 (in digital signature scenarios) have
a low security, which may bring security risks. If protocols allowed, using more secure
encryption algorithms, such as AES/RSA (RSA-2048 or higher)/SHA2/HMAC-SHA2 is
recommended.
l Password configuration declaration
Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 1

– Do not set both the start and end characters of a password to "%^%#". This causes
the password to be displayed directly in the configuration file.
– To further improve device security, periodically change the password.
l Personal data declaration
Your purchased products, services, or features may use users' some personal data during
service operation or fault locating. You must define user privacy policies in compliance
with local laws and take proper measures to fully protect personal data.
l Feature declaration
– The NetStream feature may be used to analyze the communication information of
terminal customers for network traffic statistics and management purposes. Before
enabling the NetStream feature, ensure that it is performed within the boundaries
permitted by applicable laws and regulations. Effective measures must be taken to
ensure that information is securely protected.
– The mirroring feature may be used to analyze the communication information of
terminal customers for a maintenance purpose. Before enabling the mirroring
function, ensure that it is performed within the boundaries permitted by applicable
laws and regulations. Effective measures must be taken to ensure that information is
securely protected.
– The packet header obtaining feature may be used to collect or store some
communication information about specific customers for transmission fault and
error detection purposes. Huawei cannot offer services to collect or store this
information unilaterally. Before enabling the function, ensure that it is performed
within the boundaries permitted by applicable laws and regulations. Effective
measures must be taken to ensure that information is securely protected.
l Reliability design declaration
Network planning and site design must comply with reliability design principles and
provide device- and solution-level protection. Device-level protection includes planning
principles of dual-network and inter-board dual-link to avoid single point or single link
of failure. Solution-level protection refers to a fast convergence mechanism, such as FRR
and VRRP.
Special Declaration
l This document serves only as a guide. The content is written based on device
information gathered under lab conditions. The content provided by this document is
intended to be taken as general guidance, and does not cover all scenarios. The content
provided by this document may be different from the information on user device
interfaces due to factors such as version upgrades and differences in device models,
board restrictions, and configuration files. The actual user device information takes
precedence over the content provided by this document. The preceding differences are
beyond the scope of this document.
l The maximum values provided in this document are obtained in specific lab
environments (for example, only a certain type of board or protocol is configured on a
tested device). The actually obtained maximum values may be different from the
maximum values provided in this document due to factors such as differences in
hardware configurations and carried services.
l Interface numbers used in this document are examples. Use the existing interface
numbers on devices for configuration.
l The pictures of hardware in this document are for reference only.

l In this document, public IP addresses may be used in feature introduction and

configuration examples and are for reference only unless otherwise specified.
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to
personal injury, equipment damage, and environment
deterioration.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.

Convention Description
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n

times.
# A line starting with the # sign is comments.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
l Changes in Issue 01 (2019-03-30)
This issue is the first official release. The software version of this issue is
V800R011C00SPC200.

Configuration Guide - WAN Access 2 Serial Interface Configuration
2 Serial Interface Configuration
About This Chapter
Serial interfaces are classified as synchronous or asynchronous serial interfaces. Synchronous

serial interfaces have been widely used on wide area networks (WANs).
2.1 Overview of Serial Interfaces

Serial interfaces include both synchronous and asynchronous serial interfaces.
2.2 Configuring a Serial Interface
Before you configure a serial interface, familiarize yourself with the usage scenario and
complete the pre-configuration tasks for the configuration.
2.1 Overview of Serial Interfaces

Serial interfaces include both synchronous and asynchronous serial interfaces.
Compared with asynchronous serial interfaces, synchronous serial interfaces are more
commonly used. Unless otherwise specified in this document, serial interfaces refer to
synchronous serial interfaces.
The serial interfaces formed by channelized E-carrier or channelized packet over

SONET/SDH (CPOS) interfaces have the same logical features as synchronous serial
interfaces and are commonly used serial interfaces. Here, SONET stands for synchronous
optical network, and SDH stands for synchronous digital hierarchy.
Serial interfaces support multiple types of cables and Point-to-Point Protocol (PPP) and time
division multiplexing (TDM). Serial interfaces can work on either data terminal equipment
(DTE) or data circuit-terminating equipment (DCE).
Serial Interfaces Types

The NE40E supports synchronous serial interfaces of E1 and CPOS. The naming conventions
of these serial interfaces are different.
Synchronous serial interfaces channelized by physical interfaces support configurations of

link protocols and MTU. Table 2-1 shows the naming conventions.

Table 2-1 Naming conventions for serial interfaces
Physical Interface Naming Convention
CE1 serial controller-number:set-number or serial controller-number:0
CPOS serial cpos-number/e1-number:set-number or serial cpos-

number/e1-number:0
Serial Interface Features

The serial interfaces supported by the NE40E have the following characteristics:
l Work on a DTE or DCE:
– A DTE is a user device. Only a User-to-Network Interface (UNI) on a DTE can be a
serial interface.
– A DCE is a network device that provides access for user devices. Only a Network-
to-Network Interface (NNI) on a DCE can be a serial interface.
– Generally, a DTE uses a serial interface to receive clock information from a DCE.
l Support multiple types of cables, such as V.24 and V.35. The NE40E automatically
detects the types of cables connected to serial interfaces and selects the electrical features
of these serial interfaces. Generally, this process does not require manual intervention.
l Use the PPP, TDM, , HDLCor ATM as the link-layer protocol.
l Support network-layer protocols, such as IP.
2.2 Configuring a Serial Interface

Before you configure a serial interface, familiarize yourself with the usage scenario and
complete the pre-configuration tasks for the configuration.
Usage Scenario
If you want a serial interface to carry upper-layer services, configure the link-layer attributes
of the serial interface and ensure that the status of the link-layer protocol for the serial
interface is Up.
Pre-configuration Tasks
Before configuring link-layer attributes, create a serial interface.
2.2.1 Configuring the Link Layer Protocol for a Serial Interface

This section describes how to configure a link-layer protocol for a serial interface. The link-
layer protocol used by a serial interface determines the format of frames passing through this
interface.Currently, the NE40E allows a serial interface to use PPP, TDM,, HDLC or ATM as
the link-layer protocol.

Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface serial interface-number
The serial interface view is displayed:
l To enter the view of a serial interface on a CE1 interface, you must specify interface-
number in the format of "chassis number/slot number/card number/port number:serial
interface number". For example, the name of serial interface 1 on CE1 0/2/0 is serial
0/2/0:1.
l To enter the view of a serial interface on a CPOS interface, you must specify interface-
number in the format of "chassis number/slot number/card number/port number/E1
channel number:serial interface number". For example, the name of serial interface 3 of
E1 channel 2 on CPOS0/2/0 is serial 0/2/0/2:3.
Step 3 Run link-protocol { ppp | tdm | hdlc | atm }
Step 4 Run commit
The configuration is committed.
----End
2.2.2 Configuring the MTU for a Serial Interface

This section describes how to configure the maximum transmission unit (MTU) for a serial
interface. The MTUs for two directly connected serial interfaces must be the same. Otherwise,
the link between the two interfaces cannot transmit services.
Context
Ensure that the MTU for an interface is the same as that for its directly connected interface.
Otherwise, services may be interrupted.
The length of a quality of service (QoS) queue is limited. If the MTU is too small, a packet
may be divided into many fragments. If the number of fragments exceeds the length of a QoS
queue, the QoS queue drops fragments. To avoid this situation, increase the MTU. By default,
a serial interface uses the first in first out (FIFO) queue scheduling mechanism.
Procedure
The serial interface view is displayed.
Step 3 Run link-protocol ppp
The link layer protocol is configured as PPP for the serial interface.

Step 4 Run mtu

The MTU is configured for the serial interface.
Generally, it is recommended that you use the default MTU value of 1500 bytes.
Step 5 Run commit
----End
2.2.3 Enabling the Payload Scramble Function on a Serial

Interface
To prevent communication failures caused by consecutive 0s or 1s on a link, enable the
payload scramble function on a serial interface.
Context
On a datacom network, the data link layer transmits distributed data frames to a specified
interface at the physical layer. Upon receipt, the interface decapsulates these frames into data
bits, encodes the bits based on the coding mode, and transmits them to a remote interface
through high and low levels on a link. Upon receipt of the levels, the remote interface decodes
them and restores them to data bits. In this way, the local device can communicate with the
remote device.
If the payload of a data frame contains consecutive 0s, the link will stay at the zero level for a
long time. After failing to detect signals for a prolonged period of time, the remoter interface
mistakenly thinks that all bits have been received or the link is faulty, leading to a
communication failure.
To resolve this problem, enable the payload scramble function on a synchronous serial
interface or trunk-serial interface. Using this function, the interface adds interference to the
payload to prevent consecutive 0s or 1s in the payload, avoiding communication failures.
Configurations of the payload scramble function on the local and remote interfaces must be
consistent.
Procedure
Step 2 Run interface interface-type interface-number
The view of the specified serial interface or trunk-serial interface is displayed.
Step 3 Run link-protocol atm
ATM is configured as the link layer protocol.
Step 4 Run scramble
The payload scramble function is enabled.
Step 5 Run commit

----End
2.2.4 Verifying the Serial Interface Configuration

After you configure a serial interface, you can check the protocol type, link-layer protocol
hold-timer, maximum transmission unit (MTU), and cyclic redundancy check (CRC)
information of the interface.
Prerequisites
The serial interface has been configured.
Procedure
l Run the display interface serial [ interface-number ] command to check the status of
and statistics about the specified serial interface.
----End

Configuration Guide - WAN Access 3 POS Interface Configuration
3 POS Interface Configuration
About This Chapter
Packet over SONET/SDH (POS) applies to MANs and WANs.

3.1 Overview
This section describes POS interfaces in terms of basic SONET and SDH concepts,
channelization and non-channelization, and SDH frame structure.
3.2 Configuring a POS Interface
You can configure the link layer protocol, clock mode, overhead byte, frame format, and CRC
for a POS interface.
3.3 Configuring a POS-Trunk Interface
Before configuring a POS-Trunk interface, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the data required for the configuration.
3.4 Configuration Examples for POS Interfaces
This section describes the POS interfaces in details from the aspects of applicable scenarios
and configuration commands.
3.1 Overview
This section describes POS interfaces in terms of basic SONET and SDH concepts,
channelization and non-channelization, and SDH frame structure.
Introduction to SONET and SDH

Synchronous Optical Network (SONET) is a synchronous digital transmission standard
defined by the American National Standards Institute (ANSI) and mainly used in North
America and Japan. Clocks at each level on the entire network are provided by a precise
master clock.
SONET defines the line rate hierarchical structure of synchronous transmission for the optical
transmission system. The basic transmission rate of SONET is 51.84 Mbit/s and
approximately equals the transmission rate of E3.
l For an electrical signal, the transmission rate is called Level 1 Synchronous Transport
Signal (STS-1).

l For an optical signal, the transmission rate is called Level 1 Optical Carrier (OC-1).
With synchronous signals, SONET can easily multiplex multiple signals.
Based on SONET, synchronous digital hierarchy (SDH) is an international standard defined
by the ITU-T and mainly used in Europe. The corresponding standard of SDH is the proposals
from G.707 to G.709 passed in 1988 and the proposals added in 1992.
SDH is similar to SONET to a great extent. The basic transmission rate of SDH is 155.52
Mbit/s, which is called Level 1 Synchronous Transfer Module (STM-1). This rate equals the
OC-3 rate in SONET.
With synchronous multiplexing and flexible mapping, SDH can multiplex or demultiplex low-
speed tributary signals from SDH signals without using multiplexing or demultiplexing
devices. SDH reduces signal consumption and equipment investment.
Table 3-1 lists the common transmission rates of SONET and SDH. The transmission rates
for different types of signals are increasing by four times. For example, OC-3 is a four-times
multiple of OC-1, OC-9 is a four-times multiple of OC-3, and so on. For convenience, the
approximations in the parentheses are often used to express transmission rates.
Table 3-1 Relationship between common transmission rates of SONET and SDH
SONET SDH Transmission Rate
(Mbit/s)
Electrical Optical Signal Optical Signal
Signal
STS-1 OC-1 - 51.840
STS-3 OC-3 STM-1 155.520 (155)
STS-9 OC-9 STM-3 466.560
STS-12 OC-12 STM-4 622.080 (622)
STS-18 OC-18 STM-6 933.120
STS-24 OC-24 STM-8 1244.160
STS-36 OC-36 STM-12 1866.240
STS-48 OC-48 STM-16 2488.320 (2.5 Gbit/s)
STS-96 OC-96 STM-32 4876.640
STS-192 OC-192 STM-64 9953.280 (10 Gbit/s)
Introduction to POS
Packet over SDH/SONET (POS), a technique for WANs and MANs, uses high-speed
transport channels provided by SONET/SDH to directly transmit IP data packets. POS
encapsulates IP packets into PPP or HDLC packets, maps the encapsulated packets to the
payload of SONET/SDH signals by using the service adapter of the SONET/SDH channel,
puts the payload into a SONET/SDH frame after adding the channel overhead at the
transmission layer and the section overhead at the section layer, and finally sends the
SONET/SDH frame to the optical network so that frames can be transmitted over optical

fibers on the optical network. POS adopts connectionless-oriented transmission of IP and

inherits the merit of IP packets.
SDH Frame Structure

This section describes the frame structure of an SDH signal, that is, the structure of an STM-
N frame.
To add or drop low-speed tributary signals to or from high-speed signals, try to distribute
tributary signals in the frame evenly and regularly. The ITU-T regulates that STM-N frames
are rectangular and expressed in bytes, as shown in Figure 3-1.
Figure 3-1 STM-N frame structure
9*270*N(bytes)
1 Regenerator
2 Section
3 Overhead
4 AUPTR
5 Payload
6 Multiplex
7 Section
8 Overhead
9
9*N 261*N
STM-N is a frame with the dimension of 9 rows x 270 x N columns. Here, N is the same as
that in STM-N, indicating how many STM-1 signals are multiplexed to this STM-N signal.
An STM-N frame consists of the following parts:
l Section overhead (SOH): includes regenerator section overhead (RSOH) and multiplex
section overhead (MSOH).
l Administration unit pointer (AU-PTR): is the pointer that specifies the first byte of the
payload. The receiver can correctly extract the payload according to the location of the
pointer.
l Payload
Overhead Bytes
SDH provides monitoring and management at layers. Monitoring is classified as section
monitoring or path monitoring. Section monitoring is classified as regenerator section
monitoring or multiplex section monitoring. Path monitoring is classified as higher-order path

monitoring or lower-order path monitoring. Different overhead bytes help to implement the
monitoring functions.
NOTE
This section describes only the SDH overhead bytes used in configuration.
l SOH
SOH consists of RSOH and MSOH.
The payload of an STM-N frame contains the path overhead (POH) that monitors low-
speed tributary signals.
J0, the regenerator section trace byte is contained in RSOH. This byte is used to transmit
the Section Access Point Identifiers (SAPIs) repeatedly to check the connection between
the receiver and the transmitter. The byte can be any character in a carrier's network,
whereas the J0 bytes of the receiver and transmitter must match each other at the border
of two carriers' networks. With the J0 byte, a carrier can locate and rectify faults in
advance to speed up network recovery.
l Path overhead
SOH monitors section layers, whereas POH monitors path layers. POH is classified as
lower-order path overhead or higher-order path overhead.
The higher-order path overhead monitors the paths at VC-4 and VC-3 levels.
J1, the higher-order VC-N path trace byte, is contained in the higher-order path
overhead. Similar to J0, J1 is used to transmit SAPIs repeatedly to check the connection
between the receiver and the transmitter. The J1 bytes of the receiver and transmitter
must match each other.
C2, the path signal label byte, is contained in higher-order path overhead. C2 is used to
specify the multiplexing structure and the attributes of the information payload in a VC
frame, including whether the path is loaded with services, service types, and the mapping
mode. The C2 bytes of the receiver and transmitter must match each other.
Terms
NOTE
The following terms may be used in interface configurations:

l Multiplexing units: Basic SDH multiplexing units include container (C-n), virtual
container (VC-n), tributary unit (TU-n), tributary unit group (TUG-n), administrative
unit (AU-n), and administrative unit group (AUG-n). Here, n stands for the number of
the unit level.
l Container: It is used to carry service signals that are transmitted at different rates. G.709
defines specifications for five types of standard containers: C-11, C-12, C-2, C-3, and
C-4.
l VC: It is an information terminal of SDH channels and is used to support connections
between SDH channel layers. VCs are classified as lower-order VCs or higher-order
VCs. VC-3 in AU-3 and VC-4 are higher-order VCs.
l TU and TUG: A TU provides adaptation between lower-order and higher-order path
layers. A collection of TUs, occupying a fixed position in the payload of the higher-order
VC, is called a TUG.
l AU and AUG: An AU provides adaptation between higher-order channel layer and
multiplex section layer. A collection of AUs, occupying a fixed position in the payload
of STM-N, is called an AUG.

3.2 Configuring a POS Interface

You can configure the link layer protocol, clock mode, overhead byte, frame format, and CRC
for a POS interface.
Usage Scenario
Before using a POS interface to carry packets, configure parameters for the POS interface.
l Before configuring a POS interface, power on the Router and ensure that it is working
properly.
Configuration Procedure
By default, parameters in POS interface configuration commands use default values. Perform
one or more of the following configurations as required.
3.2.1 Configuring the Link Layer Protocol for a POS Interface

The link layer protocol of a POS interface can be configured as PPP or HDLC.
Context
PPP is a link layer protocol used to encapsulate and transmit network layer packets over P2P
links. If a bit-oriented link layer protocol is needed for synchronous transmission and no
complex services are configured, HDLC can be applied. HDLC does not require that data to
be transmitted must be character sets. Instead, it can transparently transmit bit flows of all
types, especially the control and response messages. Unlike PPP, HDLC uses authentication
protocols to ensure the correctness and connectivity of links to be established. A cyclic
redundancy check (CRC) is performed for HDLC frames and information frames are
sequentially numbered to ensure reliable transmission. An IP-Trunk can consist of only POS
links, and the link layer protocol running on IP-Trunk member interfaces must be HDLC.
Perform the following steps on the Routers:
Procedure
Step 2 Run interface pos interface-number
The POS interface view is displayed.
Step 3 Run link-protocol { ppp | hdlc }
A link layer protocol is configured for the POS interface.
Step 4 Run commit

----End
3.2.2 Configuring the Clock Mode for a POS Interface

A POS interface works in either master or slave clock mode. You can configure different
clock modes for POS interfaces that function as a DTE or DCE.
Context
A POS interface supports the following clock modes:
l Master clock mode: uses internal clock signals.

l Slave clock mode: uses line clock signals.
The principles for configuring clock modes for POS interfaces in actual networking are as
follows:
l Clocks modes on the POS interfaces of two directly connected Routers must be both set
to master, or on one end set to master and the other end set to slave.
l If two Routers are connected over a WDM transmission device, clocks modes on the
POS interfaces of the two interconnected devices must be both set to master.
l If two Routers are connected over an active SDH or SONET device, clock modes on the
POS interfaces of the two interconnected devices can be set to slave to trace clock
signals of the active SDH or SONET device.
l If the connection mode of two Routers is unknown, the clocks of the POS interfaces on
the two Routers must work in master mode.
Procedure
Step 3 Run clock { master | slave }
A clock mode is configured for the POS interface.
Step 4 Run commit
----End
3.2.3 Configuring Overhead Bytes for a POS Interface

SONET/SDH provides a variety of overhead bytes to implement monitoring at different
levels.

Context
C2, the path signal label byte, is contained in the higher-order path overhead. C2 is used to
specify the multiplexing structure and the attributes of the information payload in a VC frame.
J0, the regenerator section trace byte, is contained in the section overhead. J0 is used to check
the continuity between two ports at the section layer.
J1, the higher-order VC-N path trace byte, is used to check the continuity between two ports
at the path layer.
NOTE
C2, J0, and J1 of the receiver must be the same as those of the transmitter; otherwise, the two ends
cannot communicate.
Procedure
Step 3 Configure the overhead byte for the POS interface.
Run the following command as required.
l Run flag j0 64byte-or-null-mode [ j0-value ] or flag j0 { 16byte-mode | 1byte-mode }

j0-value or flag j0 peer
The overhead byte J0 is configured for the interface.
l Run flag j1 64byte-or-null-mode [ j1-value ] or flag j1 { 16byte-mode | 1byte-mode }
j1-value or flag j1 peer
The overhead byte J1 is configured for the interface.
l Run flag c2 c2-value
The overhead byte C2 is configured for the interface.
Step 4 Run commit
----End
3.2.4 Configuring the Frame Format for a POS Interface

The frame format of a POS interface determines the application mode of the interface. POS
interfaces support two frame formats: SDH and SONET.
Context
A POS interface supports the following types of frame formats:
l SDH
l SONET

Procedure
Step 3 Run frame-format { sdh | sonet }
A frame format is configured for the POS interface.
SDH and SONET are two optical transmission standards defined by different organizations.
These two standards do not have obvious differences in contents and specifications. The
selection of SDH or SONET is determined by carriers in different geographical locations and
by different device manufacturers. The frame format configured on the POS interface must be
the same as that on transmission devices.
Step 4 Run commit
----End
3.2.5 Configuring the Scrambling Function for a POS Interface

POS interfaces support the scrambling function for the payload data to avoid excessive
consecutive 1s or 0s, which helps the receiver extract line clock signals.
Context
The scrambling function must be enabled on both of the directly connected interfaces.
Procedure
Step 3 Run scramble
The scrambling function of the payload is enabled for the POS interface.
Step 4 Run commit
----End
3.2.6 Configuring the Length of the CRC Code for a POS Interface
POS interfaces support a 16- or 32-bit CRC code.

Context
CRC uses an algorithm to verify data consistency on the POS interfaces connecting two
devices. The lengths of the CRC codes configured for POS interfaces connecting two devices
must be identical.
Procedure
Step 3 Run crc { 16 | 32 }
The length of the CRC code is configured for the POS interface.
The lengths of the CRC codes configured for POS interfaces connecting two devices must be
identical. If the lengths of the CRC codes configured for POS interfaces connecting two
devices are different, a large number of CRC error packets will be generated.
CRC uses a high-precision algorithm to verify data consistency on the POS interfaces
connecting two devices. CRC using a 32-bit CRC code is more precise than that using a 16-
bit CRC code but consumes more resources.
Step 4 Run commit
----End
3.2.7 Configuring the MTU for a POS Interface

The MTU is used to reassemble or fragment packets on a POS interface when packets are
received or sent on the interface through the IP network protocol.
Context
A Router reassembles or fragments the received or sent packets based on the MTU.
The IP layer limits the length of each frame in a packet to be sent each time. Any time the IP
layer receives an IP packet to be sent, it determines to which interface the packet should be
delivered and obtains the MTU of the target interface. Then, the IP layer compares the MTU
with the packet length. If the packet length is longer than the MTU, the IP layer fragments the
packet. Each fragment is not longer than the MTU.
NOTE
l If the MTU is set too small and the size of packets is quite large, packets will be divided into too
many fragments and be discarded by QoS queues.
l If the MTU is set too large, packet transmission will be slowed down.

After changing the MTU of an interface by running the mtu mtu command, restart the
interface to validate the configuration by running the shutdown and then undo shutdown
commands.
Procedure
l Configure the IPv4 MTU.
a. Run system-view

b. Run interface pos interface-number

c. Run mtu mtu
The IPv4 MTU is configured for the POS interface. The MTU is expressed in bytes.
The default MTU is 4470.
d. Run commit

l Configure the IPv6 MTU.
a. Run system-view

b. Run interface pos interface-number

c. Run ipv6 mtu mtu
The IPv6 MTU is configured for the POS interface.
After configuring the IPv6 MTU, run the ppp mru-negotiate { ipv4 | ipv6 }
command to start negotiation of the IPv6 MTU.
d. Run commit
----End
3.2.8 Configuring the Loopback Function for a POS Interface

Loopback is enabled on an interface only when some special function tests need to be carried
out.

Context
If local loopback has been enabled on an interface, the physical status of the interface changes
to Up, whereas the link layer protocol of the interface remains Down.
If remote loopback has been enabled on an interface and PPP is used as the link layer
protocol, the physical status of the interface changes to Up, whereas the link layer protocol of
the interface remains Down. If HDLC is used as the link layer protocol, both the physical
status and the link layer protocol status of the interface are Up.
Local loopback and remote loopback cannot be both enabled on a POS interface.
NOTE
The loopback configurations on a POS interface are different for different LPUs. In the actual
configuration, note the following points:
l To enable local loopback on a POS interface, ensure that the clock of the POS interface works in
master mode.
l To enable remote loopback on a POS interface, ensure that the clock of the POS interface works in
slave mode.
Procedure
Step 3 Run loopback { local | remote }
The loopback function is configured for the POS interface.
Step 4 Run commit
----End
3.2.9 Switching the Working Rate of a POS Subcard

You can run the speed (POS interface view) command to change the working rate of a POS
subcard to 155Mbit/s or 622Mbit/s.
Procedure
Step 3 Run speed { 155 | 622 }

Change the working rate of a POS subcard to 155Mbit/s or 622Mbit/s.

Step 4 Run commit
----End
3.2.10 Verifying the POS Interface Configuration

After configuring a POS interface, verify the configuration.
Prerequisites
A POS interface has been configured.
Procedure
l Run the display interface pos [ interface-number ] [ | { begin | exclude | include }
regular-expression ] command to check the configuration and status of the POS
interface.
l Run the display interface brief [ | { begin | include | exclude } regular-expression ]
command to check brief information about the POS interface.
----End
3.3 Configuring a POS-Trunk Interface

Before configuring a POS-Trunk interface, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Context
To configure APS on POS interfaces, create a POS-Trunk interface and add the POS
interfaces to the POS-Trunk interface.
Before configuring a POS-Trunk interface, power on the devices and check that the self-check
succeeds.
3.3.1 Creating a POS-Trunk Interface

Before bundling physical interfaces into a POS-Trunk interface, create this POS-Trunk
interface.
Procedure
Step 2 Run interface pos-trunk trunk-id
A POS-Trunk interface is created.

Step 3 Run commit
----End
3.3.2 Adding a POS Interface to a POS-Trunk Interface

After creating a POS-Trunk interface, add a POS interface to the POS-Trunk interface.
Procedure
The view of the POS interface to be added to a POS-Trunk interface is displayed.
The link layer protocol of the POS interface is configured as PPP.
NOTE
The link layer protocol of POS interfaces added to a POS-Trunk interface must be configured as PPP.
Step 4 Run pos-trunk trunk-id
The POS interface is added to a POS-Trunk interface.
Step 5 Run commit
----End
3.3.3 Verifying the POS-Trunk Interface Configuration

After completing the basic configurations of a POS-Trunk interface, check the configurations.
Prerequisites
Basic configurations have been completed on a POS-Trunk interface.
Procedure
l Run the display pos-trunk trunk-id command to check the configurations of a POS-
Trunk interface.
----End
3.4 Configuration Examples for POS Interfaces

This section describes the POS interfaces in details from the aspects of applicable scenarios
and configuration commands.

3.4.1 Example for Directly Connecting Devices Through POS

Interfaces
This example shows how to connect two devices through POS interfaces in typical
networking.
Networking Requirements
As shown in Figure 3-2, POS interfaces on Device A and Device B are directly connected
with a pair of single-mode fibers for receiving and sending packets; PPP is the link layer
protocol. It is required that Device A and Device B can communicate.
Figure 3-2 Networking diagram of connecting devices directly through POS interfaces
DeviceA DeviceB
POS1/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure PPP as the link layer protocol.

2. Configure IP addresses.
Data Preparation
To complete the configuration, you need the following data:
l IP address of POS 1/0/0 on Device A

l IP address of POS 1/0/0 on Device B
Procedure
Step 1 Configure Device A.
# Configure POS 1/0/0 and set the clock mode to slave.

<HUAWEI> system-view
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface pos 1/0/0
[*DeviceA-Pos1/0/0] ip address 10.1.1.1 30
[*DeviceA-Pos1/0/0] quit
[*DeviceA] commit
Step 2 Configure Device B.

# Configure POS 1/0/0, set the clock mode to slave, and set default values for other physical
parameters.
[~HUAWEI] sysname DeviceB
[*HUAWEI] commit
[DeviceB] interface pos 1/0/0
[~DeviceB-Pos1/0/0] clock slave
[*DeviceB-Pos1/0/0] ip address 10.1.1.2 30
[*DeviceB-Pos1/0/0] quit
[*DeviceB] commit
Step 3 Verify the configuration.
Run the display interface pos command to check the connectivity of the POS interface on
Device A.
[~DeviceA] display interface pos 1/0/0
Pos1/0/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2010-07-13 16:47:08
Description: HUAWEI, Quidway Series, Pos1/0/0 Interface (ifindex: 22, vr: 0)
Route Port,The Maximum Transmit Unit is 1600, Hold timer is 10(sec)
Internet Address is 10.1.1.1/30
Link layer protocol is PPP
LCP opened, IPCP opened, IP6CP opened, OSICP opened, MPLSCP opened
PPP negotiated peer ip address is 10.1.1.10
Current system time: 2010-07-13 17:29:44
The Vendor PN is FTLF1322P1BTR-HW
The Vendor Name is FINISAR CORP.
Port BW: 622M, Transceiver max BW: 622M, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 15km
Rx Power: 7.66dBm, Tx Power: -11.78dBm
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: none
Flag J0 "NetEngine "
Flag J1 "NetEngine "
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
section layer: B1 284236
line layer: B2 1871 REI 4445
path layer: B3 719417 REI 12417181
Statistics last cleared:never
Last 300 seconds input rate 304 bits/sec, 0 packets/sec
Last 300 seconds output rate 320 bits/sec, 0 packets/sec
Input: 5754803980 packets, 540947996544 bytes
Input error: 0 shortpackets, 0 longpackets, 0 CRC, 0 lostpackets
Output: 5676758063 packets, 533611565328 bytes
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
Run the ping command to check the network connectivity.

[~DeviceA] ping 10.1.1.2
PING 10.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=3 ms
--- 10.1.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss

round-trip min/avg/max = 2/2/3 ms
----End
Configuration Files
l Configuration file of Device A
#
sysname DeviceA
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
#
return
l Configuration file of Device B

#
sysname DeviceB
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
clock slave
#
return
3.4.2 Example for Connecting Devices with POS Interfaces

Through an FR Network
This example shows how to configure two devices in different LANs to communicate through
VCs.
On the network shown in Figure 3-3, Routers are connected to each other through POS sub-
interfaces. The type of the interface on Device A is DCE, and the type of the interface on
Device B is DTE.
Figure 3-3 Networking for connecting LANs through VCs
DeviceA DeviceB
10.1.1.1/24 10.1.1.2/24
DLCI=100
Device Name Interface IP Address
DeviceA POS0/1/0.1 10.1.1.1/24

DeviceB POS0/1/0.1 10.1.1.2/24
1. Set the link layer protocol to FR.
2. Configure interface type.
3. Configure a DLCI for each VC.
Data Preparation
l IP addresses of interfaces
l DLCI on each interface
Procedure
Step 1 Configure RouterDevice A.
# Set the link layer protocol to FR and interface type to DCE.
[*HUAWEI] commit
[~DeviceA] interface Pos0/1/0
[~DeviceA-Pos0/1/0] link-protocol fr
[*DeviceA-Pos0/1/0] fr interface-type dce
# Configure an IP address for the sub-interface and the local DLCI.

[~DeviceA] interface Pos0/1/0.1 p2p
[~DeviceA-Pos0/1/0.1] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Pos0/1/0.1] fr dlci 100
[*DeviceA-fr-dlci-Pos0/1/0.1-100] quit
[*DeviceA-Pos0/1/0.1] quit
# Commit the configuration.

[*DeviceA0/1/0] commit
Step 2 Configure RouterDevice B.

# Set the link layer protocol to FR and interface type to DTE.
[*HUAWEI] commit
[~DeviceB] interface Pos0/1/0
[~DeviceB-Pos0/1/0] link-protocol fr
[*DeviceB-Pos0/1/0] fr interface-type dte

[~DeviceB] interface Pos0/1/0.1 p2p

[~DeviceB-Pos0/1/0.1] ip address 10.1.1.2 255.255.255.0

[*DeviceB-Pos0/1/0.1] fr dlci 100
[*DeviceB-fr-dlci-Pos0/1/0.1-100] quit
[*DeviceB-Pos0/1/0.1] quit

[*DeviceB0/1/0] commit
Step 3 Check the configurations.

Run the display fr interface command on Device B to check the FR protocol status and
interface information. The command output shows that the physical status and protocol status
of the interface are both Up.
<DeviceB> display fr interface pos0/1/0.1
Pos0/1/0.1, DTE, physical up, protocol up
Run the display fr pvc-info command on Device B to check VC configurations and statistics.
<DeviceB> display fr pvc-info interface pos0/1/0.1
PVC statistics for interface Pos0/1/0.1 (DTE, PP)
DLCI = 111, USAGE = LOCAL, Pos0/1/0.1
create time = 2013/11/05 11:19:17, status = ACTIVE
in BECN = 0, in FECN = 0
in packets = 0, in bytes = 0
out packets = 0, out bytes = 0
----End
Configuration Files
l Device A configuration file
#
sysname DeviceA
#
interface Pos0/1/0
link-protocol fr
undo shutdown
fr interface-type dce
#
interface Pos0/1/0.1 p2p
ip address 10.1.1.1 255.255.255.0
fr dlci 100
#
return
l Device B configuration file

#
sysname DeviceB
#
interface Pos0/1/0
link-protocol fr
undo shutdown
#
ip address 10.1.1.2 255.255.255.0
fr dlci 100
#
return

Configuration Guide - WAN Access 4 E-Carrier Interface Configuration
4 E-Carrier Interface Configuration
About This Chapter
The E-carrier system uses European 30 -channel pulse code modulation (PCM), which is also
called E1.
4.1 Overview of E-Carrier Interfaces

E-carrier interfaces can work in channelized, unchannelized, or clear channel mode.
4.2 Configuring a E1 Interface
Before you configure a channelized E1 interface, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the configuration procedure for the
configuration.
4.3 Configuring an E3 Interface
This section describes how to configure an E3 interface to carry upper-layer services.
4.4 Maintaining E-Carrier Interface Configuration
4.5 Configuration Examples for E-carrier Interfaces
4.1 Overview of E-Carrier Interfaces

E-carrier interfaces can work in channelized, unchannelized, or clear channel mode.
Basic E-Carrier Concepts

The present digital transmission system uses pulse code modulation (PCM). PCM was
initially designed to enable multi-line telephony along a trunk cable between two telephone
exchanges. PCM has two incompatible international standards:
l European 30-channel PCM, which is also called E1
l North America 24-channel PCM, which is also called T1
E-carrier is a digital communication system recommended by the International

Telecommunication Union-Telecommunication Standardization Sector (ITU-T). It evolves
from E1 and has been applied in regions except North America.

Digital Carrier System

The carrier system enables a single physical communication channel to contain multiple
logical channels. Therefore, the carrier system supports multi-channel communication.
In the digital carrier system, a single large-capacity digital circuit supports multiple logical
channels, each of which supports one independent channel.
Working Mode
E-carrier interfaces can work in any of the following modes:
l Channelized mode: It is a framed mode in which all timeslots can be allocated to
multiple channels.
l Unchannelized mode: It is a framed mode in which all timeslots can be bundled only
once and allocated to only one channel.
l Clear channel mode: It is also called an unframed mode. There is no frame flag in the
data stream, and all bits in the data stream are data. The data in the data stream belongs
to only one channel.
Introduction to E1 Interfaces
A physical interface that is formed by E1 and can work only in clear channel is an E1
interface. A physical interface that is formed by E1 and can work in unchannelized or
channelized mode is a CE1 interface.
l In clear channel mode, or unframed mode:
An E1 interface forms a synchronous serial interface without timeslot division and with a
transmission rate of 2.048 Mbit/s. The E1 interface has the same logical features as a
synchronous serial interface. It supports link-layer protocols, such as PPP, TDM ,
HDLCand ATM, MP bundling,and network protocols, such as IP.
l In unchannelized mode, or framed mode:
A CE1 interface is physically divided into 31 timeslots numbered from 1 to 31. The
timeslots can be bundled once into one channel. For example, if timeslots 1 and 2 are
bundled into a serial interface of 128 kbit/s, the remaining timeslots cannot be bundled.
The serial interface has the same logical features as a synchronous serial interface. It
supports link-layer protocols, such as PPP, TDM , HDLCand ATM, MP bundling,and
network protocols, such as IP.
l In channelized mode, or framed mode:
A CE1 interface is physically divided into 31 timeslots numbered from 1 to 31. The
timeslots can be randomly bundled to form logical channels, each with a transmission
rate of N x 64 kbit/s.
All the timeslots can be grouped into multiple channel-sets. Each bundled channel-set of
timeslots is used as an interface with the same logical features as a synchronous serial
interface. It supports link-layer protocols, such as PPP, TDM , HDLCand ATM, MP
bundling,and network protocols, such as IP.
Introduction to CE3 Interfaces

A channelized E3 (CE3) interface is an E3 interface that can work only in unchannelized or
clear channel mode.
A CE3 interface has the following characteristics:

l In clear channel mode, also called the unframed mode, a CE3 interface functions like an
interface with the transmission rate of 34.368 Mbit/s and without timeslot division. The
CE3 interface has the same logical features as a synchronous serial interface and
supports link-layer protocols (such as PPP and HDLC).
l In unchannelized mode, also called the framed mode, all timeslots of a CE3 interface are
bundled to form a serial interface with the transmission rate of 32.768 Mbit/s. The serial
interface supports link-layer protocols (such as PPP and HDLC).
Introduction to Channelized Serial Interfaces

The serial interface formed by an E-carrier interface is called a channelized serial interface. A
channelized serial interface has the same logical features as a synchronous serial interface.
The naming convention for a channelized serial interface is "serial interface-number:set-
number," where interface-number specifies the name of the E-carrier interface, and set-
number specifies the number of the interface that the E-carrier interface timeslots are bundled
into.
4.2 Configuring a E1 Interface

Before you configure a channelized E1 interface, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the configuration procedure for the
configuration.
Precautions
Before you use a E1 interface to carry upper-layer services, configure the E1 interface. Note
that:
l If a physical interface has no cable connected, run the shutdown command to disable
this interface to prevent interference with the interface.
l After you configure services on an interface, run the shutdown and then undo
shutdown commands in the current interface view to ensure that the configured services
are loaded onto the interface.
Running the shutdown command in a E1 interface view will disable the E1 interface and may
affect the normal operation of its channel-sets.
Before configuring a E1 interface, power on the device and ensure that it is working properly.
4.2.1 Configuring the Working Mode for an E1 Interface

This section describes how to configure the working mode of a channelized E1 interface. E1
interfaces can work in either clear channel mode or channelized mode.
Context
An E1 interface can form serial interfaces with different transmission rates:

l If an E1 interface works in clear channel mode, the E1 interface forms a synchronous

serial interface without timeslot division and with a transmission rate of 2.048 Mbit/s.
l If an E1 interface works in channelized mode, timeslots 1 to 31 of the E1 interface can
be randomly bundled into channel-sets to form serial interfaces, each with a transmission
rate of N x 64 kbit/s.
NOTE
The configuration of channelized mode is supported only on the Admin-VS.
Procedure
l Create a serial interface that works in clear channel mode.
a. Run system-view
b. Run controller e1 controller-number
The E1 interface view is displayed.
c. Run using e1
The E1 interface is configured to work in clear channel mode, establishing a serial
interface without timeslot division and with a transmission rate of 2.048 Mbit/s.
You can run the interface serial controller-number:0 command to enter the serial
interface view.
d. Run commit
l Create a serial interface that works in channelized mode.
a. Run system-view
c. Run using ce1
The interface is configured to work in channelized mode.
d. Run channel-set set-number timeslot-list slot-list
A serial interface with a transmission rate of N x 64 kbit/s is created. N stands for
the number of bundled timeslots.
To change the working mode of an E1 interface:
n Delete serial interfaces and their configurations and channelization
configurations before you run the using e1 command to switch an E1 interface
from the channelized mode to the clear channel mode.
n Delete clear channel configurations and serial interface configurations before
you run the using ce1 command to switch an E1 interface from the clear
channel mode to the channelized mode.
You can run the interface serial controller-number:set-number command to enter
the serial interface view.
e. Run commit

4.2.2 Configuring the Clock Mode for a CE1 Interface

A CE1 interface works in either master clock mode or slave clock mode. When two CE1
interfaces are directly connected, you must configure one to work in master clock mode and
the other in slave clock mode. When a CE1 interface is connected to a transmission device,
the CE1 interface must work in slave clock mode.
Context
A CE1 interface works in either of the following clock modes:
l Master clock mode: In master clock mode, a CE1 interface uses internal clock signals.
l Slave clock mode: In slave clock mode, a CE1 interface uses line clock signals.
When CE1 interfaces of two NE40Es are directly connected, you must configure one interface
to work in master clock mode and the other interface in slave clock mode. When the CE1
interface of the NE40E is connected to a transmission device, you must configure this
interface to work in slave clock mode and use the clock signals provided by the transmission
device.
Procedure
Step 2 Run controller e1 controller-number
The CE1 interface view is displayed.
A clock mode is configured for the CE1 interface.
Step 4 Run commit
----End
4.2.3 Configuring the Frame Format for a CE1 Interface

You can configure a CE1 interface to use a 4-bit CRC code to check physical frames.
Context
You can configure the frame format for a CE1 interface only when it works in channelized
mode.
Procedure
Step 2 Run controller e1controller-number


Step 3 Run frame-format { crc4 | no-crc4 }
A frame format is configured for the CE1 interface.
NOTE
When setting the frame format of a CE1 interface, ensure that the local and remote ends are configured
with the same frame format.
Step 4 Run commit

----End
4.2.4 Configuring the Loopback Function for an E1 Interface

This section describes how to configure the loopback function on a channelized E1 interface.
The loopback function is used to check the interface or cable status. In normal situations, the
loopback function is disabled.
Context
The loopback function has two types:
l Local loopback: is used to locate a system fault.
l Remote loopback: is used to locate a link fault or test the quality of a link.
NOTE
l To enable local loopback on an E1 interface, ensure that the clock of the E1 interface works in
master mode.
l To enable remote loopback on an E1 interface, ensure that the clock of the E1 interface works in
slave mode.
This configuration process is supported only on the Admin-VS.
Procedure
Step 3 Run loopback { local | remote } [ autoclear period hold-time ]
The loopback function is enabled on the E1 interface.
To enable the E1 interface to delete the loopback configuration after a specified period,
specify autoclear period hold-time in the command. This function takes effect when
loopback is enabled. After the time specified by hold-time elapses, the loopback configuration
is automatically deleted.
Step 4 Restart the E1 interface.
1. Run shutdown

The interface is disabled.

2. Run commit

3. Run undo shutdown
The interface is enabled.

NOTE
After the configuration is complete, the configuration takes effect only after the interface is restarted.
Step 5 Run commit
----End
4.2.5 Configuring ES-TCA Alarm Thresholds on a CE1 Interface

If the threshold for triggering an ES-TCA alarm is set and the number of E1 code errors
exceeds the threshold, an alarm will be generated.
Procedure
The view of a specific CE1 interface is displayed.
Step 3 Run trap-threshold es-tca trigger-threshold trigger-threshold resume-threshold resume-

threshold
The thresholds for triggering and clearing an ES-TCA alarm are set.
----End
4.2.6 Verifying the CE1 Interface Configuration

After you configure a channelized E1 (CE1) interface, verify the configurations and status of
the CE1 interface.
Prerequisites
A CE1 interface has been configured.
Procedure
l Run the display interface serial [ interface-number ] command to check the status and
statistics of a serial interface.
l Run the display controller e1 [ controller-number ] command to check the
configurations and status of a CE1 interface.
----End

4.3 Configuring an E3 Interface

This section describes how to configure an E3 interface to carry upper-layer services.
Precautions
When configuring E3 interfaces to carry upper-layer services, note the following:
l If an E3 interface on the device is idle (no cable is connected to the interface), run the
shutdown command to shut down the E3 interface to prevent it from being interfered.
l After configuring services on an E3 interface, run the shutdown and then undo
shutdown commands in the interface view for the services to take effect.
l The shutdown and undo shutdown commands run on an E3 interface also take effect
with the serial interface created on the E3 interface. However, the shutdown and undo
shutdown commands run on a serial interface takes effect only with the serial interface.
Before configuring an E3 interface, power on the device and ensure that the self-check
succeeds.
4.3.1 Creating a Synchronous Serial Interface on an E3 Interface

Before using an E3 interface to transmit data, you must create a synchronous serial interface
on the E3 interface.
Context
Depending on the E3 interface working modes, you can create the following two types of
synchronous serial interfaces on an E3 interface:
l If the E3 interface works in clear channel mode, an unframed synchronous serial
interface with a bandwidth of 34.368 Mbit/s is created.
l If the E3 interface works in unchannelized mode, a synchronous serial interface with a
bandwidth of 33.831 Mbit/s is created after you manually create a framed E3 channel.
By default, an E3 interface works in unchannelized mode.
Procedure
l Create a synchronous serial interface on an E3 interface working in clear channel mode.
a. Run system-view
The specified E3 interface view is displayed.
c. Run using e3
The E3 interface is configured to work in clear channel mode, and an unframed
synchronous serial interface with a bandwidth of 34.368 Mbit/s is created.

After the synchronous serial interface is created, you can run the interface serial
controller-number command to display the view of the synchronous serial interface.
d. Run commit
l Create a synchronous serial interface on an E3 interface working in unchannelized mode.
a. Run system-view
c. Run using ce3
The E3 interface is configured to work in unchannelized mode.
d. Run e3 framed
A framed E3 channel is created, and an unframed synchronous serial interface with
a bandwidth of 33.831 Mbit/s is created.
controller-number command to display the view of the synchronous serial interface.
e. Run commit
----End
4.3.2 Configuring Loopback on an E3 Interface

To monitor the status of an E3 interface or the cable connected to the E3 interface, configure
loopback on the E3 interface.
Context
Loopback can be either local loopback or remote loopback.
l To locate a system fault, enable local loopback on an E3 interface.

l To locate a link fault or test the link quality, enable remote loopback on an E3 interface.
Local loopback must be configured in master clock mode, and remote loopback must be
configured in slave clock mode.
Running the loopback command will cause interfaces or links unable to work properly.
Therefore, exercise caution when running the loopback command. After checking the
interface or link status, immediately run the undo loopback command to disable loopback.
Procedure


The view of the E3 interface to be checked is displayed.
Step 3 Run loopback { local | remote }
Loopback is enabled on the E3 interface.
Note the following when enabling loopback on an interface:
l The interface that has local loopback enabled must work in master clock mode.
l The interface that has remote loopback enabled must work in slave clock mode.
By default, loopback is disabled.
Step 4 Run commit
----End
4.3.3 Configuring a Clock Mode for an E3 Interface

An E3 interface works either in master clock mode or slave clock mode.
Context
An E3 interface has two clock modes:
l Master clock mode: The E3 interface uses internal clock signals.
l Slave clock mode: The E3 interface uses clock signals provided by an external device.
When two Routers are directly connected through E3 interfaces, configure one E3 interface as
the master clock and the other E3 interface as the slave clock.
By default, an E3 interface works in master clock mode.
Perform the following steps on a router.
Procedure
The clock mode of the E3 interface is configured.
Step 4 Run commit
----End

4.3.4 Verifying the E3 Interface Configuration

After configuring an E3 interface, verify its status and clock configuration.
Procedure
Step 1 Run the display controller e3 [ controller-number ] command to check E3 interface
configurations.
----End
4.4 Maintaining E-Carrier Interface Configuration

4.4.1 Testing the Bit Error Rate of a CE1 Interface
The testing results can be used to locate link faults.
Context
NOTE
In VS mode, this configuration process is supported only by the admin VS.
When faults occur on a CE1 interface, you can run the test connectivity controller e1
command for fault locating.
Prerequisites
The serial interface service has been configured.
Procedure
Step 2 Run test connectivity controller e1 controller-number { unframed | channelized timeslot-

list slot-list } duration time
The bit error rate is tested on a specified CE1 interface.
----End
4.5 Configuration Examples for E-carrier Interfaces
4.5.1 Example for Configuring E1 Interface Interconnection

This section provides an example on how to interconnect devices through E1 interfaces.

On the network shown in Figure 4-1, Device A and Device B need to communicate with each
other through E1 interfaces.
Figure 4-1 E1 interface interconnection

NOTE
In this example, interface1 and interface2 represent E1 0/1/0 and E1 0/2/0, respectively.
interface1 interface2
DeviceA DeviceB
1. Create synchronous serial interfaces.
2. Configure IP addresses for the synchronous serial interfaces.
3. Restart all the interfaces to make the configuration take effect.
Data Preparation
l E1 interface number of Device A
l E1 interface number of Device B
l IP address of the synchronous serial interface on Device A
l IP address of the synchronous serial interface on Device B
Procedure
Step 1 Create a synchronous serial interface on Device A.
# Configure the E1 interface on Device A as a synchronous serial interface.
[*HUAWEI] commit
[~DeviceA] controller e1 0/1/0
[~DeviceA-E1 0/1/0] using e1
[*DeviceA-E1 0/1/0] commit
[~DeviceA-E1 0/1/0] quit
# Configure the E1 interface on Device B as a synchronous serial interface.

[*HUAWEI] commit
[~DeviceB] controller e1 0/2/0
[~DeviceB-E1 0/2/0] using e1
[*DeviceB-E1 0/2/0] commit
[~DeviceB-E1 0/2/0] quit

Step 2 Configure IP addresses for the synchronous serial interfaces.

# Configure an IP address for the synchronous serial interface on Device A.
[~DeviceA] interface serial 0/1/0:0

[~DeviceA-Serial0/1/0:0] link-protocol ppp
[*DeviceA-Serial0/1/0:0] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Serial0/1/0:0] shutdown
[*DeviceA-Serial0/1/0:0] commit
[~DeviceA-Serial0/1/0:0] quit
# Configure an IP address for the synchronous serial interface on Device B.
[~DeviceB] interface serial 0/2/0:0

[~DeviceB-Serial0/2/0:0] link-protocol ppp
[*DeviceB-Serial0/2/0:0] ip address 10.1.1.2 255.255.255.0
[*DeviceB-Serial0/2/0:0] shutdown
[*DeviceB-Serial0/2/0:0] commit
[~DeviceB-Serial0/2/0:0] quit
Step 3 Restart all the interfaces to make the configuration take effect.
# Restart the synchronous serial interface on Device A.
[~DeviceA-Serial0/1/0:0] undo shutdown
# Restart the synchronous serial interface on Device B.

[~DeviceB-Serial0/2/0:0] undo shutdown

# On Device A, ping the IP address of the synchronous serial interface on Device B. The
command output shows that the ping is successful.
0.00% packet loss
----End
Configuration Files
#
sysname DeviceA
#
controller E1 0/1/0
using e1
undo shutdown
#

interface Serial0/1/0:0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
undo shutdown
#
return

#
sysname DeviceB
#
controller E1 0/2/0
using e1
undo shutdown
#
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
undo shutdown
#
return
4.5.2 Configuring CE1 Interface Interconnection

This section provides an example on how to interconnect devices through CE1 interfaces.
other through CE1 interfaces.
Figure 4-2 CE1 interface interconnection

NOTE
In this example, interface1 and interface2 represent CE1 0/1/0 and CE1 0/2/0, respectively.
DeviceA DeviceB
1. Create synchronous serial interfaces.
2. Configure IP addresses for the synchronous serial interfaces.
Data Preparation
l CE1 interface number of Device A

l CE1 interface number of Device B

l IP address of the synchronous serial interface on Device A

l IP address of the synchronous serial interface on Device B
NOTE
The timeslot channels of the serial interfaces on Device A must be the same as those on Device B.
Procedure
Step 1 Create synchronous serial interfaces.
# Configure the CE1 interface on Device A as a synchronous serial interface.

[*HUAWEI] commit
[~DeviceA-E1 0/1/0] channel-set 1 timeslot-list 1-15
# Configure the CE1 interface on Device B as a synchronous serial interface.

[*HUAWEI] commit
[~DeviceB-E1 0/2/0] channel-set 1 timeslot-list 1-15
Step 2 Configure IP addresses for the synchronous serial interfaces.
# Configure an IP address for the synchronous serial interface on Device A.

[~DeviceA-Serial0/1/0:1] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Serial0/1/0:1] shutdown
# Configure an IP address for the synchronous serial interface on Device B.

[~DeviceB-Serial0/2/0:1] ip address 10.1.1.2 255.255.255.0
[*DeviceB-Serial0/2/0:1] shutdown
# Restart the synchronous serial interface on Device A.

# Restart the synchronous serial interface on Device B.



# On Device A, ping the IP address of the synchronous serial interface on Device B. The
command output shows that the ping is successful.
0.00% packet loss
----End
Configuration Files
#
sysname DeviceA
#
controller E1 0/1/0
channel-set 1 timeslot-list 1-15
#
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
undo shutdown
#
return

#
sysname DeviceB
#
controller E1 0/2/0
#
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
undo shutdown
#
return

Configuration Guide - WAN Access 5 CPOS Interface Configuration
5 CPOS Interface Configuration
About This Chapter
CPOS interfaces are used to aggregate multiple E1 links to improve low-speed access. E3, T1,
and T3 links cannot be aggregated.
5.1 Overview of CPOS Interfaces

This section describes packet over SONET/SDH (POS) and channelized POS (CPOS)
interfaces in terms of the basic concepts of synchronous optical network (SONET) and
synchronous digital hierarchy (SDH), channelization and non-channelization, and SDH frame
structure.
5.2 Configuring a CPOS Interface
Before you configure a channelized packet over SONET/SDH (CPOS) interface, familiarize
yourself with the usage scenario and complete the pre-configuration tasks. Here, SDH stands
for synchronous digital hierarchy.
5.3 Configuring a CPOS-Trunk Interface
Configuring a CPOS-Trunk interface includes creating a CPOS-Trunk interface, adding a
CPOS interface to the CPOS-Trunk interface, and creating a trunk serial interface on the
CPOS-Trunk interface.
5.4 Maintaining a CPOS Interface
You can test the bit error rate of a CPOS E1 link to maintain the CPOS interface.
5.5 Configuration Examples for CPOS Interfaces
This section provides CPOS configuration examples.
5.1 Overview of CPOS Interfaces

This section describes packet over SONET/SDH (POS) and channelized POS (CPOS)
interfaces in terms of the basic concepts of synchronous optical network (SONET) and
synchronous digital hierarchy (SDH), channelization and non-channelization, and SDH frame
structure.

Introduction to SONET and SDH

SONET is a synchronous digital transmission standard defined by the American National
Standards Institute (ANSI) and mainly used in North America and Japan. Clocks at each
network level are synchronized with a very precise master clock.
SONET defines the line rate hierarchical structure of synchronous transmission for the optical
transmission system. The basic SONET transmission rate is 51.84 Mbit/s :
l An electrical signal with the transmission rate is called Level 1 Synchronous Transport
Signal (STS-1).
l An optical signal with the transmission rate is called Level 1 Optical Carrier (OC-1).
SONET, which uses synchronous signals, can easily multiplex signals.
SONET-based SDH is an international standard defined by the International

Telecommunication Union Telecommunication Standardization Sector (ITU-T) and mainly
used in Europe. The corresponding SDH standard is based on the proposals from G.707 to G.
709 passed in 1988 and the proposals added in 1992.
SDH is similar to SONET to a great extent. The basic transmission rate of SDH is 155.52
Mbit/s, which is called Level 1 Synchronous Transfer Module (STM-1). This rate equals the
OC-3 rate in SONET.
SDH, which uses synchronous multiplexing and flexible mapping, can multiplex or
demultiplex low-speed tributary signals from SDH signals without using many multiplexing
or demultiplexing devices. SDH reduces signal consumption and equipment investment.
Table 5-1 lists the common SONET and SDH transmission rates. For convenience, the
approximations of these transmission rates are placed in the parentheses.
Table 5-1 Common SONET and SDH transmission rates

SONET SDH Transmission Rate
(Mbit/s)
Electrical Optical Signal Optical Signal
Signal
STS-1 OC-1 - 51.840
STS-3 OC-3 STM-1 155.520 (155)
STS-9 OC-9 STM-3 466.560
STS-12 OC-12 STM-4 622.080 (622)
STS-18 OC-18 STM-6 933.120
STS-24 OC-24 STM-8 1244.160
STS-36 OC-36 STM-12 1866.240
STS-48 OC-48 STM-16 2488.320 (2.5 Gbit/s)
STS-96 OC-96 STM-32 4876.640
STS-192 OC-192 STM-64 9953.280 (10 Gbit/s)

Channelization and Unchannelization

When SDH signals are formed by multiplexing low-speed tributary signals, these tributary
signals are called channels.
Channelization means that multiple independent channels of data are transmitted over an
optical fiber by using low-speed tributary STM-N signals. During the transmission, each
channel has its own bandwidth and start and end points and follows its own monitoring
policy.
Unchannelization means that all data is transmitted through a single channel over an optical
fiber by using all STM-N signals. During the transmission, all the data has the same ID and
start and end points and follows the same monitoring policy.
Channelization can utilize bandwidth more efficiently by transmitting multiple channels of

low-speed signals. Unchannelization is used to transmit a single channel of high-speed
signals.
Introduction to Channelized Serial Interfaces

The serial interface formed by a CPOS interface is called a channelized serial interface, which
has the same logical features as a synchronous serial interface.
An E1 channel of a CPOS interface can work in either clear channel mode (unframed mode)
or channelized mode:
l In clear channel mode, an E1 channel without timeslot division forms a 2.048 Mbit/s
serial interface.
The naming convention for a serial interface is "serial interface-number/e1-number:0,"
where interface-number specifies the name of the CPOS interface, and e1-number
specifies the number of the E1 channel.
l In channelized mode, 31 timeslots across an E1 channel, excluding timeslot 0, can be
randomly bundled into serial interfaces.
The naming convention for a channelized serial interface is "serial interface-number/e1-
number:set-number," where interface-number specifies the name of the CPOS interface,
e1-number specifies the number of an E1 channel, and set-number specifies the number
of the interface formed by bundling the timeslots of the E1 channel.
NOTE
The NE40E supports only STM-1 Channelized POS.
Pos andCPOS
POS applies to metropolitan area networks (MANs) and wide area networks (WANs) and
supports packet data, such as IP packets.
CPOS interfaces make full use of the SDH system and have the following functions:
l Perform refined division of bandwidth.
l Reduce the number of low-speed physical ports required on a Router.
l Enhance the aggregation capability of the low-speed interfaces of a Router.
l Improve the dedicated line access capability of a Router.

SDH Frame Structure

This section describes the frame structure of an SDH signal, that is, the structure of an STM-
N frame.
To add or drop low-speed tributary signals to or from high-speed signals, try to distribute
tributary signals in the frame evenly and regularly. The ITU-T regulates that STM-N frames
are rectangular and expressed in bytes, as shown in Figure 5-1.
Figure 5-1 STM-N frame structure
9*270*N(bytes)
1
Regenerator
2
Section
3
Overhead
4
5 AU-PTR Payload
6
Multiplex
7
Section
8
Overhead
9
9*N 261*N
STM-N is a frame with the dimension of 9 rows x 270 x N columns. Here, N is the same as
that in STM-N, indicating how many STM-1 signals are multiplexed to this STM-N signal.
An STM-N frame consists of the following parts:
l Section overhead (SOH): includes regenerator section overhead (RSOH) and multiplex
section overhead (MSOH).
l Administration unit pointer (AU-PTR): is the pointer that specifies the first byte of the
payload. The receiver can correctly extract the payload based on the location of the
pointer.
l Payload
Related Concepts
l Multiplexing units: Basic SDH multiplexing units include container (C-n), virtual
container (VC-n), tributary unit (TU-n), tributary unit group (TUG-n), administrative
unit (AU-n), and administrative unit group (AUG-n). Here, n stands for the number of
the unit level.
l Container: It is used to carry service signals that are transmitted at different rates. G.709
defines specifications for five types of standard containers: C-11, C-12, C-2, C-3, and
C-4.

l VC: It is an information terminal of SDH channels and is used to support connections

between SDH channel layers. VCs are classified as lower-order VCs or higher-order
VCs. VC-3 in AU-3 and VC-4 are higher-order VCs.
l TU and TUG: A TU provides adaptation between lower-order and higher-order path
layers. A collection of TUs, occupying a fixed position in the payload of the higher-order
VC, is called a TUG.
l AU and AUG: An AU provides adaptation between higher-order channel layer and
multiplex section layer. A collection of AUs, occupying a fixed position in the payload
of STM-N, is called an AUG.
Multiplexing E1 to STM-1
In the SDH multiplexing process outlined in the G.709 recommendation, there is more than
one multiplexing path from a valid payload to STM-N. Figure 5-2 shows the multiplexing
process from E1 to STM-1.
Figure 5-2 E1 to STM-1 multiplexing process
×1 ×1 ×3
STM-1 AUG-1 AU-4 VC-4
×3 TUG-3
AU-3
×7
Point processing ×7
VC-3 TUG-2
Multiplexing
Aligning ×3
C-12:2.048Mb/s
Mapping C-12 VC-12 TU-12
In practice, different countries and regions may use different multiplexing paths.
Calculation of E1 Path Sequence Numbers

CPOS interfaces use the byte interleave multiplexing mode so that the lower-order VCs in a
higher-order VC are not arranged in sequence. To facilitate configuration, the following
section uses E1 in CPOS with the AU-4 multiplexing path as an example to demonstrate the
TU number calculation method.
The multiplexing process in Figure 5-3 shows that the 2 Mbit/s multiplexing structure is
3-7-3 when the AU-4 multiplexing path is used. The following formula shows how to
calculate the TU-12 numbers located in different positions in a VC-4:
VC-12 number = TUG-3 number + (TUG-2 number - 1) x 3 + (TU-12 number - 1) x 21
In a VC-4, all TUG-3s are numbered the same; all TUG-2s are numbered the same; two
TU-12s with a number difference of 1 are adjacent.

NOTE
l The numbers listed in the preceding formula stand for the positions in a VC-4 frame.
l The TUG-3 number ranges from 1 to 3; the TUG-2 number ranges from 1 to 7; the TU-12 number
ranges from 1 to 3.
l The TU-12 number indicates which one of the 63 TU-12s is in the VC-4 frame based on the
sequence and also indicates the E1 channel number.
Figure 5-3 Sequence for arranging TUG-3, TUG-2, and TU-12 in a VC-4 frame
TU-12 1
1 1
VC-4 TUG-3 TUG-2 TU-12 2
TU-12 3
TU-12 1
2 2
TUG-3 TUG-2 TU-12 2
.
. TU-12 3
.
.
.
.
TU-12 1
3 7
TUG-3 TUG-2 TU-12 2
TU-12 3
If the AU-3 multiplexing path is used, the TU-12 number calculation can be deduced in a
similar manner.
If 63 E1 channels are configured on a CPOS interface, these channels can be directly

numbered from 1 to 63. If a Router of Huawei is connected to a channelized STM-1 interface
of a router from another vendor, take note of the differences in channel numbers.
Overhead Bytes
SDH provides monitoring and management at layers. Monitoring is classified as section
monitoring or path monitoring. Section monitoring is classified as regenerator section
monitoring or multiplex section monitoring. Path monitoring is classified as higher-order path
monitoring or lower-order path monitoring. Different overhead bytes help to implement the
NOTE
This section describes only the SDH overhead bytes used in configuration.

l SOH
SOH consists of RSOH and MSOH.
The payload of an STM-N frame contains the path overhead (POH) that monitors low-
speed tributary signals.
J0, the regenerator section trace byte, is contained in RSOH. This byte is used to transmit
the service access point identifiers (SAPIs) repeatedly to check the connection between
the receiver and the transmitter. The byte can be any character in a carrier's network,
whereas the J0 bytes of the receiver and transmitter must match each other at the border
of two carriers' networks. With the J0 byte, a carrier can locate and rectify faults in
advance to speed up network recovery.
l Path overhead
SOH monitors section layers, whereas POH monitors path layers. POH is classified as
lower-order path overhead or higher-order path overhead.
The higher-order path overhead monitors the paths at VC-4 and VC-3 levels.
J1, the higher-order VC-N path trace byte, is contained in the higher-order path
overhead. Similar to J0, J1 is used to transmit SAPIs repeatedly to check the connection
between the receiver and the transmitter. The J1 bytes of the receiver and transmitter
must match each other.
C2, the path signal label byte, is contained in higher-order path overhead. C2 is used to
specify the multiplexing structure and the attributes of the information payload in a VC
frame, including whether the path is loaded with services, service types, and the mapping
mode. The C2 bytes of the receiver and transmitter must match each other.
CPOS Interface Types

As shown in Figure 5-4, some governmental agencies and enterprises use low-end and mid-
range devices to access the transmission network over E1 leased lines. Users with bandwidth
requirements between E1 and T3 (44 Mbit/s), such as data centers, use several E1 leased lines
simultaneously.
The bandwidth of these users aggregates on one or more CPOS interfaces over the
transmission network. CPOS interfaces are then connected to the high-end device that
identifies each low-end device based on timeslots.
Figure 5-4 Networking diagram of typical CPOS implementation
N×2M
Transmission Internet
network
E1 DeviceA
Access
network
N×64K

In practice, there may be more than one level of transmission networks between CPOS
interfaces and low-end devices. Other transmission devices are needed to relay
communication between low-end devices and transmission networks. Logically, such an
implementation is equivalent to the networking mode in which each low-end device is
connected to Device A over an E1 leased line or N x E1 leased lines.
5.2 Configuring a CPOS Interface

Before you configure a channelized packet over SONET/SDH (CPOS) interface, familiarize
yourself with the usage scenario and complete the pre-configuration tasks. Here, SDH stands
for synchronous digital hierarchy.
Usage Scenario
Before you use the serial interfaces formed by the E1 channels of a CPOS interface to
transmit packets, configure the physical attributes and E1 channels of the CPOS interface.
Before configuring a CPOS interface, power on the device and ensure that it is working
properly.
5.2.1 Configuring the Working Mode of a CPOS Interface

A CPOS interface can work in either clear channel mode or channelized mode. Synchronous
serial interfaces with different transmission rates can be generated in the two modes to meet
different bandwidth requirements of services.
Context
If a CPOS interface works in clear channel mode, synchronous serial interfaces with higher
transmission rates can be generated, so that the CPOS interface can provide sufficient
bandwidth for service bearer.
If a CPOS interface works in channelized mode, the E1 channels of the CPOS interface can
generate synchronous serial interfaces with different transmission rates when they work in
different modes:
l In clear channel mode, an E1 channel functions as a synchronous serial interface without
timeslot division and with a transmission rate of 2.048 Mbit/s.
l In channelized mode, an E1 channel is divided into 32 timeslots numbered from 0 to 31.
Timeslots 1 to 31 can be randomly bundled to generate logical channels with
transmission rates of N x 64 kbit/s.
Procedure
l Configure a CPOS interface to work in channelized mode.
– Configure an E1 channel of the CPOS interface to work in clear channel mode so
that a trunk serial interface is generated.
i. Run system-view

ii. Run controller cpos cpos-number

The CPOS interface view is displayed.
iii. Run e1 e1-number unframed
The specified E1 channel is configured to work in clear channel mode, and a
serial interface with a transmission rate of 2.048 Mbit/s is created.
By default, an E1 channel works in channelized mode.
In VS mode, this command is supported only by the admin VS.
After the serial interface is created, you can run the interface serial cpos-
number/e1-number:0 command to enter the serial interface view.
iv. Run commit
– Configure an E1 channel of a CPOS interface to work in channelized mode so that a
trunk serial interface in channelized mode can be generated.
i. Run system-view
ii. Run controller cpos cpos-number
iii. Run e1 e1-number channel-set set-number timeslot-list
The specified timeslots of the specified E1 channel are bundled to generate a
serial interface with a transmission rate of N x 64 kbit/s. N indicates the
number of bundled timeslots.
After the serial interface is configured, you can run the interface serial cpos-
number/e1-number:set-number command to enter the serial interface view.
iv. Run commit
l Configure a CPOS interface to work in clear channel mode.
a. Run system-view
b. Run controller cpos cpos-number
c. Run using vc4
The CPOS interface is configured to work in clear channel mode, and a
synchronous serial interface is created on the CPOS interface. The synchronous
serial interface transmits data at 150.336 Mbit/s, without timeslot division.
cpos-number/0:0 command to enter the serial interface view.
d. Run commit
5.2.2 Configuring the Clock Mode for a CPOS Interface

A CPOS interface works in either master clock mode or slave clock mode. You can configure
the clock mode for a CPOS interface.

Context
A CPOS interface supports the following clock modes:
l Master clock mode: uses internal clock signals.
l Slave clock mode: uses line clock signals.
When a CPOS interface is connected to an SDH device, configure the CPOS interface to work
in slave clock mode because the precision of the clock in the SDH network is higher than the
precision of the internal clock source of the CPOS interface.
Procedure
Step 2 Run controller cpos cpos-number
A clock mode is configured for the CPOS interface.
Step 4 Run commit
----End
5.2.3 Configuring the Working Modes for the E1 Channels of a

CPOS Interface
This section describes how to configure the working modes for the E1 channels of a
channelized packet over SONET/SDH (CPOS) interface. Here, SONET stands for
synchronous optical network, and SDH stands for synchronous digital hierarchy.
Context
The E1 channels of a CPOS interface can form serial interfaces with different transmission
rates when they work in different modes:
l In clear channel mode, an E1 channel functions as a serial interface without timeslot
division and with a transmission rate of 2.048 Mbit/s.
l In channelized mode, an E1 channel is divided into 32 timeslots numbered from 0 to 31.
Timeslots 1 to 31 can be randomly bundled to form logical channels with transmission
rates of N x 64 kbit/s.
Procedure
l Create a serial interface in clear channel mode.
a. Run system-view


c. Run e1 e1-number unframed
The specified E1 channel is configured to work in clear channel mode, and a serial
interface with a transmission rate of 2.048 Mbit/s is created.
By default, an E1 channel works in channelized mode.
After the serial interface is created, you can run the interface serial cpos-
number/e1-number:0 command to enter the serial interface view.
d. Run commit
l Create a serial interface in channelized mode.
a. Run system-view
c. Run e1 e1-number channel-set set-number timeslot-list
The specified timeslots of the specified E1 channel are bundled to form a serial
interface with a transmission rate of N x 64 kbit/s. N indicates the number of
bundled timeslots.
After the serial interface is configured, you can run the interface serial cpos-
number/e1-number:set-number command to enter the serial interface view.
d. Run commit
5.2.4 Configuring Overhead Bytes for a CPOS Interface

SDH provides a variety of overhead bytes. You can configure overhead bytes for CPOS
interfaces to implement monitoring at different levels.
Context
SDH provides a variety of overhead bytes, which perform the monitoring function of different
levels.
l C2, the path signal label byte, is contained in the higher-order path overhead. C2 is used
to specify the multiplexing structure and the attributes of the information payload in a
VC frame.
l J0, the regenerator section trace byte, is contained in the section overhead. J0 is used to
check the continuity between two ports at the section layer.
l J1, the higher-order VC-N path trace byte, is used to check the continuity between two
ports at the path layer.
Procedure

Step 3 Perform the following commands as required.

l To configure the regenerator section trace byte J0, run:
flag j0 sdh j0
l To configure the path trace byte J1, run:

flag j1 j1
l To configure path signal label byte C2, run:

flag c2 c2
C2, J0, and J1 of the receiver must be the same as those of the transmitter; otherwise, an alarm
is generated.
Step 4 Run commit
----End
5.2.5 Configuring the Mapping Mode for the E1 Channels of a

CPOS Interface
CPOS interfaces support three E1 channel mapping modes: a-mode, h-mode, and l-mode.
Context
Different vendors' devices have different number calculation formulas for multiplexing CPOS
E1 to STM-1.
To enable a device to interwork with other vendors' devices using CPOS interfaces, you must
ensure that the E1 channel mapping mode on the device is the same as that on other vendors'
devices.
Procedure
Step 3 Run mapping-mode { a-mode | h-mode | l-mode }
An E1 channel mapping mode is configured for the CPOS interface.
Before configuring the E1 channel mapping mode of a CPOS interface, ensure that no E1
channel is created on the CPOS interface.
l a-mode:

Configures the Alcatel mode (a-mode) as the E1 channel mapping mode of a CPOS
interface. This mode applies when the E1 channel mapping mode of the interconnected
device is the Alcatel mode. In this mode, E1 channel number = (TUG-3 number – 1) x
21 + TUG-2 number + (TU-12 number – 1) x 7.
l h-mode:
Configures the Huawei mode (h-mode) as the E1 channel mapping mode of a CPOS
device is the Huawei mode. In this mode, E1 channel number = TUG-3 number +
(TUG-2 number – 1) x 3 + (TU-12 number – 1) x 21.
l l-mode:
Configures the Lucent mode (l-mode) as the E1 channel mapping mode of a CPOS
device is the Lucent mode. In this mode, E1 channel number = (TUG-3 number – 1) ×
21 + (TUG-2 number – 1) x 3 + TU-12 number
NOTE
The numbers listed in the preceding formula stand for the positions in a VC-4 frame. The TUG-3
number ranges from 1 to 3; the TUG-2 number ranges from 1 to 7; the TU-12 number ranges from 1 to
3.
Step 4 Run commit
----End
5.2.6 Configuring the Clock Mode for the E1 Channels of a CPOS

Interface
An E1 channel works in either master clock mode or slave clock mode.
Context
The clock modes of different E1 channels on the same CPOS interface are independent of
each other.
When CPOS interfaces on two devices are directly connected, one E1 channel must be
configured to work in master clock mode and use internal clock signals, and the other E1
channel must be configured to work in slave clock mode and use line clock signals.
Procedure
Step 3 Run e1 e1-number set clock { master | slave }
A clock mode is configured for the E1 channel.
Step 4 Run commit

----End
5.2.7 Configuring the Frame Format for the E1 Channels of a

CPOS Interface
E1 channels support the frame format with a 4-bit CRC code.
Procedure
Step 3 Run e1 e1-number set frame-format { crc4 | no-crc4 }
A frame format is configured for the E1 channel.
The frame format of the E1 channel must be the same on the local and remote devices.
Step 4 Run commit
----End
5.2.8 Configuring the Loopback Function for the E1 Channels of a

CPOS Interface
You can enable the loopback function on an interface to check whether the interface or the
link works properly.
Procedure
Step 3 Run e1 e1-number set loopback { local | remote } [ autoclear period hold-time ]
A loopback mode is configured for the E1 channel.

NOTE
l To enable local loopback for an E1 channel, the channel must work in master clock mode.
l To enable remote loopback for an E1 channel, the channel must work in slave clock mode.
Step 4 Run commit
----End
5.2.9 Configuring the Loopback Function for a CPOS Interface

This section describes how to configure the loopback function on a channelized packet over
SONET/SDH (CPOS) interface. Here, SONET stands for synchronous optical network, and
SDH stands for synchronous digital hierarchy. The loopback function is used to check
interface or cable status when devices are malfunctioning and must be disabled when devices
are working properly.
Context
The loopback function has two types:
l Local loopback: is used to locate a system fault.
l Remote loopback: is used to locate a link fault or test the quality of a link.
NOTE
l To enable local loopback on a CPOS interface, ensure that the clock of the CPOS interface works in
master mode.
Procedure
Step 3 Run loopback { local | remote } [ autoclear period hold-time ]
The loopback function is enabled on the CPOS interface.
To enable the CPOS interface to delete the loopback configuration after a specified period,
specify autoclear period hold-time in the command. This function takes effect when
loopback is enabled. After the time specified by hold-time elapses, the loopback configuration
is automatically deleted.
By default, the loopback function is disabled on a CPOS interface.
Step 4 Run commit
----End

5.2.10 Verifying the CPOS Interface Configuration

After you configure a channelized packet over SONET/SDH (CPOS) interface, you can check
the clock mode, frame format, overhead byte, and administrative unit group (AUG)
multiplexing path of the interface and the clock mode and frame format of its E1 channels.
Here, SONET stands for synchronous optical network, and SDH stands for synchronous
digital hierarchy.
Prerequisites
A CPOS interface has been configured.
Procedure
l Run the display interface serial [ interface-number ] command to check the status and
statistics of a serial interface.
l Run the display controller cpos [ cpos-number ] command to check the status and
configurations of a CPOS interface.
----End
5.3 Configuring a CPOS-Trunk Interface

Configuring a CPOS-Trunk interface includes creating a CPOS-Trunk interface, adding a
CPOS interface to the CPOS-Trunk interface, and creating a trunk serial interface on the
CPOS-Trunk interface.
Usage Scenario
A CPOS-Trunk interface is a logical interface that has all the functions of a CPOS interface. It
is more reliable because it has multiple CPOS interfaces bundled using the link aggregation
technology.
After a CPOS-Trunk interface is created, APS can be configured on the interface.
Before configuring a CPOS-Trunk interface, power on the device and ensure that the self-
check succeeds.
5.3.1 Creating a CPOS-Trunk Interface

Before adding a CPOS interface to a CPOS-Trunk interface, create the CPOS-Trunk interface.
Context
APS can be configured on the trunk serial interface channelized from a CPOS-Trunk interface
only after CPOS interfaces are added to the CPOS-Trunk interface.
Procedure
Step 1 Create a CPOS-Trunk interface.

1. Run system-view
2. Run interface cpos-trunk trunk-id
A CPOS-Trunk interface is created. If the CPOS-Trunk interface already exists, the
CPOS-Trunk interface view is displayed.
Step 2 Add a CPOS interface to the CPOS-Trunk interface.
1. Run controller cpos cpos-number
2. Run cpos-trunk trunk-id
The CPOS interface is added to the CPOS-Trunk interface.
NOTE
Before adding a CPOS interface to a CPOS-Trunk interface, run the aps group command on the CPOS
interface to add it to an LMSP group, and configure the interface as a working interface or a protection
interface. For more details, see LMSP Configuration.
After a CPOS interface is added to a CPOS-Trunk interface, the following situations occur:
l If you run the shutdown command on the CPOS-Trunk interface, the physical status of both the
CPOS-Trunk and CPOS interfaces becomes Administratively DOWN, and the shutdown
command configuration is automatically generated for the CPOS interface in the configuration
file.
l If you run the undo shutdown command on the CPOS-Trunk interface, the undo shutdown
command configuration is automatically generated for the CPOS interface in the configuration
file.
Step 3 Run commit

----End
5.3.2 Configuring the Working Mode of a CPOS-Trunk Interface
Context
A CPOS-Trunk interface can work in either clear channel mode or channelized mode. Trunk
serial interfaces with different transmission rates can be generated in the two modes to meet
different bandwidth requirements of services.
NOTE
The configuration of channelized mode is supported only on the Admin-VS.
Procedure
l Configure a CPOS-Trunk interface to work in channelized mode.
– Configure an E1 channel of a CPOS-Trunk interface to work in clear channel mode
so that a trunk serial interface is generated.
i. Run system-view
ii. Run interface cpos-trunk trunk-id

The CPOS-Trunk interface view is displayed.

iii. Run e1 e1-number unframed
An E1 channel of the CPOS-Trunk interface is configured to work in clear
channel mode, and a trunk serial interface is generated.
After the trunk serial interface in clear channel mode is generated, you can run
the interface trunk-serial cpos-trunk-id/e1-number:0 command to enter the
trunk serial interface view.
iv. Run commit
– Configure an E1 channel of a CPOS-Trunk interface to work in channelized mode
so that a trunk serial interface in channelized mode can be generated.
i. Run system-view
ii. Run interface cpos-trunk trunk-id
iii. Run e1 e1-number channel-set set-number timeslot-list
Timeslots of an E1 channel of the CPOS-Trunk interface are bundled, and a
trunk serial interface is generated.
After the trunk serial interface in channelized mode is generated, you can run
the interface trunk-serial cpos-trunk-id/e1-number:set-number command to
enter the trunk serial interface view.
iv. Run commit
l Configure a CPOS-Trunk interface to work in clear channel mode.
a. Run system-view
b. Run interface cpos-trunk trunk-id
c. Run using vc4
The CPOS-Trunk interface is configured to work in clear channel mode, and a trunk
serial interface is created on the CPOS-Trunk interface. The trunk serial interface
transmits data at a high rate, without timeslot division.
After the trunk serial interface is created, you can run the interface trunk-serial
cpos-trunk-id/0:0 command to enter the trunk serial interface view.
d. Run commit
5.3.3 Configuring a Working Mode for an E1 Channel of a CPOS-

Trunk Interface
An E1 channel of a CPOS-Trunk interface can be configured to work in clear channel or
channelized mode to form trunk serial interfaces with different bandwidths.

Procedure
l Configure an E1 channel of a CPOS-Trunk interface to work in clear channel mode so
that a trunk serial interface is generated.
a. Run system-view
c. Run e1 e1-number unframed
An E1 channel of the CPOS-Trunk interface is configured to work in clear channel
mode, and a trunk serial interface is generated.
After the trunk serial interface in clear channel mode is generated, you can run the
interface trunk-serial cpos-trunk-id/e1-number:0 command to enter the trunk
serial interface view.
d. Run commit
l Configure an E1 channel of a CPOS-Trunk interface to work in channelized mode so that
a trunk serial interface in channelized mode can be generated.
a. Run system-view
c. Run e1 e1-number channel-set set-number timeslot-list
Timeslots of an E1 channel of the CPOS-Trunk interface are bundled, and a trunk
serial interface is generated.
After the trunk serial interface in channelized mode is generated, you can run the
interface trunk-serial cpos-trunk-id/e1-number:set-number command to enter the
trunk serial interface view.
d. Run commit
----End
5.3.4 Creating a Global MP-Group or IMA-Group Interface and

Adding a Trunk Serial Interface to It
To increase transmission bandwidth and improve network reliability, add trunk serial
interfaces to a global MP-group or IMA-group interface.
Context
To improve network reliability, a protection channel can be configured to take over traffic
from one or more working channels if the working channels fail.
Before deploying and protecting PPP or ATM services on CPOS interfaces, add two CPOS
interfaces to a CPOS-Trunk interface and channelize the CPOS-Trunk interface into trunk

serial interfaces. Then, add the trunk serial interfaces to a global MP-group or IMA-group
interface to carry the PPP or ATM services. If one CPOS link fails, the other CPOS link takes
over traffic.
Procedure
l Create a global MP-group interface and add a trunk serial interface to it.
a. Create a global MP-group interface.
i. Run system-view
ii. Run interface global-mp-group global-mp-group-number
A global MP-group interface is created.
iii. Run commit
b. Add a trunk serial interface to the global MP-group interface.
i. Run system-view
ii. Run interface trunk-serial trunk-serial-id
The trunk serial interface view is displayed.
iii. Run link-protocol ppp
The link layer protocol is configured as PPP for the trunk serial interface.
iv. Run ppp mp-global global-mp-group global-mp-group-number
The trunk serial interface is added to the global MP-group interface.
v. Run commit
l Create a global IMA-group interface and add a trunk serial interface to it.
a. Create a global IMA-group interface.
i. Run system-view
ii. Run interface global-ima-group global-ima-group-number
A global IMA-group interface is created.
iii. Run commit
b. Add a trunk serial interface to the global IMA-group interface.
i. Run system-view
iii. Run link-protocol atm
The link layer protocol is configured as ATM for the trunk serial interface.
iv. Run ima global-ima-group global-ima-group-number
The trunk serial interface is added to the global IMA-group interface.

NOTE
After a trunk serial interface is added to a global IMA-group interface, the interface type
previously configured for the global IMA-group interface becomes invalid. To reconfigure
an interface type for the global IMA-group interface, run the atm interface-type { uni |
nni } command in the global IMA-group interface view.
l If a device connects to a user-side device, configure the IMA-group interface as a
UNI.
l If a device connects to another network-side device, configure the IMA-group
interface as an NNI.
\
v. Run commit
----End
5.3.5 Creating a Global MP-Group or IMA-Group Interface and

Adding a Trunk Serial Interface to It
To increase transmission bandwidth and improve network reliability, add trunk serial
interfaces to a global MP-group or IMA-group interface.
Context
To improve network reliability, a protection channel can be configured to take over traffic
from one or more working channels if the working channels fail.
Before deploying and protecting PPP or ATM services on CPOS interfaces, add two CPOS
interfaces to a CPOS-Trunk interface and channelize the CPOS-Trunk interface into trunk
serial interfaces. Then, add the trunk serial interfaces to a global MP-group or IMA-group
interface to carry the PPP or ATM services. If one CPOS link fails, the other CPOS link takes
over traffic.
Procedure
l Create a global MP-group interface and add a trunk serial interface to it.
a. Create a global MP-group interface.
i. Run system-view
ii. Run interface global-mp-group global-mp-group-number
A global MP-group interface is created.
iii. Run commit
b. Add a trunk serial interface to the global MP-group interface.
i. Run system-view
iii. Run link-protocol ppp

The link layer protocol is configured as PPP for the trunk serial interface.
iv. Run ppp mp-global global-mp-group global-mp-group-number
The trunk serial interface is added to the global MP-group interface.
v. Run commit
l Create a global IMA-group interface and add a trunk serial interface to it.
a. Create a global IMA-group interface.
i. Run system-view
ii. Run interface global-ima-group global-ima-group-number
A global IMA-group interface is created.
iii. Run commit
b. Add a trunk serial interface to the global IMA-group interface.
i. Run system-view
iii. Run link-protocol atm
The link layer protocol is configured as ATM for the trunk serial interface.
iv. Run ima global-ima-group global-ima-group-number
The trunk serial interface is added to the global IMA-group interface.
NOTE
After a trunk serial interface is added to a global IMA-group interface, the interface type
previously configured for the global IMA-group interface becomes invalid. To reconfigure
an interface type for the global IMA-group interface, run the atm interface-type { uni |
nni } command in the global IMA-group interface view.
l If a device connects to a user-side device, configure the IMA-group interface as a
UNI.
l If a device connects to another network-side device, configure the IMA-group
interface as an NNI.
\
v. Run commit
----End
5.3.6 Verifying the CPOS-Trunk Interface Configuration

After configuring a CPOS-Trunk interface, check the configurations and status of the CPOS-
Trunk interface.
Prerequisites
A CPOS-Trunk interface has been configured.

Procedure
l Run the display cpos-trunk trunk-id command to check the configurations of a CPOS-
Trunk interface.
l Run the display interface trunk-serial [ trunk-serial-id ] command to check the status
and packet statistics of a specified or all trunk serial interfaces.
l Run the display ppp mp-global [ interface global-mp-group interface-number ]
command to check the configurations of a global MP-group interface.
l Run the display interface global-ima-group [ global-ima-group-number ]command to
check configurations and status of a global IMA-group interface.
----End
5.4 Maintaining a CPOS Interface

You can test the bit error rate of a CPOS E1 link to maintain the CPOS interface.
5.4.1 Testing the Bit Error Rate of a CPOS E1 Link

The testing results can be used to locate link faults.
Context
NOTE
When faults occur on a CPOS E1 link, you can run the test connectivity controller cpos e1
command for fault locating.
Procedure
Step 2 Run test connectivity controller cpos e1 controller-number { unframed | channelized
timeslot-list slot-list } duration time
The bit error rate is tested on a specified CPOS E1 link.
----End
5.4.2 Clearing Error Statistics and Alarm Status Information on an

E1 Interface or on a CPOS Interface's E1 Channels
Context
NOTE
This section describes how to clear error statistics and alarm status information on an E1
interface or on a CPOS interface's E1 channels.

Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the reset e1 counters controller cpos controller-number e1 e1-number command to
clear error statistics and alarm status information on a CPOS interface's E1 channels or run
the reset e1 counters controller e1 controller-number command to clear error statistics and
alarm status information on an E1 interface.
----End
5.4.3 Monitoring the Physical Status of E1 Links

To ensure correct link connections, you must monitor the physical status of E1 links.
Context
Monitoring the physical status of E1 links can help you locate E1 link faults, ensuring correct
link connections. You can configure the system to monitor the physical status of multiple E1
links simultaneously while not affecting existing services.
Perform the following steps on a device to be checked:
Procedure
Step 1 Run monitor e1 { interface-type interface-number | interface-name } &<1-16> [ interval
interval [ times times ] | times times [ interval interval ] ]
The physical status of E1 links is monitored.
----End
5.5 Configuration Examples for CPOS Interfaces

This section provides CPOS configuration examples.
5.5.1 Example for Configuring CPOS Interfaces

This example shows how to interconnect devices through CPOS interfaces over an FR
network.
CPOS interfaces are used to improve the convergence capability of low-speed access for
Routers. STM-1 CPOS interfaces are often used to converge multiple E1/T1 interfaces.
At present, some governmental agencies and enterprises use low-end and mid-range devices
to access the transmission network through E1/T1 leased lines. Users requiring bandwidth
between E1/T1 and T3 (44M), such as the date center, lease several E1/T1 interfaces
simultaneously. Bandwidth of these users converges on one or multiple CPOS interfaces
through the transmission network. CPOS interfaces are then connected to Device A that
identifies each low-end device through timeslots.

In application, there may be more than one level of transmission networks between CPOS
interfaces and low-end devices. Other transmission devices are needed to relay
communication between low-end devices and transmission networks.
Figure 5-5 Networking diagram of using STM-1 CPOS interface
Enterprise
Intranet
Governmental
Office E1/T1
ADM
E1/T1
ADM STM-4/16 ADM
STM-
1/STM-4
ADM Device A
n×E1/T1
Device B
DataCenter
1. Create the channel.
2. Create the channel-set.
3. Bundle the channel into the channel-set.
Data Preparation

l Channel number and timeslot number of each E1 channel

l Number of the channel-set of each interface
Procedure
# Create a channel on the CPOS interface.
[*DeviceA] controller cpos 0/1/0
[*DeviceA-Cpos0/1/0] e1 1 channel-set 1 timeslot-list 1-10
[*DeviceA-Cpos0/1/0] undo shutdown
[*DeviceA-Cpos0/1/0] quit
[*DeviceA] commit
# Create a channel-set and configure the endpoint authenticator.

[~DeviceA] interface mp-group 0/3/0
[*DeviceA-Mpgroup0/3/0] discriminator
[*DeviceA-Mpgroup0/3/0] undo shutdown
[*DeviceA-Mpgroup0/3/0] quit
[*DeviceA] commit
# Bundle the channel into the channel-set.

[~DeviceA] interface Serial 0/1/0/1:1
[~DeviceA-Serial0/1/0/1:1] link-protocol ppp
[*DeviceA-Serial0/1/0/1:1] ppp mp mp-group 0/3/0
[*DeviceA-Serial0/1/0/1:1] quit
[*DeviceA] interface Serial 0/1/0/2:2
[*DeviceA-Serial0/1/0/2:2] link-protocol ppp
[*DeviceA] commit

# Create the channel on the E1 interface.
[*DeviceB] controller E1 0/2/9
[*DeviceB-E10/2/9] channel-set 0 timeslot-list 1-31
[*DeviceB-E10/2/9] undo shutdown
[*DeviceB-E10/2/9] quit
[*DeviceB] commit
# Create a channel-set.
[~DeviceB] interface mp-group 0/2/9
[*DeviceB-Mp-group0/2/9] discriminator
[*DeviceB-Mp-group0/2/9] undo shutdown
[*DeviceB-Mp-group0/2/9] quit
[*DeviceB] commit

# Bundle the channel into the channel-set.

[~DeviceB] interface Serial0/2/9:0
[*DeviceB-Serial0/2/9:0] ppp mp mp-group 0/2/9
[*DeviceB] commit
----End
Configuration Files
#
sysname DeviceA
#
controller Cpos0/1/0
e1 1 channel-set 1 timeslot-list 1-10
undo shutdown
#
interface Serial0/1/0/1:1
link-protocol ppp
ppp mp Mp-group 0/3/0
#
link-protocol ppp
#
link-protocol ppp
#
link-protocol ppp
#
interface Mp-group0/3/0
#
return

#
sysname DeviceB
#
controller E1 0/2/9
undo shutdown
#
interface Mp-group 0/2/9
#
link-protocol ppp
#
return
5.5.2 Example for Configuring CPOS Interface Interconnection

This section provides an example on how to interconnect devices through CPOS interfaces
and how to configure MP-group interfaces for link bundling.

other through CPOS interfaces, and MP-group interfaces need to be configured for link
bundling.
Figure 5-6 Configuring CPOS interface interconnection

NOTE
In this example, interface1 and interface2 represent CPOS 0/3/0 and CPOS 0/2/9, respectively.
DeviceA DeviceB
1. Configure a working mode for CPOS interfaces and channelize them into synchronous
serial interfaces.
2. Configure MP-group interfaces and add the synchronous serial interfaces to the MP-
group interfaces.
Data Preparation
l Channel number and timeslot number of each E1 channel
l IP addresses of MP-group interfaces
NOTE
The interface to be added to an MP-group interface must have the same slot number and card number as
the MP-group interface.
Procedure
Step 1 Configure a working mode for CPOS interfaces and channelize them into synchronous serial
interfaces.
# Create synchronous serial interfaces on the CPOS interface of Device A.
[*DeviceA-Cpos0/3/0] commit
[~DeviceA-Cpos0/3/0] quit
# Create synchronous serial interfaces on the CPOS interface of Device B.

[*DeviceB] controller cpos 0/2/9
[*DeviceB-Cpos0/2/9] e1 1 channel-set 1 timeslot-list 1-15
[*DeviceB-Cpos0/2/9] e1 2 channel-set 1 timeslot-list 16-31
[*DeviceB-Cpos0/2/9] undo shutdown
[*DeviceB-Cpos0/2/9] commit
[~DeviceB-Cpos0/2/9] quit
Step 2 Configure MP-group interfaces and add the synchronous serial interfaces to the MP-group
interfaces.
# Create an MP-group interface on Device A.
[*DeviceA-Mp-group0/3/0] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Mp-group0/3/0] undo shutdown
[*DeviceA-Mp-group0/3/0] commit
[~DeviceA-Mp-group0/3/0] quit
# Add the synchronous serial interfaces to the MP-group interface on Device A.

[~DeviceA] interface serial 0/3/0/1:1
[*DeviceA-Serial0/3/0/1:1] commit
[~DeviceA-Serial0/3/0/1:1] quit
# Create an MP-group interface on Device B.

[*DeviceB-Mp-group0/2/9] ip address 10.1.1.2 255.255.255.0
[*DeviceB-Mp-group0/2/9] commit
[~DeviceB-Mp-group0/2/9] quit
# Add the synchronous serial interfaces to the MP-group interface on Device B.

[~DeviceB] interface serial 0/2/9/1:1
[~DeviceB-Serial0/2/9/1:1] link-protocol ppp
[*DeviceB-Serial0/2/9/1:1] ppp mp mp-group 0/2/9
[*DeviceB-Serial0/2/9/1:1] commit
[~DeviceB-Serial0/2/9/1:1] quit
[~DeviceB] interface serial 0/2/9/2:1
[~DeviceB-Serial0/2/9/2:1] link-protocol ppp
[*DeviceB-Serial0/2/9/2:1] ppp mp mp-group 0/2/9
[*DeviceB-Serial0/2/9/2:1] commit
[~DeviceB-Serial0/2/9/2:1] quit

# On Device A, ping the IP address of the MP-group interface on Device B. The command
output shows that the ping is successful.

0.00% packet loss

----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
#
#
link-protocol ppp
ppp mp Mp-group0/3/0
#
link-protocol ppp
#
return

#
sysname DeviceB
#
undo shutdown
#
#
link-protocol ppp
#
link-protocol ppp
#
return
5.5.3 Example for Configuring CPOS Interface and E1 Interface

Interconnection
This section provides an example on how to interconnect devices through CPOS interface and
E1 interface, and how to configure MP-group interfaces for link bundling.
other through CPOS interface and E1 interfaces, and MP-group interfaces need to be
configured for link bundling.

Figure 5-7 Configuring CPOS interface and E1 Interface interconnection

NOTE
In this example, interface1, interface2, and interface3 represent CPOS 0/3/0, E1 0/2/0, and E1 0/2/1,
respectively.
interface3
DeviceA DeviceB
1. Configure a working mode for CPOS interfaces.
2. Configure MP-group interfaces and add the synchronous serial interfaces to the MP-
group interfaces.
Data Preparation
l IP addresses of MP-group interfaces
NOTE
Procedure
Step 1 Configure a working mode for CPOS interfaces and create synchronous serial interfaces.
# Create synchronous serial interfaces on the CPOS interface of Device A.
[*DeviceA-Cpos0/3/0] e1 1 unframed
[*DeviceA-Cpos0/3/0] e1 2 unframed
# # Create synchronous serial interfaces on the E1 interface of Device B.

[*DeviceB] controller e1 0/2/0
[*DeviceB-E10/2/0] using e1
[*DeviceB-E10/2/0] commit
[~DeviceB-E10/2/0] quit
[*DeviceB] controller e1 0/2/1
[*DeviceB-E10/2/1] using e1
[*DeviceB-E10/2/1] commit
[~DeviceB-E10/2/1] quit

Step 2 Configure MP-group interfaces and add the synchronous serial interfaces to the MP-group
interfaces.
# Create an MP-group interface on Device A.

[*DeviceA-Mp-group0/3/0] undo shutdown
# Add the synchronous serial interfaces to the MP-group interface on Device A.

# Create an MP-group interface on Device B.

# Add the synchronous serial interfaces to the MP-group interface on Device B.

# On Device A, ping the IP address of the MP-group interface on Device B. The command
output shows that the ping is successful.
0.00% packet loss
----End

Configuration Files
#
sysname DeviceA
#
e1 1 unframed
e1 2 unframed
undo shutdown
#
#
link-protocol ppp
#
link-protocol ppp
#
return

#
sysname DeviceB
#
controller E1 0/2/0
using e1
undo shutdown
#
controller E1 0/2/1
using e1
undo shutdown
#
#
link-protocol ppp
#
link-protocol ppp
#
return

Configuration Guide - WAN Access 6 FR Configuration
6 FR Configuration
About This Chapter
Frame Relay (FR) is a fast packet switching technology used to forward and switch data in a
simple manner at the link layer. FR allows devices to communicate with each other through
virtual circuits (VCs).
6.1 Overview of FR
FR is a standard protocol for communication between devices at the data link layer. Multiple
upper-layer protocols can be deployed on an FR-capable network.
6.2 Configuring Basic FR Functions
FR uses VCs and works at the physical and data link layers of the OSI model. FR is
characterized by high throughput and short delay and is applicable in case of burst service
traffic.
6.3 Configuration Examples for FR
This section provides FR configuration examples.
6.1 Overview of FR
FR is a standard protocol for communication between devices at the data link layer. Multiple
upper-layer protocols can be deployed on an FR-capable network.
6.1.1 Introduction
FR allows user devices, such as routers and hosts, to exchange data on an FR-capable
network.
A conventional wide area network (WAN) uses X.25, frame relay (FR), or ATM. Any of these
link-layer protocols can transmit data from one local area network (LAN) over a WAN to
another LAN. As terminals become intelligent and the quality of physical links improves, the
functions of error control and flow control for data at the data link layer on X.25 networks are
no longer required. In addition, limited bandwidth resources on X.25 networks cannot meet
requirements for services. Due to expensive ATM-capable devices and complicated
compatibility, ATM networks are unsuitable for large-scale deployment. Although the
bandwidth provided by FR-capable networks is lower than that provided by ATM networks,

FR-capable networks boast of short delays and low costs, and thereby are preferentially used
to upgrade X.25 networks.
FR simplifies Layer 3 functions of X.25. As a statistics multiplexing protocol, FR provides
multiple VCs over a single physical link. Devices at both ends of each link are connected
using a VC at Layer 2. VCs are differentiated by data link connection identifiers (DLCIs), and
several VCs can form a Permanent Virtual Circuit (PVC). On each PVC, the Local
Management Interface (LMI) protocol uses status enquiry messages and state messages to
maintain link and PVC status.
DLCI
A DLCI identifies a VC and is valid only on the local interface and its directly connected
interface at the remote end. Therefore, the same DLCI on different physical interfaces identify
different VCs on an FR-capable network.
DTE, DCE, UNI, and NNI

FR-capable networks allow devices to exchange data. Roles of devices and interfaces on FR-
capable networks are as follows:
l DTE: data terminal equipment
l DCE: data communication equipment, providing access services for DTEs
l UNI: user-network interface, interconnecting a DTE and a DCE
l NNI: network-network interface, interconnecting DCEs
LMI
After a PVC is set up, both the DCE and DTE need to know the PVC status. The LMI
protocol uses status enquiry messages and state messages to maintain link and PVC status.
For example, LMI adds PVC status information, deletes information about disconnected
PVCs, monitors PVC status changes, and checks ink integrity. LMI is defined in the following
documents:
l ITU-T Q.933 Appendix A
l ANSI T1.617 Appendix D
l Non-standard compatible protocol
Parameters for LMI Packet Exchange

The parameters for LMI packet exchange can be configured to optimize device performance.

Table 6-1 Description of parameters for LMI packet exchange

Device Paramete Parameter Description Description
r
DTE N391 Specifies the Full status (status The DTE sends a full status
of all PVCs) polling counter. report or a link integrity
verification only report at an
interval specified by T391. The
number of full status reports
and link integrity verification
only reports to be sent is
determined using the formula:
Number of link integrity
verification only reports :
Number of full status reports =
(N391 - 1) : 1.
N392 Specifies the error threshold. Specifies the threshold at which

an error is recorded.
N393 Specifies the monitored event Specifies the total number of

counter. monitored events.
T391 Specifies the polling timer at Specifies the interval at which

the user side. the DTE sends status enquiry
messages.
DCE N392 Specifies the error threshold. N392 on the DCE has similar
functions as N392 on the DTE.
However, they differ in that the
interval at which status enquiry
messages are sent is specified
by T392 on the DCE (which, in
turn, is specified by T391 on
the DTE).
N393 Specifies the monitored event N393 on the DCE has similar
counter. functions as N393 on the DTE.
However, they differ in that the
interval at which status enquiry
messages are sent is specified
by T392 on the DCE (which, in
turn, is specified by T391 on
the DTE).
T392 Specifies the polling timer at Specifies the period for which
the network side. the DCE waits for a status
enquiry message from the
DTE. The value of T392 must
be greater than that of T391.

VC
A VC is a channel or circuit established between two points on a data communications
network with packet switching. VCs can be PVCs or switched virtual circuits (SVCs).
l PVCs are manually configured.
l SVCs are automatically created and deleted through protocol negotiations.
NOTE
Currently, PVCs are more common than SVCs on FR-capable networks.
6.2 Configuring Basic FR Functions

FR uses VCs and works at the physical and data link layers of the OSI model. FR is
characterized by high throughput and short delay and is applicable in case of burst service
traffic.
Context
The Internet and IP technology has gained an overwhelming competitive edge in the
application field with their simplicity and flexibility. FR supports multiplexing. Therefore,
when IP packets enter an FR-capable network, FR devices can forward the packets to the
destination. Currently, IPoFR has become a primary alternative in deploying an IP broadband
network.
Figure 6-1 shows locations where FR can be deployed. FR deployment includes the
following parts:
l FR access (on the user side)
l FR switching (on the network side)
NOTE
Currently, only FR access is supported.
Figure 6-1 Networking for IPoFR
DTE DCE DCE DTE

FR
Network
FR Access FR Switch FR Access
FR access enables IP packets from DTEs to enter an FR-capable network and to be forwarded
by DCEs.
Before configuring basic FR functions, configure physical attributes for FR interfaces.
6.2.1 Configuring Basic FR Functions on a DCE

Before deploying FR access links, configure basic FR functions on the DCE.

Procedure
The FR interface view is displayed.
Step 3 Run link-protocol fr [ ietf | nonstandard ]
An FR encapsulation type is configured on the interface.
By default, the FR encapsulation type is IETF on the interface.
NOTE
After the FR encapsulation type on an interface is changed, the system automatically deletes all the FR
configurations on the interface. Therefore, you need to re-configure the interface.
Step 4 Run fr interface-type dce
The FR interface type is set to DCE.
By default, the FR interface type is DTE.

NOTE
After the FR interface type is changed, LMI parameters are deleted automatically.
Step 5 (Optional) Run fr lmi type { ansi | nonstandard | q933a }
The LMI protocol type is set.
By default, the LMI protocol type is Q.933a on an interface.
Step 6 (Optional) Configure basic parameters on the DCE.

1. Run the fr lmi t392dce t392-value command to configure the period for which the DCE
waits for a status enquiry message from the DTE.
2. Run the fr lmi n392dce n392-value command to configure the N392 parameter on the
DCE.
3. Run the fr lmi n393dce n393-value command to configure the N393 parameter on the
DCE.
Step 7 Run quit
Exit from the interface view.
Step 8 Run interface interface-type interface-number.subnumber [ p2p ]
The FR sub-interface view is displayed.
Step 9 Run ip address ip-address { mask | mask-length }
An IP address is configured for the FR sub-interface.
Step 10 Run fr dlci dlci
A DLCI is configured for the VC.
l If the FR interface type is DCE or NNI, a DLCI must be configured for the VC.

l If you want to change a configured DLCI, run the shutdown command to shut down the
sub-interface or delete the original DLCI.
Step 11 Run commit
----End
6.2.2 Configuring Basic FR Functions on a DTE

Before deploying FR access links, configure basic FR functions on the DTE.
Procedure
The FR interface view is displayed.
Step 3 Run link-protocol fr [ ietf | nonstandard ]
An FR encapsulation type is configured on the interface.
By default, the FR encapsulation type is IETF on the interface.
NOTE
After the FR encapsulation type on an interface is changed, the system automatically deletes all the FR
configurations on the interface. Therefore, you need to re-configure the interface.
Step 4 (Optional) Run fr interface-type dte

The FR interface type is set to DTE.
By default, the FR interface type is DTE.
NOTE
After the FR interface type is changed, LMI parameters are deleted automatically.
Step 5 (Optional) Run fr lmi type { ansi | nonstandard | q933a }

The LMI protocol type is set.
By default, the LMI protocol type is Q.933a on an interface.
Step 6 (Optional) Configure basic parameters on the DTE.
1. Run the fr lmi n391dte n391-value command to configure the N391 parameter on the
DTE.
DTE.
DTE.
Step 7 Run quit
Exit from the interface view.

Step 8 Run interface interface-type interface-number.subnumber [ p2p ]
The FR sub-interface view is displayed.
Step 9 Run ip address ip-address { mask | mask-length }
An IP address is configured for the FR sub-interface.
Step 10 Run fr dlci dlci
A DLCI is configured for the VC.
NOTE
If you want to change a configured DLCI, run the shutdown command to shut down the sub-interface or
delete the original DLCI.
Step 11 Run commit
----End
6.2.3 Verifying the Basic FR Function Configuration

After configuring basic FR functions, verify the configuration.
Prerequisites
Basic FR functions have been configured.
Procedure
l Run the display fr interface [ interface-type interface-number ] command to check FR
protocol status and interface information on a specific interface.
l Run the display fr pvc-info [ interface interface-type interface-number ] [ dlci dlci-
number ] command to check VC configurations and statistics.
l Run the display fr lmi-info [ interface interface-type interface-number ] command to
check statistics about received and sent LMI packets.
l Run the display fr statistics [ interface interface-type interface-number ] command to
check statistics about received and sent data.
----End
6.3 Configuration Examples for FR

This section provides FR configuration examples.
6.3.1 Example for Connecting LANs Through VCs

This example shows how to configure two devices in different LANs to communicate through
VCs.

On the network shown in Figure 6-2, Routers are connected to each other through POS sub-
interfaces. The type of the interface on Device A is DCE, and the type of the interface on
Device B is DTE.
Figure 6-2 Networking for connecting LANs through VCs
DeviceA DeviceB
10.1.1.1/24 10.1.1.2/24
DLCI=100
DeviceA POS0/1/0.1 10.1.1.1/24
DeviceB POS0/1/0.1 10.1.1.2/24
1. Set the link layer protocol to FR.
2. Configure interface type.
3. Configure a DLCI for each VC.
Data Preparation
l DLCI on each interface
Procedure
Step 1 Configure RouterDevice A.
# Set the link layer protocol to FR and interface type to DCE.
[*HUAWEI] commit
[~DeviceA] interface Pos0/1/0
[~DeviceA-Pos0/1/0] link-protocol fr
[*DeviceA-Pos0/1/0] fr interface-type dce


[~DeviceA] interface Pos0/1/0.1 p2p
[~DeviceA-Pos0/1/0.1] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Pos0/1/0.1] fr dlci 100
[*DeviceA-fr-dlci-Pos0/1/0.1-100] quit
[*DeviceA-Pos0/1/0.1] quit

[*DeviceA0/1/0] commit
Step 2 Configure RouterDevice B.

# Set the link layer protocol to FR and interface type to DTE.
[*HUAWEI] commit
[~DeviceB] interface Pos0/1/0
[~DeviceB-Pos0/1/0] link-protocol fr
[*DeviceB-Pos0/1/0] fr interface-type dte

[~DeviceB] interface Pos0/1/0.1 p2p
[~DeviceB-Pos0/1/0.1] ip address 10.1.1.2 255.255.255.0
[*DeviceB-Pos0/1/0.1] fr dlci 100
[*DeviceB-fr-dlci-Pos0/1/0.1-100] quit
[*DeviceB-Pos0/1/0.1] quit

[*DeviceB0/1/0] commit
Step 3 Check the configurations.

Run the display fr interface command on Device B to check the FR protocol status and
interface information. The command output shows that the physical status and protocol status
of the interface are both Up.
<DeviceB> display fr interface pos0/1/0.1
Pos0/1/0.1, DTE, physical up, protocol up
Run the display fr pvc-info command on Device B to check VC configurations and statistics.
<DeviceB> display fr pvc-info interface pos0/1/0.1
PVC statistics for interface Pos0/1/0.1 (DTE, PP)
DLCI = 111, USAGE = LOCAL, Pos0/1/0.1
create time = 2013/11/05 11:19:17, status = ACTIVE
in BECN = 0, in FECN = 0
in packets = 0, in bytes = 0
out packets = 0, out bytes = 0
----End
Configuration Files
#
sysname DeviceA
#
interface Pos0/1/0
link-protocol fr
undo shutdown
fr interface-type dce

#
ip address 10.1.1.1 255.255.255.0
fr dlci 100
#
return

#
sysname DeviceB
#
interface Pos0/1/0
link-protocol fr
undo shutdown
#
ip address 10.1.1.2 255.255.255.0
fr dlci 100
#
return

Configuration Guide - WAN Access 7 HDLC and IP-Trunk Configurations
7 HDLC and IP-Trunk Configurations
About This Chapter
High-Level Data Link Control (HDLC) is a bit-oriented link layer protocol used to
transparently transmit all types of bit flows. An IP-Trunk consists of Packet over SDH/
SONET (POS) links and is encapsulated with HDLC at the data link layer. The IP-Trunk
increases interface bandwidth and improves link reliability.
7.1 Overview
As a bit-oriented link layer protocol, HDLC transparently transmits bit flows of any type
without specifying data as a set of characters.
7.2 Configuring HDLC Functions
This section describes how to configure HDLC encapsulation and optional HDLC parameters.
7.3 Configuring an IP-Trunk Interface
IP-Trunk interfaces are a type of trunk interface. You can configure an IP-Trunk interface to
implement link backup and traffic load balancing.
7.4 Maintaining HDLC and IP-Trunk
This section describes how to maintain HDLC and IP-Trunk, including deleting statistics
about HDLC or IP-Trunk interfaces.
7.5 Configuration Examples for HDLC and IP-Trunk
This section provides examples for configuring HDLC and an IP-Trunk interface.
7.1 Overview
As a bit-oriented link layer protocol, HDLC transparently transmits bit flows of any type
without specifying data as a set of characters.
As a typical bit-oriented synchronous data control protocol, HDLC has the following
characteristics:
l HDLC works in full-duplex mode and can transmit data continuously without waiting
for acknowledgement. Therefore, HDLC features high data link transmission efficiency.

l HDLC uses cyclic redundancy check (CRC) for all frames and numbers them. This helps
you know which frames are dropped and which frames are repeatedly transmitted.
HDLC ensures high transmission reliability.
l HDLC separates the transmission control function from the processing function and
features high flexibility and perfect control capabilities.
l HDLC is independent of any character encoding set and transparently transmits data.
l Zero-bit insertion, which is used for transparent data transmission, is easy to implement
on hardware.
HDLC is especially used to logically transmit data that is segmented into physical blocks or
packages. These blocks or packages are called frames, each of which is identified by a start
flag and an end flag. In HDLC, all bit-oriented data link control protocols use a unified frame
format, and both data and control information are transmitted in frames. Each frame begins at
and ends with a frame delimiter, which is a unique sequence of bits of 01111110. The frame
delimiter marks the start or end of a frame or marks for synchronization. The frame delimiter
is invisible inside a frame to avoid confusion.
A trunk can aggregate many interfaces into an aggregation group to implement load balancing
on member interfaces. Therefore, link connectivity is of higher reliability. Trunk interfaces are
classified as Eth-Trunk interfaces and IP-Trunk interfaces. An IP-Trunk can only be
composed of POS links. It has the following characteristics:
l Increased bandwidth: An IP-Trunk obtains the sum of bandwidths of all member
interfaces.
l Improved reliability: When a link fails, traffic is automatically switched to other links,
which improves connection reliability.
7.2 Configuring HDLC Functions

This section describes how to configure HDLC encapsulation and optional HDLC parameters.
Usage Scenario
HDLC applies when a bit-oriented link layer protocol is used for synchronous transmission.
Before configuring HDLC functions, configure the physical attributes of each synchronous
serial interface on the Router to ensure that the physical layer status of the interface is Up.
7.2.1 Configuring HDLC as the Link Layer Protocol of an

Interface
You can configure HDLC as a link layer protocol on an interface.
Procedure

The interface view is displayed.
NOTE
Run the command controller e3 controller-number, the E3 interface view is displayed.
Step 3 Run link-protocol hdlc

HDLC is configured as a link layer protocol of the interface.
Step 4 Run commit
----End
7.2.2 Assigning an IP Address to an Interface

You can assign an IP address to an interface or configure IP address unnumbered.
Procedure
Step 3 Run either of the following commands.
l To assign an IP address to the interface, run:
ip address ip-address { mask | mask-length } [ sub ]
l To configure IP address unnumbered, run:

ip address unnumbered interface interface-type interface-number
NOTE
Before configuring IP address unnumbered on an interface on which HDLC runs as a data link
layer protocol, ensure that the interface borrowing an IP address can learn a route to the peer;
otherwise, data cannot be transmitted to the peer.
Step 4 Run commit

----End
7.2.3 (Optional) Configuring HDLC Link Status Monitoring

The HDLC link status can be effectively monitored by configuring the HDLC link status
monitoring function.
Context
The parameters for HDLC link status monitoring are as follows:
l Keepalive time
– Polling interval

The polling interval determines how often an interface sends a Keepalive message.
When HDLC is specified as the link layer protocol on the interface, the interface
sends a Keepalive message to its peer device at the set polling interval. If the
interface fails to receive the Keepalive message from the peer after a specified
number of polling intervals, the interface considers the peer device to be faulty and
sets the HDLC link to Down. In situations with unfavorable network delay or
significant congestion, you can increase the polling interval to reduce network
flapping.
– Keepalive count
If a device does not receive a Keepalive message from its peer within a specified
polling interval, the Keepalive count increases by 1. If the device still fails to
receive a Keepalive message from its peer after a specified Keepalive count is
reached, the device considers the link connecting to the peer device to be faulty and
sets the HDLC link to Down.
The Keepalive time equals the polling interval multiplied by the Keepalive count. In
situations with unfavorable network delay or significant congestion, a short Keepalive
time may cause network flapping. Conversely, a long Keepalive time would lead to slow
link detection. Therefore, make sure that the Keepalive time is appropriate and fits the
network situations.
l IP-Trunk member link monitoring
An IP-Trunk link is established between two devices, and multiple transmission devices
may be deployed on the link to transparently transmit data. If a link connecting a POS
interface of the IP-Trunk is faulty, the POS interface sets its HDLC status to Down. If the
loopback detection function is enabled on the transmission devices, loopback messages
will cause the HDLC status of the POS interface to become Up. As a result, IP-Trunk
traffic will continue to be distributed to the faulty POS interface and gets discarded,
causing service interruption. To prevent IP-Trunk traffic from being discarded, you can
enable IP-Trunk member link monitoring so that when a POS interface detects a
loopback message, the POS interface sets its HDLC status to Down.
Procedure
l Configure a polling interval.
a. Run system-view

b. Run interface interface-type interface-number
The interface view is displayed

c. Run timer hold seconds
A polling interval is configured.
NOTE
The polling intervals on two interconnected devices must be set to the same value (other
than 0s). If both polling intervals are set to 0s, the link detection function is disabled.
d. Run commit

l Configure a Keepalive count.
a. Run system-view


c. Run keepalive count count-number
A Keepalive count is configured.
haiyo
d. Run commit
l Configure IP-Trunk member link monitoring.
a. Run system-view
c. Run down-when-looped
IP-Trunk member link monitoring is enabled on a specific POS interface. When the
POS interface detects a loopback message, the POS interface sets its HDLC status
to Down.
d. Run commit
----End
7.2.4 (Optional) Configuring HDLC Link Dampening Function

To prevent frequent HDLC flapping from flapping of the link or network layers, configure the
HDLC link dampening function.
Context
Optical fiber flapping on a physical interface causes HDLC link to flap between Up and
Down frequently. This results in unstable link or network layers. To prevent HDLC flapping
from causing flapping of link or network layers, configure the HDLC link dampening
function. By default, HDLC link dampening function is enabled.
Procedure
Step 2 Run hdlc dampening level { light | middle | heavy | manual { half-life-period half-life-
period suppress-threshold suppress-threshold reuse-threshold reuse-threshold max-
suppress-time max-suppress-time } }
The HDLC link dampening level is configured.
Step 3 (Optional) Run the hdlc dampening disable command to disable the HDLC link dampening.

If you do not want to use the HDLC link dampening function, run the hdlc dampening
disable command to disable the function.
Step 4 Run commit
----End
7.2.5 Verifying the HDLC Function Configuration

After configuring basic HDLC functions, you can view the interface status and link layer
protocol.
Prerequisites
Basic HDLC functions have been configured.
Procedure
l Run the display interface [ interface-type [ interface-number ] ] command to check the
interface status, link layer protocol, and configuration.
l The display hdlc interface [ interface-type interface-number ] command displays
HDLC link information on an interface.
----End
7.3 Configuring an IP-Trunk Interface

IP-Trunk interfaces are a type of trunk interface. You can configure an IP-Trunk interface to
implement link backup and traffic load balancing.
Usage Scenario
To improve communication capabilities of links, you can bundle multiple POS interfaces to
form an IP-Trunk interface. An IP-Trunk interface obtains the sum of bandwidths of member
interfaces. You can add POS interfaces to an IP-Trunk interface to increase the bandwidth of
the interface.
To prevent traffic congestion, traffic to the same destination can be balanced among member
links of the IP-Trunk interface, not along a single path.
You can configure an IP-Trunk interface to improve link reliability. If an IP-Trunk member
interface goes Down, the IP-Trunk interface can use other member interfaces in the Up state
to transmit data.
Before configuring an IP-Trunk interface, power on the device and verify that it is working
properly.

7.3.1 Creating an IP-Trunk Interface and Adding Interfaces to the

IP-Trunk Interface
You can create an IP-Trunk interface and add interfaces to the IP-Trunk interface.
Procedure
l Perform the following steps in the IP-Trunk interface view:
a. Run system-view

b. Run interface ip-trunk trunk-id
The IP-Trunk interface view is displayed.

c. Run either of the following commands:
n To add interfaces to the IP-Trunk interface in a batch, run:
trunkport interface-type { interface-number1 [to interface-
number2 ] } &<1-16>
n To add an interface to the IP-Trunk interface, run:

trunkport interface-type interface-number
d. Run commit

l Perform the following steps in the view of the interface to be added to an IP-Trunk
interface:
a. Run system-view

b. Run interface ip-trunk trunk-id
An IP-Trunk interface is created.

c. Run quit
Return to the system view.

d. Run interface pos interface-number
The view of the interface to be added to the IP-Trunk interface is displayed.

e. Run link-protocol hdlc
The link layer protocol of the interface is set to HDLC.
NOTE
HDLC must run as a link layer protocol on each interface to be added to an IP-Trunk
interface.
f. Run ip-trunk trunk-id
The interface is added to the IP-Trunk interface.

NOTE
When configuring an IP-Trunk interface, note the following issues:

l HDLC must run on each interface to be added to the IP-Trunk interface.
l PPP runs on a POS interface by default. To change the link layer protocol from PPP to
HDLC, access the POS interface view and run the link-protocol hdlc command.
l The interface to be added to the IP-Trunk interface has no Layer 3 features, such as the
IP address, or any service configured.
l A POS interface can be added to only one IP-Trunk interface. If the POS interface
needs to be added to another IP-Trunk interface, it must be deleted from the current IP-
Trunk interface before being added to another IP-Trunk interface.
l An IP-Trunk interface cannot be added to another IP-Trunk interface.
l POS interfaces on different interface boards can be added to the same IP-Trunk
interface.
l Do not add interfaces with different forwarding capabilities to the same IP-Trunk
interface. If POS interfaces working at different rates are added to the same IP-Trunk
interface, the bandwidth of the IP-Trunk interface is determined by the following
factors:
l Member interfaces selected using the hash algorithm
l Number of Up member interfaces and bandwidth of each member interface
For example, a 10 Gbit/s POS interface and a 2.5 Gbit/s POS interface are added to the
same IP-Trunk interface. If both POS interfaces are Up and only the 2.5 Gbit/s POS
interface is selected as the member interface using the hash algorithm, the forwarding
capability of the IP-Trunk interface is 2.5 Gbit/s but not 12.5 Gbit/s.
l If a member interface of an IP-Trunk interface is connected to the peer, the directly
connected interface on the peer must also be a member interface of an IP-Trunk
interface.
g. Run commit
----End
7.3.2 Assigning an IP Address to an IP-Trunk Interface

You can assign an IP address to an IP-Trunk interface.
Procedure
Step 2 Run interface ip-trunk trunk-id
Step 3 Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is assigned to the IP-Trunk interface.
Step 4 Run commit
----End

7.3.3 (Optional) Configuring the Lower Threshold of Up Links

The lower threshold of Up links is the minimum number of member interfaces in the Up state.
When the number of member interfaces in the Up state falls below the configured lower
threshold, an IP-Trunk interface goes Down. When the number of member interfaces in the
Up state reaches the configured lower threshold, the IP-Trunk interface goes Up.
Procedure
Step 3 Run least active-linknumber link-number
The lower threshold of member interfaces in the Up state is set.
NOTE
To ensure normal forwarding, configure the same lower threshold for the IP-Trunk interfaces on both
ends of an IP-Trunk link.
This command is mutually exclusive with the least active-bandwidth bandwidth command. Check that
the least active-bandwidth bandwidth command configuration does not exist before running this
command.
Step 4 Run commit
----End
7.3.4 (Optional) Setting the Lower Limit for an IP-Trunk

Interface's Bandwidth
This section describes how to set the lower limit for an IP-Trunk interface's bandwidth. An
IP-Trunk interface goes Down when the sum of all Up member interfaces' bandwidth is lower
than the lower limit. An IP-Trunk interface goes Up when the sum of all Up member
interfaces' bandwidth reaches the lower limit.
Procedure
Step 3 Run least active-bandwidth bandwidth
The lower limit is set for an IP-Trunk interface's bandwidth.

NOTE
This command is mutually exclusive with the least active-linknumber link-number command. Check
that the least active-linknumber link-number command configuration does not exist before running this
command.
Step 4 Run commit
----End
7.3.5 (Optional) Configuring the Load Balancing Mode for an IP-

Trunk Interface
You can configure the load balancing mode for an IP-Trunk interface.
Procedure
Step 3 Run load-balance { src-dst-ip |packet-all }
A load balancing mode is configured for the IP-Trunk interface.
l IP-based load balancing ensures packet sequence but not bandwidth use efficiency.
l Packet-based load balancing ensures bandwidth usage efficiency but not packet
sequence.
Step 4 Run commit
----End
7.3.6 (Optional) Configuring the Weight for a Member Link

An IP-Trunk interface performs load balancing on member links based on link weights. On an
IP-Trunk interface, the greater the weight of a member link, the heavier the load over the
member link. Therefore, to enable a member link to transmit more traffic, increase the weight
for the link.
Procedure
Step 1 On the Router that uses the IP-Trunk interface, run system-view
The view of a member interface of an IP-Trunk interface is displayed.

Step 3 Run distribute-weight weight-value
The weight of the member link is set.
Step 4 Run commit
----End
7.3.7 (Optional) Configuring the Method of Sending Trap

Messages from an IP-Trunk Member Interface
You can configure an IP-Trunk member interface to send trap messages through a private
MIB.
Context
Perform the following steps on the devices where IP-Trunk interfaces are created:
Procedure
Step 2 Run trunk-member trap in private-mib enable
An IP-Trunk member interface in the Up or Down state sends trap messages through the
private MIB.
The trap message sent through the public MIB does not carry information about the IP-Trunk
interface. If you want the trap message sent by an IP-Trunk member interface to carry
information about the IP-Trunk interface, run the trunk-member trap in private-mib enable
command.
----End
7.3.8 Verifying the IP-Trunk Interface Configuration

After configuring the IP-Trunk interface, you can view the status and forwarding table of the
IP-Trunk interface and information about member interfaces.
Prerequisites
An IP-Trunk interface has been configured.
Procedure
l Run the display interface ip-trunk [ trunk-id ] command to check the IP-Trunk
interface information, including the status.
l Run the display trunkmembership ip-trunk trunk-id command to check information
about member interfaces.

l Run the display trunkfwdtbl ip-trunk trunk-id [ slot slot-id ] command to check
information about the forwarding table for a link aggregation group.
----End
7.4 Maintaining HDLC and IP-Trunk

This section describes how to maintain HDLC and IP-Trunk, including deleting statistics
about HDLC or IP-Trunk interfaces.
7.4.1 Deleting Statistics About HDLC or IP-Trunk Interfaces

You can run the reset command to delete interface statistics before re-collecting traffic
statistics on a specified interface.
Context
Interface statistics cannot be restored after you delete it. Therefore, exercise caution when
running the reset command.
To clear interface statistics on the NMS or displayed using the display interface command,
you can run the reset command in the user view.
NOTE
For information on how to view the interface statistics on the NMS, see the NMS manual.
Procedure
l Run the reset counters interface [ interface-type [ interface-number ] ] command to
delete interface statistics.
----End
7.5 Configuration Examples for HDLC and IP-Trunk

This section provides examples for configuring HDLC and an IP-Trunk interface.
7.5.1 Example for Configuring Basic HDLC Functions

This section provides an example for configuring HDLC to interconnect devices in typical
networking scenarios.
Device A and Device B are connected using HDLC-enabled POS interfaces.

Figure 7-1 Networking diagram for HDLC

NOTE
Interfaces 1 in this example is POS0/1/0.
10.1.1.1/24 10.1.1.2/24
DeviceA DeviceB
1. Configure HDLC as a link layer protocol on the interface of each Router.
2. Assign an IP address to each interface.
Data Preparation
l IP address of the interface on Device A
l IP address of the interface on Device B
NOTE
The IP addresses of interfaces on Device A and Device B must be on the same network segment;
otherwise, the link layer protocol cannot go Up.
Procedure
[*HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface pos 0/1/0
[~DeviceA-Pos0/1/0] link-protocol hdlc
[*DeviceA-Pos0/1/0] ip address 10.1.1.1 24
[*DeviceA-Pos0/1/0] undo shutdown
[*DeviceA] commit

[*HUAWEI] sysname DeviceB
[*HUAWEI] commit
[~DeviceB] interface pos 0/1/0
[~DeviceB-Pos0/1/0] link-protocol hdlc
[*DeviceB-Pos0/1/0] undo shutdown
[*DeviceB] commit

After the configuration is complete, Device A and Device B can ping each other.
The following example uses the command output on Device A.


0.00% packet loss
Run the display ip routing-table command. The command output shows that routing
information is correct.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 2 Routes : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
100.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos0/1/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos0/1/0
----End
Configuration Files
#
sysname DeviceA
#
interface Pos0/1/0
undo shutdown
link-protocol hdlc
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname DeviceB
#
interface Pos0/1/0
undo shutdown
link-protocol hdlc
ip address 10.1.1.2 255.255.255.0
#
return
7.5.2 Example for Configuring IP Address Unnumbered

This section provides an example for configuring IP address unnumbered and describes how
IP address unnumbered works in typical networking scenarios.
Device A and Device B are connected using HDLC-enabled POS interfaces.
POS 0/1/0 on Device A borrows the IP address of a loopback interface on Device A, and the
mask of the IP address is 32 bits.

Figure 7-2 Networking diagram for configuring IP address unnumbered

NOTE
Interfaces 1 in this example is POS0/1/0.
Loopback 1
10.1.1.1/32
interface1
interface1 10.1.1.2/24
DeviceA DeviceB
1. Configure HDLC as a link layer protocol on the interface of each Router.
2. Configure the IP address to be borrowed, that is, the IP address of the loopback interface
on Device A.
3. Configure IP address unnumbered for the POS interface on Device A.
4. On Device A, configure a static route to Device B.
5. Assign an IP address to the interface on Device B.
Data Preparation
l IP address of the loopback interface on Device A
l IP address of the POS interface on Device B
NOTE
These two IP addresses must be on the same network segment; otherwise, the link layer protocol cannot
go Up.
Procedure
[*HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface loopback 1
[*DeviceA-LoopBack1] ip address 10.1.1.1 32
[*DeviceA-LoopBack1] quit
[*DeviceA] interface pos 0/1/0
[*DeviceA-Pos0/1/0] link-protocol hdlc
[*DeviceA-Pos0/1/0] ip address unnumbered interface loopback 1
[*DeviceA] commit



[*HUAWEI] commit
[~DeviceB] interface pos 0/1/0
Step 3 Configure a static route on Device A.

[*DeviceA] ip route-static 10.1.1.0 24 pos 0/1/0
[*DeviceB-Pos0/1/0] commit

After the configuration is complete, Device A and Device B can ping each other.
0.00% packet loss
Run the display ip routing-table command. The command output shows that routing
information is correct.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download

to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : Public
Destinations : 2 Routes : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 Static 60 0 D 0.0.0.0 Pos0/1/0

10.1.1.1/32 Direct 0 0 D 127.0.0.1 LoopBack1
----End
Configuration Files
#
sysname DeviceA
ip route-static 10.1.1.0 255.255.255.0 Pos0/1/0
#
interface Pos0/1/0
link-protocol hdlc
undo shutdown
ip address unnumbered interface LoopBack1
#
interface LoopBack1
ip address 10.1.1.1 255.255.255.255
#
return


#
sysname DeviceB
#
interface Pos0/1/0
link-protocol hdlc
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
return
7.5.3 Example for Configuring an IP-Trunk

An IP-Trunk link between Device A and Device B is established.
Figure 7-3 Networking diagram for an IP-Trunk link

NOTE
Interfaces 1 and 2 in this example are POS 0/1/0 and POS 0/2/0, respectively.
IP-Trunk1
Interface1 10.1.1.1/24 interface1
IP-Trunk1
DeviceA 10.1.1.2/24 DeviceB
1. Connect Device A to Device B using POS interfaces.
2. Create an IP-Trunk interface.
3. Add the POS interfaces to the IP-Trunk interface.
Data Preparation
l IP address of the IP-Trunk interface on Device A
l IP address of the IP-Trunk interface on Device B
Procedure
[*HUAWEI] commit
# Create IP-Trunk 1 on Device A and assign an IP address to it.

[~DeviceA] interface ip-trunk 1
[*DeviceA-Ip-Trunk1] ip address 10.1.1.1 255.255.255.0
[*DeviceA-Ip-Trunk1] undo shutdown
[*DeviceA-Ip-Trunk1] quit

[*DeviceA] commit
# Add POS 0/1/0 and POS 0/2/0 to IP-Trunk 1.

[*DeviceA-Pos0/1/0] ip-trunk 1
[*DeviceA-Pos0/2/0] ip-trunk 1
[*DeviceA] commit

[*HUAWEI] commit
# Create IP-Trunk 1 on Device B and assign an IP address to it.

[~DeviceB] interface ip-trunk 1
[*DeviceB-Ip-Trunk1] ip address 10.1.1.2 255.255.255.0
[*DeviceB-Ip-Trunk1] undo shutdown
[*DeviceB-Ip-Trunk1] quit
[*DeviceB-Ip-Trunk1] commit
# Add POS 0/1/0 and POS 0/2/0 to IP-Trunk 1.

[*DeviceB] interface pos 0/1/0
[*DeviceB-Pos0/1/0] ip-trunk 1
[*DeviceB] interface pos 0/2/0
[*DeviceB-Pos0/2/0] ip-trunk 1
[*DeviceB] commit

Run the display interface ip-trunk command on Device A or Device B. The command
output shows that IP-Trunk 1 is Up.
[~DeviceA] display interface ip-trunk 1
Ip-Trunk1 current state : UP (ifindex: 894)
Link quality grade : GOOD

Description:
Route Port,Hash arithmetic : According to flow, Maximal BW: 155Mbps, Current BW:
155Mbps, The Maximum Transmit Unit is 9600
Link layer protocol is nonstandard HDLC
Current system time: 2013-08-08 10:26:52
Physical is IP_TRUNK
Input: 17508 packets,805368 bytes
0 errors,0 drops
Output:1750 packets,80500 bytes
0 errors,0 drops
Last 300 seconds input utility rate: 0.01%

Last 300 seconds output utility rate: 0.01%

---------------------------------------------------
PortName Status Weight
---------------------------------------------------
Pos0/1/0 UP 1
Pos0/2/0 UP 1
---------------------------------------------------
The Number of Ports in Trunk : 1
The Number of UP Ports in Trunk : 1
On Device A, view information about member interfaces of IP-Trunk 1.

[~DeviceA] display trunkmembership ip-trunk 1
Trunk ID: 1
TYPE: pos
Number Of Ports in Trunk = 1
Number Of Up Ports in Trunk = 1
operate status: up
Interface Pos0/1/0, valid, operate up, weight 1

Interface Pos0/2/0, valid, operate up, weight 1
The IP-Trunk interfaces on Device A and Device B can ping each other.
[~DeviceA] ping -a 10.1.1.1 10.1.1.2
0.00% packet loss
----End
Configuration Files
#
sysname DeviceA
#
interface Ip-Trunk1
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface Pos0/1/0
link-protocol hdlc
undo shutdown
ip-trunk 1
#
interface Pos0/2/0
link-protocol hdlc
undo shutdown
ip-trunk 1
#
return

#
sysname DeviceB
#
interface Ip-Trunk1
undo shutdown
ip address 10.1.1.2 255.255.255.0

#
interface Pos0/1/0
link-protocol hdlc
undo shutdown
ip-trunk 1
#
interface Pos0/2/0
link-protocol hdlc
undo shutdown
ip-trunk 1
#
return

Configuration Guide - WAN Access 8 PPP Configuration
8 PPP Configuration
About This Chapter
Functioning at the data link layer of the Open Systems Interconnection (OSI) and the link
layer of the TCP/IP protocol suite, the Point-to-Point Protocol (PPP) is a link layer protocol
that is used to transmit network layer packets over point-to-point (P2P) links. PPP is
developed based on the Serial Line Internet Protocol (SLIP). PPP is widely used because it
provides user authentication, supports synchronous and asynchronous communication, and is
easy to extend.
8.1 Overview of PPP

This section describes the principles of the Point-to-Point Protocol (PPP) and related
protocols.
8.2 Configuring an Interface to Support PPP
Configure an interface to support PPP so that it can implement point-to-point (P2P) traffic
transmission.
8.3 Configuring Unidirectional CHAP Authentication
CHAP performs three-way handshake authentication. Unidirectional CHAP authentication
involves two situations: the authenticator with a user name and the authenticator without a
user name.
8.4 Configuring Unidirectional PAP Authentication
The unidirectional PAP authentication configuration procedure involves configuring the
authenticator to authenticate the supplicant in PAP mode and configuring the supplicant to be
authenticated in PAP mode.
8.5 Configuring MP
The Multilink Point-to-Point Protocol (MP) is a technique that bundles multiple Point-to-
Point Protocol (PPP) links together to increase link bandwidth and improve link reliability.
8.6 Configuration Examples for PPP
This section provides examples for configuring the PAP authentication and CHAP
authentication in various usage scenarios.

8.1 Overview of PPP

This section describes the principles of the Point-to-Point Protocol (PPP) and related
protocols.
Point-to-point (P2P) connections are simple wide area network (WAN) connections. A P2P
link uses PPP or High-Level Data Link Control (HDLC) as its link-layer protocol.
PPP, which works at the second layer (data link layer) of the open systems interconnection
(OSI) model, is mainly used on links that support full-duplex to transmit data. PPP is widely
used because it provides user authentication, supports synchronous and asynchronous
communication, and is easy to extend.
PPP negotiation involves the following items:
l Data encapsulation mode: defines how to encapsulate multi-protocol data packets.

l Link Control Protocol (LCP): used to set up, monitor, and tear down data links.
l Network Control Protocol (NCP): used to negotiate options for a network layer protocol
running atop PPP and the format and type of the data to be transmitted over data links.
PPP uses the Password Authentication Protocol (PAP) and Challenge Handshake
Authentication Protocol (CHAP) to secure network communication.
If carriers have high bandwidth requirements, bundle multiple PPP links into an MP link to
increase link bandwidth and improve link reliability.
8.2 Configuring an Interface to Support PPP

Configure an interface to support PPP so that it can implement point-to-point (P2P) traffic
transmission.
Usage Scenario
PPP is a link layer protocol that transmits network layer packets over P2P links. PPP defines a
group of protocols, including LCP and NCP.
l During the LCP negotiation phase, an MRU, negotiation timeout period, and PPP LCP
link dead duration are negotiated.
l During the NCP negotiation phase, network layer packet attributes and types are
negotiated. For example, during the IPCP negotiation, the IP address of a DNS server
will be negotiated.
To monitor link status in real time, configure link status monitoring parameters so that link
faults can be identified in time. A PPP link does not require that the peer route and local route
be on the same network segment. To avoid incorrect routing information, prohibit the addition
of the peer host route to the local routing table of direct routes.
Before configuring an interface to support PPP, connect the interface and set physical
parameters to ensure that the physical status of the interface is Up.

Configuration Procedures
The following flowchart shows how to configure an interface to support PPP.
Figure 8-1 Flowchart for configuring an interface to support PPP
Configuring PPP as the Link Layer Protocol of an

Interface
Configuring PPP Negotiation Parameters
Configuring PPP Link Status Monitoring
Prohibiting a Local Device from Adding the Peer Host

Route to the Local Routing Table of Direct Routes
Mandatory procedure
Optional procedure
8.2.1 Configuring PPP as the Link Layer Protocol of an Interface

Configure PPP as the link layer protocol of an interface for the interface to implement P2P
traffic transmission.
Context
PPP is a data link layer protocol used to transmit network layer packets on P2P links. It is
extensible and supports both synchronous and asynchronous communication. Before
configuring PPP parameters of an interface, configure PPP as the link layer protocol of the
interface.
Procedure
PPP is configured as the link layer protocol of the interface.
Step 4 Run commit
----End

8.2.2 (Optional) Configuring PPP Negotiation Parameters

For a PPP link to be established between two communicating devices that have PPP enabled,
configure the following PPP negotiation parameters: MRU, negotiation timeout period, PPP
LCP link dead duration, and DNS server IP address.
Context
A PPP link is established between two communicating devices after successful LCP
negotiation and NCP negotiation. After the physical link goes Up, the two devices enter the
link establishment phase, during which one device initiates LCP negotiation. After LCP
negotiation succeeds, if the two devices have a network layer protocol configured, the device
continues to initiate NCP negotiation on network layer packet attributes and types.
Table 8-1 Usage scenario for negotiation parameters

Negotiation Usage Scenario Negotiation
Parameter Phase
PPP MRU If an MTU is configured on an interface of a PPP LCP

link, enable the PPP MRU negotiation function negotiation
so that interfaces on both ends of the PPP link phase
have the same MTU, which ensures proper data
transmission. If the interfaces have different
MTUs, the smaller MTU will be selected as the
PPP link MTU after the negotiation.
Negotiation timeout During LCP negotiation, the local device sends

period an LCP negotiation packet to the remote device.
If the local device does not receive a reply packet
from the remote device within the specified
negotiation timeout period, the local device
resends an LCP negotiation packet.
LCP link dead During LCP negotiation, if the local device fails
duration to receive a reply packet from the remote device
after retransmitting LCP negotiation packets for a
specified number of times, the LCP negotiation
enters the Dead state, and the devices stop
performing LCP negotiation. In this situation,
configure an LCP link dead duration. After the
duration elapses, the local device will re-initiate
LCP negotiation.

Negotiation Usage Scenario Negotiation

Parameter Phase
DNS server IP During IPCP negotiation, the local device can NCP
address either provide a DNS server IP address for the negotiation
remote device or accept the DNS server IP phase
address assigned by the remote device. A DNS
server is responsible for resolving domain names.
l When a device is connected to a remote
device over a PPP link, for example, a PC
dials up to the device, configure the device to
assign a DNS server IP address to the PC.
l When a device is connected to a carrier's
access server over a PPP link, configure the
device to accept the DNS server IP address
assigned by the access server.
OSICP and MPLSCP When the default OSICP and MPLSCP NCP
configurations differ on devices that are to negotiation
communicate, enables or disables negotiation to phase
ensure consistent configurations on both devices.
NOTE
In VS mode, the configuration of Negotiation timeout period is supported only on the admin VS.
Procedure
l Configure PPP MRU negotiation.
a. Run system-view


c. Run ppp mru-negotiate { ipv4 | ipv6 }
MRU negotiation is enabled at the link control layer.
If an IPv6 MTU is configured on the interface, enable PPP IPv6 MRU negotiation
for the device. After PPP MRU negotiation is enabled, to make this configuration
take effect, you must run the shutdown, commit, undo shutdown, and commit
commands in sequence, or run the restart and commit commands.
l Configure a negotiation timeout period.

a. Run system-view


c. Run ppp timer negotiate seconds
A negotiation timeout period is configured.

d. Run commit

l Configure a PPP LCP link dead duration.
a. Run system-view


c. Run ppp timer link-dead timer
The PPP LCP link dead duration is configured.
d. Run commit

l Configure a DNS server IP address
– Configure the device to assign a DNS server IP address to the remote device.
i. Run system-view
ii. Run interface interface-type interface-number
iii. Run ppp ipcp dns primary-dns-address [ secondary-dns-address ]
The device is configured to assign a DNS server IP address to the remote
device.
– Configure the device to accept any DNS server IP address assigned by the remote
device.
i. Run system-view
ii. Run interface interface-type interface-number
iii. Run ppp ipcp dns admit-any
The device is configured to accept any DNS server address assigned by the
remote device.
NOTE
If the remote device forcibly assigns a DNS server address to the local device, the local
device may refuse to accept the address, causing a negotiation failure between the two
devices. To prevent this situation, run the ppp ipcp dns admit-any command to configure
the local device to accept any DNS server IP address assigned by the remote device.

After a DNS server address is configured, to make this configuration take effect, you
must run the shutdown, commit, undo shutdown, commit, or restart, commit
commands.
l Configure the OSICP and MPLSCP

a. Run system-view


c. Run ppp osicp { enable | disable }orppp mplscp { enable | disable }
The negotiation between two devices before OSICP and MPLSCP go Up on both
devices can be enabled or disabled.
When the default OSICP and MPLSCP configurations differ on devices that are to
communicate, run the ppp osicp or ppp mplscp command as follows to ensure
consistent configurations on both devices:
n If OSICP and MPLSCP are configured to go Up without negotiation on a peer
device, run the ppp osicp disable or ppp mplscp disable command on a local
device.
n If OSICP and MPLSCP are configured to go Up only after negotiation on a
peer device, run the ppp osicp enable or ppp mplscp enable command on a
local device. Alternatively, use the default configuration on the local device.
NOTE
Run the shutdown and undo shutdown command in the interface view to make the configuration
take effect.
----End
8.2.3 (Optional) Configuring PPP Link Status Monitoring

The PPP link status can be effectively monitored using the PPP link status monitoring
function.
Context
The parameters for PPP link status monitoring are as follows:
l Keepalive time
– Polling interval
The polling interval determines how often an interface sends a Keepalive message.
When PPP is specified as the link layer protocol on the interface, the interface sends
a Keepalive message to its peer device at the set polling interval. If the interface
fails to receive a Keepalive message from the peer after five polling intervals, the
interface considers the peer device to be faulty and sets the PPP link to Down. In
situations with unfavorable network delay or significant congestion, you can
increase the polling interval to reduce network flapping.

– Keepalive count
If a device does not receive a Keepalive message from its peer within a specified
polling interval, the Keepalive count increases by 1. If the device still fails to
receive a Keepalive message from its peer after a specified Keepalive count is
reached, the device considers the link connecting to the peer device to be faulty and
sets the PPP link to Down.
The Keepalive time equals the polling interval multiplied by the Keepalive count. In
situations with unfavorable network delay or significant congestion, a short Keepalive
time may cause network flapping. Conversely, a long Keepalive time would lead to slow
link detection. Therefore, make sure that the Keepalive time is appropriate and fits the
network situations.
l PPP magic number check
PPP magic number check is used to trigger LCP renegotiation. On a network where two
devices are connected over intermediate transmission devices, if the two devices are
incorrectly connected, the transmission devices will adjust the connection relationship
between the two devices. However, the two devices are not aware of this adjustment
because the status of their interfaces does not alternate between Down and Up.
Consequently, LCP renegotiation between the two devices is not triggered. After the PPP
magic number check function is enabled, when the local device finds that the magic
number carried in the Echo Reply packet from the remote device is inconsistent with the
one previously learned, the local device will record an error. After error statistics on an
interface reach a specific threshold, the interface sets the PPP link to Down, triggering
LCP renegotiation.
Procedure
l Configure a polling interval.
a. Run system-view
c. Run timer hold seconds
A polling interval is configured.
NOTE
The polling intervals on two interconnected devices must be set to the same value (other
than 0s). If both polling intervals are set to 0s, the link detection function is disabled.
d. Run commit
l Configure a Keepalive count.
a. Run system-view
c. Run keepalive count count-number
A Keepalive count is configured.

d. Run commit

l Configure the PPP magic number check function.
a. Run system-view


c. Run ppp magic-number check
The PPP magic number check function is enabled.
l Currently, the magic number check function can only be enabled on a POS
interface.
l After configuring the PPP magic number check function, to make the
configuration take effect, you must run the shutdown, commit, undo
shutdown, and commit commands in sequence, or run the restart and commit
commands.
----End
8.2.4 (Optional) Prohibiting a Local Device from Adding the Peer

Host Route to the Local Routing Table of Direct Routes
To avoid incorrect routing information in the local routing table, you can prohibit a local
device from adding the peer host route to the local routing table of direct routes.
Context
Devices on both ends of a PPP link may have IP addresses at different network segments.
When the two devices communicate with each other, one device automatically adds the host
route of the other end to the local routing table of direct routes. If one end has an incorrect IP
address configured, incorrect routing information will be advertised on the network. To
prevent incorrect routing information, prohibit the local device from adding the peer host
route to the local routing table of direct routes.
Procedure
Step 3 Run ppp peer hostroute-suppress

The device is prohibited from adding the peer host route to the local routing table of direct
routes.
Step 4 Run commit
----End
8.2.5 (Optional) Configuring the PPP Link Dampening Function

To prevent frequent PPP link flapping from causing flapping of the link and network layers,
configure the PPP link dampening function.
Context
Optical fiber flapping on a physical interface causes PPP link to alternate between Up and
Down frequently. This results in unstable link or network layers. To prevent the link or
network layer flapping from causing PPP link frequent alternating between Up and Down,
configure the PPP link dampening function. By default, PPP link dampening is enabled.
Procedure
Step 2 Run ppp dampening level { light | middle | heavy | manual { half-life-period half-life-
period suppress-value suppress-value reuse-value reuse-value max-suppress-time max-
suppress-time } }
The PPP link dampening level is configured.
When the PPP link dampening function is enabled, run the ppp dampening level command
to configure a light, middle, or heavy dampening level based on PPP link dampening
requirements, or configure suppress-value manually.
l light: If light PPP link dampening is configured, dampening procedure will be triggered
only when the PPP link flaps frequently and rapidly.
l middle: If middle PPP link dampening is configured, intensity of PPP link dampening is
between the light and heavy.
l heavy: If heavy PPP link dampening is configured, dampening will be triggered even if
link flapping is not severe. That is, the link is vulnerable to dampening.
l manual: If PPP link dampening is configured manually, you can configure a PPP link
dampening level based on sensitivity of flapping.
Step 3 Run commit
----End
8.2.6 Verifying the PPP Configuration

After configuring PPP as the link layer protocol, verify the configuration.

Prerequisites
PPP has been configured as the link layer protocol.
Procedure
status of and statistics about a specific PPP-enabled interface.
l Run the display ppp information interface interface-type interface-number command
to check PPP link information about a specific interface.
----End
8.3 Configuring Unidirectional CHAP Authentication

CHAP performs three-way handshake authentication. Unidirectional CHAP authentication
involves two situations: the authenticator with a user name and the authenticator without a
user name.
Usage Scenario
CHAP authentication is performed before a link is set up. After a link is set up, CHAP
authentication can be repeatedly performed anytime using CHAP negotiation packets.
In unidirectional CHAP authentication, one of two communicating parties functions as the
authenticator, whereas the other functions as the supplicant. The authenticator sends a
Challenge packet to the supplicant. After performing one hash calculation, the supplicant
returns a calculated value to the authenticator. The authenticator compares the value
calculated by itself using the hash algorithm with the value sent by the supplicant. If the two
values match, authentication is successful. If the two values are different, the authentication
fails, and the link is torn down.
Before configuring unidirectional CHAP authentication, complete the following tasks:
l Connect interfaces and configure physical parameters of the interfaces to ensure that the
physical status of the interfaces is Up.
l Configure PPP as the link layer protocol of the interfaces.
l Add the user name and password of the supplicant to the user list of the authenticator in
the AAA view.
In CHAP authentication, the authenticator can be configured with or without a user name. In
practice, you can configure any type of unidirectional CHAP authentication as required.

8.3.1 Configuring the Authenticator with a User Name to

Authenticate Its Peer in CHAP Mode
Context
NOTE
You can configure the authenticator with a user name to authenticate its peer in CHAP mode.
Procedure
l Configure the authenticator.
a. Run system-view
b. Run aaa
The AAA view is displayed.
c. Run local-user user-name password [ cipher password | irreversible-cipher
irreversible-cipher-password ]
The user name and password of the supplicant are added to the local user list.
d. Run quit
e. Run interface interface-type interface-number
f. Run ppp authentication-mode chap [ pap ]
The local end is configured to authenticate the peer in CHAP mode.
You can run the ppp authentication-mode chap [ pap ] command to perform
CHAP authentication preferentially in LCP negotiation. If the peer does not support
CHAP authentication, PAP authentication is performed. If the peer supports neither
CHAP nor PAP, LCP negotiation fails. Either CHAP or PAP is involved in a PPP
negotiation.
g. Run ppp chap user user-name
A user name is specified.
h. Perform the following steps to restart the interface:
i. Run the shutdown command to shut down the interface.
ii. Run the commit command to make the configuration take effect.
iii. Run the undo shutdown command to restart the interface.
NOTE
The shutdown, commit, and undo shutdown commands must be run in sequence so that
the preceding configuration can take effect after the interface is restarted.
i. Run commit

l Configure the supplicant.

a. Run system-view
b. Run aaa
d. Run quit
f. Run ppp chap user user-name
A user name is configured.
g. Perform the following steps to restart the interface:
i. Run the shutdown command to shut down the interface.
ii. Run the commit command to make the configuration take effect.
iii. Run the undo shutdown command to restart the interface.
NOTE
The shutdown, commit, and undo shutdown commands must be run in sequence so that
the preceding configuration can take effect after the interface is restarted.
h. Run commit
----End
8.3.2 Configuring the Authenticator Without a User Name to

Authenticate Its Peer in CHAP Mode
You can configure the authenticator without a user name to authenticate its peer in CHAP
mode.
Procedure
l Configure the authenticator.
a. Run system-view
b. Run aaa

d. Run quit
f. Run ppp authentication-mode chap [ pap ]
The local end is configured to authenticate the peer in CHAP mode.
You can run the ppp authentication-mode chap [ pap ] command to perform
CHAP authentication preferentially in LCP negotiation. If the peer does not support
CHAP authentication, PAP authentication is performed. If the peer supports neither
CHAP nor PAP, LCP negotiation fails. Either CHAP or PAP is involved in a PPP
negotiation.
g. Run shutdown
The interface is shut down.
h. Run commit
i. Run undo shutdown
The interface is restarted.
NOTE
If the user name or password is changed in the interface view, run the shutdown and undo
shutdown commands in the interface view to make the configuration take effect.
During an interface restart, you need to run the commit command to submit the
configuration after running the shutdown command.
j. Run commit
l Configure the supplicant.
a. Run system-view
c. Run ppp chap user user-name
A user name is specified.
d. Run ppp chap password { cipher password | simple password }
The password for CHAP authentication is set.
e. Run shutdown
f. Run commit
g. Run undo shutdown

NOTE
If the user name or password is changed in the interface view, run the shutdown and undo
shutdown commands in the interface view to make the configuration take effect.
During an interface restart, you need to run the commit command to submit the
configuration after running the shutdown command.
h. Run commit
----End
8.3.3 Verifying the Unidirectional CHAP Authentication

Configuration
After configuring unidirectional CHAP authentication, verify the configuration.
Prerequisites
Unidirectional CHAP authentication has been configured.
Procedure
PPP configuration and running status on the current interface.
----End
8.4 Configuring Unidirectional PAP Authentication

The unidirectional PAP authentication configuration procedure involves configuring the
authenticator to authenticate the supplicant in PAP mode and configuring the supplicant to be
authenticated in PAP mode.
Usage Scenario
In PAP authentication, passwords are sent over a link in simple text. The user name and
password of a supplicant can be added to the user list of the authenticator in authentication,
authorization and accounting (AAA) mode or sent to a Remote Authentication Dial-In User
Service (RADIUS) server for authentication.
In unidirectional PAP authentication, one of two communicating parties functions as the
authenticator, whereas the other functions as the supplicant. In bidirectional PAP
authentication, two communicating parties function as both the authenticator and supplicant
of each other.
This section describes how to configure unidirectional PAP authentication by adding the user
name and password of the supplicant to the user list of the authenticator.
Before configuring unidirectional PAP authentication, complete the following tasks:
l Connect interfaces correctly and configure physical parameters for the interfaces to
ensure that the physical layer status of the interfaces is Up.

l Configure PPP as the link layer protocol of the interfaces.

l Add the user name and password of the supplicant to the user list of the authenticator in
the AAA view.
There are two types of unidirectional PAP authentication: the authenticator authenticating the
supplicant in PAP mode and the supplicant being authenticated in PAP mode. You can
configure either of the types as required.
8.4.1 Configuring the Authenticator to Authenticate Its Peer in

PAP Mode
This section describes how to configure PAP authentication on the authenticator. PAP
performs two-way handshake authentication only in the initial link establishment phase.
Procedure
Step 2 Run aaa
Step 3 Run local-user user-name password [ cipher password | irreversible-cipher irreversible-
cipher-password ]
Step 4 Run quit
The view of the interface of the authenticator is displayed.
Step 6 Run ppp authentication-mode pap
The local end is configured to authenticate the peer in PAP mode.
Step 7 Perform the following steps to restart the interface:
1. Run the shutdown command to shut down the interface.
2. Run the commit command to make the configuration take effect.
3. Run the undo shutdown command to restart the interface.
NOTE
The shutdown, commit, and undo shutdown commands must be run in sequence so that the preceding
configuration can take effect after the interface is restarted.
Step 8 Run commit

----End

8.4.2 Configuring the Supplicant to Be Authenticated in PAP

Mode
This section describes how to configure the supplicant to be authenticated in PAP mode.
Procedure
The view of the interface on the supplicant is displayed.
Step 3 Run ppp pap local-user user-name password { cipher password | simple password }
The interface is configured to send the local user name and password to the authenticator
when the local end is authenticated in PAP mode.

1. Run the shutdown command to shut down the interface.
2. Run the commit command to make the configuration take effect.
3. Run the undo shutdown command to restart the interface.
NOTE
The shutdown, and undo shutdown commands must be run in sequence so that the preceding
Step 5 Run commit
----End
8.4.3 Verifying the Unidirectional PAP Authentication

Configuration
After configuring unidirectional PAP authentication, you can view the link status and LCP
running status of the current interface.
Prerequisites
Unidirectional PAP authentication has been configured.
Procedure
link status and LCP running status of the current interface.
----End

8.5 Configuring MP
The Multilink Point-to-Point Protocol (MP) is a technique that bundles multiple Point-to-
Point Protocol (PPP) links together to increase link bandwidth and improve link reliability.
Usage Scenario
A single PPP link provides only limited bandwidth. To increase link bandwidth and reliability,
bundle multiple PPP links into an MP link.
In Figure 8-2, there are three PPP links between Device A and Device B. You can add these
three PPP links to an MP-Group to create an MP link. Compared with a single PPP link, an
MP link provides higher bandwidth. In an MP-Group, although one PPP link fails, other links
keep properly transmitting services.
Figure 8-2 Communication over an MP link
Device A Device B
Before you configure an MP link, establish PPP links.
8.5.1 Configuring MP Implementations

An MP-Group interface is a logical interface used by MP applications. MP is implemented by
adding multiple interfaces to an MP-Group interface.
Procedure
Step 2 Run interface mp-group number
An MP-Group interface is created, and the MP-Group interface view is displayed.
Step 3 Assign an IP address to the MP-Group interface.
Perform either of the following operations to assign an IP address to the MP-Group interface:
l To specify an IP address, run:
Run ip address ip-address { mask | mask-length }

l To configure the MP-Group interface to obtain an IP address from the remote device
using PPP negotiation, run:
Run ip address ppp-negotiate
Step 4 Run quit
Step 6 Run ppp mp mp-group number
The interface is added to the MP-Group interface so that the interface works in MP mode.
NOTE
The number value specified in this step must be the same as the number value specified in Step 2.
Repeat Steps 5 and 6 to add multiple interfaces to the MP-Group interface.

Step 7 (Optional) Configure authentication. For detailed information about authentication
configuration, see 8.4 Configuring Unidirectional PAP Authentication or 8.3 Configuring
Unidirectional CHAP Authentication.
Step 8 After completing the configuration, restart all the physical interfaces to trigger PPP
negotiation so that the physical interfaces are successfully added to the MP-Group interface.
1. Run shutdown
2. Run commit
NOTE
Step 9 (Optional)Run cpos mix-link-protocol enable

The coexistence of MLPPP services and any of TDM, ATM, and IMA services on CPOS
subcards is enabled.
Step 10 Run commit
----End
8.5.2 (Optional) Disabling Endpoint Discriminator Negotiation

The Link Control Protocol (LCP) status is Up only if the endpoint discriminators for the MP-
Group interfaces on both ends are the same. If they are different, disable endpoint
discriminator negotiation on both ends.

Procedure
Step 3 Run undo discriminator
Endpoint discriminator negotiation is disabled.
NOTE
The endpoint discriminator negotiation configurations on both ends must be the same so that the LCP
status can be Up. If the undo discriminator command is run on one end, whereas the discriminator
command on the other end, the parameters sent by the end with the undo discriminator command
configured do not contain the endpoint discriminator, but this end accepts the endpoint discriminator of
the other end. As a result, the MP link fails to be established.
Step 4 Restart the MP-Group interface.

1. Run shutdown
2. Run commit
NOTE
The shutdown, commit, and undo shutdowncommands must be run in sequence so that the preceding
Step 5 Run commit

----End
8.5.3 (Optional) Configuring the MRRU

The maximum receive reconstructed unit (MRRU) defines the maximum size (in bytes) of
each packet a device can receive without fragmenting the packet. The MRRU is negotiated by
two ends on a Multilink Point-to-Point Protocol (MP) link. A local end sends packets or
fragments with the maximum size equal to the negotiated MRRU to its peer. Upon receipt, the
peer can accept the packets or reassemble fragments into packets.
Context
The interface MRRU, which is used in Link Control Protocol (LCP) negotiation, is closely
related to the interface maximum transmission unit (MTU):
l If the MRRU of the peer MP-Group interface is greater than or equal to the MTU of the
local MP-Group interface, the local MP-Group interface keeps its own MTU unchanged
during LCP negotiation.

l If the MRRU of the peer MP-Group interface is less than the MTU of the local MP-
Group interface, the local MP-Group interface uses the MRRU of the peer MP-Group
interface as its own MTU during LCP negotiation.
Procedure
Step 3 Run mrru size
The MRRU of the MP-Group interface is configured.

1. Run shutdown

2. Run commit


NOTE
Step 5 Run commit
----End
8.5.4 (Optional) Configuring the Short Sequence Number for

Negotiation
A sequence number in the packet header indicates the sequence of a fragmented packet. Using
short sequence number for negotiation shortens the packet length and improves
communication reliability.
Context
A sequence number in the packet header indicates the sequence of a fragmented packet. The
header of an MP packet can use either a 12-bit short sequence number or a 24-bit long
sequence number. To configure an MP-group interface to use the short sequence number
contained in packet headers to perform negotiation, run the short-sequence command. Using
short sequence number for negotiation shortens the packet length and improves
communication reliability.

Procedure
Step 3 Run short-sequence
The MP-group interface is configured to use the short sequence number contained in packet
headers to perform negotiation.

1. Run shutdown
2. Run commit
NOTE
Step 5 Run commit

----End
8.5.5 (Optional) Configuring MP Fragmentation

Setting a proper size for Multilink PPP (MP) fragments improves bandwidth use efficiency.
Context
To improve bandwidth use efficiency on an MP link, configure MP fragmentation and set a
proper size for MP fragments.
Procedure
Step 2 (Optional) Run mp statistics fragment-mode enable
The fragment statistical mode is configured for all MP-group interfaces and global MP-group
interfaces.

The MP-Group interface view is displayed.
Step 4 Run fragment-threshold threshold
The maximum size of MP fragments is set.
NOTE
The MP fragment maximum size of 256 bytes is recommended.
Step 5 Run drop-timeout time-number
A timeout period is set for an MP interface to reassemble upstream MP packets.

1. Run shutdown

2. Run commit


NOTE
Step 7 Run commit
----End
8.5.6 (Optional) Improving MP Link Reliability

This section describes how to configure flapping damping and the minimum number of Point-
to-Point-Protocol (PPP) links allowed for a Multilink Point-to-Point Protocol (MP) link to
improve MP link reliability.
Context
The flapping status of an MP link reflects the bandwidth stability of the MP link. In a
specified monitoring period, if the number of flapping times of an MP member link exceeds
the specified maximum number of flapping times, configure flapping damping for MP
member links.
NOTE
After an MP member link is dampened, the interfaces on the two ends of the member link enter the
damping state. The data link layer status of the end interfaces for the member link is DOWN (damping)
in the display interface mp-group command output.
The minimum number of PPP links allowed for an MP link determines the minimum
bandwidth of the MP link. To meet bandwidth requirements, you can configure the minimum
number of PPP links allowed for an MP link.

Procedure
Step 3 Run ppp mp damping [ detect-time detect-time flapping-count flapping-count damping-
time damping-time ]
Flapping damping is configured for the member links of the MP link.
Step 4 Run ppp mp threshold-least number

The minimum number of PPP links allowed for the MP link is set.

1. Run shutdown
2. Run commit
NOTE
Step 6 Run commit

----End
8.5.7 Verifying the MP Configuration

After configuring the Multilink Point-to-Point Protocol (MP), verify the configuration.
Prerequisites
MP has been configured.
Procedure
l Run the display interface mp-group [ number ] command to check the status of and
traffic statistics on an MP-Group interface.
l Run the display ppp mp [ interface interface-type interface-number ] command to
check information about member interfaces of an MP-Group interface and statistics
about the packets sent and received by the MP-Group interface.
l Run the display ppp error-packet interface-type interface-number command to check
statistics about error packets received by a Point-to-Point Protocol (PPP) interface.

l Run the display time-delay-detect status command to check the transmission delays of
MP-Group member links.
----End
8.6 Configuration Examples for PPP

This section provides examples for configuring the PAP authentication and CHAP
authentication in various usage scenarios.
8.6.1 Example for Configuring PAP Authentication

This section provides an example for configuring PAP authentication.
In Figure 8-3, Device A and Device B are connected using LMP interfaces. Device A is
required to authenticate Device B in PAP mode.
Figure 8-3 Networking diagram for PAP authentication

NOTE
Interface 1 in this example is Lmpif0/1/0.
DeviceA interface1 DeviceB

10.110.0.2/24
interface1
10.110.0.1/24
Precautions
None
1. Add the user name and password of Device B to the local user list of Device A.
2. Configure Device A to authenticate Device B in PAP mode.
3. Configure Device B to send its user name and password to Device A.
Data Preparation
l User name and password of Device B
l IP address of the Lmpif interface on Device A
l IP address of the Lmpif interface on Device B

Procedure
# Add the user name and password of Device B to the local user list of Device A.
[*HUAWEI] commit
[~DeviceA] aaa
[*DeviceA-aaa] local-user rtb password cipher Hello-1234
[*DeviceA-aaa] quit
# Assign an IP address to Lmpif 0/1/0 and configure PPP as a link layer protocol of the
interface.
[~DeviceA] interface Lmpif 0/1/0
[~DeviceA-Lmpif0/1/0] ip address 10.110.0.1 255.255.255.0
[*DeviceA-Lmpif0/1/0] link-protocol ppp
# Configure Device A to authenticate Device B in PAP mode.

[*DeviceA-Lmpif0/1/0] ppp authentication-mode pap
[*DeviceA-Lmpif0/1/0] undo shutdown
# Submit the configuration.

[*DeviceA-Lmpif0/1/0] commit

interface.
[*HUAWEI] commit
[~DeviceB] interface Lmpif0/1/0
[~DeviceB-Lmpif0/1/0] ip address 10.110.0.2 255.255.255.0
[*DeviceB-Lmpif0/1/0] link-protocol ppp
# Configure Device B to send its user name and password to Device A.

[*DeviceB-Lmpif0/1/0] ppp pap local-user rtb password cipher Huawei-123
[*DeviceB-Lmpif0/1/0] undo shutdown

[*DeviceB-Lmpif0/1/0] commit

After completing the configurations, run the display interface command on each Router. The
command output shows that the LCP status is opened. The following example uses command
output on Device A.
[~DeviceA] display interface Lmpif 0/1/0
Lmpif0/1/0 current state : UP (ifindex: 15)
Description: HUAWEI, Quidway Series, Lmpif0/1/0 Interface
Route Port,The Maximum Transmit Unit is 1500
LCP opened, IPCP opened
Current BW: 100 Mbits
Statistics last cleared:never:

Input error: 0 shortpacket, 0 longpacket, 0 CRC, 0 lostpacket

----End
Configuration Files
#
sysname DeviceA
#
interface Lmpif0/1/0
undo shutdown
link-protocol ppp
ip address 10.110.0.1 255.255.255.0
ppp authentication-mode pap
#
aaa
local-user rtb password cipher @%@%j]v~7%f[#S'W>j9zzM)3,*!u@%@%
#
return

#
sysname DeviceB
#
undo shutdown
link-protocol ppp
ip address 10.110.0.2 255.255.255.0
ppp pap local-user rtb password cipher Huawei-123
#
return
8.6.2 Example for Configuring Unidirectional CHAP

Authentication
This section provides an example for configuring unidirectional CHAP authentication.
In Figure 8-4, Device A is required to authenticate Device B in CHAP mode. The
authenticator, Device A, needs to be assigned a user name.
Figure 8-4 Networking diagram for unidirectional CHAP authentication

NOTE
Interface 1 in this example is Lmpif0/1/0.

10.110.0.2/24
interface1
10.110.0.1/24

Precautions
None
1. Add the user name and password of Device B to the local user list of Device A.
2. Configure a user name on the interface of Device A.
3. Enable the interface on Device A to authenticate Device B in CHAP mode.
4. Add the user name and password of Device A to the local user list of Device B.
5. Configure a user name on the interface of Device B.
Data Preparation
l User name of Device A

l User name and password of Device B
l IP address of the Lmpif interface on Device A
l IP address of the Lmpif interface on Device B
Procedure
[*HUAWEI] commit
[~DeviceA] aaa
[~DeviceA-aaa] local-user rtb password cipher Hello-12345
[*DeviceA-aaa] quit
interface.
[~DeviceA-Lmpif0/1/0] ip address 10.110.0.1 255.255.255.0
# Configure the local end to authenticate the peer in CHAP mode.

[*DeviceA-Lmpif0/1/0] ppp authentication-mode chap
# Configure the user name of Device A.

[*DeviceA-Lmpif0/1/0] ppp chap user rta
# Start the interface.




interface.
[*HUAWEI] commit
[~DeviceB] interface Lmpif 0/1/0
# Configure the local end to be authenticated in CHAP mode.

[*DeviceB-Lmpif0/1/0] ppp chap user rtb
[*DeviceB-Lmpif0/1/0] ppp chap password cipher Huawei-123


output on Device A.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
link-protocol ppp
ip address 10.110.0.1 255.255.255.0
ppp authentication-mode chap
ppp chap user rta
#
aaa
#
return

#

sysname DeviceB
#
undo shutdown
link-protocol ppp
ip address 10.110.0.2 255.255.255.0
ppp chap user rtb
ppp chap password cipher Huawei-123
#
return
8.6.3 Example for Configuring Bidirectional CHAP

Authentication
This section provides an example for configuring bidirectional CHAP authentication.
In Figure 8-5, Device A and Device B are required to authenticate each other in CHAP mode.
Figure 8-5 Networking diagram for bidirectional CHAP authentication

NOTE
Interfaces 1 in this example is Lmpif0/1/0.

10.110.0.2/24
interface1
10.110.0.1/24
Precautions
None
1. Configure the local user lists on Device A and Device B.

2. Configure the user names on the interfaces of Device A and Device B.
3. Enable CHAP authentication on the interfaces of Device A and Device B.
Data Preparation
l User names of Device A and Device B

l Passwords of Device A and Device B
l IP address of the interface on Device A
l IP address of the interface on Device B

NOTE
Device A and Device B must use the same password; otherwise the authentication fails.
Procedure
[*HUAWEI] commit
[~DeviceA] aaa
[~DeviceA-aaa] local-user rtb password cipher Hello-456
[*DeviceA-aaa] quit
interface.
[*DeviceA-Lmpif0/1/0] ip address 10.110.0.1 255.255.255.0
# Configure the user name and password of Device A.

[*DeviceA-Lmpif0/1/0] ppp chap user rta
[*DeviceA-Lmpif0/1/0] ppp chap password cipher Huawei-123
# Configure Device A to authenticate Device B in CHAP mode.

[*DeviceA-Lmpif0/1/0] ppp authentication-mode chap


# Add the user name and password of Device A to the local user list of Device B.
[*HUAWEI] commit
[*DeviceB] aaa
[~DeviceB-aaa] local-user rta password cipher Hello-456
[*DeviceB-aaa] quit
interface.
[~DeviceB] interface Lmpif 0/1/0
# Configure the user name and password of Device B.

[*DeviceB-Lmpif0/1/0] ppp chap user rtb
[*DeviceB-Lmpif0/1/0] ppp chap password cipher Huawei-123
# Configure Device B to authenticate Device A in CHAP mode.

[*DeviceB-Lmpif0/1/0] ppp authentication-mode chap


output on Device A.
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
link-protocol ppp
ip address 10.110.0.1 255.255.255.0
ppp chap user rta
#
aaa
#
return

#
sysname DeviceB
#
undo shutdown
link-protocol ppp
ip address 10.110.0.2 255.255.255.0
ppp chap user rtb
#
aaa
local-user rta password cipher @%@%j]v~7%f[#S'W>j9zzM)3,*!u@%@%
#
return

8.6.4 Example for Configuring MP Groups

When two devices connect to each other through E1 interfaces, these E1 interfaces can be
added to MP groups to increase the available bandwidth. This section provides an example on
how to configure MP groups.
On the network shown in Figure 8-6, Device A and Device B connect to each other through
two pairs of E1 interfaces.
A single link sometimes cannot support data transmission when services are busy. To quickly,
efficiently, and securely increase the available transmission bandwidth for data transmission,
MP groups can be used.
Figure 8-6 Adding E1 interfaces to MP groups

NOTE
In this example, interface1, interface2, interface3, and interface4 represent E1 0/1/0, E1 0/1/1, E1 0/2/0,
and E1 0/2/1respectively.
DeviceA DeviceB
1. Create MP-group interfaces.
2. Create synchronous serial interfaces and add the interfaces to the MP-group interfaces.
Data Preparation
l IP address of the MP-group interface on Device A

l IP address of the MP-group interface on Device B
l E1 interface numbers of Device A
l E1 interface numbers of Device B
NOTE

Procedure
Step 1 Create MP-group interfaces.
# Create an MP-group interface and configure an IP address for it on Device A.

[*HUAWEI] commit
[*DeviceA-Mp-group0/1/1] shutdown
# Create an MP-group interface and configure an IP address for it on Device B.

[*HUAWEI] commit
[*DeviceB-Mp-group0/2/1] shutdown
Step 2 Create synchronous serial interfaces and add the interfaces to the MP-group interfaces.
# Configure E1 interfaces of Device A as synchronous serial interfaces and add them to the
MP-group interface.
[*DeviceA-Serial0/1/0:1] ppp mp mp-group 0/1/1
[*DeviceA-Serial0/1/1:1] ppp mp mp-group 0/1/1
# Configure E1 interfaces of Device B as synchronous serial interfaces and add them to the
MP-group interface.


# Restart the synchronous serial and MP-group interfaces on Device A.
[~DeviceA-Mp-group0/1/1] undo shutdown
# Restart the synchronous serial and MP-group interfaces on Device B.

[~DeviceB-Mp-group0/2/1] undo shutdown

# On Device A, check information about the MP-group interface and statistics about the
packets sent and received by the MP-group interface.
[~DeviceA] display ppp mp interface mp-group 0/1/1
Mp-group is Mp-group0/1/1
===========Sublinks status begin======
Serial0/1/0:1 physical UP,protocol UP
===========Sublinks status end========
Bundle Multilink, 2 member, slot 1, Master link is Mp-group0/1/1
0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved,
sequence 0/0 rcvd/sent
The bundled son channels are:
Serial0/1/0:1
Serial0/1/1:1
# On Device B, check information about the MP-group interface and statistics about the
packets sent and received by the MP-group interface.
[~DeviceB] display ppp mp interface mp-group 0/2/1
Mp-group is Mp-group0/2/1
Bundle Multilink, 2 member, slot 2, Master link is Mp-group0/2/1
0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved,
sequence 0/0 rcvd/sent
The bundled son channels are:
Serial0/2/0:1
Serial0/2/1:1

# On Device A, ping the IP address of MP-group 0/2/1 on Device B. The command output
shows that the ping is successful.
0.00% packet loss
----End
Configuration Files
#
sysname DeviceA
#
controller E1 0/1/0
#
undo shutdown
link-protocol ppp
#
controller E1 0/1/1
#
undo shutdown
link-protocol ppp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname DeviceB
#
controller E1 0/2/0
#
undo shutdown
link-protocol ppp
#
controller E1 0/2/1
#
undo shutdown
link-protocol ppp
#
undo shutdown

ip address 10.1.1.2 255.255.255.0

#
return

Configuration Guide - WAN Access 9 TDM Configuration
9 TDM Configuration
About This Chapter
This chapter describes the basic information about the TDM, and describes how to configure
the TDM service.
9.1 Overview of TDM

9.2 Licensing Requirements and Limitations for tdm--M2H
9.3 Licensing Requirements and Limitations for tdm--M2K
9.4 Configuring TDMoPSN
Local CCC, SVC, and PWE3 pseudo wires (PWs) can be established to transmit TDMoPSN
services.
9.5 Configuring an IP-SDH Hybrid Network to Bear the CTS or GSM-R Service
9.6 Configuration Examples for TDM
You can learn the configuration procedures based on the configuration flowchart. Each
configuration example consists of such information as the networking requirements,
configuration notes, and configuration roadmap.
9.1 Overview of TDM

Time Division Multiplex (TDM) is implemented by dividing a channel by time, sampling
voice signals, and enabling sampled voice signals to occupy a fixed interval that is called
timeslot according to time sequence. In this way, multiple ways of signals, through TDM, can
be combined into one way of high-rate complex digital signal (group signal) in a certain
structure. Each way of signal is transmitted independently.
Based on TDM circuits on a PSN, TDM Circuits over Packet Switching Networks
(TDMoPSN) is a kind of PWE3 service emulation. TDMoPSN emulates TDM services over a
PSN such as an MPLS or Ethernet network; therefore, transparently transmitting TDM
services over a PSN. TDMoPSN is mainly implemented by means of two protocols:
Structure-Agnostic TDM over Packet (SAToP) and Structure-Aware TDM Circuit Emulation
Service over Packet Switched Network (CESoPSN).

l CESoPSN
The Structure-aware TDM Circuit Emulation Service over Packet Switched Network
(CESoPSN) function simulates PDH circuit services of low rate on E1/T1/E3 interfaces.
Different from SAToP, CESoPSN provides structured simulation and transmission of
TDM services. That is, with a framed structure, it can identify and transmit signaling in
the TDM frame.
Features of the structured transmission mode are as follows:
– When services are carried on the PSN, the TDM structure needs to be protected
explicitly.
– The transmission with a sensitive structure can be applied to the PSN with poor
network performance. In this manner, the transmission is more reliable.
l SAToP
The Structure-Agnostic TDM over Packet (SAToP) function emulates PDH circuit
services of low rate.
SAToP is used to carry E1/T1/E3 services in unframed mode (non-structured). It divides
and encapsulates serial data streams of TDM services, and then transmits encapsulated
packets in a PW. SAToP is the most simple method to handle transparent transmission of
PDH low-rate services in TDM circuit simulation schemes.
Features of non-structured transmission mode are as follows:
– The mode does not need to protect the integrity of the structure; it does not need to
explain or operate the channels.
– It is suitable for the PSN of higher transmission performance.
– It needs to neither distinguish channels nor interrupt TDM signaling.
9.2 Licensing Requirements and Limitations for tdm--

M2H
Licensing Requirements
This feature is a basic feature and is not under license control.
Restrictions and Guidelines

Restrictions Guidelines Impact
The fast alarm processing Plan services properly. The fast alarm processing
function for TDM PWE3 function for TDM PWE3
services on a 4-port CPOS services on a 4-port CPOS
subcard cannot be subcard cannot be
configured on CPOS configured on CPOS
interface 3 (interface range interface 3 (interface range
0-3). 0-3).

After a CPOS interface is Plan services properly. After a CPOS interface is

enabled to send TUAIS enabled to send TUAIS
signals when the CES signals when the CES
service is interrupted on the service is interrupted on the
interface, both the CES and interface, both the CES and
ATM/PPP services cannot ATM/PPP services cannot
be created on the same E1 be created on the same E1
channel. channel.
9.3 Licensing Requirements and Limitations for tdm--M2K

The fast alarm processing Plan services properly. The fast alarm processing
function for TDM PWE3 function for TDM PWE3
services on a 4-port CPOS services on a 4-port CPOS
subcard cannot be subcard cannot be
configured on CPOS configured on CPOS
interface 3 (interface range interface 3 (interface range
0-3). 0-3).
After a CPOS interface is Plan services properly. After a CPOS interface is

enabled to send TUAIS enabled to send TUAIS
signals when the CES signals when the CES
service is interrupted on the service is interrupted on the
interface, both the CES and interface, both the CES and
ATM/PPP services cannot ATM/PPP services cannot
be created on the same E1 be created on the same E1
channel. channel.
9.4 Configuring TDMoPSN

Local CCC, SVC, and PWE3 pseudo wires (PWs) can be established to transmit TDMoPSN
services.
Applicable Environment
Services of the 2G RAN network, mainly a small number of voice services, are transmitted
over TDM links. Generally, one to three E1 interfaces on a BTS are connected to a BSC.

Some mobile carriers do not own fixed network infrastructure, and therefore have to lease E1
lines of the fixed network at a high price.
With the introduction of TDMoPSN services, the services between the CEs in the same city
can be transparently transmitted over TDM links in a Metro Ethernet (ME) network. Data of
the Fractional E1 interface can be transmitted from the BTS to BSC in the mode of
structuralized TDM circuit emulation.
A PW is established between Router through VLL or PWE3 to transparently transmit TDM
frames.
Before configuring a TDMoPSN service, complete the following tasks on the routers at both
ends of the PW:
l Configure static routes or an IGP protocol on PEs and Ps on the MPLS backbone
network to ensure IP connectivity.
l Configure basic MPLS functions on PEs and Ps of the MPLS backbone network.
l Set up LDP sessions among PEs (if the PEs are indirectly connected, set up remote LDP
sessions between them).
l Establish tunnels between PEs based on the tunnel policy (if no tunnel policy is
configured, the default tunnel policy LDP is used).
l Configure synchronous serial interfaces and TDM link protocols.
9.4.1 Configuring a Local TDMoPSN Service

To configure the local TDMoPSN Service, you need to create a local CCC connection and
only configure the incoming and outgoing interfaces of the CCC connection on a local PE.
The local CCC connection is bidirectional and only one such connection needs to be created.
Context
The local CCC connection is bidirectional, and only one connection is required.
Perform the following steps on PEs:
Procedure
Step 2 Run mpls l2vpn
MPLS L2VPN is enabled.
Step 3 Run quit
Step 4 Run ccc ccc-connection-name interface interface-type1 interface-number1 out-interface
interface-type2 interface-number2 [ jitter-buffer depth | idle-code idle-code-value | rtp-
header | tdm-encapsulation number ]
A local CCC connection is created.

Step 5 Run commit

----End
Follow-up Procedure
After the configuration mentioned above on the PE, a local CCC connection is created.
9.4.2 Configuring a Remote TDMoPSN Service

TDMoPSN supports the establishment of local SVC and PWE3 PWs to transmit CES
services.
Context
At the edge of a PSN, PE1 on the user side is connected downstream to CE1, and PE2 on the
network side is connected to upstream CE2. Both PEs require the following configurations,
whereas devices inside the PSN do not.
The following PW types are supported:
l SVC
l PWE3
Referring to the configuration of a PW, take the dynamic PWE3 as an example.
The procedures for configuring the preceding parameters in the two views are as follows:
Procedure
l Create a PW in the PW template view.
a. Run system-view
b. Run mpls l2vpn
c. Run pw-template pw-template-name
A PW template is created and the PW template view is displayed.
d. Run peer-address ip-address
An IP address is assigned to the peer PE of the PW.
e. Run tnl-policy policy-name
A policy is configured for the PW template to select tunnels.
f. (Optional) Run jitter-buffer depth depth
The depth of the jitter buffer is set.
g. (Optional) Run tdm-encapsulation-number number
The number of TDM frames encapsulated in a CESoPSN or SAToP packet is set.
h. (Optional) Run rtp-header

The RTP header carried in the TDM transparent transmission encapsulation is

configured.
i. Run quit
Exit from the PW template view.

j. Run interface controller-number : set-number

k. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ | tunnel-
policy policy-name | [ control-word | no-control-word ] | [ jitter-buffer depth ] |
[ tdm-encapsulation number ] | [ tdm-sequence-number ] | [ idle-code idle-code-
value ] | rtp-header | ignore-standby-state ] *
A dynamic PW is created.
l. (Optional) Run trap-threshold { ces-jtrovr-exc | ces-jtrudr-exc | ces-lospkt-exc |
ces-malpkt-exc | ces-misorderpkt-exc | ces-straypkt-exc } trigger-threshold
trigger-threshold-value resume-threshold resume-threshold-value
The alarm and clear alarm thresholds of CES service performance are set.
m. (Optional) Run pw-control-word rml-bit enable
The serial interface is enabled to use RML bits in PW control words to

transparently transmit alarms.
n. Run commit

l Creating a PW in the interface view
a. Run system-view

b. Run mpls l2vpn

c. Run interface controller-number : set-number

d. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ | tunnel-
e. (Optional) Run trap-threshold { ces-jtrovr-exc | ces-jtrudr-exc | ces-lospkt-exc |
f. (Optional) Run pw-control-word rml-bit enable

g. Run commit


----End
9.4.3 Configuring a Local CES Service

To configure the local CEP Service, you need to create a local CCC connection and only
configure the incoming and outgoing interfaces of the CCC connection on a local PE. The
local CCC connection is bidirectional and only one such connection needs to be created.
Context
The local CCC connection is bidirectional, and only one connection is required.
Perform the following steps on PEs:
Procedure
Step 2 Run mpls l2vpn
Step 3 Run quit
Step 5 Run using vc4
The CPOS interface is configured to work in clear channel mode, and a synchronous serial
interface is created on the CPOS interface.
Step 6 Run quit
Step 7 Run ccc ccc-connection-name interface interface-type1 interface-number1 out-interface
interface-type2 interface-number2 [ jitter-buffer depth | rtp-header ]
A local CCC connection is created.
Step 8 Run interface serial
The Serial interface view created in step 5 is displayed.
Step 9 (Optional) Run cep soh-transport enable
Enable SOH transport on a CEP interface.
Step 10 Run commit
----End

Follow-up Procedure
After the configuration mentioned above on the PE, a local CCC connection is created.
9.4.4 Configuring a Remote CEP Service

TDMoPSN supports the establishment of local SVC and PWE3 PWs to transmit CEP
services.
Context
At the edge of a PSN, PE1 on the user side is connected downstream to CE1, and PE2 on the
network side is connected to upstream CE2. Both PEs require the following configurations,
whereas devices inside the PSN do not.
The following PW types are supported:
l SVC
l PWE3
Referring to the configuration of a PW, take the dynamic PWE3 as an example.
The procedures for configuring the preceding parameters in the two views are as follows:
Procedure
l Create a PW in the PW template view.
a. Run system-view
b. Run mpls l2vpn
c. Run pw-template pw-template-name
A PW template is created and the PW template view is displayed.
d. Run peer-address ip-address
An IP address is assigned to the peer PE of the PW.
e. Run tnl-policy policy-name
A policy is configured for the PW template to select tunnels.
f. (Optional) Run jitter-buffer depth depth
The depth of the jitter buffer is set.
g. (Optional) Run rtp-header
The RTP header carried in the TDM transparent transmission encapsulation is
configured.
h. Run quit
Exit from the PW template view.
i. Run controller cpos cpos-number

j. Run using vc4

synchronous serial interface is created on the CPOS interface.
k. Run interface serial
The Serial interface view created in is displayed.
l. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ | tunnel-
m. (Optional) Run trap-threshold { ces-jtrovr-exc | ces-jtrudr-exc | ces-lospkt-exc |
n. (Optional) Run pw-control-word rml-bit enable
o. Run commit
l Creating a PW in the interface view
a. Run system-view
b. Run mpls l2vpn
c. Run controller cpos cpos-number
d. Run using vc4
synchronous serial interface is created on the CPOS interface.
e. Run interface serial
The Serial interface view created in is displayed.
f. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ | tunnel-
g. (Optional) Run trap-threshold { ces-jtrovr-exc | ces-jtrudr-exc | ces-lospkt-exc |

h. (Optional) Run pw-control-word rml-bit enable

i. Run commit
----End
9.4.5 Verifying the TDM Service Configuration

After a TDM service is configured, you cannot only view configurations and statuses of
E1/CE1 interfaces, but also view information about the static PW and dynamic PW.
Context
Run the following commands to check the previous configuration.
Procedure
l Run the display controller e1 controller-number command to check the configuration
and status of the E1/CE1 interface.
l Run the display mpls static-l2vc [ vc-id |interface interface-type interface-number |
state { down | up } ] or display mpls static-l2vc brief command to check information
about the static PW.
l Run the display mpls l2vc [ vc-id | interface interface-type interface-number ] or
display mpls l2vc brief command to check information about the dynamic PW.
----End
9.5 Configuring an IP-SDH Hybrid Network to Bear the

CTS or GSM-R Service
Usage Scenario
The Cordless Telephony System (CTS) is a dispatch phone service for railway networks. The
Global System for Mobile Communications - Railway (GSM-R) is a railway communication
system based on the GSM communication standard. To bear the CTS or GSM-R service on a
hybrid network with both IP and SDH devices deployed, perform the following operations on
the NE40E to implement communication with the SDH device.
Perform one or more of the following configurations as required.
9.5.1 Configuring Fast Alarm Detection
Usage Scenario
In TDM dual feed and selective receiving scenarios, to enable a local serial interface to
rapidly notify an AC-side device of PW faults, enable fast alarm detection on the serial

interface. The AC-side device can then quickly learn the fault information and switch to a
normal link for data receiving.
Before configuring fast alarm detection on a serial interface, run the link-protocol tdm
command to enable TDM for the interface.
Procedure
The view of the specified serial interface is displayed.
Step 3 Run fast-alarm-detect enable
Fast alarm detection is enabled.
Step 4 Run commit
----End
9.5.2 Configuring the Function to Send a Specific Bit Stream to

Notify an Idle E1 Channel Timeslot
Usage Scenario
If the NE40E is connected to an SDH device to bear the GSM-R service, configure the
function to send the 0xFF bit stream to notify the SDH device of an idle E1 channel timeslot
on a subcard, so that the SDH device can learn network-side PW faults rapidly.
Procedure
Step 2 Run slot slot-id
The slot view is displayed.
Step 3 Run idle-code-e1 ff card card-id
The specified subcard is enabled to send the 0xFF bit stream to notify an idle E1 channel
timeslot, so that the subcard can quickly and continuously send AIS bit streams to the AC-
side device if network-side PW faults occur.
Step 4 Run commit
----End

9.5.3 Configuring the Functions to Send Alarm Information on

the Device Connected to an SNCP-Enabled SDH Device
Usage Scenario
If the NE40E is connected to an SDH service to bear the GSM-R service, configure the
NE40E to notify PW-side and AC-side faults through TU-AIS and AIS bit streams,
respectively.
Procedure
The view of a specific CPOS interface is displayed.
Step 3 Run sdh-alarm uni-tuais ces-underrun enable
The CPOS interface is enabled to send TU-AIS bit streams to an AC-side device when the
CES service is interrupted on the interface.
Step 4 Run sdh-alarm nni-ais lrdi enable
The CPOS interface is enabled to send AIS bit streams to a network-side device when an
LRDI alarm is detected on the interface.
Step 5 Run commit
----End
9.6 Configuration Examples for TDM

You can learn the configuration procedures based on the configuration flowchart. Each
configuration example consists of such information as the networking requirements,
configuration notes, and configuration roadmap.
9.6.1 Example for Configuring TDMoPSN

TDM transparent cell transport provides a new alternative for wireless operators. Through
TDM transparent cell transport, services between the BTSs and BSCs in the same city can be
transparently transmitted over CES links in a Metro Ethernet (ME) network. Data of the
fractional E1 interface can be transmitted from the GSM BTS to BSC in the mode of
structuralized CES circuit emulation.Through TDM transparent cell transport, services
between the users and companys in the same city can be transparently transmitted over TDM
links in a Metro Ethernet (ME) network.
Generally, on a 2G RAN, one to three E1 interfaces on a BTS are connected to a BSC. Some
mobile operators do not own fixed network infrastructure, and have to rent E1 lines of fixed-

line network operators at a high price. By deploying CESoPSN service, that is, CES
transparent transmission on a 2G RAN, these mobile operators can achieve transparent
transmission of 2G services between the BTSs and BSCs in the same city over CES links in a
Metro Ethernet (ME) network, which is both simple and cost-saving.
As shown in Figure 9-1, it is required that the BTSUser and PE1 should be connected through
two E1 links. The BSCCompany and PE2 should be connected through the CPOS interface.
On the channelized serial interface of E1 links, configure the encapsulation protocol as CES.
Then, a PW is set up between PE1 and PE2 to transparently transmit TDM data.
Figure 9-1 Networking diagram of configuring TDMoPSN

NOTE
In thie example, Interface1 and Interface2 are GE0/2/0 and GE0/2/1 respectively.
BTS
BSC
E1 0/3/1 Interface1 Interface1
E1 0/3/2 CPOS 0/3/1
2×TDM E1 Interface1 Interface2
PE1 P PE2
PWE3 TDM
CE1 Transparent Cell Transport CE2
Router Interface IP Address
PE1 GE 0/2/0 10.1.1.1/24
Loopback0 192.168.2.2/32
P GE 0/2/0 10.1.1.2/24
GE 0/2/1 10.2.1.1/24
Loopback0 192.168.4.4/32
PE2 GE 0/2/0 10.2.1.2/24
Loopback0 192.168.3.3/32
1. Run the IGP protocol on the backbone network so that devices can communicate with
each other.
2. Configure basic MPLS functions on the backbone network, and configure MPLS
L2VPN functions on PE devices. Establish the remote MPLS LDP peer relationship
between PEs at both ends of the PW.
3. Configure parameters for the TDM interface.
4. Configure the PW template.

5. Establish MPLS L2VC connections on PEs.
Data Preparation
l L2VC IDs at both ends of the PW (must be the same)
l MPLS LSR IDs of the PEs and P router
l IP addresses of the remote peers of PEs
l Coding mode and frame format of the E1/CE1 interface
Procedure
Step 1 Run the IGP protocol on the backbone network so that devices can communicate with each
other. For detailed configurations, see the configuration file of this example.
Step 2 Configure basic MPLS functions on the backbone network, and configure MPLS L2VPN
functions on PE devices. Then, establish the remote MPLS LDP peer relationship between
PEs at both ends of the PW. For detailed configurations, see the configuration file of this
example.
The remote MPLS LDP peer relationship is required only for the dynamic PW.
Step 3 Configure parameters for the TDM interface.
1. Configure PE1.
# Configure the channelized mode and CRC4 frames for CE1 0/3/1 and CE1 0/3/2 on
PE1.
[~PE1] controller e1 0/3/1
[~PE1-E1 0/3/1] using ce1
[*PE1-E1 0/3/1] frame-format crc4
[*PE1-E1 0/3/1] channel-set 1 timeslot-list 1-31
[*PE1-E1 0/3/1] quit
[*PE1] controller e1 0/3/2
[*PE1-E1 0/3/2] using ce1
[*PE1-E1 0/3/2] frame-format crc4
[*PE1-E1 0/3/2] channel-set 1 timeslot-list 1-31
[*PE1-E1 0/3/2] quit
[*PE1-E1 0/3/2] commit
2. Configure PE2.
# Set parameters for the CPOS interface on PE2.
[~PE2] controller cpos 0/3/1
[~PE2-Cpos0/3/1] e1 1 channel-set 1 timeslot-list 1-31
[*PE2-Cpos0/3/1] e1 2 channel-set 2 timeslot-list 1-31
[*PE2-Cpos0/3/1] quit
[*PE2] commit
Step 4 Configure the encapsulation protocol on the serial interface as TDM.

1. Configure PE1.
[~PE1] interface serial0/3/1:1
[~PE1-Serial0/3/1:1] link-protocol tdm
[*PE1-Serial0/3/1:1] quit
[*PE1] interface serial0/3/2:1
[*PE1-Serial0/3/2:1] link-protocol tdm
[*PE1] commit
2. Configure PE2.

[~PE2] interface serial0/3/1/1:1

[~PE2-Serial0/3/1/1:1] link-protocol tdm
[*PE2-Serial0/3/1/1:1] quit
[*PE2] interface serial0/3/1/2:2
[*PE2-Serial0/3/1/2:2] link-protocol tdm
[*PE2] commit
Step 5 Configuring the PW.

1. [~PE1] pw-template 1to3
[*PE1-pw-template-1to3] peer-address 192.168.3.3
[*PE1-pw-template-1to3] jitter-buffer depth 8
[*PE1-pw-template-1to3] tdm-encapsulation-number 24
[*PE1-pw-template-1to3] quit
[*PE1-Serial0/3/1:1] mpls l2vc pw-template 1to3 100
[*PE1-Serial0/3/2:1] mpls l2vc pw-template 1to3 200
[*PE1] commit
2. Configure PE2.
[~PE2] pw-template 3to1
[*PE2-pw-template-3to1] quit
[*PE2-Serial0/3/1/1:1] mpls l2vc pw-template 3to1 100 control-word
[*PE2-Serial0/3/1/1:1] undo shutdown
[*PE2-Serial0/3/1/2:2] mpls l2vc pw-template 3to1 200 control-word
[*PE2-Serial0/3/1/2:2] undo shutdown
[*PE2] commit

Run the display mpls l2vc command on PEs. You can view that the status of the PW is Up.
Take the display on PE1 as an example:
<PE1> display mpls l2vc interface serial0/3/1:1
*client interface : Serial0/3/1:1 is up
session state : up
AC status : up
VC state : up
VC ID : 100
VC type : CESoPSN basic mode
destination : 192.168.3.3
local group ID : 0
remote group ID : 0
local VC label : 146432
remote VC label : 145287
TDM encapsulation number : 24
jitter-buffer : 8
idle-code : 33
rtp-header : disable
local AC OAM State : up
local PSN State : up
local forwarding state : forwarding
local status code : 0x0
remote AC OAM state : up
remote PSN state : up
remote forwarding state: forwarding
remote statuscode : 0x0
BFD for PW : unavailable
manual fault : not set

active state : active

forwarding entry : not exist
link state : up
local VC MTU : 1500
remote VC MTU : 1500
local VCCV : alert lsp-ping bfd
remote VCCV : none
local control word : disable
remote control word : disable
tunnel policy name : --
traffic behavior name : --
PW template name : --
primary or secondary : primary
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : lsp , TNL ID : 0x208000
create time : 0 days, 4 hours, 48 minutes, 51 seconds
up time : 0 days, 3 hours, 43 minutes, 49 seconds
last change time : 0 days, 0 hours, 39 minutes, 29 seconds
VC last up time : 2008/12/26 12:02:49
VC total up time : 0 days, 3 hours, 43 minutes, 49 seconds
CKey : 11
NKey : 10
PW redundancy mode : frr
AdminPw interface : --
AdminPw link state : --
Forward state : send inactive, receive inactive
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
----End
Configuration Files
l Configuration file of PE1
#
sysname PE1
#
mpls lsr-id 192.168.2.2
mpls
#
mpls l2vpn
#
pw-template 1to3
peer-address 192.168.3.3
jitter-buffer depth 8
tdm-encapsulation-number 24
#
mpls ldp
#
mpls ldp remote-peer 192.168.3.3
remote-ip 192.168.3.3
#
controller e1 0/3/1
using ce1
frame-format crc4
undo shutdown
#
controller e1 0/3/2
using ce1
frame-format crc4
undo shutdown
#
interface serial0/3/1:1

link-protocol tdm
mpls l2vc pw-template 1to3 100
undo shutdown
#
link-protocol tdm
undo shutdown
#
interface GigabitEthernet0/2/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
l Configuration file of PE2
#
sysname PE2
#
mpls lsr-id 192.168.3.3
mpls
#
mpls l2vpn
#
pw-template 3to1
#
mpls ldp
#
remote-ip 192.168.2.2
#
controller cpos 0/3/1
#
interface serial0/3/1/1:1
link-protocol tdm
mpls l2vc pw-template 3to1 100 control-word
undo shutdown
#
interface serial0/3/1/2:2
link-protocol tdm
mpls l2vc pw-template 3to1 200 control-word
undo shutdown
#
undo shutdown
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.3.3 0.0.0.0

network 10.2.2.0 0.0.0.255

#
return
l Configuration file of P
#
sysname P
#
mpls lsr-id 192.168.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.4.4 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return
9.6.2 Example for Configuring an IP-SDH Hybrid Network to

Bear the CTS Service
The Cordless Telephony System (CTS) is a dispatch phone service for railway networks. On
the network shown in Figure 9-2, both IP and SDH devices are deployed, a dispatch phone is
single-homed to a UPE, the UPE is dual-homed to SPEs, and the SPEs are connected to the
SDH devices on the transmission backbone network. To bear the CTS service in this scenario,
implement the communication between the IP and SDH devices, configure primary and
secondary PWs between the UPE and SPEs, and configure dual feed and selective receiving
on the UPE. In addition, configure BFD sessions on the IP network to monitor link status and
enable SNCP on the SDH network (the SNCP configuration is not provided in this section) to
improve service reliability.
Figure 9-2 Configuring an IP-SDH hybrid network to bear the CTS service
NOTE
On the example network, the device models of SPE1 and SPE1 are NE40Es.
Interface 0, interface 1, interface 2, and interface 3 stand for serial 0/2/1:0, GE 0/1/1, GE 0/1/2, and
serial 0/2/1/1:0, respectively.

Loopback 0
Interface 3
Loopback 0
SPE1 SDH SDH
device device
Interface 0
Loopback 0
UPE SDH
SPE2 device
Interface3
Dual feed and
selective receiving
PW protection SNCP protection
Device Interface IP Address
UPE GE 0/1/1 10.1.1.1/24
GE 0/1/2 10.1.2.1/24
Loopback0 1.1.1.1/32
SPE1 GE 0/1/1 10.1.1.2/24
SPE2 GE 0/1/2 10.1.2.2/24
1. Configure an IP address and a routing protocol for each interface on the UPE, SPE1, and
SPE2, allowing the devices to communicate at the network layer. This example uses
OSPF as the routing protocol.
2. Configure basic MPLS functions and public tunnels to bear PWs.
3. Configure primary and secondary PWs between the UPE and SPEs.
4. Configure BFD sessions to monitor the PWs.
5. Configure fast alarm detection.
Data Preparation
l IP addresses for interfaces on the UPE, SPE1, and SPE2

l LSR IDs for the UPE, SPE1, and SPE2
l L2VC IDs for each PW (must be the same on the two ends of the PW)
l BFD parameters

Procedure
Step 1 Configure an IP address and a routing protocol for each interface on the UPE, SPE1, and
SPE2, allowing the devices to communicate at the network layer. For configuration details,
see "Configuration Files" in this section.
Step 2 Configure basic MPLS functions and public network tunnels.

1. Configure basic MPLS functions and enable MPLS LDP and MPLS TE.
# Configure the UPE.

<UPE> system-view
[~UPE] mpls lsr-id 1.1.1.1
[*UPE] mpls
[*UPE-mpls] mpls te
[*UPE-mpls] quit
[*UPE] mpls ldp
[*UPE-mpls-ldp] quit
[*UPE] interface gigabitethernet 0/1/1
[*UPE-GigabitEthernet0/1/1] mpls
[*UPE-GigabitEthernet0/1/1] mpls te
[*UPE-GigabitEthernet0/1/1] quit
[*UPE] ospf 100
[*UPE-ospf-100] opaque-capability enable
[*UPE-ospf-100] area 0
[*UPE-ospf-100-area-0.0.0.0] mpls-te enable
[*UPE-ospf-100-area-0.0.0.0] quit
[*UPE-ospf-100] quit
[*UPE] commit
The configurations of SPE1 and SPE2 are similar to the configuration of the UPE. For
configuration details, see "Configuration Files" in this section.
2. Configure TE tunnels.

[~UPE] interface tunnel 0/1/1
[*UPE-Tunnel0/1/1] ip address unnumbered interface loopback 0
[*UPE-Tunnel0/1/1] tunnel-protocol mpls te
[*UPE-Tunnel0/1/1] destination 2.2.2.2
[*UPE-Tunnel0/1/1] mpls te tunnel-id 100
[*UPE-Tunnel0/1/1] mpls te reserved-for-binding
[*UPE-Tunnel0/1/1] quit
[*UPE] interface tunnel 0/1/2
[~UPE] tunnel-policy policy1
[*UPE-tunnel-policy-policy1] tunnel binding destination 2.2.2.2 te Tunnel
0/1/1
0/1/2
[*UPE-tunnel-policy-policy1] quit
[*UPE] commit
# Configure SPE1.
[~SPE1] interface tunnel 0/1/1
[*SPE1-Tunnel0/1/1] ip address unnumbered interface loopback 0

[*SPE1-Tunnel0/1/1] tunnel-protocol mpls te

[*SPE1-Tunnel0/1/1] destination 1.1.1.1
[*SPE1-Tunnel0/1/1] mpls te tunnel-id 100
[*SPE1-Tunnel0/1/1] mpls te reserved-for-binding
[*SPE1-Tunnel0/1/1] quit
[~SPE1] tunnel-policy policy1
[*SPE1-tunnel-policy-policy1] tunnel binding destination 1.1.1.1 te Tunnel
0/1/1
[*SPE1-tunnel-policy-policy1] quit
[*SPE1] commit
# Configure SPE2.
0/1/2
[*SPE2] commit
Step 3 Configure remote MPLS LDP sessions and PWs.

1. Configure a remote MPLS LDP session between the UPE and each SPE.
[~UPE] mpls ldp remote-peer 2.2.2.2
[*UPE-mpls-ldp-remote-2.2.2.2] remote-ip 2.2.2.2
[*UPE-mpls-ldp-remote-2.2.2.2] quit
[*UPE] mpls ldp remote-peer 3.3.3.3
[*UPE] commit
# Configure SPE1.
[~SPE1] mpls ldp remote-peer 1.1.1.1
[*SPE1-mpls-ldp-remote-1.1.1.1] remote-ip 1.1.1.1
[*SPE1-mpls-ldp-remote-1.1.1.1] quit
[*SPE1] commit
# Configure SPE2.
[*SPE2] commit
2. Configure PWs.
[~UPE] mpls l2vpn
[*UPE-l2vpn] quit
[*UPE] controller e1 0/2/1
[*UPE-E1 0/2/1] channel-set 0 timeslot-list 1-31
[*UPE-E1 0/2/1] quit
[*UPE] interface serial 0/2/1:0
[*UPE-Serial0/2/1:0] link-protocol tdm
[*UPE-Serial0/2/1:0] mpls l2vc 2.2.2.2 1 tunnel-policy policy1 control-word
[*UPE-Serial0/2/1:0] mpls l2vc 3.3.3.3 2 secondary tunnel-policy policy1
control-word secondary
[*UPE-Serial0/2/1:0] mpls l2vpn stream-dual-receiving
[*UPE-Serial0/2/1:0] mpls l2vpn stream-dual-send

[*UPE-Serial0/2/1:0] quit
[*UPE] commit
# Configure SPE1.
[~SPE1] mpls l2vpn
[*SPE1-l2vpn] quit
[*SPE1] controller cpos 0/2/1
[*SPE1-Cpos0/2/1] e1 1 channel-set 0 timeslot-list 1-31
[*SPE1-Cpos0/2/1] quit
[*SPE1] interface serial 0/2/1/1:0
[*SPE1-Serial0/2/1/1:0] link-protocol tdm
[*SPE1-Serial0/2/1/1:0] mpls l2vc 1.1.1.1 1 tunnel-policy policy1 control-word
[*SPE1-Serial0/2/1/1:0] quit
[*SPE1] commit
# Configure SPE2.
[~SPE2] mpls l2vpn
[*SPE2-l2vpn] quit
[*SPE2-Serial0/2/1/1:0] mpls l2vc 1.1.1.1 1 tunnel-policy policy1 control-word
[*SPE2] commit
Step 4 Configure BFD sessions to monitor the PWs.

[~UPE] bfd
[*UPE-bfd] quit
[*UPE] bfd master bind pw interface Serial 0/2/1:0 remote-peer 2.2.2.2 pw-ttl
auto-calculate
[*UPE-bfd-lsp-session-master] discriminator local 2
[*UPE-bfd-lsp-session-master] discriminator remote 2
[*UPE-bfd-lsp-session-master] quit
[*UPE] bfd master bind pw interface Serial 0/2/1:0 secondary remote-peer 3.3.3.3
pw-ttl auto-calculate
[*UPE-bfd-lsp-session-master] discriminator local 2
[*UPE-bfd-lsp-session-master] discriminator remote 2
[*UPE-bfd-lsp-session-master] quit
[*UPE] commit
# Configure SPE1.
[~SPE1] bfd
[*SPE1-bfd] quit
[*SPE1] bfd pw1 bind pw interface serial 0/2/1/1:0
[*SPE1-bfd-lsp-session-pw1] discriminator local 2
[*SPE1-bfd-lsp-session-pw1] discriminator remote 2
[*SPE1-bfd-lsp-session-pw1] quit
[*SPE1] commit
# Configure SPE2.
[~SPE2] bfd
[*SPE2-bfd] quit
[*SPE2] bfd pw2 bind pw interface serial 0/2/1/1:0
[*SPE2-bfd-lsp-session-pw2] discriminator local 2
[*SPE2-bfd-lsp-session-pw2] discriminator remote 2
[*SPE2-bfd-lsp-session-pw2] quit
[*SPE2] commit
Step 5 Configure fast alarm detection on SPE1 and SPE2.

# Configure SPE1.

[~SPE1] interface serial 0/2/1/1:0

[~SPE1-Serial0/2/1/1:0] fast-alarm-detect enable
[*SPE1] commit
# Configure SPE2.
[~SPE2] interface serial 0/2/1/1:0
[~SPE2-Serial0/2/1/1:0] fast-alarm-detect enable
[*SPE2] commit
----End
Configuration Files
l UPE configuration file
#
sysname
UPE
#
bfd
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
#
mpls
l2vpn
#
mpls ldp
#
mpls ldp remote-peer

2.2.2.2
remote-ip
2.2.2.2
#

3.3.3.3
remote-ip
3.3.3.3
#
controller e1 0/2/1
channel-set 0 timeslot-list
1-31
#
interface serial 0/2/1:0
link-protocol tdm
mpls l2vc 2.2.2.2 1 tunnel-policy policy1 control-word
mpls l2vc 3.3.3.3 2 tunnel-policy policy1 control-word secondary
mpls l2vpn stream-dual-receiving
mpls l2vpn stream-dual-send
#
interface GigabitEthernet 0/1/1

undo
shutdown
ip address 10.1.1.1
255.255.255.0

mpls
mpls
te
#

undo
shutdown
ip address 10.1.2.1
255.255.255.0
mpls
mpls
te
#
interface
LoopBack0
ip address 1.1.1.1
255.255.255.255
#
interface Tunnel 0/1/1

tunnel-protocol mpls te
destination 2.2.2.2
mpls te reserved-for-binding
mpls te bit-error-detection
mpls te tunnel-id 100
#
ospf
100
opaque-capability
enable
area
0.0.0.0
network 1.1.1.1
0.0.0.0
network 10.1.1.0
0.0.0.255
network 10.1.2.0
0.0.0.255
mpls-te
enable
#

destination 3.3.3.3
mpls te tunnel-id
200
#
tunnel-policy
policy1
tunnel binding destination 2.2.2.2 te Tunnel 0/1/1
#
bfd master bind pw interface serial 0/2/1:0 remote-peer 2.2.2.2 pw-ttl auto-
calculate
bfd master bind pw interface serial 0/2/1:0 secondary remote-peer 3.3.3.3 pw-
ttl auto-calculate
discriminator local 2

discriminator remote 2
#
return
l SPE1 configuration file
#
sysname
SPE1
#
bfd
mpls lsr-id 2.2.2.2

#
mpls
mpls te
#
mpls
l2vpn
#
mpls ldp
#

1.1.1.1
remote-ip
1.1.1.1
#

undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls
te
interface
LoopBack0
ip address 2.2.2.2
255.255.255.255
#
e1 1 channel-set 0 timeslot-list
1-31
#
interface serial 0/2/1/1:0
link-protocol tdm
mpls l2vpn pw bit-error-detection
fast-alarm-detect enable
#
destination 1.1.1.1
#
ospf
100
opaque-capability
enable

graceful-
restart
area
0.0.0.0
network 2.2.2.2
0.0.0.0
network 10.1.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy
policy1
#
bfd pw1 bind pw interface serial 0/2/1/1:0

discriminator remote
2
#
return
#
sysname
SPE2
#
bfd
mpls lsr-id 3.3.3.3

#
mpls
mpls te
#
mpls
l2vpn
#
mpls ldp
#

1.1.1.1
remote-ip
1.1.1.1

undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
#
interface
LoopBack0
ip address 3.3.3.3
255.255.255.255
#

1-31
#


link-protocol tdm
mpls l2vpn pw bit-error-detection
fast-alarm-detect enable
#
destination 1.1.1.1
mpls te record-route
#
ospf 100
opaque-capability enable
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
mpls-te enable
#
tunnel-policy
policy1
#
bfd pw2 bind pw interface serial 0/2/1/1:0

discriminator remote 2
#
return
9.6.3 Example for Configuring an IP-SDH Hybrid Network to

Bear the GSM-R Service
The Global System for Mobile Communications - Railway (GSM-R) is a railway
communication system based on the GSM communication standard. On the network shown in
Figure 9-3, both IP and SDH devices are deployed, a BTS is connected to a UPE through two
E1 interfaces, the UPE is dual-homed to SPEs, and the SPEs are connected to SDH devices.
To bear the GSM-R service in this scenario, implement the communication between the IP
and SDH devices, configure primary and secondary PWs between the UPE and SPEs, and
configure hard pipe to bear the PWs. In addition, configure service protection on the BTS-
BSC side to improve service reliability. Tunnel protection for the PWs is not required.
Figure 9-3 Configuring an IP-SDH hybrid network to bear the GSM-R service
NOTE
On the example network, the device models of SPE1 and SPE1 are NE40Es.
interface 1, interface 2, and interface 3, Interface 4, Interface 5stand for GE 0/1/1, GE 0/1/2, CPOS
0/2/1, serial 0/2/1:0 and serial 0/2/2:0 respectively.

Loopback 0
Interface 3
Loopback 0
BTS SDH
SPE1 BSC
device
Interface 4
Loopback 0 SDH
Interface 5 UPE
device
Interface3
SDH
SPE2
device
E2E protection for BTS-BSC services
Device Interface IP Address
UPE GE 0/1/1 10.1.1.1/24
GE 0/1/2 10.1.2.1/24
SPE1 GE 0/1/1 10.1.1.2/24
SPE2 GE 0/1/2 10.1.2.2/24
1. Configure an IP address and a routing protocol for each interface on the UPE, SPE1, and
SPE2, allowing the devices to communicate at the network layer. This example uses
OSPF as the routing protocol.
2. Configure MPLS TE tunnels to bear PWs.
3. Configure primary and secondary PWs between the UPE and SPEs.
4. Enable each SPE to send alarm bit streams to the peer device when specific faults are
detected on the SPE.
5. Configure each SPE to send the 0xFF bit stream to notify an idle E1 channel timeslot on
a subcard, so that the subcard can quickly and continuously send AIS bit streams to the
AC-side device if network-side PW faults occur.
Data Preparation
l IP addresses for interfaces on the UPE, SPE1, and SPE2
l LSR IDs for the UPE, SPE1, and SPE2
l L2VC IDs for each PW (must be the same on the two ends of the PW)

Procedure
Step 1 Configure an IP address and a routing protocol for each interface on the UPE, SPE1, and
SPE2, allowing the devices to communicate at the network layer. For configuration details,
see "Configuration Files" in this section.
Step 2 Configure basic MPLS functions and public network tunnels.
1. Enable MPLS TE.
<UPE> system-view
[~UPE] mpls lsr-id 1.1.1.1
[*UPE] mpls
[*UPE-mpls] mpls te
[*UPE-mpls] quit
[*UPE] ospf 100
[*UPE-ospf-100] opaque-capability enable
[*UPE-ospf-100] area 0
[*UPE-ospf-100-area-0.0.0.0] mpls-te enable
[*UPE-ospf-100-area-0.0.0.0] quit
[*UPE-ospf-100] quit
[*UPE] commit
The configurations of SPE1 and SPE2 are similar to the configuration of the UPE. For
configuration details, see "Configuration Files" in this section.
2. Configure TE tunnels.
[~UPE] interface tunnel 0/1/1
[*UPE-Tunnel0/1/1] mpls te signal-protocol cr-static
[*UPE-Tunnel0/1/1] mpls te bidirectional
[*UPE] interface tunnel 0/1/2
[*UPE-Tunnel0/1/2] mpls te signal-protocol cr-static
[*UPE-Tunnel0/1/2] mpls te bidirectional
[~UPE] tunnel-policy policy1
0/1/1
0/1/2
[*UPE-tunnel-policy-policy1] quit
[*UPE] commit
# Configure SPE1.


[*SPE1-Tunnel0/1/1] mpls te signal-protocol cr-static
[*SPE1-Tunnel0/1/1] mpls te passive-tunnel
[*SPE1-Tunnel0/1/1] mpls te binding bidirectional static-cr-lsp egress Tunnel
0/1/1
0/1/1
[*SPE1] commit
# Configure SPE2.
[*SPE2-Tunnel0/1/2] mpls te signal-protocol cr-static
[*SPE2-Tunnel0/1/2] mpls te passive-tunnel
[*SPE2-Tunnel0/1/2] mpls te binding bidirectional static-cr-lsp egress Tunnel
0/1/2
0/1/2
[*SPE2] commit
3. Configure static bidirectional co-routed CR-LSPs.

[~UPE] bidirectional static-cr-lsp ingress Tunnel 0/1/1
[*UPE-Tunnel0/1/1] forward outgoing-interface GigabitEthernet 0/1/1 nexthop
10.1.1.2 out-label 40
[*UPE-Tunnel0/1/1] backward in-label 43
[*UPE-Tunnel0/1/1] hard-pipe enable
[~UPE] bidirectional static-cr-lsp ingress Tunnel 0/1/2
[*UPE-Tunnel0/1/2] forward outgoing-interface GigabitEthernet 0/1/2 nexthop
10.1.2.2 out-label 41
[*UPE-Tunnel0/1/2] backward in-label 42
[*UPE-Tunnel0/1/2] hard-pipe enable
[*UPE] commit
# Configure SPE1.
[~SPE1] bidirectional static-cr-lsp egress Tunnel 0/1/1
[*SPE1-Tunnel0/1/1] forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
[*SPE1-Tunnel0/1/1] backward outgoing-interface GigabitEthernet 0/1/1 nexthop
10.1.1.1 out-label 43
[*SPE1-Tunnel0/1/1] hard-pipe enable
[*SPE1] commit
# Configure SPE2.
[~SPE2] bidirectional static-cr-lsp egress Tunnel 0/1/2
[*SPE2-Tunnel0/1/2] forward in-label 41 lsrid 1.1.1.1 tunnel-id 200
[*SPE2-Tunnel0/1/2] backward outgoing-interface GigabitEthernet 0/1/2 nexthop
10.1.2.1 out-label 42
[*SPE2-Tunnel0/1/2] hard-pipe enable

[*SPE2] commit
Step 3 Configure remote MPLS LDP sessions and PWs.

1. Configure a remote MPLS LDP session between the UPE and each SPE.
[~UPE] mpls ldp remote-peer 2.2.2.2
[*UPE] mpls ldp remote-peer 3.3.3.3
[*UPE] commit
# Configure SPE1.
[*SPE1] commit
# Configure SPE2.
[*SPE2] commit
2. Configure PWs.
[~UPE] mpls l2vpn
[*UPE-l2vpn] quit
[~UPE] pw-template pw_ces
[*UPE-pw-template-pw_ces] quit
[*UPE-Serial0/2/1:0] mpls static-l2vc destination 2.2.2.2 pw-template pw_ces
10 transmit-vpn-label 100 receive-vpn-label 100 tunnel-policy policy1 control-
word
[*UPE-Serial0/2/1:0] mpls l2vpn hard-pipe expand-ratio 20
[*UPE-Serial0/2/2:0] mpls static-l2vc destination 3.3.3.3 pw-template pw_ces
10 transmit-vpn-label 100 receive-vpn-label 100 tunnel-policy policy1 control-
word
[*UPE-Serial0/2/2:0] mpls l2vpn hard-pipe expand-ratio 20
[*UPE] commit
# Configure SPE1.
[~SPE1] mpls l2vpn
[*SPE1-l2vpn] quit
[~SPE1] pw-template pw_ces
[*SPE1-pw-template-pw_ces] quit


[*SPE1-Serial0/2/1/1:0] mpls static-l2vc destination 1.1.1.1 pw-template
pw_ces 10 transmit-vpn-label 100 receive-vpn-label 100 tunnel-policy policy1
control-word
[*SPE1-Serial0/2/1/1:0] mpls l2vpn hard-pipe expand-ratio 20
[*SPE1] commit
# Configure SPE2.
[~SPE2] mpls l2vpn
[*SPE2-l2vpn] quit
[~SPE2] pw-template pw_ces
[*SPE2-pw-template-pw_ces] quit
[*SPE2-Serial0/2/1/1:0] mpls static-l2vc destination 1.1.1.1 pw-template
pw_ces 10 transmit-vpn-label 100 receive-vpn-label 100 tunnel-policy policy1
control-word
[*SPE2-Serial0/2/1/1:0] mpls l2vpn hard-pipe expand-ratio 20
[*SPE2] commit
Step 4 Enable each SPE to send alarm bit streams to the peer device when specific faults are detected
on the SPE.
# Configure SPE1.
[~SPE1] controller cpos 0/2/1
[~SPE1-Cpos0/2/1] sdh-alarm nni-ais lrdi enable
[*SPE1-Cpos0/2/1] sdh-alarm uni-tuais ces-underrun enable
[*SPE1-Cpos0/2/1]] quit
[*SPE1] commit
# Configure SPE2.
[~SPE2] controller cpos 0/2/1
[~SPE2-Cpos0/2/1] sdh-alarm nni-ais lrdi enable
[*SPE2-Cpos0/2/1] sdh-alarm uni-tuais ces-underrun enable
[*SPE2-Cpos0/2/1]] quit
[*SPE2] commit
Step 5 Configure each SPE to send the 0xFF bit stream to notify an idle E1 channel timeslot on a
subcard, so that the subcard can quickly and continuously send AIS bit streams to the AC-side
device if network-side PW faults occur.
# Configure SPE1.
[~SPE1] slot 1
[~SPE1-slot-1] idle-code e1 ff card 2
[*SPE1-slot-1] quit
[*SPE1] commit
# Configure SPE2.
[~SPE2] slot 1
[~SPE2-slot-1] idle-code e1 ff card 2
[*SPE2-slot-1] quit
[*SPE2] commit
----End

Configuration Files
l UPE configuration file
#
sysname
UPE
#
mpls lsr-id 1.1.1.1

#
mpls
mpls te
#
mpls l2vpn
#
pw-template pw_ces
#
2.2.2.2
remote-ip 2.2.2.2
#

3.3.3.3
remote-ip 3.3.3.3
#
bidirectional static-cr-lsp ingress Tunnel 0/1/1
forward outgoing-interface GigabitEthernet 0/1/1 nexthop 10.1.1.2 out-label
40
backward in-label 43
hard-pipe
enable
#
bidirectional static-cr-lsp ingress Tunnel 0/1/2
forward outgoing-interface GigabitEthernet 0/1/2 nexthop 10.1.2.2 out-label
41
backward in-label 42
hard-pipe
enable
#
controller e1 0/2/1
1-31
#
link-protocol tdm
mpls static-l2vc destination 2.2.2.2 pw-template pw_ces 10 transmit-vpn-
label 100 receive-vpn-label 100 tunnel-policy policy1 control-word
mpls l2vpn hard-pipe expand-ratio 20
#
controller e1 0/2/2
1-31
#
link-protocol tdm
#
undo
shutdown
ip address 10.1.1.1
255.255.255.0

mpls
mpls
te
#

undo
shutdown
ip address 10.1.2.1
255.255.255.0
mpls
mpls
te
#
interface
LoopBack0
ip address 1.1.1.1
255.255.255.255
#

destination 2.2.2.2
mpls te signal-protocol cr-static
mpls te bidirectional
#
ospf
100
opaque-capability
enable
area
0.0.0.0
network 1.1.1.1
0.0.0.0
network 10.1.1.0
0.0.0.255
network 10.1.2.0
0.0.0.255
mpls-te
enable
#

destination 3.3.3.3
mpls te
bidirectional
#
tunnel-policy
policy1
#
return
#

sysname
SPE1
mpls lsr-id 2.2.2.2

#
mpls
mpls te
#
mpls l2vpn
#
pw-template
pw_ces
#

1.1.1.1
remote-ip 1.1.1.1
#
bidirectional static-cr-lsp egress Tunnel 0/1/1
forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
backward outgoing-interface GigabitEthernet 0/1/1 nexthop 10.1.1.1 out-label
43
hard-pipe
enable
#

undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls
te
interface
LoopBack0
ip address 2.2.2.2
255.255.255.255
#
1-31
#
link-protocol tdm
#
destination 1.1.1.1
mpls te passive-tunnel
mpls te binding bidirectional static-cr-lsp egress Tunnel 0/1/1
#
ospf
100
opaque-capability
enable
graceful-
restart

area
0.0.0.0
network 2.2.2.2
0.0.0.0
network 10.1.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy
policy1
#
sdh-alarm nni-ais lrdi enable
sdh-alarm uni-tuais ces-underrun enable
#
slot 1
idle-code e1 ff card 2
#
return
#
sysname
SPE2
#
mpls lsr-id 3.3.3.3

#
mpls
mpls te
#
pw-template pw_ces
#
mpls l2vpn
#
bidirectional static-cr-lsp egress Tunnel 0/1/2
forward in-label 41 lsrid 1.1.1.1 tunnel-id 200
backward outgoing-interface GigabitEthernet 0/1/2 nexthop 10.1.2.1 out-label
42
hard-pipe enable
#

undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
#
interface
LoopBack0
ip address 3.3.3.3 255.255.255.255
#
1-31
#
link-protocol tdm
#
destination 1.1.1.1

mpls te record-route
mpls te passive-tunnel
mpls te binding bidirectional static-cr-lsp egress Tunnel0/1/2
#
ospf 100
opaque-capability enable
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
mpls-te enable
#
tunnel-policy
policy1
#
sdh-alarm nni-ais lrdi enable
sdh-alarm uni-tuais ces-underrun enable
#
slot 1
idle-code e1 ff card 2
#
return

Configuration Guide - WAN Access 10 WDM Interface Configuration
10 WDM Interface Configuration
About This Chapter
Wavelength division multiplexing (WDM) is a technology used for long-distance

transmission over metropolitan area networks (MANs) and wide area networks (WANs).
Context
In VS mode, this feature is supported only by the admin VS.
10.1 Overview of WDM Interfaces
This section describes basic concepts of the optical transport network (OTN) and WDM.
10.2 Configuring WDM Interfaces
The physical layer of a WDM interface is configured in the WDM interface view, and service
parameters are configured in the GE interface view.
10.1 Overview of WDM Interfaces

This section describes basic concepts of the optical transport network (OTN) and WDM.
Overview of WDM
Wavelength-division multiplexing (WDM), a technology used in the MAN and WAN, is used
to transmit two or more optical signals of different wavelengths through the same optical
fiber. A WDM system uses a multiplexer at the transmitter to join multiple optical carrier
signals of different wavelengths (carrying different information) together on a single optical
fiber, and a demultiplexer at the receiver to split the optical carrier signals apart. Then, an
optical receiver further processes and restores the optical carrier signals to the original signals.
WDM interfaces supported by the NE40E consist of two interfaces, namely the controller
WDM interface and its corresponding GE interface. Parameters related to the optical layer
and electrical layer are configured in the controller WDM interface view, and all service
features are configured in the GE interface view. The mapping mode of service signals on
WDM interfaces is Ethernet over OTN.

Overview of OTN
Currently, the Synchronous Digital Hierarchy over Synchronous Optical Network (SDH/
SONET) and WDM networks are usually used as transport networks. SDH/SONET processes
and schedules services at the electrical layer and WDM processes and schedules services at
the optical layer. With the increasing of data services, more and more bandwidths are
required. The SDH/SONET network cannot meet the requirements on cross scheduling and
network scalability. In addition, operators require the WDM network of high maintainability,
security, and service scheduling flexibility. As a result, the OTN is developed to solve the
problems.
The OTN technology applies the operability and manageability of SDH/SONET networks to
the WDM system so that the OTN acquires the advantages of both the SDH/SONET network
and the WDM network. In addition, the OTN technology defines a complete system structure,
including the management and monitoring mechanism for each network layer and the network
survival mechanism of the optical layer and electrical layer. In this manner, operators' carrier-
class requirements are really met.
The OTN, which consists of optical network elements connected through optical fiber links,
provides the transport, multiplexing, routing, management, monitoring, and protection
(survival) capabilities to optical channels that are used to transmit client signals. The OTN
features that the transport settings of any digital client signal are independent of specified
client features, namely, client independence. Optical Transport Hierarchy (OTH) is a new
connection-oriented transport technology that is used to develop the OTN. Owing to the great
scalable capability, the OTN is applicable to the backbone mesh network. Ideally, the future
transport network is an all OTN network. Compared with SDH networks, the OTN is the
optical transport network of the next generation.
Compared with the traditional SDH and SONET networks, the OTN has the following
advantages:
l Higher FEC capability
l Tandem Connection Monitoring (TCM) of more levels
l Transparent transport of client signals
l Measurable data exchange
Frame Structures and Meaning of OTN Electrical-Layer Overheads

OTN electrical-layer overheads consist of OTUk(Optical channel Transport Unit - k),
ODUk(Optical channel Data Unit - k), OPUk(Optical channel Payload Unit - k), and frame
alignment overheads. Figure 10-1 illustrates the frame structures and meaning of the OTN
electrical-layer overheads.
NOTE
OTUk (k = 1, 2, 3, 4); ODUk (k = 1, 2, 2e, 3, 4); OPUk (k = 1, 2, 2e, 3, 4).

Figure 10-1 OTN electrical-layer overheads

1 78 14 15 16 17 3824 3825 4080
OUT[V]
1 FA O
OH
P
2 OTUk FEC
U OPUk payload
(4 x 256
k (4 x 3808 bytes)
3 ODUk OH bytes)
O
4
H
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 FAS MFAS SM GCC0 RES RES JC
TCM
2 RES ACT TCM6 TCM5 TCM4 FTFL RES JC
3 TCM3 TCM2 TCM1 PM EXP RES JC
4 GCC1 GCC2 APS/PCC RES PSI NJO PJO
TCM ACT: activation/deactivation JC: Justification control bytes

coordination protocol NJO: Negative justification opportunity
APS: Automatic protecting switching channel bytes
EXP: Experimental channel PJO: Positive justification opportunity
FA: Frame alignment bytes
FAS: Frame alignment signal PCC: Protection communication channel
MFAS: MultiFrame alignment signal PM: Path monitoring
FTFL: Fault type and fault location reporting PSI: Payload stucture identifier
communication channel RES: Reserved
GCC: General communication channel SM: Section monitoring
TCM: Tandem connection monitoring
l •SM overhead belongs to the OTU overhead and occupies three bytes.
l •PM overhead belongs to the ODU overhead and occupies three bytes.
l •TCM overhead belongs to the ODU overhead. The TCM overhead has six levels
(TCMn, n = 1...6) with each TCMn occupying three bytes.
Figure 10-2 shows the specific allocation of the SM, PM, and TCM overheads.

Figure 10-2 SM, PM, and TCM overheads
SM PM and TCMn（n=1...6）
1 2 3 1 2 3
TTI BIP-8 TTI BIP-8
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
SAPI B I SAPI B
15 BEI/ 15
16
DAPI D A RES 16
DAPI BEI D STAT PM
BIAE
31 I E 31 I
32 32
Opetator Opetator 1 2 3 4 5 6 7 8
specific specific B
BEI/
63 63 D STAT TCMn
BIAE
I
BDI: Backward defect indication PM: Path monitoring

BEI: Backward error indication SAPI: Source access point identifier
BIAE: Backward incoming SM: Section monitoring
alignment error STAT: Status bits
BIP8:Bit interleaved parity-8 code TCM: Tandem connection
DAPI: Destination access point monitoring
identifier TTI: Trail trace idenfier
EXP: Experimental channel
FEC Overview
The communication reliability is of great importance to communication technologies.
Multiple channel protection measures and automatic error correction coding techniques are
used to enhance reliability.
The OTU overhead of an OTN frame contains FEC information. FEC, which corrects data by
using algorithms, can effectively improve the transport performance of the system where the
signal-to-noise ratio (SNR) and dispersion are limited. In this manner, the investment cost on
the transport system is reduced accordingly. In addition, in the system using FEC, the receiver
can receive signals of a lower SNR. The maximum single span is enlarged or the number of
spans increases. In this manner, the total transmission distance of signals is prolonged.
TTI Overview
Trail trace identifier (TTI) is a byte string in the overhead of an optical transport unit (OTU)
or an optical data unit (ODU). Like the J byte in the SDH segment overhead, the TTI
identifies the source and destination stations to which each optical fiber is connected to
prevent incorrect connection. If the received TTI differs from the expected value, a TIM
alarm is generated.
OTU overhead: contains information about the transmission function of optical channels, and
defines FAS, MFAS, GCC0, and SM (such as TTI, BIP-8, BDI, BEI/BIAE, and IAE)
overheads. Among these overheads, TTI is a 64-byte string monitoring the connectivity of the
OTU segment.

ODU overhead: contains information about the maintenance and operation function of optical
channels, and defines TCM, PM, GCC1/GCC2, APS/PCC, and FTFL overheads. Among
these overheads, TCM monitors the serial connection, and PM monitors ODU paths.
10.2 Configuring WDM Interfaces

The physical layer of a WDM interface is configured in the WDM interface view, and service
parameters are configured in the GE interface view.
Applicable Environment
WDM interfaces must be configured when the OTN is used to transmit Ethernet packets.
Before configuring WDM interfaces, complete the following tasks:
l Powering on the Router and confirming that the self-check is successful
Configuration Procedure
Figure 10-3 Configuring WDM interfaces
Configuring Optical
Parameters
Configuring Service
Parameters
Mandatory step
Optional step
10.2.1 Configuring Optical Parameters

Optical parameters are configured in the WDM interface view to allow the WDM interfaces at
both ends of an optical fiber to communicate at the physical layer.
Context
Optical parameters of WDM interfaces must be configured to allow the WDM interfaces at
both ends of an optical fiber to communicate at the physical layer. Service parameters can be
configured only after optical parameters are configured. Currently, optical parameters of
WDM interfaces on the NE40E are FEC and TTI.
l FEC contained in the OTU overhead of the OTN frame is used for data error correction
by using algorithms. NE40E supports two FEC modes: standard G.709 FEC and
enhanced FEC. Compared with standard G.709 FEC, enhanced FEC improves
algorithms by using the FEC code type with stronger forward error correction capability.

l TTI is a byte string in the overhead of an OTU and or an ODU. Like the J byte in the
SDH segment overhead, the TTI identifies the source and destination stations to which
each optical fiber is connected to prevent incorrect connection. If the received TTI
differs from the expected value, a TIM alarm is generated.
Procedure
Step 3 Run set transfer-mode otn
The interface is configured to work in OTN mode.
Step 4 Run display wavelength-map
The channel corresponding to the wavelength to be configured is displayed.
NOTE
Before setting a wavelength for an optical module, you need to run the display wavelength-map
command to view the channel corresponding to the wavelength to be set, and then specify the channel in
the wavelength-channel command.
Step 5 Run wavelength-channel channel-num

The number of the channel corresponding to the WDM interface is set.
NOTE
You must set the same wavelength for two connected WDM interfaces.
Step 6 Run optical-tx-power { attenuation attenuation-value | target target-value }

The attenuation value and optical power for an optical module is configured.
Step 7 Run controller wdm interface-number
Step 8 Run fec { standard | none | enhanced-i-4 | enhanced-i-7 }
The FEC mode is configured for the WDM interface.
NOTE
Two interconnected WDM interfaces must have the same FEC configurations.
Step 9 Run signal-coding { dqpsk | qpsk }

The signal modulation mode of an interface is configured.
NOTE
The DQPSK signal modulation mode is supported on interfaces in any FEC mode, but the QPSK signal
modulation mode is supported only on interfaces in FEC mode of lhaul-sd.
Step 10 Run tti { otu | odu-pm } { expected | sent } 64byte-mode value

The TTI is configured for the OTU or ODU.

NOTE
The value on the sending end must be the same as the expected value set on the peer end of an optical
fiber.
Step 11 Run otn sd-threshold sd-threshold
The alarm thresholds on attenuation of optical transmission signals are set.
Step 12 (Optional) Run otn prefec-tca trigger-threshold trigger-coefficient trigger-power trigger-

interval trigger-time-interval [ recover-threshold recover-coefficient recover-power ]
[ recover-interval recover-time-interval ]
Configure an alarm threshold and detection interval for FEC bit error ratio detection on an
optical transport network (OTN).
NOTE
To configure an alarm threshold and detection interval for FEC bit error ratio detection on an OTN, run
the otn prefec-tca command. By default, FEC bit error ratio detection is enabled. The default alarm
thresholds and detection intervals are used. If the FEC bit error ratio exceeds a specified threshold, the
device reports an FEC bit error ratio alarm to the NMS. When the FEC bit error ratio falls below a
specified threshold, the device reports an FEC bit error ratio clear alarm to the NMS.
Step 13 Run span span-value
The span to estimate the OSNR of a line are set.
When an optical amplifier (OA) resides between two connected OTN interfaces, run the span
command to set a span based on the network situation, so that the non-linear OSNR of a line
can be more accurately estimated to facilitate line adjustment.
Step 14 Run mapping-path { opu2-standard | opu2-non-standard | opu2e }
A mapping mode for client signals is configured.
NOTE
l The undo shutdown, loopback, clock, and ptp command configurations have been cleared from the
Ethernet interface that the WDM interface corresponds to.
l Interfaces that have different mapping modes cannot communicate with each other. The mapping-
path command can be run only on 10GE OTN subcards.
Step 15 Run commit
----End
10.2.2 Configuring Service Parameters

Configuring service parameters in the Ethernet interface view allows the interface to bear
services.
Context
Before configuring service parameters, enter the Ethernet interface view. The configuration
procedure is the same as that for 10GE LAN interfaces. For details, see Ethernet Interface
Configuration.

10.2.3 Configuring OTN Delay Measurement

Configuring OTN delay measurement allows you to obtain the round-trip delay on an OTN.
Context
To obtain an OTN delay, configure OTN delay measurement. Figure 10-4 shows an OTN
delay measurement network.
Figure 10-4 OTN delay measurement network
Device A Device B
NOTE
This configuration is performed on Device A (source) and Device B (sink).
Procedure
Step 1 Enable delay measurement on Device B.
1. Run system-view
2. Run controller wdm interface-number
The WDM interface view is displayed.
3. Run delay-measurement sink pm enable
Delay measurement is enabled on Device B.
Step 2 Enable delay measurement on Device A.
NOTE
Before configuring this function on Device A, enable delay measurement on Device B.

1. Run system-view
3. Run delay-measurement source start pm [ duration value ]
Delay measurement is enabled on Device A.
----End
Verifying the OTN Delay Measurement Configuration

After the configuration is complete, run the display delay-measurement pm controller
controller-type controller-number command on Device A to verify that round-trip delay
measurement has been configured.

10.2.4 Verifying the WDM Interface Configuration

After configurations of WDM interfaces are complete, verify the configuration.
Context
After configurations of WDM interfaces are complete, you can view information about
interface configurations and status.
Procedure
Step 1 Run the display this command to check the configurations and status of a WDM interface.
Step 2 Run the display this interface command to check the statistics about a WDM interface.
----End

Configuration Guide - WAN Access 11 ATM IMA Configuration
11 ATM IMA Configuration
About This Chapter
Using an Inverse Multiplexing over ATM (IMA) group to transport ATM services improves
bandwidth usage and implements flexible bandwidth multiplexing.
11.1 Overview of ATM IMA

An IMA group can be considered a logical link that aggregates several low-speed physical
links (member links) to provide higher bandwidth. The rate of the logical link is
approximately the sum of the rate of the member links in the IMA group.
11.2 Licensing Requirements and Limitations for ATM IAM--M2H
11.3 Configuring an IMA Group to Transport ATM Services
Before configuring an IMA group to transport ATM services, familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
11.1 Overview of ATM IMA

When users access an ATM network at a rate between T1 and T3 or between E1 and E3, using
T3 or E3 lines is cost-ineffective for carriers. Using multiple T1 or E1 lines is more flexible
and efficient. IMA allows a network designer and administrator to use multiple T1 or E1
lines, not the expensive T3 or E3 lines, to implement ATM access.
IMA is the acronym of Inverse Multiplexing for ATM. The general idea of IMA is that the
sender schedules and distributes a high-speed ATM cell stream to multiple low-speed physical
links for transmission, and then the receiver schedules and reassembles the stream fragments
into one cell stream and submits the cell stream to the ATM layer. In this manner, bandwidths
are multiplexed flexibly, improving the efficiency of bandwidth usage.

11.2 Licensing Requirements and Limitations for ATM

IAM--M2H

When an IMA-group or Run the map pvc vpi/vci When an IMA-group or

serial sub-interface is added bidirectional and map pvp serial sub-interface is added
to an ATM-bundle interface, remote-vpi bidirectional to an ATM-bundle interface,
service forwarding on the command to configure PVC service forwarding on the
ATM-bundle interface fails or PVP bidirectional ATM-bundle interface fails
if PVC or PVP bidirectional mapping on ATM-bundle if PVC or PVP bidirectional
mapping is not configured member interfaces. mapping is not configured
on ATM-bundle member on ATM-bundle member
interfaces. interfaces.
The number of timeslots None An ATM serial interface

bound to the ATM serial with less than three
interface to be added to an timeslots cannot be added to
IMA group must be greater an IMA group.
than or equal to 3.
l Global IMA does not None In MC-LMSP scenarios,

support the MC-LMSP global IMA is not
scenario. supported.
l Global IMA does not In LMSP unidirectional
support the LMSP protection mode, global
unidirectional protection IMA is not supported.
mode.
11.3 Configuring an IMA Group to Transport ATM

Services
Before configuring an IMA group to transport ATM services, familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
Context
When users access an ATM network at a rate between T1 and T3 or between E1 and E3, it is
cost-ineffective for the carrier to use T3 or E3 lines. In this situation, using an IMA group that
aggregates multiple T1 or E1 lines to carry ATM services is more flexible and efficient.

Before configuring an IMA group interface, connect interfaces and set their physical
parameters to ensure that the physical status of the interfaces can go Up.
11.3.1 Creating an IMA Group Interface and Adding an Interface

to It
To increase bandwidth, create an IMA group and bundle several links in the IMA group.
Context
Interfaces can only be added to an IMA group interface that has been created. After an IMA
group interface is created, add a serial interface to the IMA group interface.
Procedure
l Create an IMA group interface.
a. Run system-view
b. Run interface ima-group interface-number
An IMA group interface is created.
c. Run quit
Exit from the IMA group interface view.
l Add a serial interface to the created IMA group interface.
a. Run interface serial interface-number
NOTE
The IMA group interface and the serial interface to be added to the IMA group interface
must reside on the same subcard of the same board.
b. Run link-protocol atm
ATM is configured as the link layer protocol of the serial interface.
c. Run ima ima-group interface-number
The serial interface is added to the created IMA group interface.
NOTE
After a serial interface is added to a created IMA group interface, the ATM interface type
configured for the IMA group interface before the serial interface is added becomes invalid. You
must run the atm interface-type { uni | nni } command in the IMA group interface view to
reconfigure the ATM interface type for the IMA group interface.
l If a device is connected to a user device through an IMA group interface, set the ATM
interface type of the IMA group interface to UNI.
l If a device is connected to a network device through an IMA group interface, set the ATM
interface type of the IMA group interface to NNI.

d. Run quit
Exit from the serial interface view.
----End
11.3.2 (Optional) Configuring IMA Group Parameters

Configure IMA group parameters as required.
Context
The following table lists the IMA group parameters and their usage scenarios in inverse
multiplexing and de-multiplexing of ATM cells.
Table 11-1 IMA Group Parameters
Parameter Description Usage Scenario
differential-delay Maximum link differential Link differential delay (LDD) is the

delay for an IMA group difference between delays at which
packets are sent along member links in
an IMA group. The difference between
delays at which packets are sent by
member links in an IMA group must be
less than or equal to the value
configured using the differential-delay
command.
To improve bandwidth usage of IMA
channels and prevent empty packets
from consuming bandwidth, decrease
the maximum LDD if traffic is heavy on
the network.
frame-length Number of ATM cells in an The transmit and receive ends of an

IMA frame IMA group work as follows:
l Transmit end: receives an ATM cell
stream from the ATM layer,
distributes the ATM cells in the
stream on a cell by cell basis among
the member links in the IMA group,
and sends them to the receive end
periodically.
l Receive end: reassembles received
cells to recover the original ATM cell
stream and transmits the stream to
the ATM layer.
You can run the frame-length command
to set the number of ATM cells in an
IMA frame. To ensure transmission
efficiency on links, use the default
configuration.

min-active-links Minimum number of active An IMA group is a logical link that

links that are required for consists of one or more physical links. It
an IMA group to work provides more bandwidth than a single
properly link. The minimum number of active
links must be set in an IMA group
before the IMA group can work
properly. If a link fails, the number of
active links in an IMA group in the
Operational state may be less than the
configured minimum value. As a result,
the IMA group status changes and even
becomes Down.
The minimum number of active links
that are required for an IMA group to
work properly depends on the bandwidth
allocated to the IMA group. An IMA
group can work properly only when the
number of active links in an IMA group
is greater than or equal to min-active-
links. The configured minimum number
of active links must be less than or equal
to the number of links in the IMA group.
By default, an IMA group can work
properly when there is at least one active
link in the group.
bandwidth- Logical bandwidth for an The physical bandwidth on an interface

overload IMA group interface is limited, which restricts the bandwidth
that can be allocated to PVCs After
logical bandwidth is configured for an
IMA group interface, the bandwidth that
can be allocated to the interface to be
added to the IMA group interface is
increased. Bandwidth for PVCs must
meet the following requirements:
l Bandwidth for each PVC cannot be
greater than the physical interface's
bandwidth.
l Total bandwidth for all PVCs must
be lower than the sum of the physical
bandwidth and logical bandwidth.

clock Clock mode If two devices are directly connected

using global IMA-group interfaces, run
the clock command to configure a clock
mode for each global IMA-group
interface so that the two devices can
communicate. A global IMA-group
interface can work in either of the
following clock modes:
l CTC mode: All member links of an
IMA group share the same clock
source, which is either an external
clock or the clock of a member link.
l ITC mode: Member links of an IMA
group use different clock sources.
Procedure
Step 2 Run interface ima-group interface-number[.subinterface ]
The IMA group interface (sub-interface) view is displayed.
Step 3 Run any of the following commands:

l To set the maximum LDD for an IMA group, run the differential-delay command.
l To set the number of ATM cells in an IMA frame, run the frame-length command.
l To set the minimum number of active links that are required for an IMA group to work
properly, run the min-active-links command.
l To configure logical bandwidth for an IMA group interface, run the service bandwidth-
overload command.
l To configure a clock mode for the global IMA-group interface, run the clock { ctc | itc }
command.
----End
11.3.3 Configuring a Service Type for a PVC

To implement ATM traffic shaping, configure a service type for a PVC.
Context
To prevent the impact of heavy burst ATM traffic and ensure efficient use of network
resources, you can configure a service type for a PVC to implement ATM traffic shaping.
Doing so can limit the outgoing traffic on an ATM network within a proper range. To
configure a service type for a PVC, you must create a service type in the system view and
apply the service type to the PVC.

Procedure
Step 2 Run atm service service-name { cbr output-pcr cdvt-value | nrt-vbr output-pcr output-scr
output-mbs cdvt-value | rt-vbr output-pcr output-scr output-mbs cdvt-value | ubr output-pcr
[ cdvt-value ] | ubr-plus output-pcr output-mcr cdvt-value }
A service type is created and its value is set.
Step 3 Run interface ima-group interface-number[.subinterface ]
The IMA group interface (sub-interface) view is displayed.
NOTE
After the view of the IMA group interface or sub-interface is displayed, you can perform the following
operations:
l Run the atm-link check command to enable OAM on an IMA group sub-interface. If the PVC/PVP
status of the IMA group sub-interface goes Down, the protocol status of the sub-interface also goes
Down.
l Run the pvc max-number command to set the maximum number of PVCs on an IMA group
interface. If the number of PVC on the IMA group interface reaches the upper limit, no PVC can be
created.
Step 4 Run pvc [ pvc-name ] vpi/vci
A PVC is created, and the PVC view is displayed.
Step 5 (Optional) Run description text
A description is configured for the PVC.
Step 6 Run service { output | input } service-name
A specified service type is applied to the PVC.
----End
11.3.4 (Optional) Configuring Continuity Check on ATM Services

After ATM cell relay has been configured on an ATM interface or a logical interface whose
link layer protocol is ATM, you can perform a continuity check on the ATM services.
Context
NOTE
Before performing a continuity check on ATM services, you must complete the following
tasks:
1. Check that the physical layer status and protocol layer status of the interface on which
the continuity check is to be performed are both Up. If the interface is a synchronous
serial interface, configure ATM as the link layer protocol for the interface.
2. Configure a PVC or PVP on the interface.

3. Configure the end-point attribute for the connection point of the PVC or PVP on the
device that initiates the continuity test.
Procedure
Step 2 Run llid
An LLID is configured.
NOTE
The LLID command must be configured both on the local and remote devices.
Step 3 Run test connectivity interface interface-type interface-number { pvc vpi/vci | pvp vpi } llid
llid
A continuity check is performed on ATM services.
Step 4 Run commit
----End
11.3.5 Configuring the Alarm threshold of ATM Module

After configuring the ATM module to report alarms to the NMS, you can monitor the alarm
status of the ATM module on the NMS interface.
Procedure
The view of the specified serial interface is displayed.
Step 2 Run link-protocol atm
ATM is configured as the link layer protocol of the serial interface.
Step 3 Run trap-threshold { atmpw-lospkt-exc | atmpw-misorderpkt-exc | atmpw-unknowncell-

exc } trigger-threshold trigger-threshold-value resume-threshold resume-threshold-value
The alarm generation and clearing thresholds for ATM service transport performance are
configured.
Step 4 Run commit
----End
11.3.6 Verifying the IMA Group Configuration

After completing configurations on an IMA group interface, verify the configuration.

Prerequisites
An IMA group has been configured to transport ATM services.
Procedure
l Run the display atm pvc-info [ interface interface-type interface-number [ pvc { pvc-
name [ vpi/vci ] | vpi/vci } ] ] command to check PVC information.
l Run the display atm service [ service-name ] command to check information about the
service type configured for a PVC.
l Run the display interface ima-group [ group-number ] command to check
configurations and status of an IMA group interface.
l Run the display connectivity-test interface interface-type interface-number { pvc
vpi/vci | pvp vpi } command to check the result of continuity check on ATM services.
l Run the display atm llid command to check whether the LLID takes effect.
----End

Configuration Guide - WAN Access 12 ATM Configuration
12 ATM Configuration
About This Chapter
The Asynchronous Transfer Mode (ATM) is a technology applicable to backbone networks.

Due to its high flexibility and support for multimedia services, ATM can be used to transmit
voice, video, and data streams, and therefore is considered as a key technology for broadband
communication.
12.1 Overview of ATM
Based on packet switching, Asynchronous Transfer Mode inherits high-speed circuit
switching to provide a universal connection-oriented transfer mode suitable for various
services. With ATM, devices, such as Devices and hosts, can communicate with each other.
12.2 Configuring ATM to Carry Upper-Layer Services
If upper-layer services need to be transmitted over an ATM network, configure ATM to carry
upper-layer services.
12.3 Configuring Parameters for an ATM OC-3/STM-1 Interface or an ATM OC-12/STM-4
Interface
This section describes how to configure parameters for an ATM OC-3/STM-1 or an ATM
OC-12/STM-4 interface. Detailed operations include configuring the frame format and the
scramble function for an ATM OC-3/STM-1 or an ATM OC-12/STM-4 interface.
12.4 Configuring the Service Type and Optional Parameters for a PVC
If PVC/PVP traffic planning is required, you can configure the service type and overload
bandwidth for PVCs/PVPs.
12.5 Configuring ATM OAM
To detect and locate faults on ATM links, you can configure ATM OAM.
12.6 Maintaining ATM
You can clear ATM interface statistics and use the loopback function to detect whether ATM
interfaces run properly.
12.7 Configuration Examples for ATM
This section provides ATM configuration examples with the networking requirements,
configuration roadmap, data preparation, and configuration procedure.

12.1 Overview of ATM

Based on packet switching, Asynchronous Transfer Mode inherits high-speed circuit
switching to provide a universal connection-oriented transfer mode suitable for various
services. With ATM, devices, such as Devices and hosts, can communicate with each other.
12.1.1 Introduction
A conventional wide area network (WAN) uses X.25, frame relay (FR), or ATM. Any of these
link-layer protocols can transmit data from one local area network (LAN) over a WAN to
another LAN. As terminals become intelligent and the quality of physical links improves, the
functions of error control and flow control for data at the data link layer on X.25 networks are
no longer required. In addition, limited bandwidth resources on X.25 networks cannot meet
requirements of users for services. ATM ensures high-quality service transmission, and
therefore is widely applied to links that require high bandwidth.
Currently, ATM is used at the data link layer. Based on packet switching, ATM inherits high-
speed circuit switching to provide a universal connection-oriented transfer mode suitable for
various services. This allows multiple upper-layer protocols (currently only IPoA) to be
carried on ATM networks.
ATM is connection-oriented. ATM connections are logical connections, called virtual circuits
(VCs). Each VC is identified by a virtual path identifier (VPI) and a virtual channel identifier
(VCI). A pair of VPI/VCI takes effect only on one segment of the link between ATM nodes.
Each ATM node maps the VPI/VCI values to a specific address. When an ATM connection is
released, the VPI/VCI values for the connection are also released, and can be used by a
subsequent connection.
NOTE
Currently, ATM interfaces support only permanent virtual circuits (PVCs).
12.1.2 ATM Features Supported by the NE40E

ATM features, such as Inverse Multiplexing for ATM (IMA) groups and ATM cell transport,
are supported. Using an ATM feature in a suitable scenario simplifies configurations and
improves performance of ATM networks.
ATM Features and Usage Scenarios

Table 12-1 lists ATM features and usage scenarios. Each feature can be used in a specified
scenario to improve performance.

Table 12-1 Description of ATM features and usage scenarios

ATM Description Usage Scenario
Feature
IMA IMA is a technology that allows a Currently, ATM cell transport is

sender to distribute ATM cell applicable only to IP RANs. For
streams over multiple low-speed information about usage scenarios of
links, and allows a receiver to ATM cell transport, see the chapter
multiplex the links to restore the cell "ATM IMA Configuration" in the
streams. Configuration Guide - WAN Access.
An IMA group is a logical link
consisting of one or more physical
links. It provides more bandwidth
(approximately equal to the sum of
the bandwidths of all member links)
than a single link.
ATM cell ATM cell transport is a technology Currently, ATM cell transport is
transport that transmits ATM cells over applicable only to IP RANs. For
Pseudowire Emulation Edge-to- information about usage scenarios of
Edge (PWE3) VCs. ATM cell transport, see the chapter
By interconnecting ATM network "VPWS Configuration" in the
resources over a packet switched Configuration Guide - VPN.
network (PSN), ATM cell transport
emulates conventional ATM services
when they are being transmitted
over the PSN. This allows terminal
users to be unaware of network
differences, and therefore protects
carriers' investment during network
convergence and construction.
NOTE
IPoA scenarios do not support IMA or ATM cell transport.
12.2 Configuring ATM to Carry Upper-Layer Services

If upper-layer services need to be transmitted over an ATM network, configure ATM to carry
upper-layer services.
12.2.1 Before You Start

Before configuring ATM to carry upper-layer services, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
Usage Scenario
Before the Gigabit Ethernet technology was developed, ATM backbone switches were
deployed on backbone networks to provide sufficient bandwidth. As ATM is well-developed,

its complex architecture causes difficulties in ATM system development, configuration,

management, and fault location. Therefore, ATM is often used at the data link layer currently
to carry upper-layer protocol packets. ATM boasts of high-quality comprehensive service
transmission, and therefore is considered as the best transport technology for Broadband
Integrated Services Digital Networks (B-ISDNs).
IPoA means that IP packets are encapsulated in ATM cells and transmitted on ATM networks.
As shown in Figure 12-1, ATM allows devices on the same network to communicate with
each other at the data link layer by transmitting ATM cells in which IP packets have been
encapsulated. As bearer networks for IP services, ATM networks provide good network
performance and mature QoS assurance.
Figure 12-1 IPoA application networking
DeviceB
ATM1/0/0
DeviceA
ATM
Network
ATM1/0/0
DeviceC
ATM1/0/0
ATM interfaces on the device have been physically connected.
Data Preparation
To configure ATM to carry upper-layer services, you need the following data.
No. Data
1 Number of each ATM interface or sub-interface, IP address and mask of each ATM
interface or sub-interface, PVC name, VPI/VCI values, and AAL5 encapsulation
type
2 (Optional)Minimum and maximum priorities of IP packets transmitted along PVCs
12.2.2 Configuring Basic PVC Functions

After a mapping between a Permanent Virtual Circuit (PVC) and a remote protocol address is
configured, upper-layer protocol packets can be encapsulated in ATM cells and transmitted on
ATM networks.

Context
Table 12-2 lists the relationships between PVC encapsulation types and upper-layer protocols.
Table 12-2 Relationships between PVC encapsulation types and upper-layer protocols
Upper-Layer aal5snap aal5mux aal5nlpid aal5nlpidietf
Protocol/
Encapsulation
Type
IPoA Supported Supported (not Supported (not Supported (not

supported if supported if supported if
Inverse Address InARP is used) InARP is used)
Resolution
Protocol
[InARP] is
used)
Procedure
Step 2 Run interface atm interface-number[.subinterface ] [ p2mp | p2p ]
The view of an ATM interface or sub-interface is displayed.
NOTE
After you enter the view of an ATM interface or sub-interface, you can configure the following
parameters:
l To enable OAM on an ATM sub-interface, run the atm-link check command. If the PVC and PVP
status of the ATM sub-interface goes Down, the protocol status on the sub-interface also goes Down.
l To configure the maximum number of VCs on an ATM interface, run the pvc max-number
command. If the number of PVCs configured on the ATM interface reach the maximum limit, no
new PVC can be configured on the interface.
Step 3 Run pvc { pvc-name [ vpi/vci ] | vpi/vci }

A PVC is created and the PVC view is displayed.
NOTE
l The VCI values 3, 4 are reserved.

l The VPI and VCI values cannot be both 0s.
l The value of vpi/vci cannot be 255/65535.
Step 4 (Optional) Run description text

The description is configured for the PVC.
Step 5 Run encapsulation { aal5snap | aal5mux | aal5nlpid | aal5nlpidietf }
An AAL5 encapsulation type is configured for the PVC.
The default AAL5 encapsulation type is aal5snap.

Table 12-2 lists the relationships between PVC encapsulation types and upper-layer protocols.
Step 6 Run map ip { ip-address | inarp [ minutes ] } [ broadcast ]
The IPoA mapping is configured on the PVC so that AAL5 carries IP packets.
Running the map ip ip-address command configures a mapping between a PVC and a
destination IP address. Every IP packet to be transmitted on an IPoA network must be mapped
to a PVC, and therefore multiple mappings are required. To configure mappings in batches,
perform the following operations as required:
l To map all the IP packets destined for the same network segment to one PVC, run the
map ip ip-address mask command.
l If the local device is the DTE, run the map ip inarp [ minutes ] command to use InARP
for automatic mapping. In this case, you do not need to configure mappings between IP
addresses and PVCs.
NOTE
minutes must be set to a proper value based on the network topology stability. If the network
topology changes frequently, set a small minutes value. If the network topology is stable, set a
large minutes value.
If the upper-layer protocol, for example, OSPF, transmits packets in broadcast mode,
configure broadcast for the PVC. If a PVC is configured with broadcast, all broadcast
packets transmitted through the interface where the PVC resides will be copied to the PVC.
----End
12.2.3 (Optional) Configuring the Priority of an ATM PVC

By setting priorities for ATM PVC traffic, you can schedule traffic on the PVCs with different
priorities.
Context
Perform the following steps on the Router:
Procedure
Step 2 Run interface atm interface-number.sub-interface
The ATM sub-interface view is displayed.
NOTE
To configure the priorities of all PVCs in the interface view, you can run the service output priority
command on the interface.
Step 3 Run pvc { pvc-name [ vpi/vci ] | vpi/vci }
The PVC view is displayed.
Step 4 Run service output priority priority
The priority of the PVC is specified.

NOTE
You can use this command to configure priorities of UBR and UBR-plus type PVCs. Therefore, the
system can schedule the traffic in the PVCs with different priorities.
----End
12.2.4 Verifying the ATM Configuration

After configuring ATM to carry upper-layer services, verify the configuration and status of
ATM interfaces or sub-interfaces, and information about Permanent Virtual Circuit (PVCs)
and PVC mapping.
Prerequisites
ATM links have been configured to transmit different protocol packets.
Procedure
l Run the display interface atm [ interface-number | main ] command to check the
configurations and status of ATM interfaces or sub-interfaces.
l Run the display atm pvc-info [ interface interface-type interface-number [ pvc { pvc-
name [ vpi/vci ] | vpi/vci } ] ] command to check information about PVCs.
l Run the display atm pvc-infostatistics [ interface interface-type interface-number ]
command to check PVC traffic statistics.
l Run the display atm map-info [ interface interface-type interface-number [ pvc { pvc-
name | vpi/vci } * ] ] command to check information about PVC mapping.
----End
12.3 Configuring Parameters for an ATM OC-3/STM-1

Interface or an ATM OC-12/STM-4 Interface
This section describes how to configure parameters for an ATM OC-3/STM-1 or an ATM
OC-12/STM-4 interface. Detailed operations include configuring the frame format and the
scramble function for an ATM OC-3/STM-1 or an ATM OC-12/STM-4 interface.

Before configuring parameters for ATM interfaces, familiarize yourself with the usage
scenario, complete the pre-configuration task, and obtain the required data. This can help you
complete the configuration task quickly and accurately.
Usage Scenario
You can set these parameters according to the actual conditions of the ATM network so that
these parameters can perfectly match the physical network.
The parameters of the ATM interface include the frame format, scramble function, loopback
mode, and interval for traffic statistics collection. All these parameters have default
configurations.

However, ATM sub-interface parameters, such as the frame format, scramble function, and
loopback mode, cannot be configured. If those parameters are configured on the ATM main
interface, the sub-interface inherits the parameters automatically.
The configured interval for traffic statistics collection on the ATM main interface cannot be
inherited by the sub-interface, and it needs to be configured on the sub-interface.
These parameters must be configured on an ATM interface that needs to be encapsulated with
an upper layer protocol.
Before configuring an ATM interface, power on and start the Router normally.
Data Preparation
To configure an ATM interface, you need the following data.
No. Data
1 Number of the ATM interface
12.3.2 Configuring the Frame Format on an Interface

ATM interfaces complying with different standards need to be configured with different frame
formats.
Context
Procedure
Step 2 Run slot slot-id
The slot view is displayed.
Step 3 Run frame-format { sdh |sonet card cardid }
The frame format is configured.
For an ATM STM-1 optical interface, the frame format is SDH; for an ATM OC-3 interface,
the frame format is SONET.
By default, the SDH frame format is used.
----End

12.3.3 Configuring the Overhead Byte on an Interface

You can configure different overhead bytes for interfaces to implement hierarchical
Context
The Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) provides
various overhead bytes to implement hierarchical monitoring functions.
The signal label byte C2, a type of high-order path overhead byte, is used to specify the
multiplexing structure and attribute of the information payload in a VC frame.
The regenerator trace byte J0, a type of section overhead byte, is used to detect the continuity
of connection between two interfaces on the section.
The path trace byte J1, a type of high-order VC-N path trace byte, is used to detect whether
the two interfaces are in the continuous connection status.
Procedure
Step 2 Run interface atm interface-number
The ATM interface view is displayed.
Step 3 Perform either of the following configurations as required:
l Run flag j0 { 16byte-mode j0-value | peer }
The regenerator trace byte J0 is configured.
l Run flag j1 { 64byte-mode j1-value | 16byte-mode j1-value | peer }
The path trace byte J1 is configured.
l Run flag c2 c2-value
The signal label byte C2 is configured.
The C2, J0, and J1 bytes on the receiving and sending ends must be consistent. Otherwise, an
alarm is generated.
For the ATM interface, the default value of C2 is 19 (13 in hexadecimal notation). The default
value of J0 and J1 is NetEngine.
----End
12.3.4 Configuring the MTU of an Interface

Configuring a proper MTU for an ATM interface effectively improves efficiency of assembly
and fragmentation of IP packets on the interface.
Context
The MTU of the ATM interface is used for the assembly and fragmentation of IP packets.

After running the mtu command on an interface, restart the interface to validate the MTU
configuration by running the shutdown and undo shutdown commands.
Procedure
Step 3 Run mtu mtu
The MTU of the ATM interface is configured.
The default MTU is 1500 bytes.
Step 4 Run shutdown
The ATM interface is shut down.
Step 5 Run undo shutdown
The ATM interface is started.
After changing the MTU by using the mtu command on a specified interface, restart the
interface to validate the newly configured MTU value.
----End
12.3.5 Configuring the Scrambling Function on an Interface

Configuring the scrambling function effectively prevents consecutive 0s or 1s in ATM cells.
Context
The scrambling function can effectively prevent continuous 0s or 1s in ATM cells.
Configurations of the scrambling function on the local and remote interfaces must be
consistent.
Procedure

Step 3 Run scramble

The scrambling function is configured.
This scrambling function is enabled by default. This function is valid only for payloads and
does not affect cell headers.
----End
12.3.6 Configuring an Interval at Which Traffic Statistics Are

Collected
This section describes how to configure an interval at which traffic statistics are collected on
an ATM interface or on an ATM sub-interface. Note that the interval must be a multiple of 10.
Context
NOTE
The NE40E supports traffic statistics collection on the ATM interface and sub-interface. Before
configuring the interval at which traffic statistics are collected, configure the PVC for the interface and
the sub-interface so that the configured statistics interval can be applied to the PVC.
Procedure
Step 2 Perform either of the following configurations as required:
l Run interface atm interface-number
l Run interface atm interface-number.subinterface-number
Step 3 Run set flow-stat interval interval
An interval at which traffic statistics are collected is configured.
By default, traffic statistics are collected at an interval of 300s.
The interval value must be a multiple of 10.
----End
12.3.7 Verifying the ATM Interface Parameter Configuration

After configuring parameters on an ATM interface, verify the configuration, such as the frame
format and MTU of the interface.
Procedure
l Run the display interface atm [ interface-number [.subinterface-number] ] command to
check the configuration and status of the ATM interface.

l Run the display interface brief command to check brief information about the ATM
interface.
----End
12.4 Configuring the Service Type and Optional

Parameters for a PVC
If PVC/PVP traffic planning is required, you can configure the service type and overload
bandwidth for PVCs/PVPs.

Before configuring the service type and optional parameters for a PVC, familiarize yourself
with the applicable environment, complete the pre-configuration task, and obtain the required
data. This can help you complete the configuration task quickly and accurately.
Usage Scenario
You can configure the service type and parameters for a PVC during PVC traffic planning.
Before configuring the service type or optional parameters for a PVC, complete the following
tasks:
l Configure physical attributes for the Router ATM interface.

l Configure an IP address and mask for the ATM interface or sub-interface.
l Create a PVC and configure the application mode.
Data Preparation
To configure the service type for a PVC, you need the following data.
No. Data
1 Number of the ATM interface or sub-interface
2 IP address and mask of the ATM interface or sub-interface
3 PVC name and VPI/VCI value
4 CBR: PCR and CDVT
5 NRT-VBR: PCR, SCR, MBS, and CDVT
6 RT-VBR: PCR, SCR, MBS, and CDVT
7 (Optional) Overload bandwidth of the ATM interface

12.4.2 Configuring a Service Type for a PVC

PVC services are classified as CBR, NRT-VBR, RT-VBR, UBR, or UBR-plus.
Context
To configure a service type for a PVC, you must create a service type in the system view and
apply the service type to the PVC.
Procedure
A service type template is created, and parameters are configured.
By default, the service type of a PVC is UBR.
The service type can be configured as CBR, NRT-VBR, UBR, UBR-plus, or RT-VBR.
Step 3 Run interface atm interface-number [ .subinterface ]
The ATM interface or sub-interface view is displayed.
Step 4 Run atm cell transfer
The ATM cell transport mode is configured.
Step 5 Run pvc [ pvc-name ] vpi/vci
A PVC is created, and the PVC view is displayed.
Step 6 Run shutdown
The PVC is shut down.
A service type template is configured for the PVC.
The PVC is started.
----End
12.4.3 Configuring a Service Type for a PVP

PVP services are classified as CBR, NRT-VBR, RT-VBR, UBR, or UBR-plus.

Context
To configure a service type for a PVP, you must create a service type in the system view and
apply the service type to the PVP.
Procedure
A service type template is created, and parameters are configured.
By default, the service type of a PVP is UBR.
The service type can be configured as CBR, NRT-VBR, UBR, UBR-plus, or RT-VBR.
Step 3 Run interface atm interface-number.subinterface
Step 4 Run atm cell transfer
The ATM cell transport mode is configured.
Step 5 Run pvp vpi
A PVP is created, and the PVP view is displayed.
A PVP can be configured only on an ATM sub-interface.
Step 6 Run shutdown
The PVP is shut down.
A service type template is configured for the PVP.
The PVP is started.
----End
12.4.4 (Optional) Configuring the Overload Bandwidth for an

ATM Interface
The overhead bandwidth of an ATM interface refers to the sum of committed bandwidth of all
PVCs and PVPs on the interface.
Context

Procedure
Step 3 Run service bandwidth-overload overload-value
The overload bandwidth is configured for an ATM interface.
You can run the service bandwidth-overload command to set the overload bandwidth of the
PVCs and PVPs of all services on the ATM interface.
By default, the overload bandwidth of the ATM interface is 0 kbit/s.
----End
12.4.5 Verifying the Configuration

After the service type and optional parameters of a PVC are configured, you can check the
configuration of the service type template and the statistics.
Procedure
l Run the display interface atm [ interface-number [.subinterface ] ] command to check
the configuration and status of the ATM interface or sub-interface.
l Run the display atm service [ service-name ] command to check the configuration of the
service type template.
l Run the display atm { pvc | pvp } statistics interface atm interface-number [ pvc
vpi/vci | pvp vpi ] command to check PVC or PVP statistics.
NOTE
The display interface atm command displays the statistics of all the packets discarded on an
interface. The display atm pvc statistics command displays only the statistics about the packets
dropped on the PVC or PVP due to traffic congestion. Therefore, run the commands as required.
----End
12.5 Configuring ATM OAM

To detect and locate faults on ATM links, you can configure ATM OAM.

Before configuring ATM OAM, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This can help you
complete the configuration task quickly and accurately.
Usage Scenario
OAM provides various optional methods of detecting and locating the faults on an ATM link.
Choose the configuration as required.

l To detect the link status and report faults in real time without interrupting services,
activate the CC function or configure the end-to-end loopback detection function.
– The CC function detects the link status in real time by sending CC cells periodically
and does not restrict the connection point attribute.
– The end-to-end loopback detection function detects the link status in real time by
sending loopback cells periodically and is available on only the PVP/PVC with the
connection point attribute of end-point.
Check whether the device supports CC cells or loopback cells and choose configurations
based on the OAM connection point attribute.
The CC function and the end-to-end loopback function cannot be configured on the same
PVP/PVC.
l To locate and remove the link faults, configure the cell loopback function.
l To debug and detect whether the ATM OAM mechanism works normally, insert OAM
cells manually.
l To respond to the OAM F5 loopback cells on the peer, configure the OAM F5 loopback
cell response function.
Before configuring ATM OAM, complete the following tasks:
l Configure physical attributes for the Router ATM interface.

l Configure an IP address and mask for the ATM interface or sub-interface.
l Configure an ATM PVC.
Data Preparation
To configure ATM OAM, you need the following data.
No. Data
1 Number of the ATM interface
2 VPI/VCI value
3 Number of times loopback cells are sent
4 Interval at which end-to-end loopback cells are sent
5 Number of delayed intervals for responding after the PVP/PVC status changes
12.5.2 (Optional) Activating the CC Function

You can activate the CC function to detect link status and report faults in real time without
service interruption.
Context

Procedure
Step 2 Run interface interface-type interface-number [.subinterface ]
Step 3 Run oam
The OAM interface view is displayed.
Step 4 Run attribute { start-vpi [ end-vpi ] | vpi/start-vci [ vpi/end-vci ] } { end-point | seg-point }
The OAM attributes of the connection point are configured.
When IPoA services are configured on a PVC, the PVC attribute can be configured only as
end-point.
When the PVC attribute is end-point, the PVC can respond to the OAM F5 loopback cells.
Step 5 Run cc { start-vpi [ end-vpi ] | vpi/start-vci [ vpi/end-vci ] } { end-to-end | segment } { both |

sink |source }
The CC function is activated.
When activating the CC function for a PVC or PVP, note the following:
l Before activating the CC function, configure OAM attributes on both ends.

l The type of the CC function to be activated must match OAM attributes.
l During fault recovery, do not deactivate the CC function.
l If the related NE board is functioning properly, you must stop the CC before deleting the
OAM connection.
l If the parameter sink or both is configured, a clear alarm will be generated when either
of the following conditions is met:
– The local end receives CC cells from the peer end.
– The local end receives data cells from the peer end.
----End
12.5.3 (Optional) Configuring OAM End-to-End Loopback

Detection
You can configure end-to-end loopback detection to detect link status and report faults in real
time without service interruption.
Context
Perform either of the following operations on the Router to implement end-to-end loopback
detection:
l Run the ping atm command in the system view.
l Run the oam-Loopback command in the ATM OAM view.

When configuring the function of end-to-end loopback detection in the ATM OAM view, note
the following:
l The attribute of the OAM connection point of the PVP/PVC must be end-point.
l The CC function and the loopback function cannot be configured on the same PVP/PVC.
l During fault recovery, the undo oam-Loopback command cannot be run.
l Before deleting OAM connections, run the undo oam-loopback command to disable the
function of OAM end-to-end loopback detection if no faults occur on the board.
Procedure
l Implement end-to-end loopback detection in the system view.
a. Run system-view
b. Run ping atm interface atm interface-number vpi/vci end-to-end [ times ]
End-to-end loopback detection is configured.
l Implement end-to-end loopback detection in the ATM OAM view.
a. Run system-view
b. Run interface interface-type interface-number [.subinterface ]
c. Run oam
d. Run attribute { start-vpi [ end-vpi ] | vpi/start-vci [ vpi/end-vci ] } end-point
The OAM attributes of the connection point are configured.
e. Run oam-Loopback vpi/start-vci [ vpi/end-vci ] end-to-end
The function of OAM end-to-end loopback detection of the PVP/PVC is enabled.
Before enabling OAM end-to-end loopback detection on an interface that is

transmitting traffic, ensure that the OAM attribute of the connection point is end-
point. Otherwise, traffic on the local interface will be interrupted.
f. (Optional) Run oam-Loopback vpi/start-vci [ vpi/end-vci ] up-cycle cycle-number

down-cycle cycle-number
The number of delayed intervals for responding after the PVP/PVC status changes
is configured.
By default, the number of delayed intervals for responding after the PVP/PVC
status changes is 5.
After the function of OAM end-to-end loopback detection is enabled, to prevent
PVP/PVC flapping, the system does not immediately respond when the PVP/PVC

status changes. When the PVP/PVC remains Down or Up for specified consecutive
intervals, the system responds to the change.
----End
12.5.4 (Optional) Configuring the Cell Loopback Function

After cell loopback is configured, the system checks loopback cells to detect and locate link
faults.
Context
Procedure
Step 2 Run interface interface-type interface-number [.subinterface ]
Step 3 Run oam
Step 4 Run attribute { start-vpi [ end-vpi ] | vpi/start-vci [ vpi/end-vci ] }{ end-point | seg-point }
When IPoA services are configured on a PVC, the PVC attribute can be configured only as
end-point.
When the PVC attribute is end-point, the PVC can respond to the OAM F5 loopback cells.
Step 5 Run loopback { vpi | vpi/vci } { end-loopback | seg-loopback } times
The cell loopback function is configured.
OAM provides loopback tests to facilitate fault locating. In tests, a loopback cell is inserted to
the VC/VP of a connection point and is looped back by the other connection point. The
system detects and locates link faults through the received loopback cells.
The loopbacks can be classified as segment loopbacks and end loopbacks.
l Before configuring the segment loopback, configure the peer loopback point as the
segment point.
l Before configuring the end loopback, configure the peer loopback point as the end point.
l The loopback in one board fails.
----End
12.5.5 (Optional) Configuring a One-Click Test for ATM Services

After ATM cell relay has been configured on an ATM interface or a logical interface that runs
the ATM protocol, a one-click test can be configured for ATM services.

Context
Before configuring a one-click test for ATM services, you must complete the following tasks:
1. Check that the physical layer status and protocol layer status of the interface on which
the one-click test will be performed are Up. If the interface is a synchronous serial
interface, configure ATM on the interface.
2. Configure a PVC or PVP on the interface.
3. Run the llid command to configure a local LLID for both the local end and peer end.
Procedure
Step 2 Run test connectivity interface interface-type interface-number { pvc vpi/vci | pvp vpi } llid
llid
A one-click test is configured for ATM services.
----End
Result
Run the display connectivity-test interface interface-type interface-number { pvc vpi/vci |
pvp vpi } command to check the one-click test results for ATM services.
12.5.6 Verifying the ATM OAM Configuration

After ATM OAM is configured, verify the configuration.
Procedure
l Run the display atm oam statistics atm interface-number { vpi | vpi/vci } command to
check statistics of ATM OAM.
l Run the display atm oam configuration atm interface-number [ vpi | vpi/vci ]
command to check configurations of ATM OAM.
----End
12.6 Maintaining ATM

You can clear ATM interface statistics and use the loopback function to detect whether ATM
interfaces run properly.
12.6.1 Enabling Loopback to Check Interface Status

Loopback can be enabled to check whether links work properly.

Context
Running the loopback command on the Router to enable loopback may cause interfaces or
links to be unable to work properly. Exercise caution when enabling loopback to check the
interface or link status. After checking the interface or link status, run the undo loopback
command to disable loopback in time.
Perform the following steps on the Router to be checked:
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the interface atm interface-number command to enter the view of an ATM interface to
be checked.
Step 3 Run the following command as required:

l To check an ATM OC-3/STM-1 or ATM OC-12/STM-4 interface, run the loopback
{ local | remote } command.
l To check an ATM E1 interface, run the loopback { local | remote } command.
l To check an ATM E3 interface, run the loopback { local | remote } command.
l To check whether the local service chip works properly, configure local.
l To check whether the peer works properly, configure remote.
By default, loopback is disabled.
----End
12.6.2 Clearing ATM Interface Statistics

You can run the reset commands to clear interface statistics before recollecting traffic
statistics on the interface.
Context
Interface statistics cannot be restored after being cleared. Exercise caution when running reset
commands.
To clear interface statistics displayed on the NMS or in the display interface command
output, run the following commands in the user view. After the statistics are cleared, the
interface starts to collect statistics again.
NOTE
See the relevant NMS manual to learn about how to view the interface traffic statistics on the NMS.

Procedure
l Run the reset counters interface [ atm [ interface-number ] ] command to clear
statistics displayed in the display interface command output.
l Run the reset counters if-mib interface [ atm [ interface-number ] ] command to clear
interface statistics displayed on the NMS.
l Run the reset atm interface [ atm interface-number ] command to clear PVC statistics
of an ATM interface.
----End
12.7 Configuration Examples for ATM

This section provides ATM configuration examples with the networking requirements,
configuration roadmap, data preparation, and configuration procedure.
12.7.1 Example for Configuring the IPoA Service

This example describes how to configure IPoA to allow IP packets to be transmitted along
ATM Permanent Virtual Circuits (PVCs) in typical networking.
As shown in Figure 12-2, Device A, Device B, and Device C access an ATM network for
communication. All the PVCs on the ATM interfaces of Routers must be configured with
IPoA.
Figure 12-2 Networking for IPoA configuration

NOTE
Interface 1 in this example is ATM0/1/0.
DeviceB
IP:10.1.1.2/24
To A:0/40
DeviceA
To C:0/42
ATM Interface: interface1
network
IP:10.1.1.1/24
To B:0/40 DeviceC
To C:0/41
Interface: interface1
IP:10.1.1.3/24
To A:0/41
To B:0/42
Interface: interface1

1. Create PVCs on the ATM interface of each Router.
2. Configure ATM PVCs to carry IP packets.
Data Preparation
l IP addresses of the ATM interfaces on the Routers
l Virtual Path Identifier (VPI)/Virtual Channel Identifier (VCI) values of the PVCs
connecting Device A to Device B and Device C
l VPI/VCI values of the PVCs connecting Device B to Device A and Device C
l VPI/VCI values of the PVCs connecting Device C to Device A and Device B
Procedure
# Enter the ATM interface view and configure an IP address for the ATM interface.
[*HUAWEI] commit
[~DeviceA] interface atm 0/1/0
[~DeviceA-Atm0/1/0] ip address 10.1.1.1 255.255.255.0
# Create PVCs and configure IPoA mapping on the PVCs.

[*DeviceA-Atm0/1/0] pvc to_b 0/40
[*DeviceA-atm-pvc-Atm0/1/0-0/40-to_b] map ip 10.1.1.2
[*DeviceA-atm-pvc-Atm0/1/0-0/40-to_b] quit
[*DeviceA-Atm0/1/0] pvc to_c 0/41
[*DeviceA-atm-pvc-Atm0/1/0-0/41-to_c] map ip 10.1.1.3
[*DeviceA-atm-pvc-Atm0/1/0-0/41-to_c] quit
[*DeviceA-Atm0/1/0] undo shutdown
[*DeviceA-Atm0/1/0] quit
[*DeviceA] commit

[~HUAWEI] sysname B
[*HUAWEI] commit
[~DeviceB] interface atm 0/1/0
[~DeviceB-Atm0/1/0] ip address 10.1.1.2 255.255.255.0

[*DeviceB-Atm0/1/0] pvc to_a 0/40
[*DeviceB-atm-pvc-Atm0/1/0-0/40-to_a] map ip 10.1.1.1
[*DeviceB-atm-pvc-Atm0/1/0-0/40-to_a] quit
[*DeviceB-Atm0/1/0] pvc to_c 0/42
[*DeviceB-atm-pvc-Atm0/1/0-0/42-to_c] map ip 10.1.1.3
[*DeviceB-atm-pvc-Atm0/1/0-0/42-to_c] quit
[*DeviceB-Atm0/1/0] undo shutdown

[*DeviceB-Atm0/1/0] quit
[*DeviceB] commit
Step 3 Configure Device C.
[~HUAWEI] sysname DeviceC
[*HUAWEI] commit
[~DeviceC] interface atm 0/1/0
[~DeviceC-Atm0/1/0] ip address 10.1.1.3 255.255.255.0

[*DeviceC-Atm0/1/0] pvc to_a 0/41
[*DeviceC-atm-pvc-Atm0/1/0-0/41-to_a] map ip 10.1.1.1
[*DeviceC-atm-pvc-Atm0/1/0-0/41-to_a] quit
[*DeviceC-Atm0/1/0] pvc to_b 0/42
[*DeviceC-atm-pvc-Atm0/1/0-0/42-to_b] map ip 10.1.1.2
[*DeviceC-atm-pvc-Atm0/1/0-0/42-to_b] quit
[*DeviceC-Atm0/1/0] undo shutdown
[*DeviceC-Atm0/1/0] quit
[*DeviceC] commit
# Check the PVC status on Device A.

[~DeviceA] display atm pvc-info
VPI/VCI |STATE|PVC-NAME |ENCAP |PROTOCOL|INTERFACE
----------|-----|----------------|---------|--------|-----------------
0/40 |UP |to_b |1 |IP |Atm0/1/0 (UP)
0/41 |UP |to_c |2 |IP |Atm0/1/0 (UP)
# Check mappings between PVCs and IP addresses on Device A.

[~DeviceA] display atm map-info
Atm0/1/0, PVC 0/40, IP, State UP
10.1.1.2
Atm0/1/0, PVC 0/41, IP, State UP
10.1.1.3
Perform the same steps to view the PVC status and mappings between PVCs and IP addresses
on Device B and Device C.
# Run the ping command on Device A to ping Device B. The ping operation succeeds.
0.00% packet loss
Run the ping command on Device A to ping Device C, on Device B to ping Device A and
Device C, and on Device C to ping Device A and Device B. All the ping operations succeed.
----End

Configuration Files
#
sysname DeviceA
#
interface Atm0/1/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
pvc to_b 0/40
map ip 10.1.1.2
pvc to_c 0/41
map ip 10.1.1.3
#
return

#
sysname DeviceB
#
interface Atm0/1/0
undo shutdown
ip address 10.1.1.2 255.255.255.0
pvc to_a 0/40
map ip 10.1.1.1
pvc to_c 0/42
map ip 10.1.1.3
#
return
l Configuration file of Device C

#
sysname DeviceC
#
interface Atm0/1/0
undo shutdown
ip address 10.1.1.3 255.255.255.0
pvc to_a 0/41
map ip 10.1.1.1
pvc to_b 0/42
map ip 10.1.1.2
#
return
12.7.2 Example for Configuring ATM OAM

ATM OAM detects links in real time without interrupting services.
In Figure 12-3, RouterDevice A, Device B, and Device C are connected to the ATM network.
IPoA services are configured on all the PVCs on ATM interfaces of the three Routers.
To implement real-time and continuous detection without interrupting services, configure the
OAM CC function.

Figure 12-3 Configuring ATM OAM

Router B
IP:202.38.160.2/24
To A: 0/40
ATM To C:0/42
Network Interface:ATM 1/0/0
Router A
IP:202.38.160.1/24 Router C
To B: 0/40
To C:0/41
Interface:ATM 1/0/0
IP:202.38.160.3/24
To A: 0/41
To B:0/42
Interface:ATM 1/0/0
1. Configure IPoA services.
2. Configure the OAM attributes of the connection point.
3. Activate the CC function.
Data Preparation
l IP addresses of the ATM interfaces of the three Router
l VPIs/VCIs of Device A connecting to Device B and Device C, respectively
l VPIs/VCIs of Device B connecting to Device A and Device C, respectively
l VPIs/VCIs of Device C connecting to Device A and Device B, respectively
Procedure
Step 1 Configure IPoA.
# Configure Device A.
[HUAWEI] sysname DeviceA
[DeviceA] interface atm 1/0/0
[DeviceA-Atm1/0/0] ip address 202.38.160.1 255.255.255.0
[DeviceA-Atm1/0/0] pvc to_b 0/40
[DeviceA-atm-pvc-Atm1/0/0-0/40-to_b] map ip 202.38.160.2
[DeviceA-atm-pvc-Atm1/0/0-0/40-to_b] quit
[DeviceA-Atm1/0/0] pvc to_c 0/41
[DeviceA-atm-pvc-Atm1/0/0-0/41-to_c] map ip 202.38.160.3

[DeviceA-atm-pvc-Atm1/0/0-0/41-to_c] quit
[DeviceA-Atm1/0/0] undo shutdown
# Configure Device B.
[HUAWEI] sysname DeviceB
[DeviceB] interface atm 1/0/0
[DeviceB-Atm1/0/0] ip address 202.38.160.2 255.255.255.0
[DeviceB-Atm1/0/0] pvc to_a 0/40
[DeviceB-atm-pvc-Atm1/0/0-0/40-to_a] map ip 202.38.160.1
[DeviceB-atm-pvc-Atm1/0/0-0/40-to_a] quit
[DeviceB-Atm1/0/0] pvc to_c 0/42
[DeviceB-atm-pvc-Atm1/0/0-0/42-to_c] map ip 202.38.160.3
[DeviceB-atm-pvc-Atm1/0/0-0/42-to_c] quit
[DeviceB-Atm1/0/0] undo shutdown
# Configure Device C.
[HUAWEI] sysname DeviceC
[DeviceC] interface atm 1/0/0
[DeviceC-Atm1/0/0] ip address 202.38.160.3 255.255.255.0
[DeviceC-Atm1/0/0] pvc to_a 0/41
[DeviceC-atm-pvc-Atm1/0/0-0/41-to_a] map ip 202.38.160.1
[DeviceC-atm-pvc-Atm1/0/0-0/41-to_a] quit
[DeviceC-Atm1/0/0] pvc to_b 0/42
[DeviceC-atm-pvc-Atm1/0/0-0/42-to_b] map ip 202.38.160.2
[DeviceC-atm-pvc-Atm1/0/0-0/42-to_b] quit
[DeviceC-Atm1/0/0] undo shutdown
Step 2 Configure the OAM attributes of the connection point.

[DeviceA-Atm1/0/0] oam
[DeviceA-Atm1/0/0-fatm-oam] attribute 0/40 0/41 end-point
[DeviceB-Atm1/0/0] oam
[DeviceB-Atm1/0/0-fatm-oam] attribute 0/40 end-point
[DeviceB-Atm1/0/0-fatm-oam] attribute 0/42 end-point
# Configure Device C.
[DeviceC-Atm1/0/0] oam
[DeviceC-Atm1/0/0-fatm-oam] attribute 0/41 0/42 end-point
Step 3 Activate the CC function.

[DeviceA-Atm1/0/0-fatm-oam] cc 0/40 0/41 end-to-end both
[DeviceB-Atm1/0/0] oam
[DeviceB-Atm1/0/0-fatm-oam] cc 0/40 end-to-end both
[DeviceB-Atm1/0/0-fatm-oam] cc 0/42 end-to-end both
# # Configure Device C.

[DeviceC-Atm1/0/0] oam
[DeviceC-Atm1/0/0-fatm-oam] cc 0/41 0/42 end-to-end both

# Display the OAM configuration on the Router.
Use the display on Device A as an example:
<DeviceA> system-view
[DeviceA-Atm3/0/1-fatm-oam] display atm oam configuration atm 1/0/0
Interface PVC Attribute CC func CC dir CC attr
--------- ----- --------- ------- ------ -------
Atm1/0/0 0/40 end-point enable both end-to-end
Atm1/0/0 0/41 end-point enable both end-to-end
Current displayed item(s) is : 2
# Display the OAM statistics of the PVC on the Router.

Use the display on Device A as an example:
<DeviceA> display atm oam statistics atm 1/0/0 0/40
Total number of received OAM Cells : 0
Number of received AIS Cells : 0
Number of received RDI Cells : 0
Number of received loopback cells : 0
Number of received CC cells : 0
Number of received crc error cells : 0
Number of received other cells : 0
Total number of sent OAM Cells : 88
Number of sent AIS Cells : 0
Number of sent RDI Cells : 44
Number of sent loopback cells : 0
Number of sent CC cells : 44
----End
Configuration Files
#
sysname DeviceA
#
interface Atm1/0/0
undo shutdown
ip address 202.38.160.1 255.255.255.0
pvc to_b 0/40
map ip 202.38.160.2
pvc to_c 0/41
map ip 202.38.160.3
oam
attribute 0/40 0/41 end-point
cc 0/40 0/41 end-to-end both
#
return

#
sysname DeviceB
#
interface Atm1/0/0
undo shutdown
ip address 202.38.160.2 255.255.255.0
pvc to_a 0/40
map ip 202.38.160.1
pvc to_c 0/42

map ip 202.38.160.3
oam
attribute 0/40 end-point
attribute 0/42 end-point
cc 0/40 end-to-end both
cc 0/42 end-to-end both
#
return
l Device C configuration file

#
sysname DeviceC
#
interface Atm1/0/0
undo shutdown
ip address 202.38.160.3 255.255.255.0
pvc to_a 0/41
map ip 202.38.160.1
pvc to_b 0/42
map ip 202.38.160.2
oam
attribute 0/41 0/42 end-point
cc 0/41 0/42 end-to-end both
#
return

Configuration Guide - WAN Access 13 LMSP Configuration
13 LMSP Configuration
About This Chapter
For STM-N links in the SDH system, liner multiplex section protection (LMSP) can be used
to allow services to be rapidly migrated to a new link upon a link failure, ensuring service
continuity.
13.1 Introduction to LMSP

13.2 Licensing Requirements and Limitations for LMSP--M2H
13.3 Licensing Requirements and Limitations for LMSP--M2K
13.4 Licensing Requirements and Limitations for LMSP--M2K-B
13.5 Configuring Single-Chassis LMSP
Two devices that support LMSP can be connected using two links. Link reliability can be
improved by configuring single-chassis LMSP.
13.6 Configuring MC-LMSP
Inter-device LMSP switchbacks can be performed by configuring MC-LMSP.
13.7 Maintaining LMSP
13.8 Configuration Examples
This section provides configuration examples of LMSP.
13.1 Introduction to LMSP

Linear multiplex section protection (LMSP) is an SDH interface-based protection technique
that uses an SDH interface to protect services on another SDH interface. If a link failure
occurs, LMSP enables a device to send a protection switching request over K bytes to its peer
device. The peer device then returns a switching bridge reply.
NOTE
LMSP is often referred to as low speed APS protection.
Large numbers of low-speed links still exist on the user side. These links may be unstable due
to aging. These links have a small capacity and may fail to work properly due to congestion in

traffic burst scenarios. Therefore, a protection technique is required to provide reliability and
stability for these low-speed links.
LMSP is an inherent feature of an SDH network. When a mobile bearer network is deployed,
a Router must be connected to an add/drop multiplexer (ADM) or RNC, both of which
support LMSP. As the original protection function of the Router cannot properly protect the
communication channel between the Router and ADM or RNC, LMSP is introduced to
resolve this issue.
13.2 Licensing Requirements and Limitations for LMSP--

M2H

Deleting OAM (TPOAM or Configure TP-OAM or The service switching status

MPLS OAM) prior to APS MPLS OAM together with is abnormal.
causes APS to falsely APS.
determine that OAM
detection fails. This affects
the protection switching
status.
LSP APS fails when Do not configure The service switching status
penultimate hop popping is penultimate hop popping is abnormal.
configured on devices. and LSP APS at the same
time.
In the MC-PW APS Configure LSP APS on the The service switching status
scenario, when E-APS/E- ICB PW. is abnormal.
trunk works in 1:1 mode,
service switching fails after
the ICB PW fails.
When E-APS works in 1 +1 Configure LSP APS on the Service traffic is abnormal.
mode, a CSG receives two ICB PW.
copies of the same traffic
after the ICB PW fails.


M2K


determine that OAM
status.
time.
the ICB PW fails.

M2K-B



determine that OAM
status.
time.
the ICB PW fails.
13.5 Configuring Single-Chassis LMSP

Two devices that support LMSP can be connected using two links. Link reliability can be
improved by configuring single-chassis LMSP.
Usage Scenario
Linear multiplex section protection (LMSP) needs to be configured when the Router is
connected to a Radio Network Controller (RNC). As shown in Figure 13-1, PE2 and BSC
(RNC) are connected using two CPOS links. You can configure CPOS 3/0/1 as a working
interface, and CPOS 3/0/2 as a protection interface.

Figure 13-1 Typical networking diagram of single-chassis LMSP
E1
interface 1 interface 2
E1 10.1.1.1/24 10.2.1.2/24 CPOS
2 ×TDM E1
10.1.1.2/24 10.2.1.1/24 CPOS
PE1 P PE2 BSC
PWE3 TDM
Transparent Cell Transport
BTS
Pre-configuration Task
Before configuring LMSP, configure an interface on the Router and ensure that the data link
layer protocol run between the Router and the RNC is Up.
13.5.1 Specifying a Working Interface and a Protection Interface

for an LMSP Group
A working interface and a protection interface must be specified and added to an LMSP group
before other LMSP configurations are performed.
Context
An LMSP group includes one working interface and one protection interface, and they are the
smallest units protected by LMSP. The communication messages between the working
interface and the protection interface are transmitted within the LMSP group. Specifying a
working interface and a protection interface and adding them to an LMSP group are the
prerequisites for LMSP operation. The working interface is connected to a working link and
the protection interface is connected to a protection link. When an LMSP group works in 1:1
mode, the working interface transmits traffic, but the protection interface does not. The
protection interface takes over traffic after LMSP switching is performed. When an LMSP
group works in 1+1 mode, both the working and protection interfaces transmit traffic. The
receive end receives traffic only from the working link.
Perform the following steps on the Router that requires LMSP:
Procedure
Step 1 Specify an LMSP working interface.
1. Run system-view

2. To display the interface view, run either of the following command:
– interface interface-type interface-number

– controller cpos cpos-number
3. Run aps group group-id

An LMSP group is created, and an interface is added to the LMSP group.
4. Run aps working
The interface added to the LMSP group is specified as a working interface.
NOTE
In a single-chassis LMSP scenario, the working and protection interfaces may be on different
subcards. If the working interface is abnormal during the restart of the two subcards, neither the
configurations on the working interface nor the configurations on the protection interface can be
restored.
Step 2 Specify an LMSP protection interface.

1. Run system-view
2. To display the interface view, run either of the following command:
– interface interface-type interface-number
– controller cpos cpos-number

The working and protection interfaces must be added to a single LMSP group.
4. Run aps protect

The interface added to the LMSP group is specified as a protection interface.
----End
13.5.2 Configuring a Working Mode for an LMSP Group

A working mode can be configured for an LMSP group. The NE40E supports LMSP working
modes, including automatic LMSP switching and a delayed switchback with the wait to
restore (WTR) time configured. An LMSP working mode must be configured on a protection
interface.
Context
Automatic LMSP switching modes are classified as 1:1 bidirectional or 1+1 unidirectional.
After a fault in the working link is rectified, services automatically switch from the protection
link to the working link. During the switchback, some service traffic is dropped because some
resources related to the working link or NE40E are being restored. To prevent service loss, the
WTR time can be set on the NE40E to delay a switchback. Services can automatically switch
from the protection link back to the working link in the specified WTR time after the working
link becomes available.
Perform the following steps on a protection interface in an LMSP group:

Procedure
l Configure an automatic protection switching mode for an LMSP group.
a. Run system-view

b. To display the interface view, run either of the following command:
n interface interface-type interface-number
n controller cpos cpos-number
c. Run aps mode { one2one bidirection | one-plus-one { bidirection |

unidirection } }
A working mode is configured for the LMSP group. One of the following modes
can be configured:
n one2one bidirection:
○ Configures LMSP to work in 1:1 mode. Only the working link transmits
traffic. The protection link only carries traffic if the working link is faulty.
○ Configures LMSP to work in bidirectional mode. If an interface fails,
both the transmit and receive ends switch their traffic to the protection
link.
n one-plus-one unidirection:
○ Configures LMSP to work in 1+1 mode. Both the working link and the
protection link transmit traffic.
○ Configures LMSP to work in unidirectional mode. If an optical fiber to an
interface fails, only the receive end switches its traffic to the protection
link.
n one-plus-one bidirection:
○ Configures LMSP to work in 1+1 mode. Both the working link and the
protection link transmit traffic.
○ Configures LMSP to work in bidirectional mode. If an interface fails,
both the transmit and receive ends switch their traffic to the protection
link.
l Set the WTR time for an LMSP group.
a. Run system-view

b. Run interface interface-type interface-numbercontroller cpos cpos-number
Or, run:
The protection interface view of the LMSP group is displayed.

c. Run aps revert wtr-time
The WTR time is set for the LMSP group.
The value ranges from 1 to 12 minutes.

NOTE
If two different switchback delays are set on two protection interfaces in LMSP groups on
two ends of a link, the effective switchback delay depends on one of the following
situations:
l If one-plus-one unidirection is configured, the switchback delays on both protection
interfaces take effect after the working interfaces recover.
l If one2one bidirection or one-plus-one bidirection is configured, the switchback delay
on the protection interface of the device with the working interface recovering later than
the other working interface takes effect on both protection interfaces.
l In a single-chassis scenario, the switchback time must be the same on two LMSP
devices.
----End
13.5.3 Adding Interfaces of an LMSP Group to a Trunk Interface

A working interface and a protection interface in an LMSP group must be added to a single
trunk interface.
Context
LMSP is used to protect traffic on attachment circuit (AC) links connecting Routers to Add/
Drop Multiplex (ADM) devices or Radio Network Controllers (RNCs) on a Synchronous
Digital Hierarchy (SDH) network. AC-side physical POS or channelized Packet Over SDH/
SONET (CPOS) interfaces on the Routers are added to a trunk interface to carry services.
Perform the following steps on the working and protection interfaces of an LMSP group:
Procedure
Step 2 Run interface cpos-trunk trunk-id
An CPOS-Trunk interface is created, and the view of the CPOS-Trunk interface is displayed.
NOTE
LMSP can be configured on the CPOS and POS interfaces. The corresponding trunk interfaces are
CPOS-Trunk and POS-Trunk. In the following example, the CPOS-Trunk configuration is used.
Step 3 Run quit
Step 5 Run cpos-trunk trunk-id
The interface is added to a trunk interface.

NOTE
The working and protection interfaces of an LMSP group must be added to the trunk interface with the
same trunk ID.
----End
13.5.4 Checking the Configurations

After configuring a single-chassis LMSP group, the LMSP group's working mode, working
interface, WTR time, and interface status can be viewed.
Procedure
Step 1 Run the display aps group group-id command to check configurations of an LMSP group.
Step 2 Run the commands below to check configurations of trunk interfaces.

l Run the display pos-trunk trunk-id command to check configurations of the POS-Trunk
interfaces.
l Run the display cpos-trunk trunk-id command to check configurations of the CPOS-
Trunk interfaces.
----End
13.6 Configuring MC-LMSP

Inter-device LMSP switchbacks can be performed by configuring MC-LMSP.
Usage Scenario
Figure 13-2 shows an MC-LMSP network. Two network-side devices back up each other,
improving link reliability. MC-LMSP needs to be configured on these two devices dual-
homed to RNCs. MC-LMSP provides higher security than single-chassis LMSP provides.
Single-chassis LMSP means interface, subcard, and board-based LMSP.
Figure 13-2 Association between an MC-LMSP group and PW redundancy
PW Device C
ry
i ma
Pr
Bypass
PW MC-LMSP
Node B Device A RNC

B ac
ku p
PW Device B

Pre-configuration Task
Before configuring MC-LMSP, complete the following tasks:
l Configure an interface on the Router and ensure that the data link layer protocol run
between the Router and the RNC is Up.
l Run an IGP protocol on the backbone network so that devices can communicate with
each other.
NOTE
In a PPP-based Layer 3 IP forwarding scenario, if devices use a dynamic routing protocol, the
dynamic routes have to be re-learned during an LMSP link switchover. In the route convergence
process, which lasts for dozens of seconds, service traffic may be dropped. To prevent this
problem, configure static routes on the LMSP interfaces of the master, device, backup device, and
the RNC. This configuration can prevent traffic loss.
Figure 13-3 Flowchart for configuring MC-LMSP

Configuring MC-LMSP
Specifying a Working Interface

and a Protect Interface for an
LMSP Group
Configuring a Working Mode for

an LMSP Group
Binding an LMSP Group to a

BFD Session
MC-LMSP Negotiation and

Authentication Parameters
Adding Interfaces of an LMSP

Group to a Trunk Interface
Mandatory
Procedure
Optional
Procedure
13.6.1 Specifying a Working Interface and a Protection Interface

for an LMSP Group
A working interface and a protection interface must be specified and added to an LMSP group
before other LMSP configurations are performed.
Context
An LMSP group includes one working interface and one protection interface. An LMSP
group is the smallest unit protected by LMSP. The communication messages between the

working interface and the protection interface are transmitted within the LMSP group.
Specifying a working interface and a protection interface and adding them to an LMSP group
are the prerequisites for LMSP operation. The working interface is connected to a working
link and the protection interface is connected to a protection link. When an LMSP group
works in 1:1 mode, the working interface transmits traffic, but the protection interface does
not. The protection interface takes over traffic after LMSP switching is performed. When an
LMSP group works in 1+1 mode, both the working and protection interfaces transmit traffic.
The receive end receives traffic only from the working link.
Perform the following steps on the Routers where the LMSP working and protection interface
are located separately:
Procedure
Step 1 Specify an LMSP working interface.
1. Run system-view

2. Run the following commands to display the interface view:
controller cpos cpos-number

4. Run aps working peer-ip local-ip
The interface added to the LMSP group is specified as a working interface.
Step 2 Specify an LMSP protection interface.

1. Run system-view

2. Run the following commands to display the interface view:
NOTE
The working and protection interfaces must be added to a single LMSP group.
4. Run aps protect peer-ip local-ip
The interface added to the LMSP group is specified as a protection interface.

5. (Optional) Run aps signal-low-priority
The low-priority signal failure code for a switching request carried in the K byte is
specified on the protection interface.
Step 3 In MC-LMSP 1+1 unidirectional mode, run:

hold-up
The interface is configured to remain Up.
This command is used on the working and protection interfaces of the LMSP group that
works in MC-LMSP 1+1 unidirectional mode.

MC-LMSP 1+1 needs to be associated with dual bypass PWs. In MC-LMSP 1+1
unidirectional mode, if an AC-side interface is Down, one of the bypass PWs associated with
the interface will be deleted. Then traffic will not be forwarded by the deleted bypass PW. To
address this problem, the hold-up command must be run on an MC-LMSP interface.
NOTE
After this command has been run, the alarm functions do not take effect on the LMSP group interface,
the link indicator on the LMSP group interface is always on, and the interface remains Up even when no
fiber is attached to it.
Step 4 Run commit
----End
13.6.2 Configuring a Working Mode for an LMSP Group

A working mode can be configured for an LMSP group. The NE40E supports LMSP working
modes, including automatic LMSP switching and a delayed switchback with the wait to
restore (WTR) time configured. An LMSP working mode must be configured on a protection
interface.
Context
Automatic LMSP switching modes are classified as 1:1 bidirectional or 1+1 unidirectional.
The default automatic LMSP switching mode is 1+1 unidirectional.
After a fault in the working link is rectified, services automatically switch from the protection
link to the working link. During the switchback, some service traffic is dropped because some
resources related to the working link or NE40E are being restored. To prevent service loss, the
WTR time can be set on the NE40E to delay a switchback. Services can automatically switch
from the protection link back to the working link in the specified WTR time after the working
link becomes available.
Procedure
l Configure an automatic protection switching mode for an LMSP group.
a. Run system-view

b. Run the following commands to display the interface view:
c. Run aps mode { one2one bidirection | one-plus-one { bidirection |

unidirection } }
A working mode is configured for the LMSP group. One of the following parameter
combinations can be configured:
n one2one bidirection:
○ 1:1 mode: Only the working link transmits traffic. The protection link
takes over traffic only if the working link fails.

○ Bidirectional mode: The transmit end sends traffic along and the receive
end receives traffic from the protection link if a fault occurs on the
working link.
n one-plus-one unidirection:
○ 1+1 mode: Both the working and protection links transmit traffic.
○ Unidirectional mode: Only the receive end receives traffic from the
protection link if a fault occurs on the optical fiber to an interface.
n one-plus-one bidirection:
○ 1+1 mode: Both the working and protection links transmit traffic.
○ Bidirectional mode: The transmit end sends traffic along and the receive
end receives traffic from the protection link if a fault occurs on the
working link.
d. Run commit
l (Optional) Set the WTR time for an LMSP group.
a. Run system-view
b. Run the following commands:

c. Run aps revert wtr-time
The WTR time is set for the LMSP group.
NOTE
If two different switchback delays are set on two protection interfaces in LMSP groups on
two ends of a link, the effective switchback delay depends on one of the following
situations:
l If one-plus-one unidirection is configured, the switchback delays on both protection
interfaces take effect after the working interfaces recover.
l If one2one bidirection or one-plus-one bidirection is configured, the switchback delay
on the protection interface of the device with the working interface recovering later than
the other working interface takes effect on both protection interfaces.
l In an MC-LMSP scenario, the switchback time must be the same on two LMSP devices
on the RNC side and slave RSG side.
d. Run commit
----End
13.6.3 (Optional) Binding an LMSP Group to a BFD Session
Context
To monitor an MC-LMSP group, a BFD session monitors an mPW between the working and
protection interfaces on the AC side, and the MC-LMSP group is bound to another BFD
session. If faults occur, the working and protection devices can use BFD to notify each other

of the faults and implement rapid traffic switchovers between the working and protection
devices.
Perform the following steps on the working or protection interface of an LMSP group:
Procedure
Step 2 Run the following commands:

The working interface view or the protection interface view is displayed.
Step 3 Bind an LMSP group to a BFD session.
This configuration procedure is based on a scenario where BFD is configured to track the
status of the working interface and quickly transmit the status to the device where the
protection interface resides. The procedure for configuring BFD to track the protection
interface and quickly transmit the status to the device where the working interface resides is
similar.
1. Establish an mPW between MC-LMSP-enabled devices. For the configuration

procedure, see the chapter "PW Redundancy Configuration" in HUAWEI NE40E-M2
Series Universal Service Router Configuration Guide - VPN.
2. Run the bfd cfg-name bind pw interface interface-type interface-number track-
interface interface interface-type interface-number command on the device with a
working interface to configure a BFD session to monitor the mPW and bind the BFD
session to the working interface.
3. Run the bfd cfg-name bind pw interface interface-type interface-number select-board
slot-id command on the device with a protection interface to specify the interface board
where the BFD session is configured to monitor the mPW.
4. Run the aps track bfd-session session-name bfd-session-name command on the device
with the protection interface to bind the interface to the BFD session.
NOTE
The undo aps group command deletes the LMSP group configurations and removes the binding
between the LMSP group and a BFD session if configured.
Step 4 Run commit
----End
13.6.4 (Optional) Configuring MC-LMSP Negotiation and

Authentication Parameters
MC-LMSP-enabled Routers run the Protection Group Protocol (PGP) to exchange control
messages. Negotiation and authentication parameters can be set for PGP message
transmission, helping use MC-LMSP functions easily and securely.

Context
Two MC-LMSP-enabled Routers run the Protection Group Protocol (PGP) to exchange
control messages along an outband channel at a specified interval. PGP negotiation messages
are exchanged periodically to verify MC-LMSP connectivity. If no response arrives within a
specified period, the Router considers its peer Router faulty and does not perform MC-LMSP
switching even though a switching trigger condition is met.
In addition to the interval at which negotiation messages are sent, the MC-LMSP connection
hold time can also be set on the NE40Es. The local NE40E retains the MC-LMSP connection
during the configured hold time. If no negotiation message is received after the hold time
elapses, the local NE40E considers the MC-LMSP connection is torn down.
PGP is a Layer 3 Huawei proprietary protocol and operates over a UDP connection. PGP's
default authentication mode is none. Messages transmitted in none authentication mode can
be easily used to initiate attacks. To protect the NE40E running PGP, an authentication string
can be configured so that PGP messages are authenticated. Two MC-LMSP-enabled Routers
use the authentication string to authenticate PGP messages. Negotiation can be successfully
performed only when the two Routers use the same authentication string. Authentication
string inconsistency will lead to a negotiation failure.
Procedure
l Set the interval at which LMSP negotiation messages are sent and the LMSP connection
hold time.
a. Run system-view

b. Run either of the following commands:
The working or protection interface view is displayed.

c. Run aps timers keep-alive-time hold-time
The interval at which MC-LMSP negotiation messages are sent and the hold time of
the LMSP connection between the working and protection interfaces are set.
d. Run commit

l Configure the authentication string for PGP messages.
a. Run system-view

The working or protection interface view is displayed.

c. Run aps authenticate { simple-key | simple simple-key | cipher cipher-key
[ sha2 ] }
The authentication string is configured for PGP messages.

NOTE
The working or protection interface must be specified before an authentication string is

configured for the PGP message.
PGP negotiation can only be performed successfully when the authentication strings
configured on both working and protection interfaces are the same.
When the cipher text mode is used, enable the SHA2 abstract algorithm to obtain a higher
security level. Ensure that the configurations on the two devices must be consistent.
l The new password is at least eight characters long and contains at least two of upper-
case letters, lower-case letters, digits, and special characters.
l When configuring an authentication password, select the ciphertext mode becasue the
password is saved in configuration files in simple text if you select simple text mode,
which has a high risk. To ensure device security, change the password periodically.
d. (Optional) Run aps anti-replay enable
APS anti-replay is enabled.

e. Run commit
----End
13.6.5 Adding Interfaces of an LMSP Group to a Trunk Interface

A working interface and a protection interface in an LMSP group must be added to a single
trunk interface.
Context
LMSP is used to protect traffic on attachment circuit (AC) links connecting Routers to Add/
Drop Multiplex (ADM) devices or Radio Network Controllers (RNCs) on a Synchronous
Digital Hierarchy (SDH) network. AC-side physical channelized Packet Over SDH/SONET
(CPOS) interfaces on the Routers are added to a trunk interface to carry services.
Procedure
Step 2 Run interface cpos-trunk interface-number
A CPOS-Trunk interface is created, and the view of the CPOS-Trunk interface is displayed.
NOTE
LMSP can be configured on the CPOS interfaces. The corresponding trunk interfaces are CPOS-Trunk.
Step 3 Run quit
Step 4 Run controller cpos interface-number

Step 5 Run cpos-trunk trunk-id
The interface is added to a trunk interface.
NOTE
The working and protection interfaces of an LMSP group must be added to the trunk interface with the
same trunk ID.
Step 6 Run commit
----End
13.6.6 Checking the Configurations

After configuring MC-LMSP, you can check the LMSP group's working mode, working
interface, switchback time, and interface status.
Procedure
Step 1 Run the display aps group group-id command to check configurations of an LMSP group.
Step 2 Run the display cpos-trunk trunk-id command to check configurations of the CPOS-Trunk
interfaces.
----End
13.7 Maintaining LMSP
13.7.1 Configuring a Command-Triggered Switching Mode for an

LMSP Group
Command-triggered LMSP switching modes include protection lockout, forcible switching to
the working link, forcible switching to the protection link, manual switching to the working
link, and manual switching to the protection link. Command-triggered LMSP switching is
used during a device upgrade, link troubleshooting, testing, and maintenance.
Context
The switching modes are prioritized in descending order:
Protection lockout > Forcible switching to the working link > Forcible switching to the
protection link > Manual switching to the working link > Manual switching to the protection
link
l Protection lock: Services are being transmitted on the working link and are unable to
switch to the protection link even though the working link becomes unavailable.
l Forcible switching to the working link: After services have been switched to the
protection link, the services can be forcibly switched back to the working link. Even if an
SD or SF fault occurs on the working link, the services will not be switched to the
protection link. As a result, services are interrupted.

l Forcible switching to the protection link: If the working link fails, services are forcibly
switched to the protection link. If an SD fault occurs on the protection link, the services
may be interrupted. If an SF fault occurs on the protection link, a device sends a request
to its peer to switch the services back to the working link.
l Manual switching to the working link: If a traffic switchover has been performed in an
LMSP group and the working link has no fault, services can be manually switched to the
working link. A device will send a request to its peer to switch services to the protection
link if an SF or SD fault occurs on the working link.
l Manual switching to the protection link: If the working and protection links have no SF
or SD fault, services can be manually switched to the protection link. A device will send
a request to its peer to switch services to the working link if an SF or SD fault occurs on
the protection link.
Procedure
l Configure a command-triggered switching mode for an LMSP group.
a. Run system-view

n interface interface-type interface-number
n controller cpos cpos-number

c. Run aps switch-command { lockout | { force | manual } [ section section-
number ] }
A switching mode is configured for the LMSP group.
NOTE
When using an aps switch-command command instance, ensure that the priority of the
switch command is higher than that of an existing switch command. Otherwise, the
command to be used does not take effect.
If the force or manual parameter is configured, the display this command does not display
configurations. You can run the display aps group group-id command to view
configurations.
----End
13.8 Configuration Examples

This section provides configuration examples of LMSP.
13.8.1 Example for Configuring TDM on the CPOS-TRUNK

Configured with LMSP
This section provides an example for configuring LMSP-based TDM on a CPOS interface.

TDMoPSN service can enable mobile operators to receive transparent transmission of 2G
services between BTSs and BSCs in the same city through TDM links in a Metro Ethernet
(ME) network. This simple and cost-reducing service can be essential, because usually, it
requires one to three E1 interfaces on a BTS to connect to a BSC on a 2G RAN, and some
mobile operators do not own fixed network infrastructure and have to rent E1 lines at high
prices.
In Figure 13-4, it is required that the BTS and PE1 be connected through two E1 links. The
BSC and PE2 should be connected through the CPOS interface, which are configured with
LMSP so as to increase reliability of data. The encapsulation protocol on the channelized
serial interface of the E1 links needs to be configured as TDM. Finally, a PW needs to be set
up between PE1 and PE2 to transparently transmit TDM cells.
Figure 13-4 TDMoPSN networking

NOTE
The configurations in this example are performed on PE-1 and PE-2. HUAWEI NE40E-M2 Series can
function as PE-1 and PE-2.
Interfaces 1 through 2 in this example are GE 0/1/0, GE 0/2/0 respectively.
E1
E1 10.1.1.1/24 10.2.1.2/24 CPOS
2 ×TDM E1
10.1.1.2/24 10.2.1.1/24 CPOS
PE1 P PE2 BSC
PWE3 TDM
Transparent Cell Transport
BTS
Device Name Interface Name IP Address and Mask
PE1 GE 0/1/0 10.1.1.1/24
Loopback0 192.168.1.2/32
P GE 0/1/0 10.1.1.2/24
GE 0/2/0 10.2.1.1/24
Loopback0 192.168.1.4/32
PE2 GE 0/2/0 10.2.1.2/24
Loopback0 192.168.1.3/32

1. Run an IGP protocol on the backbone network so that devices can communicate with
each other.
2. Configure basic MPLS functions on the backbone network, as well as MPLS L2VPN
functions on PEs. Establish a remote MPLS LDP peer relationship between PEs at both
ends of a PW.
3. Configure LMSP on PE2.
4. Configure TDM interface parameters.
5. Configure a PW template.
6. Establish MPLS L2VC connections on PE1 and PE2.
Data Preparation
l L2VC ID at both ends of the PW (must be the same)
l MPLS LSR IDs of the PEs and P device
l IP addresses of the remote peers of PEs
Procedure
Step 1 Run an IGP protocol on the backbone network so that devices can communicate with each
other. For detailed configurations, see the configuration file of this example.
Step 2 Configure basic MPLS functions on the backbone network, as well as MPLS L2VPN
functions on PEs. Then, establish the remote MPLS LDP peer relationship between PEs at
both ends of the PW. For configuration details, see Configuration Files in this section.
The remote MPLS LDP peer relationship is only required for dynamic PWs.
Step 3 Configure LMSP.
The BSC device connected to PE2 must support LMSP.
Configure PE2.
[~PE2] interface cpos-trunk 1
[*PE2-cpos-trunk1] commit
[~PE2-cpos-trunk1] quit
[*PE2-Cpos0/3/1] aps group 1
[*PE2-Cpos0/3/1] aps working
[*PE2-Cpos0/3/1] commit
[~PE2-Cpos0/3/1] quit
[*PE2-Cpos0/3/2] aps protect
[*PE2-Cpos0/3/2] aps mode one-plus-one unidirection
[~PE2-Cpos0/3/1] cpos-trunk 1

[~PE2-Cpos0/3/2] cpos-trunk 1
# Run the display aps group command on PE2 to view LMSP group configurations. Run the
display cpos-trunk command on also on PE2 to view CPOS-Trunk interface configurations.
<PE2> display aps group 1
APS Group 1: Cpos 0/3/1 working channel 1(Active)
Cpos0/3/2 protection channel 0(Inactive)
Unidirection, 1+1 mode, No Revert mode
No Request on Both Working and Protection Side
------------------------------------------------------------------------
Group Work-Channel Protect-Channel Wtr W-State P-State Switch-Cmd Switch-Result
------------------------------------------------------------------------
1 Cpos 0/3/1 Cpos 0/3/2 NA ok ok NA idle
------------------------------------------------------------------------
total entry: 1
<PE2> display cpos-trunk 1
Interface Cpos-Trunk1's state information is:,
Operate status: up Number Of Up Port In Trunk: 2
--------------------------------------------------------------------------------
PortName Status Active Status
Cpos0/3/1 Up Active
Cpos0/3/2 Up Inactive
Step 4 Configure TDM interface parameters.

1. Configure PE1.
# Configure the clear channelized mode for CE1 0/2/1 and CE1 0/2/2 on PE1.
[*PE1-E1 0/2/1] using e1
[~PE1-E1 0/2/1] quit
[*PE1-E1 0/2/2] using e1
[~PE1-E1 0/2/2] quit
2. Configure PE2.
# Set CPOS-Trunk interface parameters on PE2.
[~PE2] interface cpos-trunk 1
[~PE2-Cpos-trunk1] e1 1 unframed
[*PE2-Cpos-trunk1] e1 2 unframed
[*PE2-Cpos-trunk1] commit
[~PE2-Cpos-trunk1] quit
Step 5 Configure TDM as an encapsulation protocol on the serial interface.

1. Configure PE1.
[*PE1-Serial0/2/1:0] commit
[~PE1-Serial0/2/1:0] quit
2. Configure PE2.
[~PE2] interface trunk-serial1/1:0
[~PE2-Trunk-Serial1/1:0] link-protocol tdm
[*PE2-Trunk-Serial1/1:0] commit
[~PE2-Trunk-Serial1/1:0] quit
[~PE2-Trunk-Serial1/2:0] link-protocol tdm

Step 6 Configuring PWs.

1. Configure PE1.
[*PE1-pw-template-1to3] commit
[~PE1-pw-template-1to3] quit
[~PE1-Serial0/2/1:0] mpls l2vc pw-template 1to3 100
[~PE1-Serial0/2/2:0] mpls l2vc pw-template 1to3 200
2. Configure PE2.
[*PE2-pw-template-3to1] commit
[~PE2-pw-template-3to1] quit
[~PE2-Trunk-Serial1/1:0] mpls l2vc pw-template 3to1 100
[*PE2-Trunk-Serial1/1:0] undo shutdown
[~PE2-Trunk-Serial1/2:0] mpls l2vc pw-template 3to1 200
[*PE2-Trunk-Serial1/2:0] undo shutdown
Run the display mpls l2vc command on PE1. The command output shows that the PW
status is Up.
session state : up
AC state : up
VC state : up
VC ID : 100
VC type : SAT E1 over Packet
local group ID : 0
remote group ID : 0
jitter-buffer : 20
idle-code : FF

link state : up
local VC MTU : 1500
remote VCCV : none
VC last up time : 2008/12/26 12:02:49
CKey : 11
NKey : 10

Simulate a fault on the side of PE2 connecting to the BSC.
# Run the shutdown command on CPOS 0/3/1.
[~PE2-Cpos0/3/1] shutdown
Run the display aps group 1 command on PE2. The LMSP status changes to Switch. Run the
display cpos-trunk 1 command to view the CPOS-Trunk member interface status. CPOS
0/3/2 becomes Active.
[~PE2] display aps group 1
APS Group 1: Cpos 0/3/1 working channel 1(Inactive)
Cpos0/3/2 protection channel 0(Active)
Unidirection, 1+1 mode, No Revert mode
------------------------------------------------------------------------
------------------------------------------------------------------------
1 Cpos 0/3/1 Cpos 0/3/2 NA sf ok NA switch
------------------------------------------------------------------------
total entry: 1
<PE2> display cpos-trunk 1
Interface Cpos-Trunk1's state information is:,
--------------------------------------------------------------------------------
Cpos0/3/1 Down Inactive
Cpos0/3/2 Up Active
Run the display mpls l2vc command on PEs. The command output shows that the PW status
is Up and has not been affected by the fault in CPOS 0/3/1.
The following example uses the command output on PE1.
session state : up
AC state : up
VC state : up
VC ID : 100
VC type : SAT E1 over Packet
local group ID : 0
remote group ID : 0


jitter-buffer : 20
idle-code : FF
link state : up
local VC MTU : 1500
remote VCCV : none
VC last up time : 2008/12/26 12:02:49
CKey : 11
NKey : 10
----End
Configuration Files
l PE1 configuration file
#
sysname PE1
#
mpls lsr-id 192.168.1.2
mpls
#
mpls l2vpn
#
pw-template 1to3
#
mpls ldp
#
remote-ip 192.168.1.3
#
controller e1 0/2/1
using e1
undo shutdown
#
controller e1 0/2/2
using e1
undo shutdown
#

link-protocol tdm
undo shutdown
#
link-protocol tdm
undo shutdown
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.1.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.1.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
mpls lsr-id 192.168.1.3
mpls
#
mpls l2vpn
#
pw-template 3to1
#
mpls ldp
#
remote-ip 192.168.1.2
#
undo shutdown
aps group 1
aps working
#
undo shutdown
aps group 1
aps protect
aps mode one-plus-one unidirection
#
interface cpos-trunk1
e1 1 unframed
e1 2 unframed
Cpos0/3/1
Cpos0/3/2
#
interface trunk-serial1/1:0
link-protocol tdm
undo shutdown
#
interface trunk-serial1/2:0
link-protocol tdm

undo shutdown
#
undo shutdown
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.1.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.1.3 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
l P configuration file
#
sysname P
#
mpls lsr-id 192.168.1.4
mpls
#
mpls ldp
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 192.168.1.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.1.4 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
13.8.2 Example for Configuring LMSP on a CPOS-Trunk

In this example, a CPOS-Trunk is configured on the Router to aggregate multiple E1 links
connected to mid-range-and-low-end devices and identify devices with different timeslots. In
addition, LMSP is configured on the CPOS interfaces of the Router to implement protection
switching.
As shown in Figure 13-5, mid-range-and-low-end devices are connected to the transport
network through E1 links. These E1 links are aggregated into a CPOS-Trunk interface
configured on Device A. Device A uses timeslots to identify these devices. The CPOS-Trunk
interface on Device A consists of two CPOS interfaces. Single-chassis LMSP needs to be
configured on the CPOS interfaces to improve data transfer reliability.

In real-world situations, mid-range-and-low-end devices are usually connected to CPOS

interfaces over a multi-layer transport network. Therefore, relay devices and other transport
means are probably involved.
Figure 13-5 Networking diagram for configuring LMSP on a CPOS-Trunk

NOTE
The configurations in this example are performed on Device-A. HUAWEI NE40E-M2 Series can
function as Device-A.
E1 ..
ADM
Device A
CPOS
E1
ADM STM-4/16 ADM CPOS-Trunk 0 Internet
OC-3/STM-1 CPOS
ADM
nx E1 ..
1. Configure single-chassis LMSP on the two CPOS interfaces and add the CPOS
interfaces to a CPOS-Trunk interface.
2. Bundle timeslots of E1 channels in the CPOS-Trunk interface to create Trunk-Serial
interfaces and add the Trunk-Serial interfaces into a Global-MP-Group interface.
Data Preparation
l LMSP parameters
l CPOS-Trunk interface parameters
l Global-MP-Group interface number
Procedure
Step 1 Configure single-chassis LMSP.
1. Configure single-chassis LMSP on Device A.
[~HUAWEI] commit
[~DeviceA] controller cpos 0/1/0

[*DeviceA-Cpos0/1/0] aps group 1

[*DeviceA-Cpos0/1/0] aps working
[*DeviceA-Cpos0/2/0] aps group 1
[*DeviceA-Cpos0/2/0] aps protect
[*DeviceA-Cpos0/2/0] aps mode one-plus-one unidirection
[*DeviceA-Cpos0/2/0] aps revert 6
2. Create a CPOS-Trunk interface on Device A and add CPOS interfaces to the CPOS-
Trunk interface.
[~DeviceA] interface cpos-trunk 0
[*DeviceA-Cpos-Trunk0] commit
[~DeviceA-Cpos-Trunk0] quit
[~DeviceA-Cpos0/1/0] cpos-trunk 0
[~DeviceA-Cpos0/2/0] cpos-trunk 0
Step 2 Configure the CPOS-Trunk interface.

1. Bundle timeslots of E1 channels in the CPOS-Trunk interface.
[~DeviceA] interface cpos-trunk 0
[~DeviceA-Cpos-Trunk0] e1 1 channel-set 1 timeslot-list 1-15
[*DeviceA-Cpos-Trunk0] e1 2 channel-set 2 timeslot-list 17-31
[*DeviceA-Cpos-Trunk0] commit
[~DeviceA-Cpos-Trunk0] quit
2. Create a Global-MP-Group interface.

[~DeviceA] interface global-mp-group 0
[*DeviceA-Global-Mp-Group0] shutdown
[*DeviceA-Global-Mp-Group0] commit
[~DeviceA-Global-Mp-Group0] quit
3. Add Trunk-Serial interfaces to the Global-MP-Group interface.

[~DeviceA] interface Trunk-Serial0/1:1
[~DeviceA-Trunk-Serial0/1:1] shutdown
[*DeviceA-Trunk-Serial0/1:1] link-protocol ppp
[*DeviceA-Trunk-Serial0/1:1] ppp mp-global global-mp-group 0
[*DeviceA-Trunk-Serial0/1:1] commit
[~DeviceA-Trunk-Serial0/1:1] quit
[~DeviceA-Trunk-Serial0/2:2] shutdown
[*DeviceA-Trunk-Serial0/2:2] link-protocol ppp
[*DeviceA-Trunk-Serial0/2:2] ppp mp-global global-mp-group 0
4. Restart Trunk-Serial interfaces and the Global-MP-Group interface.

[~DeviceA] interface global-mp-group 0
[~DeviceA-Global-Mp-Group0] undo shutdown
[*DeviceA-Global-Mp-Group0] commit
[~DeviceA-Global-Mp-Group0] quit
[~DeviceA-Trunk-Serial0/1:1] undo shutdown
[~DeviceA-Trunk-Serial0/2:2] undo shutdown


# Run the display aps group command on Device A to view the LMSP configuration. The
command output shows the working interface, protection interface, and switchback WTR
time.
[~DeviceA] display aps group 1
APS Group 1: Cpos0/1/0 working channel 1(Active)
Unidirectional, 1+1 mode, Revert time(6 minutes)
------------------------------------------------------------------------
------------------------------------------------------------------------
1 Cpos0/1/0 Cpos0/2/0 6 ok ok NA idle
------------------------------------------------------------------------
total entry: 1
# Run the display cpos-trunk command to view the CPOS-Trunk interface configuration.
The command output shows the status of CPOS-Trunk member interfaces.
[~DeviceA] display cpos-trunk 0
Interface Cpos-Trunk0's state information is:
--------------------------------------------------------------------------------
Cpos0/1/0 Up Active
Cpos0/2/0 Up Inactive
# Run the display ppp mp-global command to view the Global-MP-Group interface
configuration. The command output shows the status of Trunk-Serial interfaces in the Global-
MP-Group interface.
[~DeviceA] display ppp mp-global
Global-Mp-Group is Global-Mp-Group0
Trunk-Serial0/1:0 physical UP,protocol UP
Trunk-Serial0/2:0 physical UP,protocol UP
----End
Configuration Files
#
sysname DeviceA
#
undo shutdown
aps group 1
aps working
cpos-trunk 0
#
undo shutdown
aps group 1
aps protect
aps mode one-plus-one unidirection
aps revert 6
cpos-trunk 0
#
interface Cpos-Trunk0
undo shutdown

#
interface Global-Mp-Group0
undo shutdown
#
interface Trunk-Serial0/1:1
undo shutdown
link-protocol ppp
ppp mp-global global-mp-group 0
#
undo shutdown
link-protocol ppp
#
return
13.8.3 Example for Configuring Dual-System LMSP in the

Scenario of Forwarding IP Packets Using PPP
This section describes how to configure dual-system Linear multiplex section protection
(LMSP) on CPOS interfaces on a Layer 3 IP packet forwarding network using Point-to-Point
Protocol (PPP).
As shown in Figure 13-6, PE1 is dual-homed to PE2 and PE3 through two PWs. MC-LMSP
is implemented on the AC side to prevent a network fault from causing data loss.
NOTE
If the LMSP-enabled interface uses a dynamic routing protocol to advertise routes on the Layer-3 IP packet
forwarding network using PPP, the dynamic routes must be learned again after an LMSP is performed. The
route convergence takes dozens of seconds, causing a service interruption. To prevent the problem, static
routes can be bound to the master device, backup device, and the LMSP-enabled interfaces of a radio network
controller (RNC) and imported by a dynamic routing protocol. When an LMSP is performed, the routes do
not have to be learned again, which accelerates the route convergence and prevents a long service
interruption.
Figure 13-6 Configuring dual-system LMSP in the scenario of forwarding IP packets using
PPP
Loopback0 Loopback0
2.2.2.2 4.4.4.4
Loopback0 P1 PE2
interface6 int
1.1.1.1 erf
ac
e5
e1 e1
interface1 int
ac ac erf
erf erf ac CE2
int int e3
interface2
PE1 MC-LMSP
inte i nt e interface2 4
rfa a ce
rfa ce erf
ce 2 2
interface1 int
e 5
ac
nt er f
i
interface1
P2 PE3
CE1
Loopback0 Loopback0
3.3.3.3 5.5.5.5

Device Interface Name Interface
PE1 interface1 GE0/2/1

interface2 GE0/2/2
P1 interface1 GE0/2/1
interface6 GE0/2/5
P2 interface1 GE0/2/1
interface2 GE0/2/2

interface2 GE0/2/2
interface5 CPOS0/2/3

interface2 GE0/2/2
CE2 interface3 CPOS0/2/1

1. Assign an IP address to each interface.

2. Configure MC-LMSP on PE2 and PE3 and LMSP on CE2.
3. Bind static routes to the MC-LMSP-enabled interfaces of PE2 and PE3 and the LMSP-
enabled interfaces of CE2.
4. Configure a dynamic routing protocol to import direct routes.
Data Preparation
l MC-LMSP parameters
l CPOS-Trunk interface parameters
l Global-MP-Group interface number
Procedure
Step 1 Configure IP addresses.
Assign the IP address and mask to each interface according to Figure 13-6. For configuration
details, see Configuration Files in this section.

Step 2 Configure MC-LMSP.

1. Configure LMSP on PE2, PE3, and CE2.
# Configure PE2.
[~PE2-Cpos0/2/3] undo shutdown
[*PE2-Cpos0/2/3] aps working 4.4.4.4 5.5.5.5
# Configure PE3.
[~PE3-Cpos0/2/3] undo shutdown
[*PE3-Cpos0/2/3] aps protect 5.5.5.5 4.4.4.4
[*PE3-Cpos0/2/3] aps mode one2one bidirection
[*PE3-Cpos0/2/3] aps revert 1
# Configure CE2.
[~CE2] controller cpos0/2/1
[~CE2-Cpos0/2/1] undo shutdown
[*CE2-Cpos0/2/1] aps group 24
[*CE2-Cpos0/2/1] aps working
[*CE2-Cpos0/2/1] commit
[~CE2-Cpos0/2/1] quit
[~CE2-Cpos0/2/2] undo shutdown
[*CE2-Cpos0/2/2] aps group 24
[*CE2-Cpos0/2/2] aps protect
[*CE2-Cpos0/2/2] aps mode one2one bidirection
[*CE2-Cpos0/2/2] aps revert 1
2. Create a CPOS-Trunk on PE2, PE3, and CE2 and add interfaces to the CPOS-Trunk.
# Configure PE2.
[~PE2] interface Cpos-Trunk 24
[*PE2-Cpos-Trunk24] e1 24 unframed
[*PE2-Cpos-Trunk24] commit
[~PE2-Cpos-Trunk24] quit
[~PE2] controller cpos0/2/3
[~PE2-Cpos0/2/3] cpos-Trunk 24
# Configure PE3.
[~PE3] interface Cpos-Trunk 24
[*PE3-Cpos-Trunk24] e1 24 unframed
[*PE3-Cpos-Trunk24] commit
[~PE3-Cpos-Trunk24] quit
[~PE3] controller cpos0/2/3
[~PE3-Cpos0/2/3] cpos-Trunk 24
# Configure CE2.
[~CE2] interface Cpos-Trunk 24
[*CE2-Cpos-Trunk24] e1 24 unframed
[*CE2-Cpos-Trunk24] commit

[~CE2-Cpos-Trunk24] quit
[~CE2-Cpos0/2/1] cpos-Trunk 24
[~CE2-Cpos0/2/2] cpos-Trunk 24
Step 3 Configure the CPOS-Trunk interface.

1. Create Global-Mp-Group interfaces.
# Configure PE2.
[~PE2] interface Global-Mp-Group 24
[*PE2-Global-Mp-Group24] ip address 27.1.1.3 255.255.255.0
[*PE2-Global-Mp-Group24] commit
[~PE2-Global-Mp-Group24] quit
# Configure PE3.
[~PE3] interface Global-Mp-Group 24
[*PE3-Global-Mp-Group24] ip address 27.1.1.3 255.255.255.0
# Configure CE2.
[~CE2] interface Global-Mp-Group 24
[*CE2-Global-Mp-Group24] ip address 27.1.1.1 255.255.255.0
[*CE2-Global-Mp-Group24] commit
[~CE2-Global-Mp-Group24] quit
2. Add a Trunk-Serial interface to each Global-Mp-Group interface.
# Configure PE2.
[~PE2] interface Trunk-Serial 24/24:0
[~PE2-Trunk-Serial24/24:0] link-protocol ppp
[*PE2-Trunk-Serial24/24:0] ppp mp-global global-mp-group 24
# Configure PE3.
[~PE3] interface Trunk-Serial 24/24:0
[~PE3-Trunk-Serial24/24:0] link-protocol ppp
[*PE3-Trunk-Serial24/24:0] ppp mp-global global-mp-group 24
# Configure CE2.
[~CE2] interface Trunk-Serial 24/24:0
[~CE2-Trunk-Serial24/24:0] link-protocol ppp
[*CE2-Trunk-Serial24/24:0] ppp mp-global global-mp-group 24
[*CE2-Trunk-Serial24/24:0] commit
[~CE2-Trunk-Serial24/24:0] quit
Step 4 Bind static routes to the LMSP-enabled interfaces of PE2, PE3, and CE2.
# Configure PE2.
[~PE2] ip route-static 193.4.1.0 255.255.255.0 Global-Mp-Group24 27.1.1.1
NOTE
193.4.1.0 is the destination IP address, and 255.255.255.0 is the IP address mask.

# Configure PE3.
[~PE3] ip route-static 193.4.1.0 255.255.255.0 Global-Mp-Group24 27.1.1.1
NOTE
# Configure CE2.
[~CE2] ip route-static 193.4.2.0 255.255.255.0 Global-Mp-Group24 27.1.1.3
NOTE
Step 5 Configure an Interior Gateway Protocol (IGP) and import static routes on PE2, PE3, and CE2.
Intermediate System to Intermediate System (IS-IS) is used in this example.
# Configure PE1.
[~PE1] isis 1
[*PE1-isis-1] is-level level-1
[*PE1-isis-1] network-entity 1111.1111.1111.1111.00
[*PE1-isis-1] graceful-restart
[*PE1-isis-1] cost-style wide-compatible
[*PE1-isis-1] timer spf 1 1 50
[*PE1-isis-1] traffic-eng level-1-2
[*PE1-isis-1] commit
[~PE1-isis-1] quit
[~PE1] interface gigabitEthernet 0/2/1
[~PE1-GigabitEthernet0/2/1] isis enable 1
[*PE1-GigabitEthernet0/2/1] commit
[~PE1-GigabitEthernet0/2/1] quit
[~PE1] interface loopback 0
[~PE1-LoopBack0] isis enable 1
[~PE1-LoopBack0] commit
[~PE1-LoopBack0] quit
# Configure P1.
[~P1] isis 1
[*P1-isis-1] is-level level-1
[*P1-isis-1] network-entity 2222.2222.2222.2222.00
[*P1-isis-1] graceful-restart
[*P1-isis-1] cost-style wide-compatible
[*P1-isis-1] timer spf 1 1 50
[*P1-isis-1] traffic-eng level-1-2
[*P1-isis-1] commit
[~P1-isis-1] quit
[~P1] interface gigabitEthernet 0/2/1
[~P1-GigabitEthernet0/2/1] isis enable 1
[*P1-GigabitEthernet0/2/1] commit
[~P1-GigabitEthernet0/2/1] quit
[~P1] interface loopback 0
[~P1-LoopBack0] isis enable 1
[*P1-LoopBack0] commit
[~P1-LoopBack0] quit
# Configure P2.
[~P2] isis 1

[*P2-isis-1] is-level level-1

[*P2-isis-1] network-entity 3333.3333.3333.3333.00
[*P2-isis-1] graceful-restart
[*P2-isis-1] cost-style wide-compatible
[*P2-isis-1] timer spf 1 1 50
[*P2-isis-1] traffic-eng level-1-2
[*P2-isis-1] commit
[~P2-isis-1] quit
[~P2] interface loopback 0
[~P2-LoopBack0] isis enable 1
[*P2-LoopBack0] commit
[~P2-LoopBack0] quit
# Configure PE2.
[~PE2] isis 1
[*PE2-isis-1] import-route static
[~PE2-isis-1] quit
[*PE2-LoopBack0] commit
[~PE2] interface global-mp-group 24
[*PE2-Global-Mp-Group24] isis enable 1
# Configure PE3.
[~PE3] isis 1
[*PE3-isis-1] import-route static
[~PE3-isis-1] quit


[*PE3-LoopBack0] commit
[~PE3] interface global-mp-group 24
[*PE3-Global-Mp-Group24] isis enable 1
# Configure CE2.
[~CE2] isis 1
[*CE2-isis-1] import-route static
[*CE2-isis-1] is-level level-1
[*CE2-isis-1] network-entity 5555.5555.5555.5555.00
[*CE2-isis-1] graceful-restart
[*CE2-isis-1] cost-style wide-compatible
[*CE2-isis-1] timer spf 1 1 50
[*CE2-isis-1] traffic-eng level-1-2
[*CE2-isis-1] commit
[~CE2-isis-1] quit
[~CE2] interface global-mp-group 24
[*CE2-Global-Mp-Group24] isis enable 1
[*CE2-Global-Mp-Group24] commit
[~CE2-Global-Mp-Group24] quit

# Run the display aps group command on PE2, PE3, and CE2 to view the MC-LMSP
configurations.
PGP authentication string: 1234
APS protection channel is 5.5.5.5
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
24 Cpos0/2/3 5.5.5.5 NA ok ok NA idle
--------------------------------------------------------------------------------
APS Group 24: APS working channel is 4.4.4.4
PGP authentication string: 1234
Bidirection, 1:1 mode, Revert time(1 minutes)
KeepAlive Timer: 2(seconds), Hold Timer: 200(seconds)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
24 4.4.4.4 Cpos0/2/3 1 ok ok NA idle
--------------------------------------------------------------------------------
[~CE2] display aps group 24
Cpos0/2/2 protection channel
0(Inactive)
Bidirection, 1:1 mode, Revert time(1
minutes)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
24 Cpos0/2/1 Cpos0/2/2 1 ok ok NA idle
--------------------------------------------------------------------------------
# Run the display current-configuration | include route command on PE2, PE3, and CE2 to
view the configured parameters.
[~PE2] display current-configuration | include route

import-route static
ip route-static 193.4.1.0 255.255.255.0 Global-Mp-Group24 27.1.1.1
[~PE3] display current-configuration | include route
import-route static
[~CE2] display current-configuration | include route
import-route static
----End
Configuration Files
#
sysname PE1
isis 1
is-level level-1
network-entity 1111.1111.1111.1111.00
graceful-restart
cost-style wide-compatible
timer spf 1 1 50
traffic-eng level-1-2
#
interface gigabitEthernet 0/2/1
isis enable 1

isis enable 1
interface loopBack 0
ip address 1.1.1.1 32
#
return
l P1 configuration file
isis 1
is-level level-1
network-entity 2222.2222.2222.2222.00
graceful-restart
timer spf 1 1 50
#
isis enable 1

isis enable 1
#
return
l P2 configuration file
isis 1
is-level level-1
network-entity 3333.3333.3333.3333.00
graceful-restart
timer spf 1 1 50

#
isis enable 1

isis enable 1
#
return
isis 1
import-route static
is-level level-1
network-entity 4444.4444.4444.4444.00
graceful-restart
timer spf 1 1 50
#
isis enable 1

isis enable 1
interface global-mp-group 24
isis enable 1
#
undo shutdown
aps group 24
aps working 4.4.4.4 5.5.5.5
cpos-trunk 24
#
link-protocol ppp
#
interface Global-Mp-Group24
ip address 27.1.1.3 255.255.255.0
#
return
isis 1
import-route static
is-level level-1
network-entity 5555.5555.5555.5555.00
graceful-restart
timer spf 1 1 50
#
isis enable 1


isis enable 1
interface global-mp-group 24
isis enable 1
#
controller
Cpos0/2/3
undo
shutdown
aps group
24
aps protect 4.4.4.4
5.5.5.5
aps mode one2one

bidirection
aps revert
1
cpos-trunk 24
#
interface Cpos-
Trunk24
e1 24 unframed
#
interface Trunk-
Serial24/24:0
link-protocol
ppp
#
interface Global-Mp-
Group24
ip address 27.1.1.3 255.255.255.0
#
return

HUAWEI NE40E-M2 Series Universal Service Router 14 Transmission Alarm Customization and Suppression
Configuration Guide - WAN Access Configuration
14 Transmission Alarm Customization and

Suppression Configuration
About This Chapter
Transmission alarm customization and suppression can reduce the impact of transmission
alarms on network stability.
14.1 Overview of Transmission Alarm Customization and Suppression

Transmission alarm customization can control the impact of alarm signals on interface status.
Transmission alarm suppression can efficiently suppress alarm signals, which prevents
interfaces from frequently flapping.
14.2 Configuring Transmission Alarm Customization
This section describes the usage scenario, pre-configuration tasks, and data preparation for
transmission alarm customization.
14.3 Configuring a Transmission Alarm Filtering Interval
This section describes the usage scenario of the transmission alarm filtering interval, and the
pre-configuration tasks and operation procedure for configuring the transmission alarm
filtering interval. If the lifetime (interval between alarm generation and alarm clearance) of an
alarm is shorter than the transmission alarm filtering interval, the alarm is regarded as a burr
and is filtered out. Otherwise, the alarm is processed as a normal alarm.
14.4 Configuring Transmission Alarm Suppression
This section describes the usage scenario, pre-configuration tasks, and configuration
procedure for transmission alarm suppression. After a transmission alarm suppression
threshold is configured, the alarms that reach the threshold will be reported to the system.
14.5 Maintaining Transmission Alarm Customization and Suppression
14.1 Overview of Transmission Alarm Customization and

Suppression
Transmission alarm customization can control the impact of alarm signals on interface status.
Transmission alarm suppression can efficiently suppress alarm signals, which prevents
interfaces from frequently flapping.

Definition
Carrier-class networks require high reliability for IP devices. IP devices are required to
rapidly detect faults.
When the fast detection function is enabled on an interface, alarm reporting becomes faster.
This may cause the physical status of the interface to switch between Up and Down. As a
result, the network flaps frequently. Therefore, alarms must be filtered and suppressed to
prevent frequent network flapping.
Transmission alarm suppression can efficiently filter and suppress alarm signals to prevent
interfaces from frequently flapping. In addition, transmission alarm customization can control
the impact of alarms on the interface status.
Transmission alarm customization and suppression provide the following functions:
l The Transmission alarm customization function allows you to specify alarms that can
cause the physical status of an interface to change. This function helps filter out
unwanted alarms.
l The Transmission alarm suppression function allows you to suppress network flapping
by setting a series of thresholds.
Purpose
Transmission alarm customization allows you to filter unwanted alarms, and transmission
alarm suppression enables you to set thresholds on customized alarms, allowing devices to
ignore burrs generated during transmission link protection and preventing frequent network
flapping.
On a backbone network or an MAN, IP devices are connected to transmission devices,
including synchronous digital hierarchy (SDH), Synchronous Optical Network (SONET), or
Wavelength Division Multiplexing (WDM) transmission devices. When transmission devices
become faulty, IP devices will receive alarms. Then, faulty transmission devices perform link
switchovers and the alarms disappear. After an alarm is generated, a link switchover lasts 50
ms to 200 ms. In the log information on IP devices, the transmission alarms are displayed as
burrs that last 50 ms to 200 ms. These burrs will cause the interface status of IP devices to
switch frequently. IP devices will perform route calculation frequently. As a result, routes flap
frequently, affecting the performance of IP devices.
From the perspective of the entire network, IP devices are expected to ignore such burrs. That
is, IP devices must customize and suppress the alarms that are generated during transmission
device maintenance or link switchovers. This can prevent route flapping. Transmission alarm
customization can control the impact of transmission alarms on the physical status of
interfaces. Transmission alarm suppression can efficiently filter and suppress specific alarm
signals to avoid frequent interface flapping.
14.2 Configuring Transmission Alarm Customization

This section describes the usage scenario, pre-configuration tasks, and data preparation for
transmission alarm customization.
Usage Scenario
In the scenario where transmission devices are connected to IP devices, if the network is
unstable, a large number of burr alarms will be generated. As a result, the physical status of

interfaces on the transmission devices will switch between Up and Down. To enable IP
devices to ignore these burrs, configure transmission alarm customization on the IP devices.
Before configuring the transmission alarm customization function, power on the Router and
ensure that it is working properly.
For the following configuration tasks (except for the configuration verification), perform one
or more of the following configurations as required.
14.2.1 Configuring the Types of Alarms That Affect the Physical

Status of Interfaces
Transmission alarm customization can be configured on interfaces or globally.Different
interfaces support different alarm types.
Context
After alarms are generated on a transmission device, transmission alarm customization can be
used to control the impact of the physical interface status. Configure the following commands
globally or on the interface connecting to the transmission equipment.
The transmission alarm filtering interval can be configured globally or on the interface. The
global configuration takes effect on interfaces supporting the function. The relationship is as
follows:
l When the alarm customization is configured globally, if the non-default alarm
customization configuration exists on an interface, the configuration on the interface
takes effect.
l When the alarm customization is not configured on the interface, the global
configuration takes effect.
NOTE
In VS mode, the global configuration of transmission alarm customization is supported only by the
admin VS.
Procedure
l Configure transmission alarm customization globally.
a. Run system-view
b. Run transmission-alarm down { wan | pos } { auais | b1tca | b2tca | b3tca | lais |
lcd | lof | lom | lop | los | lrdi | lrei | oof | pais | pplm | prdi | prei | puneq | rdool |
rrool | sdbere | sfbere | trool } *
The alarm customization is configured on 10GE WAN interfaces and on POS
interfaces globally, which can cause interfaces to go Down.
c. Run commit

l Configure transmission alarm customization on interfaces.

a. Run system-view
b. Perform either of the following commands.
n To enter the POS interface or 10GE WAN view, run the interface interface-
type interface-number command.
n To enter the specified ATM interface view, run the interface interface-type
interface-number command.
n To enter the specified CPOS interface view, run the controller cpos cpos-
number command.
n To enter the WDM interface view, run the controller wdm controller-number
command.
n To enter the CE1 interface view, run the controller e1controller-number
command.
n To enter the E3 interface view, run the controller e3controller-number
command.
n To enter the Trunk-serial interface or serial interface view, run the interface
interface-type interface-number command.
c. Perform either of the following commands:
n To customize alarms that affect the physical status of POS or 10GE WAN
interface, run the transmission-alarm down { auais | b1tca | b2tca | b3tca |
lais | lcd | lof | lom | lop | los | lrdi | lrei | oof | pais | pplm | prdi | prei | puneq
| rdool | rrool | sdbere | sfbere | trool } * command.
n To customize alarms that affect the physical status of WDM interfaces, run the
transmission-alarm down { odu-ais | odu-lck | odu-oci | otu-ais | otu-lom |
otu-sd-ber | otu-sf-ber | pm-bdi | pm-tim | r-lof | r-los | r-oof | sm-bdi | sm-
iae | sm-tim } * command.
n To customize alarms that affect the physical status of CPOS interfaces, run the
transmission-alarm down { los | lof | oof | lais | lrdi | lrei | b1tca | b2tca |
b3tca | sdbere | sfbere | rrool | pais | auais | prdi | prei | lop | pplm | puneq |
lom } * command.
n To customize alarms that affect the physical status of ATM interfaces, run the
transmission-alarm down { los | lof | oof | lais | lrdi | lrei | b1tca | b2tca |
b3tca | sdbere | sfbere | rrool | pais | auais | prdi | prei | lop | pplm | puneq |
lom } * command.
n To customize alarms that affect the physical status of CE1 interfaces, run the
transmission-alarm down { lof | los | pais | prdi } * command.
n To customize alarms that affect the physical status of E3 interfaces, run the
transmission-alarm down { lof | los | pais | prdi } * command.
n To customize alarms that affect the physical status of Trunk-Serial or Serial
interfaces, run the transmission-alarm down { pais | prdi | oof } * command.

NOTE
l Not all interfaces support the preceding alarms because alarm types vary with hardware
types. If the alarm type that the hardware does not support is configured, the
configuration fails. The system will display a message telling you which alarm types are
not supported on this interface.
l WLNK alarms can be viewed only and cannot be configured by using this command.
The WLNK alarms are always enabled and can cause the physical status of interfaces to
go Down. The display transmission-alarm command can be used to view the status and
statistics on wlnk alarms.
By default, the LAIS, LOF, and LOS alarms can change interface status. If these
alarms are disabled, service data cannot be forwarded correctly. Enabling the three
types of alarms is recommended.
d. Run commit
----End
14.2.2 (Optional) Configuring b1tca, b2tca, b3tca, sdbere, and

sfbere Alarm Thresholds
The b1tca, b2tca, b3tca, sdbere, and sfbere alarm thresholds can be configured. When an
alarm reaches the threshold, it will be reported to the system.
Context
Perform the following steps on the interfaces that are connected to transmission devices:
Procedure
10GE WAN ,POS ,ATM interfaces support the configuration of alarm thresholds.
Or you can run controller cpos cpos-number to enter CPOS interface view.
Step 3 Run transmission-alarm threshold { b1tca b1tca | b2tca b2tca | b3tca b3tca | sdbere sdbere
| sfbere sfbere } *
The b1tca, b2tca, b3tca, sdbere, and sfbere alarm thresholds are configured.
The alarm thresholds are in the format of 10-n. "n" is specified by an alarm parameter in the
transmission-alarm threshold command. The value of sdbere must greater than or equal to
the value of sfbere.

Step 4 Run commit
----End
14.2.3 Verifying the Transmission Alarm Customization

Configuration
After configuring transmission alarm customization, verify the configuration and check the
alarm status and statistics on an interface.
Prerequisites
Transmission alarm customization has been configured.
The transmission alarm suppression function has been enabled using the transmission-alarm
damping command.
Procedure
l If an interface is a 10GE WAN interface, run the display transmission-alarm wan
interface-number [ auais | b1tca | b2tca | b3tca | lais | lcd | lof | lom | lop | los | lrdi | lrei
| oof | pais | prdi | prei | pplm| puneq | rdool | rrool | sdbere | sfbere | trool | wlnk ] *
command to check alarm configuration on the interface.
l If the interface is a WDM interface, run the display transmission-alarm wdm interface-
number [ odu-ais | odu-lck | odu-oci | otu-ais | otu-lom | otu-sd-ber | otu-sf-ber | pm-
bdi | pm-tim | r-lof | r-los | r-oof | sm-bdi | sm-iae | sm-tim ] * command to check alarm
configuration on the interface.
l If the interface is CE1, run the display transmission-alarm e1 interface-number [ los |
lof | pais | prai ] * command to check alarm configuration on the interface.
l the interface is a CPOS interface, run the display transmission-alarm cpos interface-
number [ auais | b1tca | b2tca | b3tca | lais | lof | lom | lop | los | lrdi | lrei | oof | pais |
pplm | prdi | prei | puneq | rrool | sdbere | sfbere ] *command to check alarm
l If the interface is E3, run the display transmission-alarm e3 interface-number [ los | lof
| ais | rai ] * command to check alarm configuration on the interface.
l Run the display transmission-alarm threshold [ interface-type interface-number ]
command to view the thresholds of b1tca, b2tca, b3tca, sdbere, and sfbere alarms on the
interface.
----End
14.3 Configuring a Transmission Alarm Filtering Interval

This section describes the usage scenario of the transmission alarm filtering interval, and the
pre-configuration tasks and operation procedure for configuring the transmission alarm
filtering interval. If the lifetime (interval between alarm generation and alarm clearance) of an
alarm is shorter than the transmission alarm filtering interval, the alarm is regarded as a burr
and is filtered out. Otherwise, the alarm is processed as a normal alarm.

Usage Scenario
In the scenario where transmission devices are connected to IP devices, if the network is
unstable, transmission devices on the network will generate a large number of burr alarms. As
a result, the physical status of interfaces on the transmission devices switches between Up and
Down. After a transmission alarm filtering interval is configured, the alarms whose lifetime is
longer than the interval will be ignored.
The transmission alarm filtering interval can be configured globally or on an interface. The
global configuration takes effect on interfaces supporting the function. The relationship is as
follows:
l After the global configuration, if a non-default transmission alarm filtering interval is
configured on the interface, the interval configured on the interface takes effect.
l If no transmission alarm filtering interval is configured in the interface view, the global
configuration takes effect.
NOTE
In VS mode, the global configuration of filtering function for alarm messages and a filtering interval is
supported only by the admin VS.
Before configuring the transmission alarm filtering interval, complete the following tasks:
l Power on the Router and ensure that it is working properly.
l Configure transmission alarm customization on the Router interface
NOTE
The filtering function on an interface can take effect only when the transmission alarm customization
function is enabled on the interface.
Procedure
l Enable the global filtering function for alarm messages and set a filtering interval.
a. Run system-view
b. Run transmission-alarm holdoff-timer holdoff-time
The global filtering function is enabled, and a filtering interval is configured.
c. Run transmission-alarm holdup-timer holdup-time
The global filtering function is disabled, and a filtering interval is cleared.
d. Run commit
l Configure the transmission alarm filtering interval and set filtering intervals on an
interface.
a. Run system-view
b. Perform either of the following commands.
n To enter the POS interface or 10GE WAN view, run the interface interface-
type interface-number command.

n To enter the specified CPOS interface view, run the controller cpos cpos-
number command.
n To enter the WDM interface view, run the controller wdm controller-number
command.
n To enter the CE1 interface view, run the controller e1 controller-number
command.
n To enter the E3 interface view, run the controller e3 controller-number
command.
c. Run transmission-alarm holdoff-timer holdoff-time
The alarm filtering function is enabled, and a transmission alarm filtering interval is
set.
If the lifetime (interval between alarm generation and alarm clearance) of an alarm
is less than the transmission alarm filtering interval, the alarm is filtered out as a
burr. Otherwise, the alarm is a normal alarm.
.
d. Run transmission-alarm holdup-timer holdup-time
The alarm clearance filtering function is enabled, and an alarm clearance filtering
interval is set.
e. Run commit
----End
Checking the Configurations

Run the following commands to check the configurations:
l If the interface is a CPOS interface, run the display transmission-alarm cpos interface-
number [ auais | b1tca | b2tca | b3tca | lais | lof | lom | lop | los | lrdi | lrei | oof | pais |
pplm | prdi | prei | puneq | rrool | sdbere | sfbere ] * command to check alarm
l If the interface is a WDM interface, run the display transmission-alarm wdm interface-
number [ odu-ais | odu-lck | odu-oci | otu-ais | otu-lom | otu-sd-ber | otu-sf-ber | pm-
bdi | pm-tim | r-lof | r-los | r-oof | sm-bdi | sm-iae | sm-tim ] * command to check alarm
l If the interface is a CE1 interface, run the display transmission-alarm e1 interface-
number [ los | lof | pais | prai ] * command to check alarm configuration on the
interface.
l If the interface is an E3 interface, run the display transmission-alarm e3 interface-
number [ los | lof | ais | rai ] * command to check alarm configuration on the interface.
l Run the display transmission-alarm configuration [ interface-type interface-number ]
command to and suppression on the specified interface.
If the alarm filtering function has been configured, you can view that the filtering function has
been enabled.
# Check check the configuration of alarm customization and suppression on POS 0/1/0.

14.4 Configuring Transmission Alarm Suppression

This section describes the usage scenario, pre-configuration tasks, and configuration
procedure for transmission alarm suppression. After a transmission alarm suppression
threshold is configured, the alarms that reach the threshold will be reported to the system.
Usage Scenario
In the scenario where transmission devices are connected to IP routing devices, if the network
is unstable, transmission devices on the network will generate a large number of burr alarms.
As a result, the physical status of interfaces on the transmission devices will switch between
Up and Down. To suppress frequent network flapping caused by transmission alarms, or
enable IP devices to ignore burr alarms, enable transmission alarm suppression on IP devices.
Before configuring transmission alarm suppression, complete the following tasks:
l Power on the Router and ensure that it is working properly.
l Configure transmission alarm customization on the Router interface
NOTE
Transmission alarm suppression can take effect on an interface only after transmission alarm
customization is enabled on the interface.
Procedure
Step 2 Perform either of the following configurations as required.
1. Run interface interface-type interface-number
The POS or 10GE WAN interface view is displayed.
4. Run controller e1 controller-number
5. Run controller e3 controller-number
Step 3 Run transmission-alarm damping [ ceiling ceiling | reuse reuse | suppress suppress | decay-
ok decay-ok | decay-ng decay-ng ] *
Transmission alarm suppression is enabled, and suppression parameters are set.

Step 4 Run commit
----End
Checking the Configurations

Run the following command to check the configurations:
Run the display transmission-alarm configuration command to view the transmission alarm
configuration of an interface.
# Display the configurations of transmission alarm customization and suppression on GE

0/1/0.
<HUAWEI> display transmission-alarm configuration wan 0/1/0
Interface: GigabitEthernet0/1/0
Filter function: disable
Damping function: enabled
Suppress value: 999
Ceiling value: 6000
Reuse value: 500
OK half decay value: 500
NG half decay value: 1000
# Check the configurations of transmission alarm customization and suppression on E1 0/7/0.
14.5 Maintaining Transmission Alarm Customization and

Suppression
14.5.1 Clearing the Information About Transmission Alarms
Before re-collecting information about transmission alarms on an interface, clear the existing
information about transmission alarms on the interface.
Context
After information about transmission alarms has been cleared, all statistics on alarms will be
reset. Exercise caution when running the reset transmission-alarm statistics command.
Procedure
Step 1 To clear the information about transmission alarms, run the reset transmission-alarm
statistics command in the interface view.
----End

Configuration Guide - WAN Access 15 PRBS Testing Configuration
15 PRBS Testing Configuration
About This Chapter
The Pseudo Random Binary Sequence (PRBS) testing function supports one-click tests on
user-side and network-side service connectivity.Only theNE08Esupports PRBS Testing
Configuration.
15.1 Overview of PRBS

PRBS generates random data for service connectivity testing.
15.2 Configuring PRBS Testing
This section describes how to configure user-side and network-side PRBS testing.
15.1 Overview of PRBS

PRBS generates random data for service connectivity testing.
During site deployment or device maintenance, PRBS testing can be performed when there is
no BER tester. The testing details are as follows:
l A PRBS testing-enabled local device sends a PRBS bit stream over a link to a loopback-
enabled remote device on a tested network.
l The bit stream is looped back to the local device.
l Upon receipt of the bit stream, the PRBS monitoring module on the local device checks
whether the bit stream is the same as the one previously sent and determines whether the
link or devices on the tested network are working properly.
PRBS testing includes user-side and network-side tests.
Figure 15-1 shows user-side RPBS testing.

Figure 15-1 User-side RPBS testing
Enables PRBS
testing and sends a
Enables remote PRBS bit stream.
loopback on the TX 1
base station and RX Receives the looped
loops back the back PRBS bit stream,
PRBS bit stream. 2 compares it with the
RX one previously sent,
TX 3 and calculates a bit
error rate.
MPLS/IP Core
CE PE1 PE2 RNC
After PRBS testing is enabled on PE1, PE1 sends a PRBS bit stream to the remote loopback-
enabled CE. The PRBS bit stream is then looped back to PE1. Upon receipt of the bit stream,
PE1 checks whether the bit stream is the same as the one previously sent and calculates a bit
error rate.
Figure 15-2 shows network-side RPBS testing.
Figure 15-2 Network-side RPBS testing

NMS
1
Sends a
PRBS bit
stream. Enables local 2
loopback.
PW
CE PE1 PE2 Local RNC

loopback
Calculates a bit
3 error rate.
After PRBS testing is enabled on PE1, PE1 sends a PRBS bit stream to PE2 that has local
loopback enabled. The PRBS bit stream is then looped back to PE1. Upon receipt of the bit
stream, PE1 checks whether the bit stream is the same as the one previously sent and
calculates a bit error rate.
15.2 Configuring PRBS Testing

This section describes how to configure user-side and network-side PRBS testing.

Usage Scenario
PRBS testing is used to test service connectivity between two devices. A PRBS testing-
enabled NE40E sends a PRBS bit stream to a remote device that has remote loopback enabled
to perform a user-side test or to a remote device that has local loopback enabled to perform a
network-side test. After the bit stream is looped back to NE40E, NE40E compares the bit
stream with the one it previously sent and calculates a bit error rate to determine the service
connectivity.
l Before configuring user-side PRBS, ensure that remote loopback has been enabled on
the remote device.
l Before configuring network-side PRBS, ensure that local loopback has been enabled on
the remote device.
15.2.1 (Optional) Configuring UNI-Side PRBS Testing

After PRBS testing is enabled, you can perform a one-click test to check the service
connectivity on the UNI side, that is, whether services between CE and PE are running
properly.
Context
As shown in Figure 15-3, remote loopback is enabled on a base station, and service
connectivity between PE1 and the base station is tested by enabling PE1 to send a PRBS bit
stream to the base station.
NOTE
Before performing a UNI-side PRBS test on a local device, you must configure remote loopback on the
remote interface connecting to the local device. Services on the remote interface are then interrupted. After
the test is completed, manually restore services on the remote interface.
Figure 15-3 UNI-side RPBS testing
Enables PRBS
testing and sends a
Enables remote PRBS bit stream.
loopback on the TX 1
base station and RX Receives the looped
loops back the back PRBS bit stream,
PRBS bit stream. 2 compares it with the
RX one previously sent,
TX 3 and calculates a bit
error rate.
MPLS/IP Core
CE PE1 PE2 RNC
NOTE
Both the CE and PE1 are NE40Es in this example.

Procedure
Step 1 Configure remote loopback on the E1 interface of the CE connecting to PE1.
1. Run system-view


3. Run e1 e1-number set loopback remote
Remote loopback is enabled for the E1 interface.
Step 2 Perform a PRBS test on PE1.

1. Run system-view

2. Run test connectivity interface { interface-name | interface-type interface-number }
uni-direction pattern pattern-list interval { hour hour-value | minute minute-value |
second seconde-value } interval-repeat repeat-count
An enhanced PRBS connectivity test on the user-side is started.

3. Run test connectivity error-insert interface { interface-name | interface-type interface-
number } { single-bit | insert-ratio ratio-list }
Bit errors are injected into a PRBS bit stream while the enhanced PRBS connectivity test
is going on.
4. (Optional) Run test connectivity abort interface { interface-name | interface-type
interface-number }
The enhanced PRBS connectivity test is ended.
Step 3 After the PRBS test is completed, cancel the remote loopback configuration on the E1
interface of the CE.
1. Run system-view


3. Run undo e1 e1-number set loopback
Remote loopback of the E1 interface is canceled.
----End
15.2.2 (Optional) Configuring Network-Side PRBS Testing

After PRBS testing is enabled, you can perform a one-click test to check the service
connectivity on the NNI side, that is, whether the PW between PEs is functioning properly.

Context
As shown in Figure 15-4, PW connectivity between PE1 and PE2 can be tested by enabling
PE1 to send a PRBS bit stream to PE2, which has local loopback enabled.
NOTE
Before performing a NNI-side PRBS test on a local device, you must configure local loopback on the remote
interface connecting to the local device. Services on the remote interface are then interrupted. After the test is
completed, manually restore services on the remote interface.
Figure 15-4 Network-side RPBS testing

NMS
1
Sends a
PRBS bit
stream. Enables local 2
loopback.
PW
CE PE1 PE2 Local RNC

loopback
Calculates a bit
3 error rate.
NOTE
Both the PE1 and PE2 are NE40Es in this example.
Procedure
Step 1 Configure local loopback on the E1 interface of the PE2 connecting to PE1.
1. Run system-view
3. Run e1 e1-number set loopback local
Local loopback is enabled for the E1 interface.
Step 2 Perform a PRBS test on PE1.
1. Run system-view
2. Run test connectivity interface { interface-name | interface-type interface-number }
nni-direction pattern pattern-list interval { hour hour-value | minute minute-value |
second seconde-value } interval-repeat repeat-count

An enhanced PRBS connectivity test is performed on a network-side low-speed

interface.
3. (Optional) Run test connectivity error-insert interface { interface-name | interface-
type interface-number } { single-bit | insert-ratio ratio-list }
Bit errors are injected into a PRBS bit stream while the enhanced PRBS connectivity test
is going on.
4. (Optional) Run test connectivity abort interface { interface-name | interface-type
interface-number }
The enhanced PRBS connectivity test is ended.
Step 3 After the PRBS test is completed, cancel the local loopback configuration on the E1 interface
of the PE2.
1. Run system-view
3. Run undo e1 e1-number set loopback
Local loopback of the E1 interface is canceled.
----End
15.2.3 Verifying the PRBS Testing Configuration

After configuring PRBS testing, verify the configuration.
Procedure
l Run the display connectivity-test history interface { interface-name | interface-type
interface-number } [ index index-value ] command to view the results of PRBS test
instances on a specified interface.
l Run the display connectivity-test history command to view PRBS historical test
instances.
----End
15.2.4 Example for Configuring a PRBS Test

This section provides an example on how to configure a PRBS test to check device
connectivity when two devices are connected to each other through E1 interfaces.
On the network shown in Figure 15-5, Device A and Device B connect to each other through
E1 interfaces. A PRBS test needs to be performed to check the connectivity between the two
devices.
Figure 15-5 Networking diagram for configuring a PRBS test

NOTE
In this example, interface1 and interface2 represent E1 0/1/0 and E1 0/2/0, respectively.

Send a PRBS bit

stream on Device A.
1 TX RX Enables remote loopback on
the Device B and loops
Receives the looped
back the PRBS bit stream.
back PRBS bit 2
stream, compares it
RX
with the one 3 TX
previously sent, and
calculates a bit error interface1 interface2
rate.
DeviceA DeviceB
1. Create a synchronous serial interface on Device A and Device B.
2. Configure remote loopback on the E1 interface of Device B.
3. Perform a PRBS test on Device A.
4. Check the PRBS test result on Device A.
5. After the PRBS test is completed, cancel the remote loopback configuration on the E1
interface of Device B.
Data Preparation
l E1 interface number of Device A
l E1 interface number of Device B
Procedure
Step 1 Create a synchronous serial interface on Device A and Device B.
# Configure the E1 interface on Device A as a synchronous serial interface.
[*HUAWEI] commit
# Configure the E1 interface on Device B as a synchronous serial interface.

[*HUAWEI] commit
Step 2 Configure remote loopback on the E1 interface of Device B.

[~DeviceB-E1 0/2/0] loopback remote


Step 3 Perform a PRBS test on Device A.

[~DeviceA-Serial0/1/0:1] link-protocol tdm
[~DeviceA] test connectivity interface Serial0/1/0:1 uni-direction pattern prbs15
interval second 20 interval-repeat 5
Step 4 Check the PRBS test result on Device A.

[~DeviceA] display connectivity-test interface serial 0/1/0:1
Summary:
Start time Side Pattern Phy-port Total time (Interval*Round)
2018-08-10 16:12:46 UNI PRBS15 E1 0/1/0 00:01:40 (20s*5)
Total bits Error bits BER LOS Test progress
198400000 0 0e-0 0s 100%(00:01:40)finished
Details:
Round Total bits Error bits BER LOS ES EFS SES UAS
1 39680000 0 0e-0 0s 0s 20s 0s 0s
2 39680000 0 0e-0 0s 0s 20s 0s 0s
3 39680000 0 0e-0 0s 0s 20s 0s 0s
4 39680000 0 0e-0 0s 0s 20s 0s 0s
5 39680000 0 0e-0 0s 0s 20s 0s 0s
Error Bits Insert Record (Latest 10):
Start time Type BER Duration Insert in round
Step 5 After the PRBS test is completed, cancel the remote loopback configuration on the E1
interface of Device B.
[~DeviceB-E1 0/2/0] undo loopback
----End
Configuration Files
#
sysname DeviceA
#
controller E1 0/1/0
#
link-protocol tdm
#
test connectivity interface Serial0/1/0:1 uni-direction pattern prbs15
interval second 20 interval-repeat 5
#
return

#
sysname DeviceB
#
controller E1 0/2/0
#
controller E1 0/2/0
loopback remote
#
controller E1 0/2/0
undo loopback

#
return

NE40E-M2H and NE40E-M2K V800R011C00 Configuration Guide - WAN Access 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NE40E-M2H and NE40E-M2K V800R011C00 Configuration Guide - WAN Access 01

Uploaded by

Copyright:

Available Formats

HUAWEI NE40E-M2 Series Universal Service

Configuration Guide - WAN Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. i

1 About This Document.................................................................................................................. 1

3 POS Interface Configuration.....................................................................................................10

4 E-Carrier Interface Configuration............................................................................................ 28

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. ii

4.2.2 Configuring the Clock Mode for a CE1 Interface..................................................................................................... 32

5 CPOS Interface Configuration..................................................................................................44

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. iii

5.5.2 Example for Configuring CPOS Interface Interconnection.......................................................................................70

7 HDLC and IP-Trunk Configurations.......................................................................................87

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. iv

8.2.5 (Optional) Configuring the PPP Link Dampening Function................................................................................... 116

9 TDM Configuration.................................................................................................................. 144

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. v

10 WDM Interface Configuration..............................................................................................181

11 ATM IMA Configuration.......................................................................................................190

12 ATM Configuration................................................................................................................ 199

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. vi

12.5.2 (Optional) Activating the CC Function................................................................................................................. 214

14 Transmission Alarm Customization and Suppression Configuration......................... 267

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. vii

14.5 Maintaining Transmission Alarm Customization and Suppression......................................................................... 276

15 PRBS Testing Configuration................................................................................................. 277

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. viii

1 About This Document

Product Name Version

NE40E-M2 Series V800R011C00

l Data configuration engineers

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 1

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 2

l In this document, public IP addresses may be used in feature introduction and

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 3

[ x | y | ... ]* Optional items are grouped in brackets and separated by

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 4

2 Serial Interface Configuration

About This Chapter

Serial interfaces are classified as synchronous or asynchronous serial interfaces. Synchronous

2.1 Overview of Serial Interfaces

2.1 Overview of Serial Interfaces

The serial interfaces formed by channelized E-carrier or channelized packet over

Serial Interfaces Types

Synchronous serial interfaces channelized by physical interfaces support configurations of

Issue 01 (2019-04-15) Copyright © Huawei Technologies Co., Ltd. 5

Table 2-1 Naming conventions for serial interfaces

Physical Interface Naming Convention

CE1 serial controller-number:set-number or serial controller-number:0